I'm surely a bit late
, but the case you report was reported somes years ago, now i remember
from my understanding, it's basicaly because the way FG deal with the external input is a kind of successive "frozen" state, each being a received position, and it's not a plane having a linear velocity and a smooth sailing as in a "normal" FG session.
if you look at the ground from the plane view, you'll see a saccaded movement, ie the position doesn't change during a bunch of FG frame .
the solution is:
- to use the external input, and compute the plane's position each FG frame, from last received position and velocity,the same way it's done in aimp code, so a bit of c++ work is needed
- you need to cheat the mp protocol, to send packets with the same fdm states as received in input (optionnal).
an other way is to have simulink send directly the two planes positions as mp protocol paquets, and then you just have to do a run with the obs and follow the 2 planes, if you only need FG as a external visualisation tool.
or you can mix both, having two fg session receiving from simulink, the sending with mp protocol to a 3rd fg used to visualise, in this case you need to be sure the mp protocol use the fdm states provided by simulink (position, orientation, velocity and timestamp at minimum) to have coherent time-space relations.
The first part is in my long term todo list, but with my coding speed, there can be years before a fg integration
jano