iFly GPS Forum

What are the effects of fiiltering ghost traffic--or not--on the display of airplanes you're flying with, either in tight formation or in trail?

On a flight in trail yesterday, I tried it both ways, but was unable to "see" the other airplane most of the time, regardless of whether ghost traffic was filtered, or not.

Later, however, when flying alone, I saw traffic right on my tail with ghost filtering off, so evidently filtering would have been more comforting then.

(I'm not sure this is an iFly issue, however, as I've found ADS-B traffic display to be very erratic on my equipment (uAvionix UAT and iFly 740 and iPhone). It's equally erratic on the FAA's own test site and the various flight-tracking apps. The FAA site always reports that my equipment is working correctly--even when that site shows only parts of my flight track, and almost never when I'm on the ground, taxiing within a few hundred yards of an ADS-B tower.)

I sure wish someone (maybe an iFlyGPS person?) would explain to me/us why this is an issue.  As a retired programmer, I can imagine that the ADS-B system is reporting all targets in an area, and of course your own aircraft will be one of those targets.  There may even be two (or more) targets for your aircraft, one (or more) reported from another aircraft(s), and one from the ADS-B tower.  Who knows?  I don't.

But....  there is data within the target information, including but not limited to your unique tail number and your unique Broadcast ICAO number.  From a programming perspective, it should be easy enough to extract that data from your own ADS-B unit's configuration file, and compare it with target information that is inbound.  If two targets have the same tail number, or if they have the same ICAO number, or both, then that target should be discarded.  If the target information is incomplete (such that a comparison isn't possible), then you have a choice to make:  you can display it or discard it.  If it were me and I decided, in an abundance of caution, to display it, I would exclude it from any alerts that may be set. (And stop me from jumping out of my seat with I hear that collision alert sound!) Perhaps make it purple and flashing, or something, so you can easily notice it (like you wouldn't notice something right on your tail!). 

But since this doesn't seem to be so easy to solve, there must be more to it than I can imagine.  But it'd be nice if someone could explain it to me/us!

I am neither an iFly employee (though I do consider myself an "iFlyGPS person" :-) ) nor a retired programmer.  Nor am I an expert in ADSB data structures.  I haven't even slept in a Holiday Inn Express lately.

But with those caveats out of the way, off the top of my head I can think of at least two things that could complicate the solution to this problem.  One is trivial and one is not, but both are simply user speculation.

1)  If you don't have your aircraft definition filled out in iFly, then iFly won't have a "my tail number" for iFly to filter against.  (Trivial; most users here probably have that defined, though I wouldn't necessarily assume that across the broader and potentially more casual iFly user population.)

2)  Part of the set of "ADSB rebroadcast" data includes targets that are identified by ATC via primary radar reflections and not via direct ADSB-out transmissions.  It may be that some/most/all of these targets do not have tail numbers associated with them.  ATC's systems have long been sophisticated enough to "tag" a radar target with a datablock (including tail number) if ATC's in comm with that flight.  Presumably, the ADSB broadcast system is also sophisticated enough to include this datablock data when re-transmitting these primary return targets.  However, prior to the 2020 ADSB mandate many VFR-only flights would not have such data associated with therm, and even today there may yet be significant VFR-only traffic flying outside of ADSB-mandated areas that are not Mode S or ADSB-equipped and so may not have datablocks associated with them in ATC's system.  When those targets are rebroadcast to ADSB-in receivers in the air, there will be no tail number for iFly to use for disambiguation.

This issue of rebroadcasting "unknown" primary returns could be the crux of the programming challenge.  I don't know how the FAA multiplexes the primary radar and ADSB-direct target data it collects to build its model of traffic in the sky, or how that gets reduced down to the target data rebroadcast to planes in flight.  But I can imagine a number of ways that data latency, data duplication, and especially the possiblily of duplicae targets with different metadata associated with them could cause issues. 

For example:  If ATC collects my plane as a target via ADSB-out with full metadata, then also collects my plane as a target via primary radar with no metadata, and then the ATC traffic system does not manage to filter those two targets and disambiguate them into a single target, then two seemingly-unique and nearly-colocated targets will be appear in the ADSB-out stream.  Software like iFly consuming those multiple ADSB-in targets then have to try to disambiguate those targets with no 100% foolproof algorithm to do it.

I'm not saying that's the actual reason this problem is hard to completely solve.  I'm just saying it's easy to imagine some possible reasons why this problem might be hard to completely solve.