VRInsight and Lvar Updates

[Scotfleiger]

Hi John

Is there a defined polling interval for VRInsight devices with Com connections similar to the FSUIPC7.ini Buttons PollInterval and ButtonRepeat parameters? I ask because the response time to VRI Combo MCP and CDU keys inputs is slow compared with FSUIPC6 and not all inputs are registered for processing.

The FSUIPC_WASM.ini setting LvarScanDelay= was added for FSUIPC7 to wait for MSFS to prepare and make available internal Lvar values. A delay of 45sec is recommended but I have found 60sec necessary to pick up all FBW A32NX Lvars. This aircraft has a total of 1268 but I have found the number read can be as low as 1126 missing some key Lvars. When a user selects List Lvars in FSUIPC7/Addons/WASM would it be possible to force WASM to rescan the Lvars available?

[John Dowson]

Hi Andrew,

3 hours ago, Scotfleiger said:

A delay of 45sec is recommended but I have found 60sec necessary to pick up all FBW A32NX Lvars. This aircraft has a total of 1268 but I have found the number read can be as low as 1126 missing some key Lvars.

That was the delay that worked for me around 6-8 months ago. This will depend on many things (hardware, software running, MSFS version, FBW version, etc). It is up to each user to determine what delay works for them, and this should be checked on each MSFS release and for each aircraft update (for the aircraft you are using). I am not going to be checking each aircraft on each release to determine what this should be, it is up to the user.

3 hours ago, Scotfleiger said:

When a user selects List Lvars in FSUIPC7/Addons/WASM would it be possible to force WASM to rescan the Lvars available?

I guess I could add this. But only when using that menu option, not when using the control.
I will add in the next release.

John

[Scotfleiger]

Thanks John for Lvar answer. I agree it is very much aircraft dependent and up to the user to set the delay to suit.

Do you have an answer to my main question?

3 hours ago, Scotfleiger said:

Is there a defined polling interval for VRInsight devices with Com connections similar to the FSUIPC7.ini Buttons PollInterval and ButtonRepeat parameters? I ask because the response time to VRI Combo MCP and CDU keys inputs is slow compared with FSUIPC6 and not all inputs are registered for processing.

[John Dowson]

22 minutes ago, Scotfleiger said:

Do you have an answer to my main question?

Sorry, forgot about this. I don't know much about using VRInsight devices (I don't have any!) so can't help you with this. Maybe @Pete Dowson can shed some light on this.

John

 

[Scotfleiger]

Hi @Pete Dowson Just for clarification on above. LINDA uses the event.VRIread to set up call to the VRI device handlers. With the CDU3 if I press the keys too quick (normal pace) some events are missed and input lost. Not all events are being presented for processing. For example, pressing 1, 2, 3, 4, 5, 6, 7, 8, 9 in sequence returns events for 1, 2, 3, 8, 9 missing 4, 5, 6, 7. This varies between tests. I have to pause between key presses to ensure a key events is generated correctly. Sometimes a key press is repeated/read twice.

[John Dowson]

I've talked to Pete about this. The read/write sleeps are set to 10ms, so the poll rate is around 100 times per second. The code for this is identical in FSUIPC6 and DSUIPC7, so any differences will be to do this FSUIPC6 being an embedded dll and FSUIPC7 being a separate executable.

He also says: 

Quote

Note that as it is a serial connection, with a buffer in the hardware and one in the Windows drivers, I don’t really see how any signals can be getting lost, as he states, unless he is again referring to FSUIPC’s response like in the assignments, Perhaps he needs to be more precise and define what he’s doing and how he’s measuring.

 

21 hours ago, Scotfleiger said:

For example, pressing 1, 2, 3, 4, 5, 6, 7, 8, 9 in sequence returns events for 1, 2, 3, 8, 9 missing 4, 5, 6, 7. This varies between tests. I have to pause between key presses to ensure a key events is generated correctly. Sometimes a key press is repeated/read twice.

Maybe you can show me a log file showing this, although I don't think there will be much I can do about this...

John

[John Dowson]

There are also some log settings you could try which may help to see what is happening with the missing inputs. Try setting the Log -> Custom value to x2044.

This will probably generate a lot of information. Try setting this just before you do your tests, then clear afterwards.

If there is too much logged that makes it difficult to see what is happening, you could also try the individual log flags, which are:

#define LOG_VRICOM                0x0040 // 4
#define LOG_COMDATA               0x0400 // 64
#define DEBUG_COM                 0x20000 // 8192

 

John

Edited January 31, 2022 by John Dowson
corrected

[Scotfleiger]

Hi John/Pete

I have tracked down the source of the problem. There appears to be a clash with output to VRi Combo MCP (com3) and key presses on the VRi CDU3 (com4). When a write command to com3 (eg. DSP8100) occurs it is blocking one or more reads from com4 (eg. KEY1). The 2 serial-to-USBs are connected to different USB hubs which suggests it is not a hardware issue.

