here's a quick drawing to help explain what happens:
you expect simulink to send the data, then fg to run once, next simulink to run then fg etc like in the timeline above.
But that can be only if all programs involved are exactly running at 30 Hz in a synchronized way, If it works, you don't need to use a precise timestamp for each fdm state, the way they are running together ensure the synchronisation.
but FG respect only the 30Hz "as much as it can" given the variable load from doing 3d stuff, so some frame are longer, wich lead to a shift in the timing, you then have lost the sync you were counting on, and got jitterly planes for multiple simulink driven planes.
the best way to see this is to capture the network traffic involved here with a high multiplay sending rate to ensure each fg run send a mp packet (wireshark is your friend)
We have two solutions, we can try to run FG synchronised to simulink, or we can use precise timestamp for the fdm states from simulink.
1) the "run in synch way"
- simulink part
I'm curious to see how precise simulink is in its run, (wireshark log welcome
) and if the 30Hz is very good, is the sending time adjusted to the wall clock (eg there are frame sent at exactly the full seconds, or the sending time depend the moment you start simulink. Can your check if different simulink run send the packet in nearly the same time windows inside a second ?
-fg part
For now, FG can't run at some precise decimal part of the wall clock second (eg 0.1s 0.2s 0.3s etc for 10Hz) for once because the starting time will add an offset, and mainly because huge frame will shift the reference (eg: 0.1s 0.2s then 0.44s 0.54s ) so we can't expect a repetably timeline inside each second.
with your current FG, you can first try to play with sim/model-hz, wich give fg the "step" it is allowed to have for frame time, by default it will be 120hz, either ask for 30 as for all the other props (and with the frame rate limitation you don't have in the lines you reported):
- Code: Select all
--prop:/sim/model-hz=30 --prop:/sim/frame-rate-throttle-hz=30
or call for lot more for model-hz, like 1000
and see if it's better.
if simulink is able to be consistent relative to the wall clock, i can send here a patch to have fg more fixed to a time grid (if you compile fg yourself), this is part of a solution to address a bug in mp protocol sending rate in the way.
ther could be a solution to trigger a fg run each time something new come from simulink, but the racing condition between 2 fg sessions would probably lead to jitter too, depending which FG run first each step so imho the best are time synch based on wall clock, or solution 2
2) using a precise timestamp
with each fdm state having a precise timestamp, we don't need to have a strict timeline for simulink and fg, we only need to do a bit of prediction, to have the plane position adjusted to where it should be at FG time, mainly adding a (speed * time) difference vector. that's what the mp code do for multiplayer pilots, so we're back to either make a mp protocol from simulink (but for this i can't help, so obviously it's the solution i prefer as the job in fg is already done
) or change the time used in the netfdm protocol to have a precise timestamp, and add position prediction in fg netfdm (wich could improve master-slave fg sessions)
It's obvious for this kind of "real time mode", that the different pc you are using need to have clocks in sync, so ntp or ptp are your friend ...
hope this is a bit more clear for those reading this, this is always a bit difficult to explain what is evident to me
not in my native language and without simulink .