Hi Guys,

Has there been some kind of update to the flight aware data, which now seems to include Aus ATC (ADSB), where before it never used to? It now seems that every flight across Australia is now tracked using the Airservices Australia ADSB system, virtually making any independent feeders (such as my pi-aware) redundant?


I’m still seeing plenty of instances of where my data is being used in aircraft tracklogs …

There might be a problem with your feed??


Thanks for responding Andrew.

I’m convinced flightaware is now utilising the airservices ADSB data across Australia.

Some time ago, when clicking on a plane that was in a very remote location it would show ‘estimated’ locations, if there were no flightaware feeders and it was outside of airservices radar. Now click on ANY plane flying across the country and check the track log, it is all 100% up to date and accurate, no flightaware approximations/estimations.

It used to always show ATC (Radar), but it’s now showing ATC (ADS-B).

Seems we might as well turn off our feeders… :frowning:

My feeder is working sweet.

The coverage map shows radar coverage. Australia has been there for a while. Direct ADS-B feeds from piaware are still very useful, the radar and ATC ADS-B coverage complements it but does not replace it.

Same situation in the UK and the US, it’s not unique to Australia.

Checked out a few track logs and it seems you are correct with Aus ATC (ADSB) making up the bulk of the log entries and independent feeders only showing up as a very small percentage of isolated log entries.
If this is the case then it is sad as i have only just got into this hobby.
If the data is not really needed and is only like a backup to any slight gaps in Aus ATC (ADSB) coverage then it feels like a lot of almost wasted effort.
I will look at more track logs to see how common this is.
Hopefully Flightaware can comment on what the exact benefit is to independent feeders if the data is only used to double check Aus ATC (ADSB) data or fill momentary gaps in their coverage.
I realise lots of feeders do it to compete in the “Top Sites” ladder but i am doing it for the satisfaction of providing data that benefits the users of the Flightaware system.
But it feels pointless if that data isn’t truly essential. :cry:

Generally the feeds from ANSPs are a processed feed, it’s not the raw messages.

Having the raw messages is generally more interesting because you can extract things that that ANSPs aren’t extracting, and you also have more confidence about exactly what processing is being done. So the piaware coverage is definitely useful even where it overlaps with the ANSP coverage.

Thanks for the reply.
I checked quite a few track logs and it does appear that Aus ATC (ADS-B) data is used even where there should be heaps of independent feeder data.
Even in areas where there are large numbers of independent feeders covering that airspace. Eg. Final minutes of approach to Melbourne airport. 83% of track log entries are Aus ATC (ADS-B).

Whereas looking at random flights over the UK it is the independent feeders data that is logged 99% of the time.

Does Aus ATC (ADS-B) data have a higher priority or is it based on signal level, data delay or something like that. Is it the first source to send a location message in that time block that is used?
If the independent feeder positional messages contain more interesting data and are a truer (unprocessed) source of data shouldn’t the Aus ATC (ADS-B) data be used only where there was no independent feeder data?

Not trying to be confrontational, just keen to know the value of the data i provide. If the independent feeder data was the preferred data source then great, i am doing something really useful. If it isn’t then i am just providing data redundancy and that feels much less thrilling. :laughing: Edit: oops, wrong smiley used. :blush: As Oh from the movie home would say “reply all right next to reply is bad design”, Mad right beside laughing is bad design. :slight_smile:

It is delay related, basically the first data to arrive wins. piaware ADS-B processing has between 15 and 45 seconds of delay (15 seconds processing delay on the FlightAware side, 0-30 seconds on the piaware side due to the frequency of reports) before it gets to that point so it will lose to a truly-realtime feed. Improving the prioritization of different feeds is on the todo list somewhere but it’s a little tricky because either you have to supersede a message you already processed, or you have to hold data for a while to see if something better arrives.

Well it seems to me piaware has become redundant in Aus to flight aware. :anguished:

The Airservices adsb is a commercial system, it’s clearly not going to be unreliable where any redundancy is required. … -coverage/

The Aus ATC data provides pretty good coverage, particularly in the center of the country where there are very few PIAwares or other infrastructure for us to leverage.

However, I continue to observe that PiAware contributes a huge amount, particularly to departure and arrival. PiAware is still very important in Australia.

FlightAware has had RADAR in Australia for many years and, of course, had RADAR in the United States and Canada for nearly a decade before beginning the PiAware project.

Thank you for your continued contributions.

Is there anything we can do to reduce the data delay in our feeders?

Where are the delays?

Is it in the feeder waiting for a certain number of messages before sending a batch of them at once.

Is the MLAT processing delaying things?

Would reducing the noise by reducing the amplification speed up the processing at the expense of reduced range?