Newbie: Sudden drop in altitude, suggested cause please?


#1

Hi, I’m newbie here, apologies if this is the wrong board. I’ve done a search for FAQs and existing threads, and can’t find anything - maybe my technique/terms are amiss as I’m sure this isn’t a first:

Tracking my little brother on BA193 (BAW, EGLL / LHR - KDFW) this morning on his first international flight, noticed the altitude drop from over 30,000ft to just under 4,000ft.
I was wondering if this was due to flying over very high ground or something similar, but through reading your FAQs I read the wiki page on it being a barometric altitude rather than sea level or ground level.
This led me to think that the data appeared this way due to the air pressure/weather, rather than an actual altitude change for the plane, but could someone please shed some light on my thoughts and possible causes? I’m intrigued by the science if you have the time please.

I’ve added a screen shot, with the anomalous data in the centre so you can see the flow of data around it:

As you can see, the latitude and longitude seem out of sync with the general pattern, which I thought may mean it’s just a glitch in the matrix…
Thank you


#2

It’s either just outright bad data, or more usually due to aircraft losing GPS lock briefly and falling back to inertial navigation for position reports.
The inertial position drifts from the true position over time, so this shows up as a sudden jump in position (and then a jump back when GPS comes back)
For some reason the altitude data is often a casualty too when this happens.

You can see another case of this at 11:23 (position and altitude both jump at the same time, then jump back)


#3

I see - Thank you very much!


#4

It’s not a case of the aircraft having a problem or sending bad information, rather it’s the station that’s receiving the transmission from the aircraft that is interpreting the data incorrectly. If you notice the reporting facility at that time was a FlightAware ADS-B receiver, not a ATC radar facility. ADS-B receivers are great and all, but they’re nowhere near as reliable as the systems used by ATC.

Just to clear up another matter, aircraft don’t just “lose GPS lock” (whatever that means) and revert to an inaccurate INS source. All modern aircraft use multiple forms and sources of positional and navigational technology simultaneously that are constantly being orchestrated to provide redundancy and error checking against each other. Rest assured planes never have a “hiccup” and not know where they are for a moment. :wink:


#5

Actually, I am working specifically on this in dump1090 at the moment, and I can assure you that aircraft do regularly start sending position data that’s offset from the true track with a lower NUCp than normal (i.e. the ES metype changes). Often it’ll drop from NUCp=7 to NUCp=0 (NUCp=0 means “I have no certainty about this position at all”, basically). Usually it is one or two messages, then they’re back to the regular NUCp.

While there are certainly receiver problems around (notably in stock dump1090), this is not a receiver problem.

My best explanation for that is the GPS equipment reported it no longer had confidence in its position (“lost lock” - either because the HDOP has gone out of bounds or it does not have visibility of enough satellites), so the transponder reverted to an alternative datasource.

If you’ve got a better explanation then I am all ears.

At the same time, for some aircraft, they start emitting garbage in the altitude field (of the ES message only). I don’t have quite such a good explanation for that one, since they are usually claiming to report baro altitude, not GNSS HAE - but maybe the data’s taking a different route and the secondary path isn’t working properly. So for the moment at least, dump1090 is going to throw away the altitude data whenever the position data is suspect, too.

For some specific aircraft 80% of the data they send has NUCp=0 and garbage contents (I mean really garbage - if you were to believe the positions they’d be doing loops along the prime meridian at Mach 10). If you weed out the 80% you actually can extract a plausible track.


#6

For example, here’s some completely garbage position data from some tracing I was doing:

global maxrange check failed: 4b390f: even 61440,0 (3) *odd 51482,2898 (8) pos 26.803,-6.770 (3) = 2882.6 km, max 555.6 km
global maxrange check failed: 4b390f: even 61440,0 (3) *odd 51482,2898 (8) pos 26.803,-6.770 (3) = 2882.6 km, max 555.6 km
global maxrange check failed: 4b390f: even 57344,0 (3) *odd 51527,2855 (8) pos 14.602,-6.178 (3) = 4218.4 km, max 555.6 km
global maxrange check failed: 4b390f: *even 57344,0 (3) odd 51575,2810 (8) pos 14.625,-6.207 (3) = 4216.2 km, max 555.6 km
global maxrange check failed: 4b390f: even 53248,0 (3) *odd 51619,2767 (8) pos 2.403,-6.076 (3) = 5567.4 km, max 555.6 km
global maxrange check failed: 4b390f: even 53248,0 (3) *odd 51663,2727 (8) pos 2.405,-6.078 (3) = 5567.1 km, max 555.6 km
global maxrange check failed: 4b390f: even 49152,0 (3) *odd 51752,2643 (8) pos -9.794,-6.082 (3) = 6919.3 km, max 555.6 km
global maxrange check failed: 4b390f: even 49152,0 (3) *odd 51796,2603 (8) pos -9.792,-6.084 (3) = 6919.1 km, max 555.6 km

And an example of a one-off glitch: in this case, the most recent (even) CPR report has NUCp=0, while the last globally determined position was from an odd/even pair with NUCp=7; this position change implies a speed of 8000km/h.

global speed check failed: 394c09: *even 69310,126014 (0) odd 50542,126568 (7) 51.166,-0.344 (7) -> 51.173,-0.375 (0) = 2.3 km in 1.0 seconds, max 1.0 km

(The fields are: ICAO address, even CPR message raw lat/lon/nucp, odd CPR message raw lat/lon/nucp, from->to positions in decimal lat/lon with derived nucp; the star indicates the most recent message)


#7

And here’s NPT022P (400648) doing those loops that I mentioned:

400nm in a few seconds, not bad…


#8

Your original post could have been misconstrued as it made it sound like the aircraft and crew just don’t know where they are when this happens. That’s not true… it’s just the ADS-B system and the people on the ground looking at the signal that don’t know. The flight crew never know that there was a “glitch” and keep on navigating the same as they regularly do. No danger of getting lost etc.

I didn’t go through all of your technical explanation as I just dumped $16,000 into my plane for a UAT IN/OUT retrofit. I’m kind of sick of the ADS-B technical maze by now lol. :smiley:


#9

I have no idea how you read that into my post.