FSUIPC 7 - Issue reading some offsets, others work - No C#

[John Dowson]

I'm surprised at this if you are only polling every 500ms, which is slow. I would have thought that there would be plenty of time to receive the updated values back from the FS, even at a 6Hz update frequency. You could try setting the  update frequency to VisualFrame (or Frame), to see if that helps.

 

[activex]

Quote

I'm surprised at this if you are only polling every 500ms

I did not mention that for encoders only: When I change a dataref (Xplane) or offset (MSFS), I read the value from the sim immediately and update the MCP display immediately. I do this for both sims, Xplane and MSFS. As long as I have direct access to the offset (or dataref) it is very responsive. The timer is used more for LEDs on buttons and if state changes in the sim (for example, turning off FD, turn's of other modes) or even changing hdg/alt/speed in the sim (not via hardware) I sync those changes back to the hardware. 500ms in this setup works fine.

Quote

You could try setting the  update frequency to VisualFrame (or Frame), to see if that helps.

Not using WASM monitoring, I explicitly read the offsets using my own timer. Unless, the offsets I read are being populated by WASM monitoring this will not make any difference. I can try though.

My bet is still on the fact that I cannot write CRJ offsets and have to trigger a change using an offset for an encoder (which requires you to simulate a button press, set it to 1, then reset it back to 0, and the reset action needs a delay otherwise it will not work).

 

[John Dowson]

3 hours ago, activex said:

Not using WASM monitoring, I explicitly read the offsets using my own timer. Unless, the offsets I read are being populated by WASM monitoring this will not make any difference. I can try though.

If you are reading the lvar values from offsets, the lvar values are populated via the WAPI/WASM. 

Why don't you just try increasing the update frequency in the WASM, as advised?

 

[activex]

 

Quote

Why don't you just try increasing the update frequency in the WASM, as advised?

So I tried it, there's quite noticeable response improvement, when I write the values into the CRJ (as I rotate the encoder and watch the display change in the CRJ cockpit, in the sim), I would say pretty comparable to writing standard offsets. The important thing here is that when benchmarking I should be observing the changes inside the CRJ cockpit, not on my MCP hardware since that is affected by the hard-coded encoder delay (in my code) explained below. I am stating this because initially I was looking at the hardware displays when turning the encoders.

Quick question: How much of a performance hit to my FPS is there if I use the setting LvarUpdateFrequency=Frame (as opposed to other settings)? In my case, I only have like 30 offsets total that are mapped to lvars. Are these only offsets that get monitored (my/user defined offsets), or internally there are other offsets? I haven't noticed any FPS degradation, but I thought I ask.

I noticed in your ini file acronym "CDA", what does that stand for, what is it used for?

So that fixes that, one still remaining item that I have on my list is to see if I can find some writeable offsets for hdg/speed/alt/vs so I don't have to simulate encoder turns. To turn an encoder in the CRJ, I have to set the lvar to 1, put a small delay, and reset it back to 0 (simulate a push button hold/release). That delay has to be long enough so that CRJ can detect the release. 10ms works best (best trade-off between performance and CRJ seeing the reset). 

Thanks for the help.

[John Dowson]

On 8/20/2021 at 4:01 AM, activex said:

Quick question: How much of a performance hit to my FPS is there if I use the setting LvarUpdateFrequency=Frame (as opposed to other settings)? In my case, I only have like 30 offsets total that are mapped to lvars. Are these only offsets that get monitored (my/user defined offsets), or internally there are other offsets? I haven't noticed any FPS degradation, but I thought I ask.

Increasing the update frequency will apply to all lvars, not just those that you are adding to lvars. Increasing the frequency will (obviously) tale more resources, but not by much, at least in the ad-hoc tests that I have done. I wouldn't worry about this too much, unless you start having performance issues.

On 8/20/2021 at 4:01 AM, activex said:

I noticed in your ini file acronym "CDA", what does that stand for, what is it used for?

a CDA is a Client Data Area. It is simcoonect terminology, and referes to the memory areas used to exchange data (via SimConnect) between the WASM and FSUIPC7. Its a technical term and I wouldn't worry about it too much.

On 8/20/2021 at 4:01 AM, activex said:

one still remaining item that I have on my list is to see if I can find some writeable offsets for hdg/speed/alt/vs

First try the standard offsets/controls for these to see if they work, otherwise look at the available lvars and hvars. The Mobiflight spreadsheet (now a web app - see https://hubhop.mobiflight.com/#/list) is a good resource for finding lvae/hvar/calculator code scripts for various a/c.