I stopped looking at the global stats, I’m still in the top 50 but I feel I don’t deserve it because I recently understood that a part of my ranking was based on unintentional bogus ‘other’ messages. Luckily this has stopped thanks to the new airspy software but it’ll take a couple of weeks to drop far enough before I know my ‘true’ ranking.
Yes, it was just a check for me. Stats depend primarily by the location so it’s best to compare with people around you.
I had also no idea my stats were also had bogus “other” messages
now i know things look better and still adjusting
Now we just need Flightaware to fix their filtering so the leaderboards aren’t messed up by artificially high figures from misconfigured receivers - not that it actually matters too much.
Yeah, I fully agree that FA should filter out this erm… monkey business
Test with the new version in 1.70 !
I have the impression that on the value -3 the graphs in green fall sharply, and if I put -2, there is still a lot of red zone.
Or is the new version in 1.70 that captures less signal causes this fall in the green zone ?
Because there is really a big difference with the previous version (the zone just before -3).
Are you just restarting the airspy or are you actually rebooting??? I have noticed a couple of times that just restarting the airspy after an option change, just doesn’t quite work for whatever, because an immediate reboot, seems to show a better “reaction” to what I have done …???
If you have lots of red, some of the green is bogus as well.
Running a high -e number necessitates good filtering, with lower preamble filter thresholds it’s not as critical.
-w 3 should be the default. I’m not sure if
-w 2 or even
-w 1 are ever a good idea.
(well except if you want bogus aircraft)
I don’t think
-w 3 will cut any legitimate aircraft.
A position message (half a position) which doesn’t need to have an CRC error corrected, immediately passes the filtering with -w 3 or -w 4.
A position message that needs to be CRC corrected will give you a score of 2, just like an All Call reply that didn’t need a CRC error fixed.
All Call replys with one fixed CRC error still give you a score of 1 for that aircraft.
So it’s very easy for real aircraft to pass get on the whitelist with the first few messages you will receive from them.
Often they are instantly on the whitelist if it’s a position message you are receiving.
(when a plane is on the whitelist, messages from that plane are used and passed to dump1090)
Well the “reaction” is actually fake if you restart dump1090-fa or reboot.
dump1090-fa will count every aircraft it sees as a new track when it is restarted, thus the graph spikes. Due to the averaging the spike lasts 8 minutes as it grows smaller.
That’s what happens to me. I guess it is enough to restart just the airpspy_adsb?
Yes, it appears to be, but now that I have seen that the option you have just done, might not actually start working, I now reboot to be sure.
If you don’t restart dump1090-fa, MLAT might have a short hiccup until it detects the timestamps have started from zero.
That’s the only downside to restarting only airspy_adsb.
But not restarting dump1090-fa is the best option if you want to compare airspy options as the graphs don’t hiccup.
What are you restarting, maybe you are using the wrong command?
Save the configuration file /etc/default/airspy_adsb and then use this command:
sudo systemctl restart airspy_adsb
This will for sure change the settings unless you mistype.
But it will take 10 minutes until you see it on the graphs, they are redrawn every 4 minutes only, plus the averaging and some other stuff they lag a few minutes behind.
Sorry working nights here right now, which is why I haven’t been keeping up with this thread lately lol. I’ll try it in the morning again and see what I get from the output, I’ve reverted to a previous version for now. To answer yes it is still decoding though but with that CPU usages of course I’m dropping like crazy!
Ah no. But only giving info on whats happening here
Related topic. Now I was restarting my computer today and Virtual Radar Server and I was “reminded” about a feature in the home window “bad messages”. Now at the moment it is showing no bad messages on any of my VRS connected units. What bad messages does this show, anything we have been tweaking???
I am having the same issue with my XU4, my options:- pgrep -a airspy
11501 /usr/local/bin/airspy_adsb -v -f 1 -e 3 -l 47806:asavr -l 47787:beast -c localhost:30004:beast -g 19 -m 20
100% cpu with dropped samples,my previous airspy_adsb version (approx 3 month old) ran at 30-40% cpu.
Okay glad to know it’s not just me @prog, any idea why us XU4 users are seeing this problem in the new build?
I can only recommend you do your homework and debug your own system by yourself, regardless of what you may think is the same problem in other setups you don’t control.
First obstacle (for illustration) is that I cannot reproduce:
Am I seeing things or is your instance not running at 126% CPU, looks like you have 3 airspy process’s running but 24339 looks to be at 126% CPU usage?