Gamepads making involuntary movements in Emulation Station
-
Running into this issue as well, using the onboard bluetooth and Wii U Pro (knockoff) controllers as well as PS4 controllers and I get random ghost inputs, games start on their own, menus change, etc simply when the controller is powered on and sitting on my desk. I'm going to order a usb bluetooth dongle and bypass the onboard bluetooth to see if that helps and I will report back.
-
This is not a wireless vs wired problem. The buffalo (and many other wired controllers if you search the interwebs) suffer from this. I am thinking it's an emulation station issue.
I am really surprised that I haven't found any evidence of anyone getting a trace of the USB events during these phantom presses. When I get back to my RPI3, I can investigate, but a couple of ideas..
- use USB_MON and dump all events
- use FUNCTION_TRACE to check the EVENT rings
- Use a USB analyzer to see if any phantom events are sent (I have a couple of expensive analyzers at work I could use to do this)
Also, some folks have speculated that
- Only people with Video thumbnails are affected? This seems unlikely, but worth a shot...I know I have video previews and I also have this issue
- Deleting the controller config appears to help some folks and rebuilding from scratch
- Using a powered USB hub kinda sorta fixes it...but this can only be true if we are getting true USB packets from these 'PHANTOM' inputs
-
Yesterday I disabled the onboard Bluetooth and installed a USB Bluetooth dongle in my unit. I haven't had a single ghost input since then. I will report back if things change. I went with this dongle for $14.
https://www.amazon.com/gp/product/B009ZIILLI/ref=oh_aui_detailpage_o01_s00?ie=UTF8&psc=1
-
@adawalli said in Gamepads making involuntary movements in Emulation Station:
This is not a wireless vs wired problem. The buffalo (and many other wired controllers if you search the interwebs) suffer from this. I am thinking it's an emulation station issue.
I am really surprised that I haven't found any evidence of anyone getting a trace of the USB events during these phantom presses. When I get back to my RPI3, I can investigate, but a couple of ideas..
- use USB_MON and dump all events
- use FUNCTION_TRACE to check the EVENT rings
- Use a USB analyzer to see if any phantom events are sent (I have a couple of expensive analyzers at work I could use to do this)
people have used jstest to see the ghosts happening. and similar tests in window. it's a hardware issue. most games/interfaces probably ignore single input frames, which ES probably should be changed to do.
Also, some folks have speculated that
- Only people with Video thumbnails are affected? This seems unlikely, but worth a shot...I know I have video previews and I also have this issue
- Deleting the controller config appears to help some folks and rebuilding from scratch
- Using a powered USB hub kinda sorta fixes it...but this can only be true if we are getting true USB packets from these 'PHANTOM' inputs
only the last is potentially viable (it worked for me), and my working theory is that it reduces/stops whatever electrical interference is happening when directly connected, at least in my setup.
-
Jeez... I also just got myself a Pi and a Buffalo gamepad and am having this same issue. As others have said, would it be feasible to change the software to not accept button presses that measure in very small input times? Is anyone able to measure exactly how long these phantom button presses are? We gotta figure out how to fix this!
-
Well, this explains my Kodi issue. I've never had an issue while playing games.
-
Well, I have this issue big time. Bought 2 Buffalo controllers. Didn't know of this problem when I bought them, or obviously I wouldn't have. Both ghost heavily in EmuStation, but I rarely see ghosting in game. Damnit. What makes it extra frustrating is that I bought one of them as a present for a friend.
If anyone has figured out a fix, please let me know. I don't suppose disabling Blutooth does anything?
I've been pressing the 'clear' button together with the ghosty buttons like no tomorrow, but to no avail. I've also tried deleting the controller config file, thereby resetting the inputs. Also doesn't work. Tried different USB ports--nope.
Some people say it's a hardware issue, but I think it's not so simple. These controllers don't malfunction in other setups. My guess would be that these controllers are exceptionally prone to these sorts of problems, and that, at the same time, Retropie/EmuStation is promoting of them as well.
My PS3 controller (Bluetooth) and two crappy PiHut controllers have no ghosting issues whatsoever. Ofc the Buffalos, which I think are amazing, have the issue :/
-
@dankcushions said in Gamepads making involuntary movements in Emulation Station:
with my ibuffalo pads i "fixed" this issue by connecting them via a powered usb hub. i think for them specifically the issue is caused by electrical inteference or something like that.
I just now caught this response.
Could you kindly post a link on where to purchase these powered usb hub thingies?
-
I also have issues with my Dual shock 4 controller. When I scroll through a games list , the controller keeps scrolling on it's own every time the system lags for a little bit. I remedied this for the most part by reducing the size of some of my custom boxart images. Before I did this, I could hardly choose a game because of all the automatic scrolling.
I have similar issues in the N64 emulator. When I use select + L1 to load a save state, I keep strafing to the left, because the emulator still thinks I am holding the L1 button. -
@addison said in Gamepads making involuntary movements in Emulation Station:
@dankcushions said in Gamepads making involuntary movements in Emulation Station:
with my ibuffalo pads i "fixed" this issue by connecting them via a powered usb hub. i think for them specifically the issue is caused by electrical inteference or something like that.
I just now caught this response.
Could you kindly post a link on where to purchase these powered usb hub thingies?
this is the one i have: https://www.amazon.co.uk/Belkin-Ultra-Powered-Power-Supply/dp/B0061RSACG
i can't g'tee it will solve the issue for everyone, though. if my theory is correct, there will be many factors at play. that said, it is good to have a powered hub with a raspberry pi anyway - more ports and doesn't sap power away from the board.
-
just to report I'm also having this with a WiiU Pro Controller. Another 8bitdo NES30 is fine, no ghosts.
The WiiU one has lots of them, several per minute. Odd. -
I just got two Buffalo SNES controllers. I quickly noticed that one appears to have ghost/phantom inputs and the other doesn't. I've tested both controllers on RetroPie (RPi 3) and my Dell laptop running Windows + RetroArch. Same issue.
I noticed that my controller didn't appear to "press" any other buttons than the directional ones. So, I opened up Windows' Game Controllers dialog to check if I could spot any issues. Lo and behold, on the controller with the phantom input issue, the little marker in the X/Y axis box sort of vibrates, with miniscule X/Y inputs occuring all the time.
When I did the same test with the controller that appears to be fine, no such small phantom inputs could be seen. The little marker stays put in the middle of the X/Y axis box.
I now tried different USB ports on my laptop. Turns out there's noticeably less movement occuring on one of the other ports. I also tried connecting the controller to my monitor's built-in USB hub. No more phantom inputs!
So, it seems there is a hardware issue with these controllers. Like @dankcushions, I'd guess that this is caused by insufficient power supply filtering. That's why changing ports can affect this, since different ports can pick up different amounts of interference/noise which is then passed on to the controller.
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.
Now we need to figure out how to fix it. Unfortunately, there's no point in doing a software fix. This needs to be fixed with a soldering iron. My guess is that the little microcontroller in the gamepad gets fed 5V on the X/Y axis inputs when no button is pressed and those 5V get pulled down to ground when the D-pad is pressed. So, the first thing I'd do is to use an oscilloscope to check for ripple on this 5V supply. One potential fix would be to cut the 5V cable just before it goes into the PCB and put a small ferrite bead there, but that's just speculation at this point.
Unfortunately, I don't have much time for this kind of stuff these days, so I'm not sure when I'll be able to look at it. I also don't have an oscilloscope readily available (but I can get hold of one with some effort). So, feel free to help out with this if you can!
-
@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.
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.