Strange quirk with new arcade stick

A couple of months ago I purchased an eightarc (Qanba) arcade stick – the PS3 Pearl. I had been using a MadCatz TE (MvC2 edition) for over a year and was very happy with its performance, but I wanted an all-white stick and planned to do some other customizations (e.g. artwork). I was just going to use my MadCatz as a backup in case I busted the new one via the mods.

When I received it in the mail, the stick seemed to work fine during “testing” in practice mode on Tekken 6 (my main game). I made a small mod to the stick right away (I spray painted the USB cover white since it was black by default, which to me was clashing with the all-white theme I had going) which of course voided my warranty. It wasn’t a big deal, as the stick worked the “same” after placing the cover back on. But when it came to our weekly gathering I noticed an issue…

I was dropping simultaneous button inputs like LP+RP or LP+RK, etc. At first I thought it was all in my head, so I continued to use the stick for a few days. Same thing. I then attempted to identify the button(s) at fault and replace them with some other Sanwas I had lying around (previously installed in an HRAP). Same thing. I then replaced ALL the buttons. Same thing. I replaced the Sanwa stick (again with one from my old HRAP) since it does have a PCB of some kind and could be at fault. Same thing.

I then plugged up my old MadCatz and tried using/performing the same characters/moves that seemed to give me the most trouble and found I had no issue at all. I could do the same combo/multi-throw 50 times (literally!) w/o dropping it on my MadCatz but I could not get into double-digits on the eightarc w/o dropping an input (well, maybe “drop” is a bad word; what actually happens is you get LP~RP i.e “button roll” aka “slide” instead of LP+RP, for example). So I decided to perform another modification I had been thinking about doing…

I purchased a Paewang Revolution (Joytron) PCB from so the stick would be dual-mod (PS3/Xbox360). I’d then have a “fully-working”, dual-mod stick (“kill two birds with one stone” was the idea). So I had a buddy (who was a recent EE grad and had a temperature-controlled soldering iron, multi-meter, etc) solder it up according to Laugh’s guide here on SRK (linked-to from Once I installed the Paewang PCB in the stick, it is worth noting that ALL buttons (except the mode, turbo, start, home and select buttons on the side; since they are non-standard 22mm buttons), ALL stick components (including the wiring harness) and ALL electronics (PCB, wiring, etc) had been replaced at this point and guess what… SAME THING!

So I look at it like this: 1) I got two bad PCBs in a row – not probable, but possible 2) There is some kind of explanation involving small electronics (PCBs, USB, etc) or 3) I am just crazy and need to stop whining (or just use the MadCatz stick!).

So to all of the “people in the know” regarding electronics, stick mods, etc. – Toodles, Laugh, etc. – is there an explanation for this other than bad components or general craziness?

this sounds really really fishy or mental…

So keeping everything constant you had a process of
1 - buy stock stick (works fine)
2 - paint your USB panel (works fine?)
3 - find that simu inputs are different and replaced parts (not working properly)
4 - dual mod with paewang with every part replaced (not working properly)

So then the problem happens somewhere when you painted your usb panel or changed out parts then?
Could it be a problem with the wire harnesses themselves?
That’s the only constant that I see that could be causing the issue.

Any other ideas?

One problem is that I did not test the stock stick rigoroursly enough to know that it truly worked fine from the start. No doubt I think that was a mistake, but I truly believe the issue was there all along (this also assumes that painting the USB panel did not break anything, which in my mind is a pretty safe assumption). So it is more like this:

1 - buy stock stick (works fine? i.e. based on limited testing)
2 - paint USB panel (works fine? i.e. works same at least)
3 - find that simu inputs are different (not working properly i.e. compared to MadCatz)
4 - replace some parts (not working properly)
5 - replace more parts (not working properly)
6 - dual mod with paewang replacing ALL parts (STILL not working properly!)

