ADS-B flight paths are sometime wrong

FlightAware ADS-B Flight Tracking
1

Hi,

Occasionally I notice ADS-B flight paths are shifted, i.e. wrong.

By way of explanation, I unfortunately live under one of the newly designated NextGen focused arrival vectors. Before NextGen, flights were dispersed over several miles on random vectors above my (previously) quiet rural Island; I never even noticed them. Now half of the traffic coming into KSEA follows a precise RNP North/South track just slightly East of me. They also reduced altitude ~35% to reduce downwind legs.

Anyway, this means that all arrivals on ADS-B always follow the exact same path over my house, so when dump1090 shows a flight shifted a few thousand feet to the West it really sticks out. Further it’s very easy to visually confirm this just by looking up. One path is slightly East of me and the other a little West.

Some examples are DAL2210 on Feb 26th, SWA3857 on Mar 12th, and DAL1768 on April 1st.

One piece of evidence (beyond my visual confirmation) of this is the ABS-B path showing DAL2210 landing in a neighborhood a mile West of the airport, which clearly didn’t happen:

1037×1513 463 KB

Another piece of evidence are the primary radar tracks compared to ADS-B. The port operates a tracker web site based on radar. Below are the two tracks of SWA3857, ADS-B vs. Radar:

1043×1215 448 KB

1019×1117 400 KB

Now as to the source of the error it’s tough to say if it’s a problem in the plane or a problem in the PiAware software or even a bug in the RTL2832U chip.

However this morning it happened again to flight DAL1768:

1037×1389 252 KB

1037×1279 353 KB

and it’s not just the same flight number as a week earlier; it’s the same plane(N547US). Note the two dates for DAL1768, April 1st and 8th, are the arrivals in Seattle. The departed Hawaii the previous day.

Does this prove it’s a fault in the ADS-B equipment on the plane, or could it still be on our side?

This brings serious doubt to the idea that primary radar can be scrapped in favor of ADS-B. Instead of a single centralized and secure radar facility completely under ATC’s control, the safety of air traffic is now completely dependent on every single ADS-B unit in every single plane performing flawlessly, with ATC having no direct control over them.

Any theories on what could be happening here would be appreciated.

Thanks,

David

2

This generally means that the aircraft is using an inertial source (INS) for the position it reports; inertial navigation systems drift over time; it’ll generally be worse for arrivals because it’s been drifting for longer.

There is some data in the ADS-B messages that indicates the reliability of the position information (NUCp/NACp etc) which is sourced from whatever is generating the position (those systems have a good idea of how accurate they are). dump1090 doesn’t currently display that but it is decoded and you could pull it out of the json data.

Note that primary radar is not particularly precise and secondary radar requires correct operation of the aircraft’s transponder, so relying on correct operation of the aircraft’s systems for safe operation is not a particularly new thing. If an aircraft is reporting degraded ADS-B position information then ATC will need to give it greater separation and fall back to other systems to work out where it is.

3

Interesting. I didn’t even realize ADS-B used anything other than GPS as a data source. The word “inertial” doesn’t even appear on Wikipedia’s ADS-B page.

Some part of the navigation system on that plane was working as it managed to fly the HAWKZ flight plan locking into longitude 122.455367 heading due North – just like every other West side arrival to KSEA.

David

4

I would guess that it’s dependent on exactly how the transponder is wired into the main avionics. It’s conceivable that the GPS avionics doesn’t provide information in a form that can be used by the transponder, so it never got hooked up.

I’m not familiar with the exact US requirements for 2020, but elsewhere e.g. Australia has progressively tighter requirements for ADS-B as time goes on - see e.g. casa.gov.au/standard-page/key-timelines, they are moving everything towards ADS-B with a good GNSS position source. So you may see aircraft with older ADS-B upgrading their avionics as 2020 approaches.

5

Historical flight track information on FlightAware seems to use FAA data when only MLAT was available.

However when ADS-B is available it just uses that. Perhaps FlightAware should check the json data for the indicator of low ADS-B accuracy and use FAA data instead. Since it’s historical, the FAA delay doesn’t matter.

6

In addition to the ADS-B source accuracy issues, radar has errors up to about a half mile laterally.

The FAA data isn’t intentionally delayed anymore, but it does lag a little more than our ADS-B reports.

7

If anybody who deeply understands ADS-B has a moment in their copious free time (sarcasm intended) it would be nice if they could update Wikipedia’s page on ADS-B. For instance it says, “The system relies on two avionics components—a high-integrity GPS navigation source and a datalink (ADS-B unit)”.

The impression out there is that ADS-B is synonymous with GPS and don’t realize it just describes the equipment and protocol for transmitting the data, not the source of the data. Wikipedia is very often the first stop for learning about something, so a small improvement there could reap large gains in understanding.

Thanks,

David

8

The problem with wikipedia is you need a source for the information. Finding out what airlines are doing with their avionics is a difficult task. They usually don’t publish that.

Maybe a good addition to piaware, would be a boolean switch to ignore aircraft sending out data with low accuracy, and not forward these guys upchannel. Maybe just ignore the squitters and switch to MLAT when quality is marked low.

9

The problem is that 80% of the time when the data is flagged as “bad”, it’s actually fine, so we’d be throwing away a ton of useful information. Even when it’s wrong, it’s usually not so wrong that it’s useless; a position that’s a few km off is still fine for estimating ETAs and declaring aircraft arrived etc.

I would speculate that this is what happens when the GPS+transponder combination isn’t certified to the level where regulatory bodies are willing to let you claim one of the useful accuracy/uncertainty categories.

edit: in my completely unscientific snapshot right now, I see 18 ADS-B aircraft, of which 15 report NUCp=7 (Rc<0.1NM, HFOM < 0.05NM, “5 nines” integrity) and 3 report NUCp=0 (Rc>=20NM, HFOM >= 10NM). The ones reporting NUCp=0 seem to have plausible enough data, almost certainly not >=10NM out.

10

Usually the exact location is shown on the sign of a parking position. Pilots can adjust their INS prior to departure. During the flight, the INS position drifts away from the true positions. If the transponder is not linked to GPS but to the INS, the ADS-B position can be significantly wrong after a long haul flight. That’s why most of the time those flights are wrong here in Frankfurt.

The problem with implementing something in piaware is, that transponders are sometimes “lying” about their capabilities. When analyzing the values, aircraft claim to have a good position and time source but they have not and vice versa. The same problem exists with Mode S and the flight ID, the 25ft altitude resolution or enhanced Mode S registers.

11

In another non-scientific snapshot in ORD airspace, here’s what I’m seeing. First column is # of planes, second is the NUCp code.


$ curl --silent 'http://localhost/data/aircraft.json' | jq '.aircraft] | select (.mlat | length==0) | .nucp | select (.!=null)' | sort | uniq -c
      1 0
      2 5
      3 6
     24 7
      2 8
12

crikey, I didn’t realise inertial nav’ systems were still around :slight_smile: I remember them in the Harrier GR3, where you could take position fixes to update the internal map location, so as to account for the gyro drift etc.

13

as of 3 years ago when I retired most of the new a/c went out with some sort of Inertial system. Its all Laser driven but still the same. But there is a ton of other stuff that interfaces with them to the FMC to keep the planes where they belong.

14

This data is typical of older 767s and 757s. I recall “seeing” such aircraft landing a few miles north of runway 28R at EGLL around 4 years ago. Weird!

IIRC it was transatlantic flights where the errors accumulated over a longer period of time. I found discussion at the time about INS being the cause.

Seems like it is still happening :smiley: