SimConnect Data Read Rate Suddenly/Intermittently Drops

Version: 1.37.19.10

Frequency: For most: Rarely, for Certain Users: Frequently/recreatable

Severity: High

Context: TFDi Design MD-11 (though the bug affects other aircraft)

Bug description: It appears that SimConnect data updates are at some point either slowing down significantly in frequency or SimConnect in general is becoming delayed. I have several reports from customers demonstrating this, including this report which seems to have steps to reproduce that work: [BUG] - PFD ISSUE SIGNIFICANT FPS DROP ON SCREEN · Issue #1551 · invernyx/md11-bugs · GitHub

I can say with confidence that this is a SimConnect issue and not a code issue on our side for two reasons. Reason one is that the sim framerate seems largely unaffected (or, at least does not coincide with the apparent data update rate) and other, non-SimConnect code is running at the appropriate speed. I say this because I have seen other videos of this issue in our plane where our yoke is animating properly as our autopilot moves it and flashing elements on our PFD update at the correct rate (both of which are faster than the apparent update rate of sim data). Additionally, I’m told our MD-11 is not the only aircraft this issue has been observed in.

As always, I am happy to share relevant source or implementation details to help debug. Right out of the gate I can say that we do have a significant number of variables that we read, however, we only have a few read define IDs. We have a large amount of write define IDs (so we can control variables at different rates), but these should be unrelated.

We request the actual read data like so: SimConnect_RequestDataOnSimObject(hSimConn, DATA_REQUEST_ID_READ, DATA_DEFINE_ID_READ, SIMCONNECT_OBJECT_ID_USER, SIMCONNECT_PERIOD_SIM_FRAME, SIMCONNECT_DATA_REQUEST_FLAG_CHANGED);

Repro steps: See [BUG] - PFD ISSUE SIGNIFICANT FPS DROP ON SCREEN · Issue #1551 · invernyx/md11-bugs · GitHub

2 Likes

We are also noticing this in our aircraft… it doesn’t manifest always, but when it does, it’s exactly like in your video.

I’ll take a look at your flight plan to see if I can replicate.

Also able to reproduce this issue here. It only happens at low level (below 10,000ft) and it does appear to be location based. As stated, the simconnect update rate reduces to about 1Hz. Happy to supply logs if required.

Saw this as well through a standalone WASM module

Another video showcasing it in something other than the MD-11: https://www.youtube.com/watch?v=bJpxpegsMtg

Hello everyone,

I’m not sure this is SimConnect related.
Last video illustrates the problem with the PMDG 737 which retrieves sim variables through lookup_var.

Are you able to reliably replicate the problem yourself?
I flew a few of the mentioned flight plans with the 737 but did not witness the problem so far.

If you manage to have a repro, here are a few things you can check:

  • Track one of the simvar in SimVarWatcher with a high frequency and see if all clients are impacted.
  • If you have the opportunity, get that same variable through gauge api and behavior RPN so we can see if this is consistent across all APIs
  • Check if you are receiving frequent simconnect data with identical values or if it’s the data callback itself that is less frequent.

Regards,
Sylvain

1 Like
  1. I have seen this happen when debugging my own WASM module and have observed that the heading indicator on my PMDG 737 was also affected by the delay. Rendering was still smooth but the data (probably produced by their WASM module) was delayed.
  2. It occurred to me in a default 152 and the gauges were still smooth and appeared unaffected.
  3. Will test and update here with my results.
  1. Data transmission frequency is reduced to 1/second. The data is not transmitted with identical values.

I have also seen that switching aircraft using Dev Mode resets it to the proper frequency. This was tested on a standalone WASM module that wasn’t reloaded when switching aircraft.

1 Like

This is probably the same issue we have been trying to diagnose for the last 3 years with shared cockpit. Position sync stops for all clients and PFD displays start glitch/reset every second. Sometimes takes 5+ minutes for it to start recovering resulting in teleporting forward in jumps and then eventually fully recovers.

I know how to consistently reproduce this issue within 5-10 of taking off. We’ve been trying to debug it for a long time and haven’t found a cause, but I’m very much leaning towards SimConnect.

3 Likes

This too. Our freezing issue primarily happens at lower altitudes and closer to airports (on final approach). I can easily reproduce this issue by spawning on an island with an airport then taking off, turning on autopilot, and start doing steep left/right turns while also doing steep climbs/descents. Bug appears within 5 minutes.

1 Like

Hello @runshotgun @Tailh00k

Can you elaborate on what addon you are referring to and provide additional details on repro steps if needed?
I’ll follow your guidelines and try to replicate it.

Regards,
Sylvain

I can’t see a way to repro this. It really does occur at random and it’s a very rare one at that. After a week of debugging and most of those days spent reloading aircraft and rebuilding projects, it only happened once.

If there is a file (memory dump or whatever) I can generate that could help you guys, let me know.

1 Like

From my experience today, it also affects aircraft_varget(get_aircraft_var_enum...

It’s the first time in a few months I’ve seen the issue on my system.

I am really getting sick and tired off this error in 2020 sim. I keep getting this in the FSlabs newly released A321. This only seems to happen when there is a lot off turbulence. I even tried putting my max clients from 64 to 256 in simconect text file. Something needs to be done about this. See the video below shows the problem. https://youtu.be/oNcP9VGscYg?feature=shared I really hope this can be fixed or at least give us a workaround this.

If you’re having a problem with a 3rd party aircraft, it’s best to reach out to the 3rd party developer for support. This forum is for developers using the SDK to develop addons.

@turbofandude
FBW switched from SIMCONNECT_PERIOD_SIM_FRAME to SIMCONNECT_PERIOD_VISUAL_FRAME a long time ago to work around this issue with SIM_FRAME fix: use VISUAL_FRAME instead of SIM_FRAME for simconnect requests by lukecologne · Pull Request #8169 · flybywiresim/aircraft · GitHub.

1 Like

@EPellissier @Boris

Hello guys and Happy New Year!

Any ideas why SIM_FRAME would cause 1Hz stutters and VISUAL_FRAME would not?

@Tailh00k are you using SIM_FRAME rather than VISUAL_FRAME as well?

We are still experiencing this as of today. Our aircraft uses WASM compiled with MSFS 2024 build tools. Sometimes (I have not found reproduceable conditions) simconnect events and variables are delayed. Some days there is no delay, at other times the delay varies minute to minute, in the range of 0 to >30 seconds. For example, if I am masking the aileron axis event and make a step change in my controller position, my event callback is not triggered until 0-30 seconds later. Our HUD and PFD (which read variables from simconnect) show a lag similar to the key event callbacks. However, I do not think that simconnect itself is the root of the problem, as testing with many default aircraft (even very bare-bones ones which presumably do not use simconnect) reveals that their instruments all exhibit the same delay pattern as our aircraft, and do so with a cold start of the sim, no external projects loaded. Note: all testing was done with developer mode active, and we have never observed this bug in MSFS 2020 or earlier sims. Obviously, this bug is a complete show-stopper, and we’d really appreciate if it can be given some attention.

@Farley are you using SIM_FRAME rather than VISUAL_FRAME in your code?