The airspy decoder is multithreaded, it’s just that one of the threads is very demanding of cpu and can’t be split across multiple cores. The other threads use minimal cpu.
How come you get so many mode-s only aircraft near you? I notice that the other guy who’s appeared recently also has a lot. Do you have tons of GA activity or is it a lot military stuff?
I’m between mildenhall lakekenheath honington wattisham and 20 + private airfields
In my experience, that’s just noise being decoded as aircraft which are not really there.
Happens when people use DX mode or there is some interference which creates more bit errors leading to statistically more bad decodes.
You can see it with navzptc’s stats as well.
Almost certain it’s bogus in both cases. Not their fault, but i don’t believe it’s genuine aircraft.
We are talking over a thousand “Other” aircraft a day, no way that even lots of small airfields are that busy.
I saved some screenshots of my stats a couple of months ago when I was still using the orange FA dongle and it seems that the mode-s only ratio is not receiver related as it is somewhat lower now with the better performing Airspy.
Mode Smixer 2 can be used to show the details of Mode S-flights and some of them look quite genuine:
I’m not saying ModeS = bogus decode.
If you have more than 100 messages from an aircraft it’s very very unlikely it’s bad decodes.
Even with 10 messages it’s unlikely.
I’m not sure what the requirements for “Other” aircraft are in terms of the number of messages.
Two messages, with at least one “useful” data item (e.g. altitude, ident, squawk, etc)
Part of the problem here is that once you’ve heard what appears to be a DF11 for an aircraft, the probability of a garbage message for that aircraft being accepted goes up (because after hearing the DF11, other message types with poor CRC coverage like DF4/5/20/21 will also be accepted).
Possibly requiring a few more messages with better CRC (say, at least 5 DF11s or DF17/18s, or something like that) before accepting the track would help here.
Sounds like a good idea. I would like to add a new switch configuring the whitelist threshold. Currently it defaults to 1.
The switch could be -w <N> where N >= 1
That’ll be very useful. I had to back down from -e 10.0 to 9.0 just because of the sheer number of fake decoded planes.
I am testing now. Release in a few minutes.
…
And it’s out. Check v1.59. The defaults are the same as before.
V.159 definitely cut down the amount of bad decodes significantly. More often than not, the bad decodes that I would see had ground altitudes and aircraft originating outside of North America. “-w 3” has cleaned that up. Per 100 AC seen on my dump1090 at any given time, it looks like it has removed about 5-7 entries that otherwise would be showing up when running -e 8.5.
Thanks Youssef!
Mike
Quick update: I added the setting in the GUI version for interactive testing.
The command line version was synchronized to v1.60.
Even DX Mode plays nice with the white list now.
Wow, sure dropped down with “-w 3”. Not sure if that is the best option or not. But certainly cleared things up.
-w 2 is most likely sufficient.
If you are using my graphs, make sure to update them, the logic for plotting these is now more consistent in my opinion.
GitHub - wiedehopf/graphs1090: Graphs for readsb / dump1090-fa / dump1090 (based on dump1090-tools by mutability)
Try different values from 1 to 3 and check what happens.
Ok, will do. I’m going to let each one run at least an hour so we can see a good comparison on graph.
Ok will do that. thanks
You can also edit /etc/default/graphs1090 and at the end set a fixed upper limit for that graph.
# set custom y-axis upper limits for the individual graphs
# for automatic upper limits leave them blank
ul_message_rate=
ul_aircraft=
ul_tracks=
ul_range=
ul_maxima=
ul_rate_per_aircraft=
ul_adsb_cpu=
ul_range_uat=
ul_tracks=2000 should work fine for you with the new graphs.
If you want to redraw all graphs:
sudo systemctl restart graphs1090
Any reason why some of the graphs have min/avg/max values except for ads-b cpu utilization?
Not really.
But i couldn’t add that for ADS-B CPU as it’s also for dump1090.
Also it doesn’t really matter to have an exact number.