At this point the only things that have not been replaced are the side buttons (only because I cannot find some 22mm Sanwa/Seimitsu/etc buttons long enough for the MDF wooden frame), the MDF wooden frame and the top metal/plexi. I have considered the possibilty that there is some “give” somewhere in the metal/plexi due to imperfections in the MDF wooden frame, causing it to “wobble” a bit (making it an uneven surface) or that the smaller height of the stick is causing my hand/fingers to approach the buttons from a different angle (

But all that seems like I am grabbing at straws. Occam’s Razor says there is something going on with the stick internals… In fact, it points to the eightarc/Qanba & Paewang/Joytron behavior as “normal” (2-out-of-3 sticks showing the same behavior; meaning I am just a slob with inputs) with the MadCatz being the standout. It’s almost as if the MadCatz has some kind of built-in protection for slobs such as myself. If so, I am torn – do I use the MadCatz with its built-in “crutch” (I definitely feel more confident using it) or just suck it up and use the bare bones? This really bothers me…

Well, chances are that it’s simple a matter of getting used to that stick. The bright note is that you can test it for sure to rule everything out except your execution.
To do this, you will need to be able to determine which of the wires going to those two buttons is the signal, and which is the ground. If you post pics, we can probably eyeball it, otherwise you may need your EE friend’s help if you don’t have a multimeter.
What you want to do is take a small, thin wire and remove some of the insulation from each end. Pull off the signal QD for the first button, run the exposed wire through the hole in the button terminal, and slide the QD back on. It’s a little rough, but it can be done. The QD doesn’t have to go all of the way down, just enough to stay put so the QD, button tab, and wire are all touching. Repeat with the other end of the wire with the second button. Go into any good training mode, preferably the one you’ve been testing with already, and slowly press and release the first button a number of time. You should see both buttons activate in the input display each and every time. Do it some more with the second button. Repeat a bunch of times.
If the display shows a perfect both buttons at the same time, it’s your execution. Practice and adapt, or go back to your MadCatz.

OK, so let’s assume my execution is not perfect i.e. I don’t hit the two buttons at the EXACT same time. Is there anything about these types of controllers that could give more or less “leniency” in terms of how much time can exist between two button presses before they are considered simultaneous? It simply feels like the eightarc/Qanba & Paewang/Joytron will only let the buttons be pressed within X microseconds of one another whereas the MadCatz allows X+Y microseconds (with Y being some undefined “buffer”). However, as I understand it USB is host-controlled meaning that the PS3 is the one polling for button presses. Thus the X & Y timings above should be controlled by the PS3 which is constant no matter what controller I use. Right?

You’re correct about the polling speeds being controlled by the console, but there’s also the frequency that the game checks the inputs that the console read, and that should be happening once per frame, regardless of the controllers being used.
The frequency that the console checks the controllers is controlled by the consoles’s USB, but the frequency should be based on what the controller requests. Snooping the USB like a year+ ago, I was left with the impression that the console may ignore that frequency, so I really don’t know how fast the console will check those sticks or any others. At worst case possible scenario, the first button may connect during one check from the console before the game checks for that frame, and the second button gets seen by the next time the console checks the controller after the game checks the frame. Sorry, that may be confusing, so let me pull a hypothetical out.
Let’s say the game checks one controller every 10ms, and the second controller every 1ms. The game checks the inputs every 16ms. You try to press your buttons simulataneously, but fail by 2ms.
t=9ms : Your first button is pressed
t=10ms: The console queries the stick, sees the first button is pressed and not the other.
t=11ms: Your second button is pressed
t=16ms: The game checks the inputs by seeing what the console saw on its last poll, and sees only one button.
t=20ms: The next query of the pad is done, and both buttons are seen as down. Everything from here on out works as normal, the game will see both buttons pressed.

Same thing but with the 1ms controller:
t=0, 1, 2, 3, 4, 5, 6, 7, 8ms: queries from the console sees no buttons pressed.
t=9.5ms : Your first button is pressed
t=10ms: The console queries the stick, sees the first button is pressed and not the other.
t=11ms: The console queries the stick, sees the first button is pressed and not the other.
t=11.5ms: Your second button is pressed
t=12ms: The console queries the stick, sees both buttons pressed.
t=13ms: The console queries the stick, sees both buttons pressed.
t=14ms: The console queries the stick, sees both buttons pressed.
t=15ms: The console queries the stick, sees both buttons pressed.
t=15.9ms: The game checks the inputs by seeing what the console saw on its last poll, and sees both buttons.

So, hypothetically, it could definitely be a physical execution problem that appears worse with some electronics than others. But I have no reason to suggest or expect it from any of the electronics you mentioned.