SimVar “GPS GROUND TRUE TRACK” has become very noisy on the ground

Version: SU/AAU/WU XX -

Frequency: Consistently

Severity: Low

Context: Can beviewed in any SimVar watcher

Bug description:
I’m assuming this is a side-effect of the new ground physics with planes jittering very slightly on their tyres. That motion of the plane (probably) causes the GPS GROUND TRUE TRACK simvar to bounce (pun intended) rapidly around all points of the compass.

Of course the theoretical computation of GROUND TRUE TRACK in a sim using millimeter-resolution position and millisecond updates of that simvar WILL produce those artifacts, but a real GPS output would (a) not have that spatial or temporal resolution of it’s incoming info and (b) I’d expect most GPS outputs to apply some smoothing to GROUND TRUE TRACK anyway to avoid digital glitches possible in any real-world device (such as between successive location updates which can jitter on any real-world GPS, but the device won’t allow that to make GROUND TRUE TRACK essentially meaningless.

I noticed this issue first in the MSFS MapInstrument when set to Track Up, the map spins wildly as the plane spawns into the sim. I’d argue that’s a problem with the simvar rather than the map.

Repro steps:

Open a simvar watcher, watch A:GPS GROUND TRUE TRACK, spawn into the sim in the Cessna 172. For the first few seconds the simvar will whizz around to essentially random values and then settle down.

Private attachments: Send a PM to @PrivateContent with the link to this topic and the link to download your content

BTW as a suggestion for the most convenient fix, it might be the best coding effort / benefit be with setting GROUND TRUE TRACK to TRUE HEADING when (ON GROUND and GROUND SPEED < some small number) rather than coding a smoothing algorithm.

1 Like

or, what maybe another option is to keep updating it with its initial (possibly Random) heading, while Ground speed is below a threshold.

Question then is – what does the RL unit do, and simulate that …

Have the same issue with my GPS Compass APP on my head unit in my car. when I 1st start the car, and am not moving, it cannot calculate the direction I am moving in, because I am not moving !!

For that, my solution was to REMOVE the Compass needle, when it did not have valid Direction information.
To me, No Needle is better than a wrong needle>

You could also code the GPS to do a similar thing, NOT display any value, or a “----” when it is not getting the the required changing sequential position to calculate a “TRUE GPS TRACK”

we could talk about the nuanced options of what choices do the manufacturers make to keep the ‘Ground Track’ reasonably sensible, but I doubt any of them allow it to spin around wildly because they know it will be used for ‘track up’ or other calculations that won’t necessarily have coded to handle those unrealistic rapid changes.

My trusty Garmin 76S I bought a century ago (ok, 18 years) might have an ‘unreliable’ track value at very low speeds on first power on but it wouldn’t go crazy guessing divergent values. That GPS has a magnetometer, even from 2006, which is probably used to provide more clues in that situation, but I don’t know. I’d suspect reassuringly expensive modern aviation GPS’s will be pretty sensible.

For a modern aviation application I think there’s a strong argument to assume the magnetic sensor and the choice of that as a default stationary value rather than a random one.

But in any case a track value that was previously stable but now glitching randomly at 60 fps is a much bigger problem. There won’t be much MSFS code out there that natively looks at the ground track simvar given the extremely niche hobby of coding nav instruments, and the issue can be coded for in each instrument, but given over 100,000 downloads on half-a-dozen planes it’s tricky to go back and distribute fixes to work around a problem that didn’t previously exist.

1 Like

This problem also exists for real avionics whether they use GPS (GA) or IRS (airliners and higher end GA) to determine track. It is often solved by outputting the heading as the track below a certain speed. As an example, one model of Honeywell ADIRU outputs the heading in the track data words instead of track below 50 knots groundspeed.

The WT avionics also take this approach.