Gamepads making involuntary movements in Emulation Station

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.

Addison

@brunnis Can you test again with at least a secondary controller plugged in, perhaps a USB memory card as well, and whatever else you can think of to shove into those three other ports?

I get that your solution fairs quite well.

I'm just asking if it can still handle it all with other junk in the USB ports.

Brunnis

@addison I won't have access to the system over the weekend, but I did already have a SanDisk Extreme 64GB high performance USB thumb drive connected for an hour or two and that didn't produce any issues. Neither did having a keyboard connected. I'll see if I can shove some more stuff into the ports on Monday.

Brunnis

@addison 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"). Unfortunately, this did provoke a few phantom presses. Nothing huge; two phantom presses over four hours.

I guess the conclusion is that this fix will dratically reduce the risk of phantom presses. However, the combination of a fairly unstable controller and a USB port that provides noisy power can still produce occasional phantom presses. I should point out that I'm using the official power supply for my Pi, so it's not some no-name crappy one. However, since this phantom press issue seems to be very much tied to the quality of the USB power, even just changing to another RPi board could provide different results. This also makes it tricky to verify that a fix is 100% effective.

Although I would have liked for this fix to have completely eliminated the issue, I'm still glad it works as well as it does. I don't doubt that a more elaborate investigation (using an oscilloscope) could provide a better fix (probably involving adding smaller caps as well), but I won't spend any more time on it.

stoo

Just in case anyone is wondering, this issue is not solved between board revisions on the Buffalo controllers. I have both a BSGP801GY and a BGSP815GY. The 815 has packaging that advertises Windows 10 compatibility, the 801 is an older one from the Windows 8 era. There are differences, specifically the 815 has 33Ω resistors at R11 and R12 which are unpopulated on the 801.

I don't know why they added these resistors (or omitted them in the 801) but the phantom issue remains in the newer revision. Within a few minutes of plugging in the 815 I got this in jstest:

Event: type 2, time 7408630, number 0, value -32767
Event: type 2, time 7408640, number 0, value 0
Event: type 2, time 7835420, number 1, value 16552
Event: type 2, time 7835430, number 1, value 0

That's a "full" left and a "half" down on the D-PAD.

I may try replacing the caps to see if it makes any difference, but in my mind the Buffalo controllers simply cannot be trusted to perform correctly. I'd kinda like to know what chip they're using but I cba scraping the epoxy off to find out.

stoo

Interestingly, the hardware ID of the Buffalo controller is HID\VID_0583&PID_2060&REV_0100.

VendorID 0x583 is a company called Rockfire, which leads us to...

https://rockfire.com.tw/en/products/pc-gameing/gamepad/51-qf-109u-mjolnir.html

So the controller is a rebadge of a Taiwanese controller, which is hardly a surprise.

jonnykesh

@stoo So, are the older ones just rebranded Rockfire or is this a recent thing? I can't check mine as it died a few months ago.

stoo

@jonnykesh Both the iBuffalo 801 and the Buffalo 815 have identical hardware IDs. It's almost certainly the same chip in both of them. I'm guessing Buffalo saw a gap in the Japanese market, went out and found an existing manufacturer who made SNES-type controllers of good-enough quality and said "Just put Buffalo on these and we'll sell them under our brand".