non-blocked ADSB traffic verified posted to FR24 - on local piaware map but not FR24

[qcfr]

My feeders are separated by 7.5 nm, and non-blocked ADSB aircraft just drop off the FR24 map below about 1500 ft AGL even though I am feeding them from two separate airports.

Most of the time they overlap, so the same aircraft would be fed from two separate sharing keys until very close to ground.

Each PiAware's FR24 local statistics, FR24 sharing statistics, and heatmap are all good. I know the aircraft are being transmitted by reviewing the FR24 log on each of the Pi's. FR24 is just taking port 30002 from an existing dump1090-fa. All PiAware logs are good, and when I review message output from dump1090, they are good.

I am able to follow ADSB aircraft during taxi at both airports using the local map on PiAware. Both airports are covered by the Class C terminal approach radar of one of them. Chicago Center picks up around 5,000 ft MSL for ATC handoffs depending on the direction of flight.

Apologies if this has been covered before, but multiple searches using vBulletin haven't been very productive.

It doesn't make sense why the better data isn't being displayed from contributors. There are many things I like better about FR24.

Thanks

[Oblivian]

Just shows that fr24 are selective on their mlat sources. FA is not so much. It may also be that there are more fa feeders and less fr24 in the vicinity providing the different mlat timing they need.

Sent from my XT1092 using Tapatalk

[qcfr]

This isn’t about MLAT, I am talking about ADSB

[Oblivian]

Same boat for normal data. We'll never get a real answer other than some pointing to a FAQ somewhere that blanket covers it.

But likely same reason everyone thinks the stats page doesn't match their long distance contacts.

I suspect as the data is evaluated periodically there's some 'quality filtering'. And unless in the stream the data meets criteria it's probably ignored

For instance we know 2 'blips' a second is the norm from a transmitter. So you have 10 opportunities between uploads of data not meeting a criteria in a 5 second space. Say it monitors 3 consecutive uploads for continuation of previous theres 30 opportunities all of a sudden.

Like, in a 5 second collection, 2 of the expected packets missed due to outter edge/trees and so on.. |..xx.| we know will likely still show on VRS and so on when it immediately re-establishes and join the plot on the map as you can separately specify to have 10sec-5min timeout between loss of signal (this is where the bung 'animate aircraft' tracks come from)

But given we don't have that option server side its possible FR24 require consecutive updates with a different threshold |.....|.....| may be a case of 'yay awesome data' when |..xx.|..x..| may not

[qcfr]

So I actually look at the raw data and know that ADSB messages comprise multiple message types and the message types I’m talking about are 3 and 7. They contain lat/long, speed, Altitude from the adsb encoded message from the WAAS transponder. I’m a pilot and engineering background. There’s no excuse not to use the good data decoded by my receiver.

Here are some sample messages that if they are compared to the previous transmissions (for a sanity check) would be evident that they are quality data and should be used by a service that wants to have the best data:

MSG,3,1,1,A11F59,1,2018/06/10,20:51:52.683,2018/06/10,20:51:52.739,,36925,,,42.18800,-91.25500,,,,,,0
MSG,8,1,1,A39AB4,1,2018/06/10,20:51:52.683,2018/06/10,20:51:52.739,,,,,,,,,,,,0
MSG,4,1,1,A06B48,1,2018/06/10,20:51:52.687,2018/06/10,20:51:52.740,,,411,261,,,-2048,,,,,0
MSG,7,1,1,A7912A,1,2018/06/10,20:51:52.688,2018/06/10,20:51:52.740,,28000,,,,,,,,,,
MSG,7,1,1,A01112,1,2018/06/10,20:51:52.710,2018/06/10,20:51:52.747,,35000,,,,,,,,,,
MSG,3,1,1,ADC9B6,1,2018/06/10,20:51:52.713,2018/06/10,20:51:52.748,,34025,,,43.06184,-90.63695,,,,,,0
MSG,3,1,1,A1B519,1,2018/06/10,20:51:52.719,2018/06/10,20:51:52.749,,34000,,,42.15848,-91.21018,,,,,,0
MSG,4,1,1,A7912A,1,2018/06/10,20:51:52.729,2018/06/10,20:51:52.752,,,470,269,,,0,,,,,0
MSG,7,1,1,A7302F,1,2018/06/10,20:51:52.732,2018/06/10,20:51:52.753,,30975,,,,,,,,,,
MSG,8,1,1,AD18DA,1,2018/06/10,20:51:52.737,2018/06/10,20:51:52.793,,,,,,,,,,,,0
MSG,7,1,1,AC78B0,1,2018/06/10,20:51:52.739,2018/06/10,20:51:52.794,,29000,,,,,,,,,,
MSG,3,1,1,A39AB4,1,2018/06/10,20:51:52.751,2018/06/10,20:51:52.797,,29000,,,43.65454,-90.10954,,,,,,0
MSG,4,1,1,A7302F,1,2018/06/10,20:51:52.753,2018/06/10,20:51:52.798,,,483,97,,,-128,,,,,0

So you can see that ADSB transmissions comprise multiple message types and the decoded data from dump1090 is: Message Type, the HEX ICAO code (programmed into the transponder, including Mode S), timestamp, then data examples:
Message type 3 would be Altitude,Lat/Long (required to be from WAAS receiver on the airplane)
Message type 7 is showing timestamp+Altitude
Message type 4 is is TAS, Heading
and so on.

The key from a software development perspective is to perform a sanity check, and see if the feeds from the ATC are along the trend line of the ADSB feeder station. MLAT is a whole different story.

These are from a few minutes ago UTC-5, but I get 120/180 positions per minute that I'm transmitting on a slow time period. Every HEX ICAO code ID from each airplane would require a few messages to get the whole story and it's the International Standard for ADSB.

[Oblivian]

Yeah well. Like everything else. Its a big unknown. And asking the question even hear will fall on deaf ears.

I like many others figure, I'm uploading. I get an acct as kickback. Not my loss if the system is too picky.

Even if you watch the app logging processing more and more I'm seeing 'x ignored due to data overlapping'. So pretty obvious not everything is being evaluated for display.

[Anmer]

Your PiAware Skyview map shows what your local receiver is picking up. ADS-B, non-positional Mode-S and, where possible, MLAT plots that your local data has helped achieve.

The FR24 public map shows what FR24 decides to display. And as Oblivian has alluded, only FR24 knows what criteria is used.

Many use their local display, such as Skyview, BaseStation, VRS etc, to track local movements and FR24 (and others) to "see" beyond the local vicinity.

Influencing FR24 through this forum isn't a productive option, not these days.

[Coxy]

That's the path ill soon be doing too, a shame considering that the FR app is the best in regards to Aircraft Silhouettes, back ground layers, UI etc and beats apps like Flight Aware hands down in that department. However the Flight Aware MLAT return is far more beneficial esp if you live near a GA airport. Surely both FR and FA know that a large source of their traffic is supplied by people using Dump1090 etc and we like to tinker around with our own apps, maps, silhouettes etc, especially with the hidden aircraft on both Apps.

If Fr had Mlat return i wouldn't use FA and if FA had a better user interface i wouldnt use FR. !!!