In this track, https://flightaware.com/live/flight/N2871R/history/20210910/1542Z/KJYO/KMQI, the altitude recording jumps from ~4500’ to 10,000’, then 38,000, and back again to 4500’. Obviously a C182 can’t do that. Can’t you filter out anomalies like that?
@jbarrer1, I’ve noticed similar rare, impossible altitude changes in the data from my receiver (Piaware & dump1090-fa) and wondered about them. They’re clearly wrong, but where in the data pipeline the flaw occurs is a mystery to me so far. I tried digging through documentation and many forum discussions about a year ago but didn’t find any good explanation. What most bothers me about them is it seems to only show up in altitudes so far as I’ve noticed. For example, I haven’t seen any momentary wildly-wrong latitudes, speeds, or callsigns, etc.
But, you are certainly correct that regardless of the root cause, one could filter these using software.
In one of the courses I teach, one homework involves giving my students large files of decoded messages (like we see on port 30003 from dump1090) and have them programmatically find those altitude anomalies among other kinds of statistical findings. But there’s an important difference between doing this filtering/correction after the fact, versus in the decoder stage. To do it requires keeping track of every craft’s recent messages and calculating rate of change, plus ideally not revising the anomalous values until after you’ve received subsequent normal-looking messages from the craft. Doing those things properly in the real-time decoding stream could slow it down too much I think, and might introduce new problems.
Possible explanations that have occurred to me include:
- The aircraft’s ADS-B transmitter sending a wrong value, and the receiver is correctly interpreting this “wrong” message.
- The message was sent correctly, but the signal was degraded (interference) yet still accidentally passed the CRC checksum and was therefore kept as valid. If this can occur though, I’d expect we’d see other things besides altitude that have momentary crazy values.
- Same as #2 but it’s a case where the decoder is ignoring checksums.
- A software bug in the decoding
I only have one receiver myself so I don’t have the data of same flight tracks via two receivers to compare the same messages. I’d like to set up that to experiment and see if it can eliminate some of the possible explanations. Maybe I’ll set that up so I can use such variations in the data analysis homework I assign. 
I’m sure the aggregators (e.g. FlightAware, OpenSky-Network, ADSBexchange) must already know the answer to this because they would get hundreds of copies of the same messages from feeders and have to match them up.
- The message types that cause this don’t have CRC at least not in the way DF17/DF11 have CRC
https://mode-s.org/decode/book-the_1090mhz_riddle-junzi_sun.pdf
So for aircraft which send DF17 (aircraft with ADS-B position do) you could just ignore the altitude from other messages if you’re serious.
Just to iterate on the CRC: The CRC for non-DF11/17/18 messages is the 24 bit address (often called hex, icao address) of the aircraft in question.
Now we can check this against a whitelist of aircraft we’ve recently received DF11/17 messages from but it’s statistically much easier to get errors in those non-CRC frames even with the whitelisting.
The number of aircraft for a receiver and some other decoding internals will also change the rate of this happening.
You only notice it with altitudes but you can check all the data in non-CRC frames, they suffer the same issue.
thanks for the info. At least it seems that it’s not the ADS-B source data. we just had a new ADS-B installed in the AC (along with an AHRS and and Autopilot) and I’m hoping that that did not cause these anomalies; that it was on the data processing side.
Looks like you had altitude reporting turned off for part of that flight.
Altitude reporting is sometimes somewhat wrongly called Mode C as this an older transponder type but introduced altitude reporting so the name stuck.
See the FA tracklog: Flight Track Log ✈ N2871R 10-Sep-2021 (KJYO-KMQI) - FlightAware
As a secondary source you can see it here, no altitude for a portion of that flight: ADS-B Exchange - track aircraft live
In the FA tracklog you can see the positions are all from the “reporting facility” ADS-B.
ADS-B positions always carry an altitude if the transponder is transmitting the altitude.
Thus it would be technically easy to ignore altitudes that didn’t come with the ADS-B position.
Anyhow … easy solution: Don’t turn off altitude reporting and the bogus altitudes that typically arise from bit errors in decoding will likely be drowned in the sea of valid altitude messages.
couldn’t you simply use an exponential smoothing process? You store the last smoothed value, S(n). the next data value, X, comes in and if X differs from S(n) by more than some threshold, Z, you set X= S(n). then, using a smoothing value of say .2, set S(n+1) = (.8)S(n)+.2X.
If X is altitude, then because the data are arriving so frequently, Z could be a small number like 100.
Yep. In particular we suppress use of non-DF17 Mode-S altitude data when DF17 altitude data is available. If you’re not transmitting any altitude data at all, then that does not help and Mode S altitude “data” (actually noise) with poor CRC correction might be accepted.
Internally we have various quality indicators that track how reliable data such as altitude is, but that’s not directly visible on the tracklog.
Well, if you don’t care about reporting the actual values sent by the aircraft you could do that.
you report the actual value, X in my example, unless X is too far away from S(n) in which case you report S(n).
Turning off ADS-B not something that can be done in my aircraft. The ADS-B is powered up with the master switch. My concern is whether or not the new ADS-B unit was misbehaving. The fact that the FlightAware data is absent could be because it wasn’t sent, wasn’t received, or improperly processed.
Either the altitude wasn’t getting to the transponder or the transponder was configured not to transmit altitude.
That’s a setting that is available as i believe it was quite some time in the past what you would do on the ground.
It’s still used if the your barometric sensors are going haywire i suppose.
I linked you a 2nd site, neither FA nor this 2nd site has altitude data for that part of the flight.
That’s pretty clear, isn’t it?
If the transponder had sent that wrong altitude (44000 ft or whatever) consistently for a couple seconds you’d see it on the other site that shows the altitude as not available.
Just like FA shows the altitude not available for most of the time altitude reporting was switched off.
Thanks for taking the time to respond. You made me wonder how the new ADS-B unit is getting its altitude. Two weeks ago we installed a new JPI EDM830 engine monitor, an ADS-B ( Stratus ES ADS-B in and out), two Garmin G5s (with AHRS) and a Garmin GFC500 autopilot. It may be the case that the Stratus is getting altitude from the G5 primary flight display. In that case it would be possible for the pilot (I was not flying when this occurred) to misuse the G5 PFD and temporarily change the barometric reference setting; although getting it to read 40000 seems unlikely.
I will keep investigating. I notice in some of the other flights there are tiny altitude spikes during times when the altitude is otherwise very constant. So something is not working correctly. For example, in this flight, flown by an x-military pilot, you see the altitude very constant with the autopilot, but with tiny altitude spikes (e.g. time 21:34:13) that are obviously data problems, not actual altitude deviations. N2871R Flight Tracking and History 17-Sep-2021 (KJYO-KHPN) - FlightAware
thanks again.
The 40000 ft didn’t come from the transponder, just ignore that single data point, that’s just how receiving Mode-S works. If you filter the data too much you don’t see what’s going on. The 40000ft was just noise.
Anyhow as i tried to convey before:
From around 1544Z to 1607Z the transponder was working, but no altitude was transmitted.
The altimeter setting never affects the altitude transmitted by the transponder, that’s by design.
ATC uses the local altimeter to correct the transmitted altitude for controller display.
FA reports the uncorrected altitude. (so does adsbexchange what i linked earlier)
That’s a red herring, see the data source on the right, it’s not ADS-B i don’t know where FA gets it from … .just ignore it.
The most likely scenario:
That’s your unit Stratus ES yes?
2.4. Mode selection keys
The table below describes each transponder mode. These modes will
automatically transition for various phases of flight. Unless otherwise
instructed, no action is needed.
Mode Key Description
- Off PWR Stratus ES/ESG is powered off.
- Standby SBY Stratus ES/ESG is powered on and does not send
responses to any ATC interrogations. - Altitude ALT Stratus ES/ESG is powered on and responds to all
Mode A/C/S interrogations. Altitude is reported. - Ground (none)
Stratus ES/ESG is powered on and in ALT or On
mode, but does not report altitude. Ground mode is
automatically detected. Press the ALT or ON key to
override Ground mode. Press SBY to remove this
override. - On ON
Stratus ES/ESG is powered on and responds to all
Mode A/C/S interrogations, but altitude reporting is
suppressed.
So if someone presses the “ON” button instead of the “ALT” button, the transponder won’t send altitude.
A ha! thanks for looking to that. I will make sure the other pilots are aware. This is a shared-ownership aircraft.
I’ve been retired for about 11 years and it was about another 10 before that when I was involved with ADS-B stuff at MITRE. I have forgotten more than I ever knew ;).
That’s some stupid button naming …
This topic was automatically closed 365 days after the last reply. New replies are no longer allowed.