FlightAware Discussions

Non-ICAO airports have no support for ADS-B flights; therefore most US airports including FlightFeeder hosts are excluded

Last March we installed a FlightFeeder at Placid Lakes Airport (09FA) so we could see the ADS-B flights that arrive and depart. Unfortunately after the install the ADS-B equipped aircraft arriving and departing 09FA showed on the airport page for Sebring, FL (KSEF) about 15 miles away. We contacted tech support who assumed this must be a bug of some sort and submitted a ticket. After months of back and forth via text, email and phone calls someone finally managed to communicate with the “ADS-B Team” who determined that all non-ICAO airports (the vast majority of them) were excluded from ADS-B position tracking, even those that host a FlightFeeder. This provides little benefit for non-ICAO fields who host a FlightFeeder as the airport page will not show flights unless they are fed from ATC. No data from the FlightFeeder will be posted on the host airport page. While I don’t understand why FlightAware will not include any non-ICAO airports in there position only database including there FlightFeeder hosts and Enterprise customers, FlightAware should be more upfront about this limitation before an airport invests in a FlightFeeder instillation or pays for an enterprise account.

Ironically the FlightFeeder airport featured in FlightAware’s latest ADS-B newsletter SOARING CLUB OF HOUSTON AIRPORT (WALLER, TX) 89TA is not supported. I wonder if the Soaring Club was aware of that before they installed both 978 and 1090 feeders on there field.


That would be like $0?

I get your frustration about the flights not being shown. On the other hand I am sure there are logistical issues with adding all the non-ICAO airfields and flights.


Please let me know where you get that free labor from. Have a lot of jobs here that we would love to get done for nothing. :slightly_smiling_face:

Not saying that ALL non-ICAO airports should be added. The issue is that by policy they are all excluded. That is a lot of airfields, some very busy, that won’t be supported. What is the point of hosting a FlightFeeder when you can’t see the flights it received that arrived or departed your airfield? Is hard to imagine that FlightAware can’t afford to support at least its enterprise, or FlightFeeder customers at non-ICAO fields. Is also a huge amount of data and revenue that FlightAware is leaving on the table for the sake of being inflexible. Really, if an airfield or FBO is willing to invest in the labor to install a FlightFeeder, or pay for an enterprise subscription then it is more than reasonable to add them to the database necessary to support ADS-B arrivals and departures.

I guess some nuance got lost somewhere along the line here.

We don’t exclude airports from position tracking; what you’re probably talking about is that adhoc flights will not pick non-ICAO airports as a possible origin/destination when looking for a nearby airport to associate the start or end of a flight with (which in turn means those flights won’t show up on the airport page, as you mention). This is mostly a practical decision to avoid picking a grass field that sees 1 flight a month over the commercial airport with 200 flights a day that’s 4 miles away. It’s actually a bit more subtle than “ICAO vs non-ICAO” but that works as a first approximation.

The flights are still tracked; and you can still get the raw data & local map direct from the FlightFeeder if you’d prefer; the problem is solely in how we pick origin/destination when that data is not available from other sources. If there’s a commercial deal here that’s being blocked by not having that origin/destination data, then I’m sure our sales team would love to hear from you - there are various other ways we can get that data from you if you need it for a FA TV install, etc.

The Soaring Club install is about traffic awareness, not about having an arrivals/departures page, so this isn’t a problem for them.


Maybe you would be able to make an exception to that rule when tracking includes ADS-B on-ground track data?

Because if a plane is on the ground, even 4 miles or less away should make it very clear which airport it landed at.

I guess one problem is that many small aircraft don’t send a reliable on-ground signal?

Yeah, that’d be the ideal case, but it’s not entirely smooth sailing…

  • we need geospatial data for the airport surface (runway polygons, etc); finding up to date data that has good coverage is hard
  • we need to be able to hear those surface positions, which historically has been the exception not the rule (though there is a bunch of effort going in to getting better surface coverage at airports to help enable this)
  • as you say, smaller aircraft often don’t have a WoW sensor

It’s fairly common to lose tracking of aircraft a couple of miles out from the airport, so the current decision mechanism is biased towards that case.

We also have heuristics that try to decide whether an aircraft “should” be on the ground or not based on groundspeed and altitude, but then that has the opposite problem for small aircraft, helicopters, etc - we’ll never declare them airborne!

1 Like

Ok maybe a couple of ideas:

Even small airports should be more than 2 miles apart in almost all cases.
There shouldn’t be any cases where the 1 mile circle for a small airport touches the airport surface for a commercial airport.

So placing a flight with a very small airport could be tied to these conditions:

  • WoW sensor signals on ground
  • Track is within 1 mile circle of small airport

As a substitute for WoW signal one could also use low ground speed, verified by checking two successive ADS-B position and time delta.
This might trigger for balloons, though i’m not sure how relevant they are.

That should at least help when there is a receiver covering the airport ground.
It would in doubt revert to the old behaviour, thus should not cause any problems for commercial flights which aren’t tracked down to the ground.

You mean the labor to build the devices and maintain the running system of servers and software?
Oh, for that labor to be free is fine, since is other people labor, but because you have to zip-tie a small antenna on a pole you got outraged…

This is the a great example of entitled mentality.

