So, I’ve written a database backend system using PHP that grabs the FA JSON data and inserts it into a series of database tables, including one where I track “fun statistics”, such as highest altitude, fastest flight, and farthest-away tracked flight. It then emails me updates on the flights and also if any of the statistics set “new records”.
Today I got bombarded with a ton of emails because UAL 1002 broke all my distance records and set new ones today when it crossed Iowa. However, when I go to the FA flight page and play back the flight…well, go and look for yourself:
Malfunctioning GPS position which is fed into ADS-B.
Navigation relies on IRUs (inertial reference units) and is only corrected for drift by GPS.
That means the computer will just reject the malfunctioning GPS in regards to navigation.
But ADS-B is properly fed from a single GPS source so that is the track you see.
Ahhhhh…gotcha. Makes sense! I did check and the hex codes for the aircraft don’t line up. But good thought! That makes more sense than, “Uh…did it…uh…turn around??”
Yep, this can happen for a few different reasons, a duplicated Mode S address is one possibility. (this happens more often than you’d think, even with airlines)
Ok, BUT…my Piaware picked up this flight as it crossed Iowa and, presumably, followed it, although I wasn’t at home at the time to watch it, but I got the alerts for tracking it. So why does the FA graph show “estimated” throughout its journey over Iowa? Is there some sort of part of the algorithm that, once the flight becomes so “off” of its projected, planned course, that FA goes and stops listening to ground stations and just “fast-fowards” it along its planned route to get it back on track? Or similar?
Else I would have expected it to have a real track through Iowa and as other ground stations picked up the ADS-B transmissions.
Well when it was actually in your receivers range it didn’t necessarily transmit that position.
Also for some of the jumps of the emitted position maybe FA marked that data as bad and waited until the data was considered good again.
The meantime is then filled in connecting to the next valid point.
Yes, that’s the short version; we won’t match positions to a flight if they’re far off where we expect it to be because they’re typically just bad data (wrong callsign, more than one flight in the air simultaneously, etc)
What are the metrics then, I wonder (and perhaps this is more a philosophical conversation than technical), to determine reliability or authenticity of ADS-B data vs. any other measurement system? I mean, the idea is that ADS-B should be supplementing radar coverage and be somewhat of a reliable nature for other aircraft and traffic control to be able to manage the airways – if we have such situations like the above where the data is somehow clearly flawed, how do we detect that? Correct for it? Etc. I mean, if my receiver receives data that says an aircraft is at 90,000’, that’s clearly wrong (unless sleds have taken flight once again), but how would it know? Or anyone else? muses
But good thought! That makes more sense than, “Uh…did it…uh…turn around??”