IPAC2 Problem / Slow buttons [Resolved]

[T3quila]

Hi Guys,

been a lurker here for a while and built my first cabinet.
I bought and setup an IPAC2 (2015 edition via USB on USB2.0 port) and the buttons work so far with the exception that I can't get any decent rates.
With the Passmark Keyboard Test the depress time is about 92ms. When I use the cheap wireless Keyboard that is connected I get about 50ms depress time just by hammering on one key. I get way more Characters / sec just by using the Keyboard than by using the buttons.
Noticed it when playing Track and Field, I can't get any decent press rates. I barely can make it through the first 2 stages. I have an Intel i3 3.8GHz which should be beefy enough to handle old games or at least the Passmark Test.

All buttons/joysticks work when I hit them, so I assume there are no stuck buttons. I've tried Happ, GGG and Ultimarc Ultralux buttons with different switches but the depress time and the low char/sec stay the same constantly regardless of Button/Switch combo. Therefore I assume it is in IPAC problem.

Any suggestions would be welcome.

Cheers and thank you

Edit:
I can get about 10 chars/sec from the buttons which is on par with the about 93ms depress time.
On the keyboard I can get up to 15 chars /sec. 
And I played the same game on a friend's cabinet and I'm doing way better there. Same setup there as I took his install for testing.
I also tried different USB ports for the IPAC. 

[T3quila]

I removed all wires and hooked only one micro switch back up to make sure no faulty connection was causing the problem.
Tried different USB ports (2.0 and 3.0) swapped the usb cable and even tried it on a different machine with a different Mainboard chipset.
Everywhere the same result...
Nobody got any ideas?

[PanicAcid]

Hey there, I don't know too much about the I-Pac 2 as I've only just had mine used for testing and haven't finished my build yet. But have you tried speaking to Andy from Ultimarc and asking him what it should be getting performance wise?

[T3quila]

Hi,
I will be doing that next.
I figured I would try here first before I bother Andy hoping it would be an easy fix.

[Malenko]

How do you fair on track and field running on arcade hardware?

[WakiMiko]

[T3quila]

@Malenko: Not that well right now on my own cab. Barely make it through the first 2 rounds. I'm better off playing with the keyboard or on my friends cab. I'm usually not breaking records but can comfortably play through the game at least on normal.
@WakiMiko: That is awesome. I'm nowhere near that. Wonder how much practice that took.

[BorgDog]

@WakiMiko - Dude!    So it's just one button you are using?  I've always used 2 for Track & Field, one for each hand, but never that technique, I am going to try it out however.

[T3quila]

I have to thank and compliment Andy from ultimarc here. He saw the thread, contacted me and helped me to resolve my issues.
This is customer service above and beyond what I have ever seen from any Vendor. 
As it turns out the debounce time in the controller was set to a value preventing the registration of more keypresses per second if you only hammer on a single button. He provided me with a new firmware for the ipac and voila the problem vanished.
He is thinking about publishing this firmware as a general release  for  all Ipacs on his website.
I remember reading a post from a while ago on here explaining that there was a batch of  shoty switches around requiring higher debounce times.

Thanks again Andy, you are awesome!

[AndyWarne]

Just to explain this in more detail, the de-bounce only affects the SAME switch repeatedly pressed. It has to be a reasonably long value for microswitches otherwise skipping happens when used for functions such as stepping through menus etc.

The problem is T&F does require exactly this, the same button repeatedly pressed.

Nevertheless, reducing the debounce seems to be the best option so I will indeed be releasing this into general use. The new version will be for 2015 boards only (all variations).

[RandyT]

It has to be a reasonably long value for microswitches otherwise skipping happens when used for functions such as stepping through menus etc.

This isn't exactly accurate.  One of the benefits of microswitches (or "snap" switches") is the reduced need for long debounce times, thanks to the action which slams the two contacts together under spring tension.   This does two things: 1) it helps to break through any corrosion build-up on the surface of the contact points (corrosion being the primary reason for debounce code) and 2) greatly reduces the ability of the points to "bounce".  The inherent reset travel which makes this possible, is also what makes these particular switches less than desirable for titles which require rapid fire.  There's also the fact that a fully emulated game, where code was present for debouncing the inputs, would still have this code intact.  And if no code is present in the original ROM, then it probably shouldn't be introduced by the controller.

IMHO, no controller should be hobbled in this regard to account for fiddly menu operation, which can be remedied by the softwares author.  Longer debounce times for computer keyboards is a great thing.  Nobody wants to be constantly correcting double inputs when typing, and the nature of keyboard switch mechanics is that they are prone to it.  Arcade controls, not so much.

