I guess the conclusion is that this fix will dratically reduce the risk of phantom presses. Nothing huge two phantom presses over four hours. Unfortunately, this did provoke a few phantom presses. As a last step, I took the controller that was most unstable before the fix and connected it to my RPi3 together with a mechanical USB HDD (Western Digital 2.5"). However, to make one of them stable, I added an additional 22♟ cap at position C41.Īll of those tests were done with just one controller attached to the USB ports of my Pi. I did all my tests on my Raspberry Pi 3 and each of the four controllers survived at least 72 hours of testing without producing any phantom presses. It’s possible the extra capacitance (in addition to the 22♟) was what was really needed… It did make a difference, but I didn’t attempt to add the same cap before the bead instead. By adding this cap, the cap can supply the input pin directly.
The reason I added the extra 10♟ cap after the bead is that the bead could throttle any rapid current changes and cause dips in the voltage. I’d really like to know if the issue is caused by unstable voltage supply from the host (coupled with too tight margins in the controller) or if it’s the controller itself that causes the dips in voltage because of high current draw. All my controllers are now modded, but it would have been interesting to measure the current draw on a really unstable sample. Unfortunately, I have no easy way of measuring the USB current draw. Yeah, I’ve thought about those things as well. my guess is the controller is probably drawing too much current from the usb(usb 2.0 mode is 500ma max) or it needs a bit higher voltage than typical 5v usb port has(probably 5.1-5.3 volt needed?) if you have a device that can measure voltage and current that can be connected in between the usb cable and usb port, do that and check. The rest of the caps( is that a zero ohm resistor on the the added cap?) makes me think this is indeed a power issue.
0 kommentar(er)
