Gamepads making involuntary movements in Emulation Station

Pussyfoot

Okay, I just noticed an up movement. I wouldn't have detected that had I not been in kodi. I still get movements even with all the capacitors.

Brunnis

@pussyfoot I noticed a similar thing now as well. I was testing the most unstable of my controllers after having applied the fix. I had actually run a 16 hour test on this one before, but I thought I’d do a 24 hour one like I’m doing on the others. Turns out it still seems to generate a phantom press on average every 8 hours or so. It’s an enormous improvement compared to before the fix (phantom presses every few minutes), but obviously a bummer that it doesn’t completely fix all controllers. It does seem to completely have fixed another one of my more stable controllers, though.

I took apart this controller again tonight and installed the missing cap at the input and also resoldered all components in the power supply path. Running a new test over the weekend. If that doesn’t completely solve the issue, I will just use the controllers anyway. A phantom press every 8 hours isn’t much of an issue.

Brunnis

Good news! As I wrote in my last post, I made another attempt at fully stabilizing this controller: I populated the position marked as C41 with a 22µF cap. This position is unpopulated out of the box (which is because the manufacturer has deemed it unnecessary).

I also resoldered the SMD components in the power supply path (both 5V and 2.5V) by quickly dipping the soldering iron on each side of the components, melting the solder. This has to be done very quickly, or you risk damaging the component or desoldering it completely.

The result: I left RetroPie sitting in the ES menu on Friday afternoon and when I came back today it was still in the same place. That's 69 hours without any phantom presses! Well, I guess there's a very minute risk of it having moved and gone back to the same place, but it's significantly more likely that it just hasn't moved.

So, for anyone still having issues after applying the fix in the original post, I'd suggest first adding the 22µF cap at position C41. If that doesn't work, perform the mentioned resolder.

EDIT: I'll be back with final test results of all controllers later this week.

Rion

@brunnis Why don't you test out the controller in the command line using jstest? As long as you ssh client don't disconnect you could clearly see if there are any movements at all.

By the way great job finding out what seems to be the root of the problem!

Clyde

@rion said in Gamepads making involuntary movements in Emulation Station:

@brunnis Why don't you test out the controller in the command line using jstest? As long as you ssh client don't disconnect you could clearly see if there are any movements at all.

Another idea: Stream the input from /dev/js0 (or whatever js device the controller is mapped to) into a file. If the file gets bigger, ghost inputs occurred.

cat /dev/js0 >ghosttest.txt

edit: Alternatively, omit the >ghosttest.txt and watch the screen for funny characters to appear.

Pussyfoot

I just added the capacitor and left it on Kodi settings on the skin setting. If it moves any direction, I'll know.

Pussyfoot

@rion I'm trying out

jstest --event /dev/input/js0

in a Putty window.

Pussyfoot

I haven't had a chance to look at the display, but I'm getting some output from jtest:

Event: type 2, time 397626870, number 0, value 5742
Event: type 2, time 397626880, number 0, value 0
Event: type 2, time 397758600, number 1, value -32767
Event: type 2, time 397758600, number 1, value 0
Event: type 2, time 401954150, number 0, value -5406
Event: type 2, time 401954160, number 0, value 0
Event: type 2, time 402109800, number 1, value 337
Event: type 2, time 402109810, number 1, value 0
Event: type 2, time 402480700, number 1, value 16552
Event: type 2, time 402480710, number 1, value 0
Event: type 2, time 403222120, number 1, value 337
Event: type 2, time 403222130, number 1, value 0
Event: type 2, time 403485030, number 0, value -16216
Event: type 2, time 403485030, number 0, value 0
Event: type 2, time 404585240, number 0, value -5406
Event: type 2, time 404585250, number 0, value 0
Event: type 2, time 404633300, number 1, value -16216
Event: type 2, time 404633310, number 1, value 0
Event: type 2, time 406905280, number 0, value 337
Event: type 2, time 406905290, number 0, value 0
Event: type 2, time 409262200, number 0, value -5406
Event: type 2, time 409262210, number 0, value 0
Event: type 2, time 410590300, number 1, value -32767
Event: type 2, time 410590310, number 1, value 0
Event: type 2, time 411523080, number 1, value 16552
Event: type 2, time 411523090, number 1, value 0