[AndyWarne]

It has to be a reasonably long value for microswitches otherwise skipping happens when used for functions such as stepping through menus etc.

This isn't exactly accurate.  One of the benefits of microswitches (or "snap" switches") is the reduced need for long debounce times, thanks to the action which slams the two contacts together under spring tension.   This does two things: 1) it helps to break through any corrosion build-up on the surface of the contact points (corrosion being the primary reason for debounce code) and 2) greatly reduces the ability of the points to "bounce".  The inherent reset travel which makes this possible, is also what makes these particular switches less than desirable for titles which require rapid fire.  There's also the fact that a fully emulated game, where code was present for debouncing the inputs, would still have this code intact.  And if no code is present in the original ROM, then it probably shouldn't be introduced by the controller.

IMHO, no controller should be hobbled in this regard to account for fiddly menu operation, which can be remedied by the softwares author.  Longer debounce times for computer keyboards is a great thing.  Nobody wants to be constantly correcting double inputs when typing, and the nature of keyboard switch mechanics is that they are prone to it.  Arcade controls, not so much.

I have observed on a digital scope exactly the opposite. A large amount of bounce on microswitches and less on keyboard-type switches.

Different switches vary, the worst I have seen are some Cherry-manufactured switches.

The game ROMs might well have de-bounce built in. But they are reading the switch ports directly. Thats a whole different issue to sending spurious switch transitions through an interface to a PC. You really only want one transition to be sent on the wire per switch closure/open.

[RandyT]

I have observed on a digital scope exactly the opposite. A large amount of bounce on microswitches and less on keyboard-type switches.

Different switches vary, the worst I have seen are some Cherry-manufactured switches.

What I wrote is not to say that a particular microswitch (very light ones in particular) won't bounce, or that a new and clean keyboard style switch will.  However, microswitches are less susceptible to bounce than the parts they replaced, which were leaf switches (where some bounce can be beneficial to play) and older pushbuttons which basically hold a couple of contact points together and can be minutely slid around on each other when held down by the actuator/user.

Again, IMHO, the answer isn't to hobble the capabilities of any and every switch connected to account for the lowest common denominator, rather to replace poorly performing/dirty/worn out switches (or in the case of leaf switches, just clean them).  Any switch which would require nearly 100ms of debounce should probably be considered suspect.

The game ROMs might well have de-bounce built in. But they are reading the switch ports directly. Thats a whole different issue to sending spurious switch transitions through an interface to a PC.

At the nuts and bolts level, that's true.  But in practical use, it's really not.  If a game places a fire limit to X switch transitions per screen refresh, or other arbitrary criterion, that will be the limit, whether as the result of switch bounce, or input from an interface to a PC.  Some debouncing isn't a bad thing, but when switches are debounced by the interface for a period longer than what the game expects, you start to see issues like the one mentioned by the OP.

The code in the games will take care of this to great extent.  Asteroids, for example, will only place shots as close together as the code allows, regardless of the bounciest switch.  It would also be hard to convince Defender and Stargate players that some switch bounce on their fire button is a "bad thing".  Arcade games used leaf switches almost exclusively, and if bounce were an issue for any particular title, it'd been accounted for in the code.  And if not, I would posit that any switch bounce was expected to be part of the play dynamic (again, see the Defender / Stargate example.)  Players will spend a lot more time in the games than the menus, so in-game performance is the paramount concern.  My perspective is to let the FE and menu coders handle fiddly menus by simply inserting a tiny input delay, if they deem it necessary, but it really isn't.

[T3quila]

Well, Randy, consider this: Since I built one cab for a lot of games (mame or other emulators) and use likely a set of controls the original software wasn't designed for(currently a mixture of buttons purchased from you and Andy) , I'll appreciate that there are actually measures in the hardware that make 99% of those games and FEs usable and playable right out of the box, without having to beg a plethora of developers to alter there software to make it work with my specific set of controls.
On top of that Andy seems to be open to suggestions of the community, and changing firmware upon request inside a 1 hour time frame is pretty much unheard of anywhere else.

All that being said: I have ordered from both companies in the past and intend to do so again in the immediate future. I appreciate you guys both for what you do for the community. 

[WakiMiko]

How about letting the user set the debounce time? It could be an advanced option in the config software.

[sikm8]

How about letting the user set the debounce time? It could be an advanced option in the config software.

I second this.