remove NAV_GPS_GLITCH_DETECTION

[stronnag]

Recently I've been presented with a number of BBL that exhibit a huge number of GPSGlitch oscillations (on/off); often glitch for c. 3sec, then OK for c. 0.2 secs repeatedly. It occurs to me that GPS Glitch (which was introduced for 2015 low quality Neo6M and typically MR navigation at speeds below 7m/s) just doesn't scale to modern FW speeds and generates loads of false positives.

Looking deeper: With 5Hz GPS, if you fly > 13.5m/s you will "glitch", even if your GPS is perfect. With 10Hz, if you fly > 25.5m/s you will "glitch", even if your GPS is perfect.

This is not suitable for modern aircraft (FW at least), or even MR at 5Hz.

As Glitch is computed effectively on velocity it seems pointless to try and scale it based on velocity.
Unless someone has a better idea to redeem it, it's time for it to go.

[sensei-hacker]

Do actualglitches sometimes put the craft kilometers away?
Meaning > 300 - 400 kmh is likely a glitch.

It could also be scaled on the velocity over the last x seconds, if one wanted to get fancy. I would think making the threshold about 4X higher would do the trick though, wouldn't it?

[stronnag]

Do actualglitches sometimes put the craft kilometers away? Meaning > 300 - 400 kmh is likely a glitch.

I don't think I've seen a valid GPS glitch since we fixed the (self-inflicted) broken SBAS bug in ?2016?. My famous "amuse the local children with the tri-copter in the tree" incident. Not even the day when we had a local "military playing with GPS jammers NOTAM".

It could also be scaled on the velocity over the last x seconds, if one wanted to get fancy. I would think making the threshold about 4X higher would do the trick though, wouldn't it?

It would likely require the time scaled parameter about 6 times higher for fast-ish (85kph) planes on 5Hz.
Sure, come up with a better way, at the moment it generates false positives for very many real world scenarios.

[stronnag]

And should anyone which to play with a desktop emulation via BBL, attached is a little Golang program that plays a BBL through the extant glitch algorithm (requires blackbox_decode on the PATH). Instructions in the source.
glichtest.zip

[DzikuVx]

I suppose we can disable this for now for sure. I will take a looks at this later maybe

[breadoven]

Not too clued up on the GPS glitch stuff but have noticed it appearing on logs when there were otherwise no obvious flight problems. Seemed like a glitch with the glitch detection.

What real world problem was it trying to solve originally, loss of Nav control or erratic Nav data/log values ?

[stronnag]

Not too clued up on the GPS glitch stuff but have noticed it appearing on logs when there were otherwise no obvious flight problems. Seemed like a glitch with the glitch detection.

Indeed, if you fly at modern speeds there will be spurious glitches.
The modern log I was asked to analyse for this issue was a fast (85kph) plane 2380 second flight. The log had 1140 glitch / no glitch transitions. The each "no glitch" duration was 0.2s (1 5Hz GPS reading); the rest (90% of the flight) was glitched, with possibly downgraded navigation performance.

What real world problem was it trying to solve originally, loss of Nav control or erratic Nav data/log values ?

Unreliable, slow GPS in 2015/2016. Big jumps in reported locations, significant drop outs. The widespread availability of M8N in late 2016 pretty much mitigated the problem.

The original reporter plans to make a similar flight to that above, without glitch detection later this week.

[digitalentity]

Indeed, modern multi-system GPS units (M8N, M9N) don't glitch that often. In fact, I've never seen any significant coordinate jumps for years now. This code is safe to remove now.

[DzikuVx]

Then let's do it :)