I am working on an inertial navigation system simulation and I need a callback
function which is guaranteed to be synced to the flight model position update
callback, along with the total elapsed time of the internal simulation clock
used for integrating the flight model. I am aware of the suggestions in this
thread: <https://devsupport.flightsimulator.com/questions/6016/drawing-
independent-event-timer.html> However there are a couple problems:
SimConnect_RequestDataOnSimObject, with SIMCONNECT_PERIOD_SIM_FRAME does
appear to potentially be synced to the flight model update, but that would
only be if as mentioned in the post, the flight model frame and visual frames
are the same. This uncertainty is not useful when debugging something as
sensitive as an INS where small errors can creep up rapidly. Secondly, it only
solves half the problem in that it provides the callback, but not the total
elapsed time internal to the sim. Next, the QueryPerformanceCounter was
suggested. But this also is not satisfactory for the following reasons: 1: In
previous flight simulators like FSX and P3D, where we found an undocumented
timer function that linked us to the sim time, we established that SimConnect
SimFrame periods would occasionally occur multiple times in the same frame. We
figured this out because comparing elapsed sim time from one from to the
previous showed a delta_t of 0. This allowed us to elliminate those duplicate
frames from the integral process for our INS, and ensure that no additional
unwanted errors would creep in. QueryPerformanceCounter however will return a
very small non zero delta_t which absolutely will introduce errors in any
integral function that we cannot accept. In addition, it is certain to differ
slightly from the internal sim timer which is guaranteed to add additional
errors to the integrator. 2: It also introduces the problem of integrator
windup when the sim is paused as the timer keeps ticking instead of stopping
with the sim. This is again unacceptable for high precision integrators. Next,
the tick18 Token variable was mentioned, but 18Hz (along with the 6Hz timer)
is far too low for an inertial navigation system, let alone a flight model,
and as such are hardly even worth mentioning since they are also guaranteed
not to be synced with the main flight model position update rate. Finally, for
those who may suggest to just take the sim position and add a random wander
rate and direction, please don’t. We take pride in our work in engineering our
systems here to work using the proper physics of reality. No time for
gimmicks.
To write code that uses a variable time that is in sync with the sim you
always use the sim zulu time or simulation time. Not sure if simulation will
pause. (E:ZULU TIME, Hours) (E:ZULU TIME, Minutes) (E:ZULU TIME, Seconds)
(E:SIMULATION TIME, Hours) (E:SIMULATION TIME, Minutes) (E:SIMULATION TIME,
Seconds)
I wonder what the Velocopter guys did with their wasm flight model. They
either had some inside info from Asobo or did some incredible hack to get that
code to work. I write real-time aero code in MSFS and as far as I can tell
there are very very few people who comprehend what that implies inside the
sim. MSFS intentionally has 3rd party code running asynchronously from the
core sim (unlike FSX, for sound resiliency reasons in MSFS) but basic concepts
are not in place to enable aero calculations via the provided API’s because
time and data values are sampled at an interval independent of the sim model
update cycle. If your calculations are simple or slow enough you’ll think
that’s fine but some calculations (like the rate-of-change of potential energy
plus kinetic energy) are far too volatile to be able to use a bag of loosely
related variables, particularly the time delta. Some Asobo code (in JS)
calculates the update time delta using a real-world timestamp in preference to
the in-sim time simvars because the real-world delta doesn’t have the extreme
per-frame sampling jitter of the time simvars. Again, this only matters if the
accuracy of the time delta between updates is important in your code and for
the vast bulk of 3rd party code it doesn’t matter so long as the frame rate is
high enough. An easy test is to request ABSOLUTE TIME and subtract to get the
delta on successive frames. You’ll see the delta toggle between two (main)
values as the request cycle slides over the free-running update cycle of
ABSOLUTE TIME itself being updated. The most practical solution I have found
is to move time-sensitive calculations into the model XML (hello RPN) which
can be computed using a coherent set of sim input values , and have those
calculations produce intermediate results that are far more robust to be
shared with the asynchronous module written in something more practical than
RPN. As an aside I’d be very interested to know how you expect to apply forces
to the aircraft. AFAIK there’s no documented way to do that, but there are
hacks which take careful tuning to avoid instabilities.
Most external flight models involve writing to the simvar accelerations and
velocities instead of merely applying forces and letting the sim flight model
take it away.
These vars aren’t accessible in the WASM environment except by
execute_calculator_code which is honestly one of the dumber and most
inefficient functions with an extra useless overhead of string processing.
This was a problem in earlier sim versions, and persists here.
It seems that there is still no way to get the delta time period? I, too, used an external clock reference on the older sims to get around this issue, but as you rightly state, this creates unacceptable errors over time.