Gamepads making involuntary movements in Emulation Station
-
@brunnis thanks!
IMO this could still potentially be fixed by the software. games themselves are probably immune to this kind of interference - if you tap a direction for a less than a frame it's probably not going to have a gameplay effect. i half suspect that consoles games/BIOS would ignore these kind of inhuman inputs anyway, rather than rely on zero electrical interference.
i think it would be feasible to make emulationstation ignore these kind of inputs and that would 'solve' the problem, but like you - i have no time :)
-
Thanks for the updates, guys. This problem is still bothering me quite badly. Do you think it's a legitimate reason to return the controllers to Amazon and get a refund? I wonder if they'd accept the reason, I mean. But it really does suck :/
-
Yes, this is a legitimate reason for return. The hardware is defective and it's easy to prove by connecting the controller to Windows and viewing the d-pad "vibrations" in the Game Controllers dialog. You might want to wait with returning them for another week though (see info below).
Yeah, it may be possible to make a software work-around, but I'm a bit sceptical about "fixing" flaky hardware with such work-arounds unless absolutely necessary.
Anyway, I may have a hardware fix coming up! I opened up my flaky controller and inspected it. Turns out that there actually is several decoupling caps and ferrite beads to filter the 5V power. Still, I started messing around with a 10µF capacitor I had laying around, applying it between the 5V power and ground at different places on the PCB while the controller was connected to my laptop. I used the Game Controllers dialog to see if the d-pad phantom movements changed with the extra decoupling.
After som experimentation, I eventually found out that applying the capacitor in parallel with the existing 4.7µF capacitor close to the microcontroller's power input made the phantom movements seemingly stop. You can see my temporary setup below, where I've just let the 10µF cap squeeze onto the existing 4.7µF one.
I connected this setup to my RPi3 running RetroPie. The result?
Without the extra cap: Phantom d-pad inputs every ~2 minutes on average.
With the extra cap: 1-2 phantom inputs per hour.
So, this more or less seems to have fixed the issue. I will, however, try to fix it completely. I have ordered high quality capacitors rated for 16V to experiment with. I believe the existing capacitor is some crappy chinese one and it's rated for 50V, which isn't optimal when the supply voltage is just 5V. Apparently, using capacitors with voltage rated this much over the operating voltage can cause excessive ripple and lower than expected/rated capacitance.
-
@brunnis The max voltage of the capacitor shouldn't make a difference. By putting it in parallel with the existing capacitor, you increase the overall capacitance, thus filtered out more noise. You might want to try using a larger capacitor value or add ANOTHER 10µF in parallel to test.
-
@pussyfoot Yes, in this testcase it's the extra capacitance that makes it work. However, using a better matched 4.7µF capacitor in the first place may have at least reduced the issue. The combination of a possibly over-specced chinese cap that's running at just 10% of max voltage might give an actual capacitance far lower than the 4.7µF the circuit designer expected.
Anyways, I'll be replacing the existing 4.7µF 50V no-name cap with a Nichicon 10µF 16V one. If that doesn't sove it, I'll try a Nichicon 22µF 16V instead.
-
Well it sounds as though you chaps are moving in for the kill on this problem, but I'll put in my two pennies worth just to corroborate what some users have said...
I'd also picked up a couple of iBuffalo Classic USB Gamepad's to use with my old Raspberry Pi 2. Like many of you I started getting ghost / phantom / involuntary D-pad movements right out of the box. I only really noticed it on menu screens and the like, not in-game... that was until I got around to playing some classic arcade Frogger and realised that it very much depends on the type of game you're playing as to how noticeable the problem is.
A quick search led me to your thread and to some users recommending trying a powered USB hub. I had an old StarTech.com 7 Port USB 2.0 Hub upstairs, so I dug it out and gave it a go without plugging in the bundled AC power adapter and left it for a couple of hours - and I didn't get any ghost / phantom / involuntary D-pad movements at all!
I suppose there are too many hardware and software variables for me to say that this will work for everyone here but if you do have any old powered or unpowered USB hubs lying around then you might be able to get a cheap and easy quick-fix out of trying them.
Many thanks to all the users who suggested this solution and good luck to all those deep-diving this problem. "Many frogs died to bring you this information."
-
Hey, I skimmed the thread, so I might have missed it, but I would like to know if this issue only occurs on axes that are registered as analog?
We might want to look at the "dead space" that EmulationStation allows for.I'm afraid it will not save any frogs though...
-
@zigurana In my case, yes, it's only the d-pad. That's also the only kind of phantom button press I've read about on these Buffalo SNES replicas.
-
I was triggered by this
It's also interesting that the D-pad on the Buffalo controller actually appears to present itself as an analog stick. If this was a purely on/off digital button like the others, we probably wouldn't have this issue.
It looks like ES will interpret any controller as a joystick, with analog axis (independent of the hw). Now, if the HW is a pair of buttons (one axis of a dpad), it should report either 0, or +32k or -32k.
ES will react on inputs on the axis which are larger than DEADZONE (defined as 23000, so 70%), which already is very wide for a deadzone, if you would want to use it for anything else than binary inputs.But if the hardware is iffy, and de controllers's output is kind of dirty, then it might send signals even larger than this.
-
Hi all
Can any one help.
I I'm building an arcade unit in fact just finished it, I'm using Suso happy controllers and arcade buttons, they go through a zero delay pcb and I'm getting this ghost inputs it's driving me mad , can any one help.
Thanks
-
Would setting a controller, like the PS4 Dualshock, to only use bluetooth, resolve this issue?
-
I can confirm that iBuffalo sends phantom signals that are not related to the turbo/auto functions. It even happened on my HyperSpin (PC) setup.
They're excellent controllers, the plastics, the feedback, everything is great about them but I can't forgive the random momental inputs.
Use something by innext or the CirKa premium SNES USB controller. I have both without any problems whatsoever.
-
@matchaman Yup, I also have a couple of Cirka S91 USB controllers that have no such ghosting issues (despite the d-pad being detected as an analog x/y axis). Unfortunately, the Cirka is not really close to the feel of the Buffalo. The Cirka's d-pad is kind of squeaky and the a/b/x/y buttons have a nasty hollow click to them and too long travel. The Cirka is decent compared to pretty much all other SNES replicas, but compared to the Buffalo and 8bitdo it's lacking.
I'm still looking into fixing the Buffalo, but I'm sort of fumbling in the dark without an oscilloscope. I have almost managed to stabilize the controller by replacing the two 4.7µF barrel caps with 22µF ones, but I have few stray ghost inputs left (~1 per hour, maybe less). I'm running a test now with an additional 4.7µF cap connected between the chip and the last ferrite bead. There is already one cap there, but it's a small SMD one.
The root cause is still eluding me (why does one controller need larger caps to work than another?), but my best guess right now is that tolerances in other components and/or the microcontroller itself means the difference between stable and unstable operation. The solder job is not exactly stellar, but at least it seems all components make contact with their pads.
-
Okay, so something strange happened last night.
I watched a three hour movie in Kodi with my iBuffalo controller still plugged in the whole time.
It was about an 8 GB ripped DVD movie that I have stored on my computer, so I was streaming this film.
During the entire movie, there wasn't one single phantom signal that either did a fast forward or a rewind while watching it.
Normally, that would occur about once every 5 to 10 minutes or so.
So for three straight hours, something must be different.
I thought for a moment, and the only thing that I changed was I removed a 32 GB micro SDHC card from the Pi earlier.
Usually, I always have that in one of the USB ports.
Could using more than just one USB port at a time be a cause for these ghost signals?
-
Okay, so below is my attempt at fixing the phantom input (ghosting) on the iBuffalo/Buffalo SNES replica controllers. I've let RetroPie sit in the ES menu since yesterday (16 hours) and the menu selection is still where I left it. It's of course possible that it has moved away and then back to the starting position between checks, but I have checked the screen pretty frequently during these 16 hours and haven't seen any changes.
Please note: YMMV. This phantom input issue probably varies in severity between controllers. My controller was pretty severe and it now seems to be fixed, but there's still no guarantee that it will remove all phantom inputs on all controllers.
The fix consists of replacing the two 4.7µF through-hole mounted electrolytic capacitors that are visible from the PCB back side with 22µF ones. I've also added an extra 10µF electrolytic capacitor close to the microcontroller input. I've used the following caps:
Nichicon UMA1C220MDD1TP (22µF, 16V)
Nichicon UMA1C100MDD1TP (10µF, 16V)The photos below show the three caps installed on the PCB:
Please note: It's possible that other cap values or setups (for example omitting the extra cap that was added and beefing up the other one) would work. I didn't have time to go crazy with the details/testing. This is what worked for me and probably will for you as well, but feel free to experiment.
It would be great to hear back from anyone else who tries this. If the procedure looks daunting, I'd just start with adding a 22µF cap in parallel with the left one in the first photo above (the one marked C13). That way, you don't have to remove the old cap and it's possible that this is enough to fix the issue on your particular controller.
-
@addison said in Gamepads making involuntary movements in Emulation Station:
Could using more than just one USB port at a time be a cause for these ghost signals?
Yes, that's certainly possible. The issue seems to be caused by the controller's inability to suppress noise on the voltage supply line. Adding more USB peripherals could affect the noise level on the supply line, therefore changing the behavior.
-
@brunnis The USB adapter thingy that I use with the SDHC card has a red light indicator.
When in use, it stays red, when sending or receiving data, it begins to flash the red light off and on.
I'm guessing that this might possibly cause some instability with my Pi.
I was really happy though when it finally went three plus hours without a single improper input signal.
That had never happened before until yesterday.
-
@brunnis Excellent work! Here's a tip for anyone else attempting this: Instead of desoldering the original capacitors, cut the heads off at the top of the capacitors so the existing leads remain. Trim the leads to the new capacitors and solder the new cap's leads to the existing ones poking out of the board. I suggest taking a picture of the board with the original capacitors BEFORE you start. Why? You may forget how the polarity went. Electrolytic capacitors have a positive and negative side.
-
@Pussyfoot Thanks!
Please see further updates in my Reddit post: https://www.reddit.com/r/emulation/comments/7g2d0n/howto_fix_phantomghost_input_on_ibuffalobuffalo/
-
@megafacehead said in Gamepads making involuntary movements in Emulation Station:
To get around the problem i've been using the mayflash wii u pro controller wireless dongle.Google it.Simply sync your pro controller to the dongle, then the dongle tells the pi the wii u pro controller is actually a wireless xbox 360 controller and is detected as such in es when assigning buttons and i can say with 100% certainty there is no ghost input while using this adaptor.
Thanks for the hint. I already owned the Mayflash Wii U Pro adapter, but used it only with my PC that has no bluetooth itself. I never tried it with my Raspi.
The adapter seems to have fixed the ghost inputs from my two Qumox Wii U Pro controllers. I'll have to test them for longer periods to tell for sure, but first tests look promising.
Contributions to the project are always appreciated, so if you would like to support us with a donation you can do so here.
Hosting provided by Mythic-Beasts. See the Hosting Information page for more information.