Control spike elimination for buttons

[Andydigital]

I've seen your control spike elimination function and wondered how difficult it would be to add this function for joystick button presses as well. The reason this is needed is because of the new Saitek Pro flight yoke system. A significant number of users are having problems with random button presses been activated when moving the yoke axis, be it elevator or aileron.

Lots of test's have been done by myself and others on the official saitek forums but all saitek say is to return the yoke for a replacement, well that's next to impossible as these things are so popular they are on back order nearly everywhere, and the replacements a lot of people have received exhibit the same fault.

It appears the offending axis is sending some kind of spike to the control board which sets off a random joystick button activation as well, they are completely random as to how soon and how often it happens. Someone wrote in a thread today that this maybe fixed in a driver update so that it ignores these random button activations. The trouble is though Saitek seems very slow in everything they do and aren't prepared to deal direct with customers to replace faulty goods.

Finally im getting to the bit where you are involved Pete sorry to ramble on. Would it be possible for you to add some kind of code to FSUIPC to ignore any button presses of say less than 50ms or something like that. If its a big job then forget it don't worry about it we will have to wait for an official fix. But if its not too difficult to implement then maybe an option to switch the function on or off, and maybe also a option to change the delay before it accepts it as a valid button press.

Thanks Andy.

ps there are quite a few people with the problem so it may be some potential new customers for you :wink:

[Pete Dowson]

I've seen your control spike elimination function and wondered how difficult it would be to add this function for joystick button presses as well.

Erhow? What would be the difference between a button "spike" and a normal button press? Do you mean to not take any notice of a change in button state unless it held the new state for some time?

The reason this is needed is because of the new Saitek Pro flight yoke system. A significant number of users are having problems with random button presses been activated when moving the yoke axis, be it elevator or aileron.

Ouch! That is bad!

It appear the offending axis is sending some kind of spike to the control board which sets of a random joystick button activation as well, they are completely random as to how soon and how often it happens. Someone wrote in a thread today that this maybe be fixed in a driver update so that it ignores these random button activations.

The driver, being close to the USB port, is more likely to be able to tell the difference between a transient "press" than a full "finger press", but it also rather depends upon whether the buttons are on (pressed) off (not-pressed), or just momentary (do their own on-off when pressed, even if held).

The problem with trying to differentiate between momentary and held events in higher levels like FSUIPC is that the only way would be to have a faster polling rate. FSUIPC's default is 25 mSecs (40Hz). I would have thought it relatively easy for a normal finger press of a button to last less than that, don't you think?

Of course, on top of this, the true achieved period in FSUIPC's button polling will vary somewhat, depending upon the processor loading and all the other things FS is doing.

Finally im getting to the bit where you are involved Pete sorry to ramble on. Would it be possible for you to add some kind of code to FSUIPC to ignore any button presses of say less than 50ms or something like that.

It would be near 50 mSecs, on average, with the PollInterval parameter left to default at 25. I would simply make the "press" only work if it were true for two successive polls. I suppose you could then experiment with a faster polling rate, get the best compromise between FS performance and "spike" elimination.

If its a big job then forget it don't worry about it we will have to wait for an official fix. But if its not too difficult to implement then maybe an option to switch the function on or off, and maybe also a option to change the delay before it accepts it as a valid button press.

Not sure how big it would be till I look, but it sounds simple enough if I use the PollInterval. I'd need a buffer for previous inputs and simply use the logical "AND". But since we hope it is temporary, would an INI-file only option be okay? It is less work if I don't have to mess with the Dialogues (and main documentation, for that matter). And wouldn't this have to be joystick-number specific, or wouldn't it matter if it applied to all? It would be less work for blanket coverage.

I assume you are hoping for it in both FSUIPC3 and FSUIPC4?

I would have to apply it only to local joysticks, not those connecting via WideFS, since the timings across the Network would make a mess. Although, if really necessary, I suppose the filtering could be done at the WideClient end.

Regards

Pete

[Andydigital]

Erhow? What would be the difference between a button "spike" and a normal button press? Do you mean to not take any notice of a change in button state unless it held the new state for some time?

Yes it definitely needs to ignore the button activation for a certain amount of time, whether this is 50ms or not im not sure, that figure is just a guess. Looking at the spike appearing in the control panel for the yoke it does appear to be very brief. Holding the button to activate a function is fine by me.

it also rather depends upon whether the buttons are on (pressed) off (not-pressed), or just momentary (do their own on-off when pressed, even if held).

The buttons are all separate, even the rocker switches are actually 2 separate buttons when looked at in the control panel. They are "on" when held and off as soon as you release them.

There is one switch called a mode switch which works in a different way, it has 3 positions and it holds a different button "on" constantly until you move it to another position, then it holds that new button "on" constantly, etc.... i.e. position 1 button 15 held on, position 2 button 16 held on, position 3 button 17 held on.

But since we hope it is temporary, would an INI-file only option be okay? It is less work if I don't have to mess with the Dialogues (and main documentation, for that matter). And wouldn't this have to be joystick-number specific, or wouldn't it matter if it applied to all? It would be less work for blanket coverage.

Yes a INI file only option would be fine for me and i dont think it matters that its blanket coverage for all joysticks. As long as people are aware that a button has to be held to activate it i'm sure that would work fine.

I assume you are hoping for it in both FSUIPC3 and FSUIPC4?

I would have to apply it only to local joysticks, not those connecting via WideFS, since the timings across the Network would make a mess. Although, if really necessary, I suppose the filtering could be done at the WideClient end.

Being selfish i could say that i only need it for version 4 as I'm using FSX, but i do know that people using FS9 are having the same problem too so version 3 would be highly appreciated i'm sure by those users.

I'm not currently a WideFS user (probably in the distant future) so this would not be important to me, but surely if someone has one of these jokes (oops i mean yokes) then surely they can make sure its connected to the PC running the main FSUIPC module saving you alot of extra work.

Thanks Pete its greatly appreciated, this yoke is very good its just a shame the first manufacturing runs haven't been properly tested for EMC.

[Pete Dowson]

Yes it definitely needs to ignore the button activation for a certain amount of time, whether this is 50ms or not im not sure, that figure is just a guess. Looking at the spike appearing in the control panel for the yoke it does appear to be very brief. Holding the button to activate a function is fine by me.

Please try the interim updates I've put up on the Server. Use these links:

FSUIPC3: http://fsuipc.simflight.com/beta/FSUIPC3765.zip

FSUIPC4: http://fsuipc.simflight.com/beta/FSUIPC4201.zip

Add EliminateTransients=Yes to the main [buttons] section in the INI file to enable the option. It operates only with locally-connected joysticks (not EPIC or GoFlight devices).

Note that enabling this option may mean you have to consciously press buttons for slightly longer. It depends on the PollInterval, another [buttons] parameter, which defaults to 25 (milliseconds). A "transient" button indication is one which only exists for one poll, so a real press would have to last up to 50 mSecs to be sure of being seen (more allowing for variations in the polling due to processor/FS activity). You may find you need to adjust the PollInterval too.

Please let me know how you get on.

Regards

Pete

[Andydigital]

Wow quick work Pete thanks.

Does EliminateTransients=Yes have to be put it the sections for aircraft specific buttons as well?

Edit:

It's ok Pete i think i've figured out the answer for myself, no its not needed in the aircraft specific sections. I can press buttons fast enough so as not to get an action from them, but you have to be really fast :lol: seems to be just right at these setting. Now i just need to do lots of testing to see if its long enough to stop the transients.

Again thanks for you time and effort so far.

[Pete Dowson]

Does EliminateTransients=Yes have to be put it the sections for aircraft specific buttons as well?

No, it's a Global parameter, just like PollInterval. That's why I said "main" [buttons] section.

I can press buttons fast enough so as not to get an action from them, but you have to be really fast :lol: seems to be just right at these setting. Now i just need to do lots of testing to see if its long enough to stop the transients.

You can adjust it, of course, via the PollInterval. Try values from 5 to 50, but be wary of impinging on FS performance with low values.

Regards

Pete

[Andydigital]

Just to let you know Pete this seems to be doing what i want it to do and i haven't had any problems with it so far. I haven't been able to get on FSX as much as id have liked, but still it seems to have done the trick. I didn't have to change the pollinterval either which was a bonus.

Thanks again Pete.

regards,

Andy.

[Pete Dowson]

Just to let you know Pete this seems to be doing what i want it to do and i haven't had any problems with it so far. I haven't been able to get on FSX as much as id have liked, but still it seems to have done the trick. I didn't have to change the pollinterval either which was a bonus.

Good. Glad it helps, and thanks for the feedback.

Incidentally, I had to make interim releases anyway, without waiting for confirmation, so those two links I gave you are now wrong. You and others needing this fix should get 4.023 or 3.766 from the Download Announcements at the top of the Forum.

Regards

Pete

[Andydigital]

Ok thanks Pete will do.