Attached is an extract of the FSUIPC7.log with Log Bit 6 set (VRICOM). The VRI com3 <- lines are the write to the MCP and the CDUcontrols lines are logged by the LINDA event handler when keys are pressed on CDU (uses event.VRIread(dev2, "CDUcontrols")). Sometimes all key presses are captured, but when a write occurs you can see the missed key presses.

The LINDA MCP display code is written to avoid unnecessary writes when the display data is unchanged. Otherwise, the display update is 1Hz.

VRICOM.txt

[John Dowson]

11 hours ago, Scotfleiger said:

I have tracked down the source of the problem. There appears to be a clash with output to VRi Combo MCP (com3) and key presses on the VRi CDU3 (com4). When a write command to com3 (eg. DSP8100) occurs it is blocking one or more reads from com4 (eg. KEY1). The 2 serial-to-USBs are connected to different USB hubs which suggests it is not a hardware issue.

But if this is not an issue in P3D / FSUIPC6. then it must be related to the timing differences between when FSUIPC is an embedded dll and when it is a standalone executable. Have you tried similar tests with FSUIPC6? If not, can you also do that to see how the logging differs.

This is an area of the code that I am not currently familiar with, and it is difficult for me to investigate not having any VRI (or com) devices.
I will take a look at this, but I am afraid it will have to wait for a while as I am busy with other things at the moment. I will take a look at this in more detail when time permits, most probably after the next FSUIPC7 release, hopefully ready in a coupe of weeks. 

John

[Scotfleiger]

Hi John

As suggested I have run a test with P3D v5.3.15 and FSUIPC6 6.1.7. With both VRI MCP (Airbus) (com3) and CDU3 (com4) connected, I repeated the same CDU key press test and found that all key events were captured even when 'interrupted' by data writes to the MCP (1Hz). It did not matter how quickly I pressed the keys - all were captured and actioned.

There definitely appears to be a difference between FSUIPC6 and FSUIPC7 event.VRIread() handling. I don’t think can be explained by the use of .EXE vs .DLL as the handling of the comms should be independent of the Flt Sim and SimConnect. This is not an urgent matter as I suspect few users have both these hardware devices.

P3D_VRICOMD.txt

Edited February 3, 2022 by Scotfleiger
Clarification

[OVD]

Hi everybody,

I don´t know if somebody finally found a solution to this problem, but I have been experiencing it from the release of MSFS and it´s very annoying. As Scotfleiger explained, you have to pause between key presses to avoid a key press is repeated twice.

Thank you so much!

[John Dowson]

Sorry, this one had moved off my radar...I will take another look and report back, although it will be difficult for me to investigate properly as I don't have any VRInsight devices.

[John Dowson]

Could you please try with the following setting in the [General] section of your FSUIPC7.ini file:
    ComReadLoopTime=10

If you get the same issue, can you also try with a value of 5 and then maybe 2 and then 0...

Let me know if any of those values make any difference. Thanks,

John

 

[OVD]

Hi John,

I have changed that parameter from 20 to 10 and I don´t have characters repeated any more! But the key response remains low... Some times I have to repeat the key press twice in order to have the character written. I don´t know if there is another parameter controlling that aspect...

Thank you so much!

[John Dowson]

2 hours ago, OVD said:

I have changed that parameter from 20 to 10 and I don´t have characters repeated any more! But the key response remains low... Some times I have to repeat the key press twice in order to have the character written.

Did you try with a lower value, e.g. 5? Try with various values to see if any improve the response.

2 hours ago, OVD said:

I don´t know if there is another parameter controlling that aspect...

Not at the moment.... I could add a similar parameter to control the write delay (ComWriteLoopTime) which is currently fixed at 20. You could then play around with both parameters to see which give a better response.

John

[OVD]

Hi John,

At 5 I have the same behaviour... Making the parameter ComWriteLoopTime setteable would be great!!

Thank you!

 

[John Dowson]

I have added ComWriteLoopTime as a new ini parameter in the attached version, and have set the default value of both ComReadLoopTime and ComWriteLoopTime to 10 (was 20).
Could you please try this version first with the default values, and then maybe play around with different values to see what gives the best results.

Thanks,

John

FSUIPC7.exe

 

[OVD]

Hi John,

I have already tested it and with ComWriteLoopTime=10 the key response is improved a lot.

After testing both parameters with the values 10, 5, 2, and 1 my conclusion is that there is a lot of difference between both parameters at 20 and at 10, and lowering both parameters to 5, 2, or 1 doesn´t make the repetitivity of the characters or the key response to improve much more.

Thank you so much!

[John Dowson]

20 minutes ago, OVD said:

I have already tested it and with ComWriteLoopTime=10 the key response is improved a lot.

Both ComWriteLoopTime and ComReadLoopTime  should now have a default value of 10, so you shouldn't need to set these values in your ini file.

Thanks for the update.

John