SimConnect Data Read Rate Suddenly/Intermittently Drops

I tried both. VISUAL_FRAME was, if anything, worse than SIM_FRAME. And of course, that only applies to the sim vars read to be displayed on the instruments. The event callbacks for controls are delayed as well.

OK-
thank you - the SIM_FRAME callback has a known issue in MSFS2020 as well which has not been fixed so far.

Another question for you:

Are you using Tagged Data and thus only receiving information on variables that have changed according to an epsilon value? Iā€™d strongly recommend doing that so as not to flood your code with unnecessary callback updates.

No. I have 1 data request which is set for SIM_FRAME (although as I said, Iā€™ve tried VISUAL_FRAME and behavior was about the same), and a 1hz request per each non-user aircraft. Each frame Iā€™m calling SetDataOnSimObject twice, and I have about 30 events masked. The events are the biggest problem, as Iā€™ll have to wait 0-30 secs for the callback to come through when the sim is in a bad mood. As for the data read delay issue, like I said before A) this never happened in 2020, and B) when the sim is in a bad mood, I observe the exact same instrument data update delay on every default aircraft I try, even on a fresh start without my project loaded. So I am hesitant to go and rewrite a whole bunch of the core code of the aircraft unless thereā€™s really no alternative and/or I can be reasonably sure that it would actually help. I realize that Iā€™m posting a 2024 bug on a 2020 bug report, but it seems like it may be the same or a related bug.

I feel compelled to also point out that my company has been using this method for many years on several different aircraft - that is to say, 1 data request set to SIM_FRAME - and this aircraft itself has been in development for many years with the core simconnect code unchanged, all without issue. Weā€™ve only first observed this bug a few days ago, in MSFS 2024.

Hi Farley,

we have also been using SIM_FRAME since the FSX days and it was working just fine - it was only with MSFS 2020 that it started causing issues, and that was only in some cases with some customers (not everyone would experience this issue). We have not yet been able to find a solid repro scenario or we would have told Asobo ā€œdo this and this and it will happenā€.

We had to switch to VISUAL_FRAME which causes a relatively significant drop in performance, however not something that we canā€™t communicate to our customers. We do not, however, observe the 1Hz update bug anymore using this method.

I think your event propagation issue is a separate one, not necessarily related to the untimely receipt of Simconnect variable updates, but I could be wrong of course.

Another question - you said this was in your WASM code - is that on a process thatā€™s running outside of MSFS or is it a WASM gauge inside an aircraft in MSFS?

This is a WASM gauge running from panel.cfg. Iā€™m also not sure if itā€™s one issue or two, but it definitely seems to be coincident - when there is a lag in the events, there is also a lag in the data. When the data is up to speed, the events are as well. Iā€™ve found that pausing the sim for 30 secs or so usually causes the delay to disappear, at least temporarily. Also note that when this happens, the data update rate doesnā€™t change - as measured by A:SIMULATION TIME it appears to be pretty constant, and while it stutters a bit, itā€™s certainly smoother than 1 second - what changes is that the actual attitude data (and maybe other data as well, attitude is just the easiest to observe) is significantly behind the attitude as seen outside the cockpit.

OK - this is then consistent with what weā€™ve found but we never noticed that itā€™s coincident with events, as we donā€™t send quite that many, quite so often.

It was quite evident in our aircraft that using SIM_FRAME was causing this exact 1Hz update rate, rather than normal updates coming every sim frame.

Switching to VISUAL_FRAME fixed the issue, as mentioned by others here.

Not sure if this would fix your events issue.

Yeah @simfan unfortunately I think this bug and your bug are two different bugs, as you describe a 1hz update rate that was fixed by switching to VISUAL FRAME. Neither of those things apply to my case, however Iā€™m not sure if @turbofandudeā€™s bug is your bug or my bug. From the original post, it sounds more like my bug - a delay rather than a 1hz update rate. Curious which one, and if you figured this one out or not Collin?