This looks like analog, yes?

EDIT: I don't see any movement. Unless there was movement, but it ended up back in the same exact spot, I'm going to assume that so far, the controller is working.

Brunnis

Don't know why I didn't use jstest before... I'm running it now. The controller I'm running on has already been connected to the Pi for 44 hours without any button presses (that I've been able to detect in the menu, at least). I'm running jstest through SSH in Cygwin, in parallel with EmulationStation, so I'll be able to observe if any phantom presses registered by jstest show up in ES.

@Pussyfoot It does look like you've received a couple of full presses (-32767), so I would expect those to have produced a visible effect...

Pussyfoot

@brunnis I know, but the the selection in Kodi was on the same exact spot as I left it. Maybe it's true that it moved off and moved back. I still have it up, so I'll check it later today.

jonnykesh

@pussyfoot Both of those full inputs were UP presses on the D-Pad.

#UP
Event: type 2, time 12916484, number 1, value -32767
Event: type 2, time 12916556, number 1, value 0

#DOWN
Event: type 2, time 12917476, number 1, value 32767
Event: type 2, time 12917580, number 1, value 0

#LEFT
Event: type 2, time 12918228, number 0, value -32767
Event: type 2, time 12918380, number 0, value 0

#RIGHT
Event: type 2, time 12919188, number 0, value 32767
Event: type 2, time 12919268, number 0, value 0

Pussyfoot

@jonnykesh I just checked again after leaving it another 24 hours on the same screen. There were no movements in any direction. The addition of the missing capacitor fixed the problem for me regardless what jstest is dumping.

Brunnis

@pussyfoot That's good to hear!

I've been running jstest since yesterday (20 hours now) on the sample that originally had the most phantom presses. Still zero button presses registered.

Pussyfoot

@brunnis It's been over 48 hours without a peep. To anyone reading this thread, try the missing capacitor first.

Rion

@Brunnis @pussyfoot

I wonder what the difference will be if you use Capacitors with a tolerance level of 10% instead of 20%?

Brunnis

@Rion Probably none. It mainly seems that additional capacitance is needed and not an exact value.

@Pussyfoot I should mention that before I started modding my controllers, I tried applying a single capacitor at different places while looking for changes in the jittery d-pad movements in Windows' Game Controllers dialog. Just applying the missing cap at position C41 only had a smaller stabilizing effect. The same goes for adding the one closest to the input. It was the cap at C13 that really made a difference. It seems all my controllers are now stable (still undergoing final testing, though), but if I still had issues, the thing I'd really like to try is to increase the capacitance of capacitor C13 further. It's certainly possible that it's just the extra capacitance of the other caps that give the additional stabilizing effect, so a single 47µF cap at C13 might actually be enough.

Zigurana

You guys have been focusing a lot on adding capacitors at specific places, but did you consider using a ferrous bead around the lead?

Brunnis

@zigurana I did, actually. I searched around at home and at work for one but didn't find any. When I found out that the caps made such a difference, I focused on that instead. But I would definitely have liked to try with a bead.

Addison

@brunnis Heya. Quick question for you.....

How many USB ports are you using on your Pi when testing this?

Brunnis

@addison Just the one for the controller. Out of all the USB ports on my Dell laptop and HP screen, the Pi's is still the most likely to cause phantom presses. So USB power supply might not be where the Pi 3 excels...

I guess its possible that the phantom issue could reappear once you start loading the other ports. However, if that's the case, I'd be more inclined to just conclude that the Pi 3 itself needs better USB power supply/filtering.