Aircraft position error (AJT820 approaching TTPP)


A hundred aircraft a day arriving at my local airport (TTPP) are displayed properly on flightaware, and on a PC connected directly to a local Flightfeeder.

But then,… as shown on the above flight for Amerijet 820 this morning, an aircraft is shown more than 6000m off the centreline on finals.

The very next aircraft approaching TTPP displays properly. The latitude in the tracklog above (10.694N) reflects the displayed position on the mountain range, 6000m north of the runway. Runway 10 threshold is at latitude 10.5953N.

There is longitudinal error also.

This has been happening for around 2 years. Scared me to death the first time I saw an aircraft making a final approach into a mountain. Visual observation of the tail beacons on the correct approach path put my mind at ease… and thought it might be an error with the Flightfeeder Blue.

But I recently received a second feeder (Flightfeeder Orange, v7.1). Installed for test purposes about 100m from the first, prior to being shipped to its final destination at another airport. The PC connected directly to that receiver showed the same position error for AJT820.

Can anyone explain to me what the cause is? Is it in any way serious?


And now… another. … /TNCC/TTPP



And now… FAA Canadair Challenger aircraft in the pattern: dated 21 June. Wish there was a way to post a screenscrape!


The usual cause of this is that the GPS position information is missing or unreliable so the transponder has switched to sending the inertial navigation data.
Inertial systems accumulate errors at a rate of something like 0.5-1 NM/hour.


Is there any way to identify that status (INS-derived, or GPS-derived) from the data packets? Can’t imagine it being too difficult to change the colour of the dump1090 plot to a different colour based on the accuracy (or source) of the position information being plotted, would it?


You can sometimes guess at it from NUCp values (which dump1090 does export in the json) but there’s no hard-and-fast rule for good data vs. bad. Often a NUCp value of 0 means uncertified (and so not safe to use for separation) rather than bad data.