Filtering inputs

[MarkFox]

So I'm working with a VRInsight CDU II on FSUIPC6/P3Dv5, and it works great except for the fact that the CDU II is incredibly prone to sending multiple inputs (it's a hardware design issue.)

Now the primary aircraft I fly it with is the FSLabs A32x, and I was able to filter the excess inputs by writing using a modified version of the Lua script provided for LINDA to have it loop the inputs via a (very rough) program I wrote to proxy the inputs and drop any duplicates that occur within 1 second of the last one. Unfortunately the way I've done it only works on this specific aircraft, so I'm looking to find a way to implement a similar rate limit via normal FSUIPC (ie ignore same button press if within 1 second, unless another control has been pressed in between)

 

Thanks in advance for any help!

[John Dowson]

3 hours ago, MarkFox said:

So I'm working with a VRInsight CDU II on FSUIPC6/P3Dv5, and it works great except for the fact that the CDU II is incredibly prone to sending multiple inputs (it's a hardware design issue.)

That is strange...I thought the issue with this CDU was that the buttons don't send a press and release, they alternate, as discussed here: 

 

Or maybe that is a different issue?

Alternatively, if you are using mouse macros, please see the following post: 

If none of those apply to your problem, can you please show me your FSUIPC ini and log files, the latter with logging for Button & Key operations and Events (non-axis controls) activated and showing your issue.

4 hours ago, MarkFox said:

Unfortunately the way I've done it only works on this specific aircraft,

Why does your current method only work with the one aircraft? Cannot you use the same method for other aircraft also using LINDA?

4 hours ago, MarkFox said:

I'm looking to find a way to implement a similar rate limit via normal FSUIPC (ie ignore same button press if within 1 second, unless another control has been pressed in between)

There is no way to do this unless you use lua scripts to control everything. But there are many FSUIPC users with this CDU and I have not heard of this sending multiple inputs before, so I would like to verify that this is actually the case and this is not caused by the other known issues with this device.

 

[MarkFox]

That specific method only works because the aircraft will take HTTP inputs for it's CDU, so I was able to use a proxy server specifically written in C to filter based on the input. (I'm definitely more of a C guy than a Lua one - I also hit some race conditions in my early attempts to filter/rate limit without C since the duplicate inputs come in so close together)  I found the one second delay to work very well across all CDU functions, because outside of the very rare need to hit the same button twice in a row, the response time still felt roughly in line with the not amazingly fast speed of the simulated CDU anyway

I did encounter the mouse macro issue, but was able to deal with it by simply altering the macros to include a ",13" (left-click release) as part of the macro (thank god for the 

The issue has been encountered previously as seen here by at least two others: https://www.mycockpit.org/forums/showthread.php?t=26867 (which also links to a review on Simflight where the author has the same issue via the official VRInsight software too) - I verified that the multiple inputs were coming from the device rather than elsewhere by using VSPE to allow me to sniff the outputs coming in from the serial port directly - it doesn't do it on every key press, but it appears that the switches they've used in at least some of the batches are extremely twitchy and can trigger multiple times - fast enough that they come in within a second. I will try and get some logs tomorrow, however tomorrow is also the last day before I go away for three days so I'm not 100% on if I'll have chance.

My main reason for raising it here and finding out if there's a way to limit it from the FSUIPC side is that the author of LINDA has apparently completely left the community, so moving forward I'm aiming to depend more on FSUIPC directly - especially when it comes to migrating to future versions of MSFS) and also to avoid writing both Lua and macros for potentially every plane.

 

Obviously I will get the log files done, but if having one of the misbehaving devices personally would help, I'd be happy to temporarily ship my unit over to you - I used to work in embedded development, and I know how much easier it can be to have direct access to a problem device.

Edited October 17, 2023 by MarkFox

[John Dowson]

Can you try adding this to the [Buttons] section of your FSUIPC ini file:
    EliminateTransients=Yes
This may be what you are looking for - from the Advanced User guide:

Quote

EliminateTransients: This can be added, and set to ‘Yes’, to eliminate short (transient) button press indications. This is intended to help deal with some devices which create occasional spurious button press signals. It operates only with locally-connected joysticks (but 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 (below). A “transient” button indication is one which only exists for one poll, so a real press would have to last up to 50 mSecs (twice the default poll interval) 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.

Cheers,

John

[MarkFox]

Thanks John - It's looking like it'll either be late this evening or when I get back that I'll be able to test, but I shall definitely try that- it does sound like it might be just the job