If this was his attitude about the free stuff here on the forum (shoot first ask questions later), I can’t even imagine how will it be supporting him, when he will be a paying customer.

Probably that’s why I am an engineer and not a sales person.


Thank you for the reply.

I certainly can understand why you would not want to include the one flight a month airport in your example. The question is why are all non-ICAO airports always excluded?

For the example airport I provided (09FA) the nearest ICAO airport is over 15 miles away. 09FA is very active with numerous GA, a busy agricultural operation and even some jet traffic. Most of these aircraft do transmit air/ground as required by the FAA AC on ADS-B installs. Legally they are required to; however, I can imagine there are some faulty installations out there. There is a FlightFeeder instillation on the field, so surface coverage is not a problem. Also, this airport happens to have good geospatial data.

The other issue is that since the FlightFeeder has been installed here, aircraft that do land at 09FA often show up on the Arrivals and Departures list for Sebring (KSEF) over 15 miles away causing confusion for your customer there. Am sure that adding 09FA to the appropriate database would also fix that problem.

Would it not be reasonable then to include select non-ICAO fields that would be of good benefit like the example above, also meeting certain criteria like having a FlightFeeder installed, numerous operations, and a specified distance from another busy airfield?

1 Like

I agree with the simple opinion that feeder-equipped airports should be FA airports. The FA feeder settings page already has a “nearest airport” field - what’s the purpose of this field?

1 Like


Perhaps with some older mode S installs done previously there was no Air/Ground detection, Weight on Wheels being one way. I understand that to be ADS-B compliant, air/ground detection is mandatory. All the ADS-B compliant aircraft that I have seen, big or small, have air/ground detection and accurately transmit air or ground mode. Again, they have to in order to be legal.

To my knowledge all the above criteria are identical for the example airports that I provided. A very good airport vector diagram is avial for both, 09FA actually has better surface coverage as the FlightFeeder is located at 09FA, not KSEF. Based on what you stated, 09FA should actually have better ground detection, yet KSEF is included, while 09FA is not. Also both airports are fairly active.

The only difference seems to be that one has an ICAO identifier (KSEF), and the other has a local identifier (09FA).

In that case, what do you think it would take for 09FA to be added?

1 Like

In practice, we regularly see flaky air/ground detection.

I can pass it on to the flight tracking team, but no promises about when it’ll be looked at. Can you explain exactly what your use case is, so the right thing gets fixed? Do you have a commercial relationship with FlightAware that could be used to drive this change?


That’s good info about the flaky air/ground detection. We are currently equipping our aircraft to be ADS-B compliant. Do you see this with MLAT, or Mode S aircraft, or do you also see it with fully ADS-B compliant aircraft like 1090ES or UAT equipped?

Actually there are two relationships. First, we host a flight feeder at our field (09FA) in an area where coverage is needed for FlightAware. Our intended benefit was so we could see what ADS-B equipped aircraft have arrived and departed to help manage hanger space, and help track the operations at the field for accounting purposes. Second, there is the Sebring airport (KSEF) which may be a commercial customer - also uses our site to track aircraft arriving and departing from there field. Unfortunately, as we discussed before because of the “ICAO only” limitation, aircraft landing here often are included on the Sebring (KSEF) arrivals & departures list.

Though there are other reasons, would think that hosting FlightFeeder here on the field would be enough incentive to include 09FA in the database necessary to track ADS-B arrivals and Departures.

In other words, if an airfield installs and hosts a FlightFeeder, it would only be fair to include them if possible.

@jlhrstv you should be receiving an email from me on this topic shortly.

I plan to install an ADS-B receiver at the small KRAS airport which is 25 miles east of Corpus Christi, TX.

  1. Will the KRAS arrivals and departures get merged with the Corpus Christi traffic?

  2. Will the general FA Flight Tracker map show planes on the ground from aircraft that just landed or planes taxiing for take-off? Checking a few major airports, it looks like FA does not show ground traffic so I’m assuming the answer is no (except for Skyview ADS-B receiver map).

We see unreliable values on both Mode S and ADS-B. I can’t say what proportion of those are meant to be compliant installs because compliance is not something that gets transmitted (a noncompliant DO-260B install will still tell you it’s DO-260B). Also we process data globally. not only from the US; different countries have different requirements.

There are a number of different ways I’ve seen it go wrong, pretty much every combination you can think of.

  • sending CA=6 or CA=7 (in either ADS-B or regular Mode S); this status means “either airborne or on the ground” (aka “I don’t know”) and we outright ignore it for air/ground determination; this is probably the most common case.
  • never transmitting surface position messages
  • claiming CA=4 (on the ground) or sending surface positions while actually airborne
  • claiming CA=5 (in the air) while actually on the ground
  • always transmitting surface position messages (no, really, this happens!)

FWIW, this is what Annex 10 says about the CA field:

When the conditions for CA code 7 are not satisfied, aircraft with Level 2 or above transponders:
a) that do not have automatic means to set the on-the-ground condition shall use CA code 6;
b) with automatic on-the-ground determination shall use CA code 4 when on the ground and 5 when airborne; and
c) with or without automatic on-the-ground determination shall use CA = 4 when commanded to set and report the on-the-ground status via the TCS subfield ( f)).

1 Like