• Which the release of FS2020 we see an explosition of activity on the forun and of course we are very happy to see this. But having all questions about FS2020 in one forum becomes a bit messy. So therefore we would like to ask you all to use the following guidelines when posting your questions:

    • Tag FS2020 specific questions with the MSFS2020 tag.
    • Questions about making 3D assets can be posted in the 3D asset design forum. Either post them in the subforum of the modelling tool you use or in the general forum if they are general.
    • Questions about aircraft design can be posted in the Aircraft design forum
    • Questions about airport design can be posted in the FS2020 airport design forum. Once airport development tools have been updated for FS2020 you can post tool speciifc questions in the subforums of those tools as well of course.
    • Questions about terrain design can be posted in the FS2020 terrain design forum.
    • Questions about SimConnect can be posted in the SimConnect forum.

    Any other question that is not specific to an aspect of development or tool can be posted in the General chat forum.

    By following these guidelines we make sure that the forums remain easy to read for everybody and also that the right people can find your post to answer it.

SimConnect Visual Frame Timing

Messages
32
Country
unitedstates
I'm pulling some data via RequestDataOnSimObject every visual frame. I'd like to know the exact time the data was "synthesized" within FSX to be able to interpolate between values (to both normalize and precisely calculate certain behaviors).

Locally timing arrival is the simplest method, but this may not always provide the correct results (network jitter etc.). SimConnect variables seem only to provide one second granularity (e.g. absolute time) which is useless when I'm getting 30+ events per second.

Pulling lat/lon and speed, and then calculating time between frames is also a possibility, but without knowing precisely when these are populated internally, it likely won't provide enough precision.

I also noticed SubscribeToSystemEvent Frame, which provides frame rate data, but again, it can arrive at delayed intervals and no guarantee to be in sync. with other SimConnect data. Also, the FPS measurement details are missing, so it's not known whether it is instantaneous (thus measuring the elapsed time from the last frame - which would be great) or averaged.

Has anyone looked at this problem and found a solution?
 
Hi,

You can't use per-frame to calculate trends as the frames are NOT guaranteed to be generated equally spaced.

You need to check the parameters from FS on a regular basis and independent of frame rate.

Best regards,
Robin.
 
Hi,

You can't use per-frame to calculate trends as the frames are NOT guaranteed to be generated equally spaced.

You need to check the parameters from FS on a regular basis and independent of frame rate.

Best regards,
Robin.

I'm aware of that, which is why I normalize the data based on the actual time difference between frames. However, this is where the problem starts. Measuring such frame delta time locally may not be valid because of propagation delays and jitter. Therefore I'm looking for some way to figure out what the frame delta might be from within FSX. Ideally, it would be nice if there were a "Milliseconds since Load" simulation variable, but there isn't. Thus my post asks if anyone has found a solution to reliably measuring frame delta.
 
Hmm - I appreciate your issue with the network delay, but I think you are asking a very difficult question. I know that previous it has been attempted to determine trend in real-time on the local computer in FSX with disastrous results because of the nature of the fact that neither FSX nor the OS are real-time.

Maybe you should request the data e.g. every 1/4 sec and use that? It will smooth out any jitter and make any trends more reliable, whilst continuing to use the per frame data for current state.

Best regards,
Robin.
 
Last edited:
Hmm - I appreciate your issue with the network delay, but I think you are asking a very difficult question. I know that previous it has been attempted to determine trend in real-time on the local computer in FSX with disastrous results because of the nature of the fact that neither FSX nor the OS are real-time.

Maybe you should request the data e.g. every 1/4 sec and use that? It will smooth out any jitter and make any trends more reliable, whilst continuing to use the per frame data for current state.

Best regards,
Robin.

There's definitely a difference in data between a networked client and a local client. A 1/4 second granularity is not adequate, but perhaps I can requests data at both at 1/4s intervals and every visual frame, and try to sync up. It might be worth some experimentation...
 
I do not know if it helps here, but I have used the invers of the frame rate returned from the frame event, and then smoothed with a function
time=a*newrate+(1-a)*time, with a=0.1 or whatever suits. This is a function that will not get out of control case a single frame gets far too late, but adaptes to trend changes fast enough.
 
Back
Top