I have my ADSB local server page set to sort reports by distance, furthest first.
Interestingly, PiAware reported an aircraft over 3,000 miles away!
Zooming the map out it showed what it said was an RAF aircraft off the west coast of Africa. Had Tail Number etc etc.
From my younger days with FM, I believe atmospherics (“bouncing off clouds” etc) can lead to anomalies like this.
I assume the same goes for ADS-B?
(NB - How does one review older / all reported records? Realted, as I’d like to look back over this record, have also noticed a few other interesting (clearly personalized) ID’s recently).
Somehow I don’t put much trust in that report… While 1GHz signals can experience ducting/scatter occasionally, path loss makes the signal undetectable to all but the Gods. Without ducting, the minimum altitude required for 3000 mile line of sight places the target at least in orbit (it’s too early for me to do the computation), but again, too weak for us mortals to decode. I think the amateur radio records for tropo scatter at 1296 MHz are around 2000 km by guys running kilowatts, very large antennas, and cooled receivers.
My favourite bogus report so far was an aircraft at 2700 nm, cruising at 430 kt at an altitude of 86 feet. Must have been exciting! Either that or the report was not entirely correct.
Putting in a plug for dump1090-mutability: that code has a configurable maximum range setting. The default is to ignore reports greater than 350 miles.
This is an interesting area; how much filtering should be done at the local level versus how much should be done at the hub. The tradeoff between “don’t send crap,” and 'you figure it out!"
There’s an argument for filtering what you can at the data collection points (that’s us). Don’t send bogus data upstream. A range gate, for example not sending in reports with distances over 350 miles. Or positions that don’t meet minimum altitude levels, like my example of 2700nm and 86 feet.
Yet I’ve worked on data fusion systems that need damaged and broken data, and work to extract what they can. A “bad” report from me can be combined with a slightly different “bad” report from a station nearby, and combined with history or other information to extract arguably valid data. Think Kalman filters, neural networks, and the like. My record with valid identifiers yet with a position of (0,0) could be matched with another damaged record matching enough of the identifiers and having a position report that fits into a possible flight path.
This is the philosophy behind dump1090-mutability’s --net-verbatim option … it turns off some of the sanity checks (e.g. “fix CRC errors before forwarding” and “don’t forward messages until you’ve seen two from the same aircraft”) so that the hub can apply its own policies. Those sanity checks can require state beyond the message being received, so a hub is in a better position to make the decisions. There’s a bit of a delicate balance here as Mode S messages don’t have a very robust preamble, so noise often looks like a message. The most basic checks discard 90%+ of possible messages - forwarding them all would be silly!
For similar reasons dump1090 never filters the raw position messages even if the higher-level decoding says they appear to be bogus or incomplete - maybe the hub has more info than we do.
For decoded-and-interpreted output e.g. the json output used by the webmap, or the SBS-format feed, or the FATSV feed, the filtering is always done; the assumption here is that if you want to apply your own decisions about how to interpret possibly-bad data, then you should be working with a raw feed rather than an interpreted feed.
