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.
Attachments:
none 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.
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.
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.
In the case of the C172, the track is computed by the Working Title avionics framework.
Check the getInstantaneousTrack function in msfssdk.js
If you select the C152 instead, you’ll have the track computed by the sim.
The sim does not update the track when the aircraft is stationary.
Ultimately, GPS GROUND TRUE TRACK is supposed to be computed by the avionics so you will never have any guarantee that its behavior is consistent across all aircraft/instruments.
You want to either:
apply your own filter on top of the simvar value you receive
Thanks but of course the algorithm to calculate a sensible GPS GROUND TRUE TRACK value would take only a few seconds whether that was in JS or XML RPN.
There are two issues here - one pretty basic and another structurally problematic:
There is existing html/js code that relies on GPS GROUND TRUE TRACK that predates its jittery behaviour after the introduction of the new ground physics. An example of that is the Asobo MapInstrument.
There is simply no alternative in MSFS for html/js gauges requiring a controllable map other than using the NetBing map and the MapInstrument. Of course WT representatives recommend their entire typescript-compile-to-javascript toolchain that they chose for their nav instrument development, but that has essentially made their code unusable outside of their proprietary toolchain.
What other developers have done is place a WT instrument (the dumbest one they can find) underneath their html/js gauge, simply to get a map displayed, and accepting that map has no usable API (unlike the MapInstrument). In effect they’re re-inventing the MapInstrument by using a complex WT product doing the same things using maybe 100,000 lines of JS code that in plain html/js can be done in maybe 6.
I think realistically given the trajectory MSFS is on is the only viable nav gauges will be from Working Title, because at the same time as their proprietary development (i.e. outside of html/js) you can detect an idea that the existing support for ‘plain’ html/js nav gauges should be deprecated.
The easiest strategy for independent nav instrument development given that will be to simply use a different map/API which can be from Microsoft, Google or open-source - it should be noted those can be added to a html/js instrument in maybe 6 lines of JS. There has never been any SDK example of how you could add a ‘WT’ map to a HTML/JS gauge, I suspect for good reason that’s not possible.
I would love to be corrected that there is a Bing map in MSFS that can be used in a html/js code in a few lines of code, with a documented API, but each time that question is conflated with references to how WT develop their gauges using a non-html/js toolchain and if everyone used that instead of html/js then all would be well.