HowTo: Fix phantom/ghost input on iBuffalo/Buffalo SNES controllers

General Guides
#1

As many of you know, the Buffalo/iBuffalo SNES controllers are probably the most authentic feeling ones out of all the USB SNES replicas. Unfortunately, many of these controllers have issues with phantom d-pad presses, i.e. the d-pad is “pressed” by itself. I recently acquired a couple of these controllers and have been working on a fix for this issue. Please see my reddit post for the details:

It would be great if you reported back in this thread if you try this fix. I’m still doing the final testing (24 hours) on each of the four controllers I have access to but so far, so good.

1 Like
#2

oh lol I didn’t realize that was your post. Good stuff!

I have one of them but I don’t think it suffers from the phantom inputs. It would be pretty obvious, I assume?

#3

Heheh, thanks! :slight_smile:

It doesn’t have to be all that obvious. One of the controllers I have seems to only do this once every few hours. Whether or not that will be noticeable depends on what you do at the moment. If you play a platformer, it will probably be pretty hard to spot it. If you play some puzzle game like Tetris, with obvious discreet steps in the movement, it will be pretty noticeable.

It’s also dependent on host hardware, it seems. My Pi3 seems to be the worst, while connecting my controllers to my monitor’s USB port seems to mask the issue completely. It’s probably dependent on USB port power supply quality and noise level.

If you haven’t noticed anything in day to day usage, I’d suggest to skip this procedure for the time being.

#4

Interesting. Well, if I notice it at some point, I’ll swap the caps out and let you know how it goes :slight_smile:

#5

Yes, my iBuffalo SNES controller has the dreaded phantom d-pad input. Got a refund from the Amazon seller and got to keep the defective piece if crap. I’ll try the fix if I can find someplace to buy the capacitors.

Aside from the electronic defect, the d-pad is mechanically stupid. I placed a tiny rubber nub on the pivot point to make the d-pad less loose and un-depressible in the center.

#6

are the caps in signal path? if they are on the supply part, have you tried plugging into a well-built powered usb hub? if its more about signal, how about adding bigger ferrite cores on both ends of the usb cord. or probably try both.

#7

Two of the caps (C13 and the extra one I added) are on the voltage supply. To be honest, I didn’t really try to work out the purpose of the third one. I believe that cap can probably be left as-is and the fix will be just as effective. I just couldn’t get myself to spend more time on testing this…

I did try one of the really unstable controllers in my monitor’s USB port and it appeared to work much better. I didn’t run a long test, but it did remove the spurious inputs seen in Windows’ Game Controllers dialog. So some of these controllers seem to be very sensitive to power supply quality.

#8

ok the other cap (below input pins) is probably just another bypass cap since one end is connected to ground. check the voltage on that pin there, or probably hook it into oscilloscope to see if there are changes if you press buttons etc.

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. 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. 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?)

#9

Yep, I’ve now confirmed it’s a bypass cap for 3.3V. No measureable changes when buttons are pressed (measured with a DVM). I’d guess this is the core supply for the microcontroller and the 5V input is used for the buttons and analog x/y axis.

I believe that’s another ferrite bead.

Yeah, I’ve thought about those things as well. Unfortunately, I have no easy way of measuring the USB current draw. All my controllers are now modded, but it would have been interesting to measure the current draw on a really unstable sample. 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.

The reason I added the extra 10µF cap after the bead is that the bead could throttle any rapid current changes and cause dips in the voltage. By adding this cap, the cap can supply the input pin directly. It did make a difference, but I didn’t attempt to add the same cap before the bead instead. It’s possible the extra capacitance (in addition to the 22µF) was what was really needed…

#10

possibly a bad (high resistance) cable then. whats the voltage after the bead? especially when a button or buttons are pressed?(hopefully you have a high sensitivity dvm)

#11

I don’t have any of the controllers open at the moment (I’m hoping they’re finally OK and I don’t have to open them again), but I believe I previously measured 5.0V both before and after the bead but only with no buttons pressed. The DVM is nothing special, though, so probably not trustworthy when more exact results are needed.

I did notice that the cable is rather thin and flimsy. The cable on my Cirka S91 controllers is significantly thicker. Not that that has to mean anything, but it’s an observation I made immediately when taking it out of the packaging.

EDIT: I really would have liked going into greater detail on this, but lack of time and difficulties getting access to an oscilloscope made me focus on just trying to get these things to work. :slight_smile:

#12

I’m kind of wondering if bad component mounting (soldering) could be the culprit… I read the 1/2 star reviews on Amazon and there’s a decent chunk of people reporting DOA controllers (some with loose components inside) as well as controllers that stop working quickly or start acting up in one way or the other. One reviewer had his controller stop being recognized by the host when plugging it in. He went on to take the controller apart and used a soldering iron to resolder all connections and the controller then started working again.

I have noticed that the components are pretty shoddily mounted to the board. Some SMD components look like they’d fall off the board pretty easily if you gave them a nudge… :stuck_out_tongue:

#13

its not uncommon for stuff like that to happen on low priced devices. anyways from your test since its working better by adding caps this should be voltage issue(needing higher, clean and stable voltage, crappy cable or just basically poor regulation(internal regulation)

#14

I have two iBuffalo SNES controllers and none of them seem to be affected by this problem ; but thanks for the guide anyway ! :slight_smile:

#15

I have two of these as well, and while I haven’t noticed any problems, I know that I will eventually feel compelled to test them both–for that reason, I’d rather just open them both up and perform the fix, necessary or not. This is a 10 minute job.

Yet another great contribution to the emulation community, Brunnis. You’re a star. Thanks!

Bonus mod: While future readers have theirs open, these controllers can really be improved with a bit of lead tape inside the case (be sure to balance it carefully). Mine feel very authentic now that I’ve brought them within 100 mg of a real SNES controller. This also improved their ATK by 17 when retro gaming frustration calls for a throw.

2 Likes
#16

Thanks!

I have now concluded my testing. 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. However, to make one of them stable, I added an additional 22µF cap at position C41.

All of those tests were done with just one controller attached to the USB ports of my Pi. 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"). 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. Besides, without an oscilloscope I can’t even know for sure that my Pi’s USB voltage is within spec.

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 admit that I’ve used some trial and error to get my controllers stable and I don’t doubt that a more elaborate investigation (using an oscilloscope) could provide a better fix (probably involving adding smaller caps as well). However, I’ve already spent too much time on this, so someone else will have to do that. :slight_smile:

3 Likes
#17

i would have but iBuffalo is not available here locally and sellers online are overpricing this.

#18

Great find. I have seen people using an external powered usb hub.

#19

Well, I was lazy and didn’t do my fixes right away as I’d planned, but not too lazy not to test my controllers overnight the last several days. Both of my iBuffalo BSGP801GY controllers (purchased from Amazon July of 2016) performed flawlessly, each being tested for some 20+ hours. I tested by assigning asdf to D-pad directions and leaving open a text editor with active cursor. No phantom typing. This isn’t to say that my units aren’t intolerant to bus noise/voltage fluctuations. After all, I’m assuming this is the same PCB considering the 815 model is PCB v1.0.

What I conclude is I’m either lucky and the die roll with possibly loose tolerance components (and no safeguards in place to mitigate them) just happened to land in my favor in both cases, or my upper tier X99 board and EVGA Gold-certified PSU just provide really stable power (despite having many USB devices plugged in simultaneously).

I don’t have any SoC devices to test with. I have a feeling my other desktop would reveal the same results.

#20

Yup, could be either (or a combination of) stable or reasonably stable controllers and good power supply. But good to hear that your controllers are working!