They don’t “stick” to the map longer than 60 seconds. The GUI removes them if there is no messages received after 60 seconds.
They are whitelisted for a longer period in airspy_adsb.
I guess I was remembering wrong.
I thought that, if they are previously selected, then they remain for the duration of t.
I think now that is something else though.
If you have them selected, I think they will stay visible until you deselect it, even though it disappeared hours ago.
9 is probably the next very significant threshold, try that.
But just reducing -t might be the better approach.
It depends a bit if they just come in over time or at once.
I might get you a testing version, i’ll let you know.
It seem that they are somewhat equally distributed over the day. Noticed last night that I had between 5-10 msg/sec according to tar1090 with no aircrafts visible (checked with multiple external sites, the sky was clear of any aircrafts).
I’ll do a change later today.
The super-mega special version that teleport signals from @keithma antennas to my location? That’ll be fine with me 
That’s not what i meant, anyhow technical details.
I know, just an observation that may (or may not) be relevant if perhaps I have too much noise that decodes into bad icaos.
To hopefully fix the above error:
2.2-RC19
- hopefully fix rare hang condition
3 Likes
I decreased -t (currently 90) and raised -P from 5 to 8.
- Number of MLAT aircraft increased significantly, compared to nearby stations that usually follow the same pace.
- Number Other aircraft decreased fairly significantly, probably by a few more than the # of increased MLAT mentioned above
- Number of bogus altitudes increased by raising from -P 5 to 8 and lowering -t with -e in 24/25 range. Seems like fewer bogus altitudes than what I’d get with -P 8 and a high -t value.
- FA Other positions rate seem unchanged. Overall positions are probably about the same, hard to tell.
I’ll try -P 7 with -t 90 next.
Edit: Hmm, but not all my MLAT aircraft look healthy. Some n/a, and one I notice not logging positions but still hanging around. (OPTIONS= -v -t 90 -f 1 -w 5 -e 12 -b -C 87 -P 7)
1 Like
Good morning all. Just a quick one, going out for a couple of hours. Dropped my mhz down to 12 overnight, on my RC18, just to see. Only just starting to get some planes up. Noticed though, from my reference unit still on RC14, 20 mhz, the RSSI for the last 2 hours avg peak is 73.2. The RC18 unit down to 12 mhz average peak 66.9. Plane and position numbers in FA also down for the 12 mhz. Normally their neck and neck with the RC18 generally slightly ahead. All other options for both units not changed. Comments??
Well that C172 is just almost out of sight, see the RSSI.
Nothing to do with the RC or the settings.
FA numbers are affected by skyaware anywhere and are generally unreliable for comparisons.
RSSI for 12 / 20 is different, that’s normal.
So more performance with the 20, I thought so. FA reference as is, realise their data unreliable. Might try 24 later.
My CPU increased by approx 7% after installing RC19. I often see changes of 2% -3% on restarts, but this seems a bit bigger than usual. I rebooted to see if this would bring it back below 90% - minor impact. May just be random impact of restarts/reboots and nothing to do with RC19.
Interestingly, the reboot provided an example of @wiedehopf’s “training wheels” - my fixed -e setting of 11 was over-ruled to establish a connection.
As the above chart and the log shows:
Sep 22 08:00:10 raspi4-1 systemd[1]: Started Airspy ADS-B receiver.
Sep 22 08:00:10 raspi4-1 airspy_adsb[342]: airspy_adsb v2.2-RC19
Sep 22 08:00:10 raspi4-1 airspy_adsb[342]: Listening for beast clients on port 47787
Sep 22 08:00:10 raspi4-1 airspy_adsb[342]: Acquired Airspy device with serial B8B067DC3623901F
Sep 22 08:00:10 raspi4-1 airspy_adsb[342]: Decoding started at 20 MSPS (Gain: auto; Preamble Filter: 11.0)
Sep 22 08:00:11 raspi4-1 airspy_adsb[342]: /!\ Lost 131072 samples /!\
Sep 22 08:00:11 raspi4-1 airspy_adsb[342]: /!\ Lost 262144 samples /!\
Sep 22 08:00:11 raspi4-1 airspy_adsb[342]: /!\ Lost 131072 samples /!\
Sep 22 08:00:11 raspi4-1 airspy_adsb[342]: /!\ Lost 262144 samples /!\
Sep 22 08:00:11 raspi4-1 airspy_adsb[342]: /!\ Lost 262144 samples /!\
Sep 22 08:00:11 raspi4-1 airspy_adsb[342]: /!\ Lost 131072 samples /!\
Sep 22 08:00:11 raspi4-1 airspy_adsb[342]: /!\ Lost 262144 samples /!\
Sep 22 08:00:11 raspi4-1 airspy_adsb[342]: /!\ Lost 131072 samples /!\
Sep 22 08:00:11 raspi4-1 airspy_adsb[342]: /!\ Lost 131072 samples /!\
Sep 22 08:00:11 raspi4-1 airspy_adsb[342]: /!\ Lost 262144 samples /!\
Sep 22 08:00:11 raspi4-1 airspy_adsb[342]: /!\ Lost 262144 samples /!\
Sep 22 08:00:11 raspi4-1 airspy_adsb[342]: /!\ Lost 131072 samples /!\
Sep 22 08:00:11 raspi4-1 airspy_adsb[342]: /!\ Lost 262144 samples /!\
Sep 22 08:00:11 raspi4-1 airspy_adsb[342]: /!\ Lost 131072 samples /!\
Sep 22 08:00:11 raspi4-1 airspy_adsb[342]: /!\ Lost 131072 samples /!\
Sep 22 08:00:11 raspi4-1 airspy_adsb[342]: /!\ Lost 262144 samples /!\
Sep 22 08:00:11 raspi4-1 airspy_adsb[342]: /!\ Lost 131072 samples /!\
Sep 22 08:00:11 raspi4-1 airspy_adsb[342]: /!\ Lost 131072 samples /!\
Sep 22 08:00:11 raspi4-1 airspy_adsb[342]: /!\ Lost 262144 samples /!\
Sep 22 08:00:11 raspi4-1 airspy_adsb[342]: /!\ Lost 131072 samples /!\
Sep 22 08:00:11 raspi4-1 airspy_adsb[342]: /!\ Lost 393216 samples /!\
Sep 22 08:00:11 raspi4-1 airspy_adsb[342]: Dropped samples more than 20 times within 10 seconds, enabling CPU target of 95 % for the next 60 seconds!
Sep 22 08:00:11 raspi4-1 airspy_adsb[342]: You should reduce the preamble filter setting -e or enable -C 90 -E 11.0 to target 90 percent CPU usage.
Sep 22 08:00:11 raspi4-1 airspy_adsb[342]: /!\ Lost 262144 samples /!\
Sep 22 08:00:11 raspi4-1 airspy_adsb[342]: /!\ Lost 131072 samples /!\
Sep 22 08:00:11 raspi4-1 airspy_adsb[342]: /!\ Lost 131072 samples /!\
Sep 22 08:00:11 raspi4-1 airspy_adsb[342]: /!\ Lost 131072 samples /!\
Sep 22 08:00:11 raspi4-1 airspy_adsb[342]: /!\ Lost 262144 samples /!\
Sep 22 08:00:11 raspi4-1 airspy_adsb[342]: /!\ Lost 262144 samples /!\
Sep 22 08:00:11 raspi4-1 airspy_adsb[342]: /!\ Lost 131072 samples /!\
Sep 22 08:00:11 raspi4-1 airspy_adsb[342]: /!\ Lost 131072 samples /!\
Sep 22 08:00:11 raspi4-1 airspy_adsb[342]: /!\ Lost 262144 samples /!\
Sep 22 08:00:11 raspi4-1 airspy_adsb[342]: /!\ Lost 262144 samples /!\
Sep 22 08:00:11 raspi4-1 airspy_adsb[342]: /!\ Lost 131072 samples /!\
Sep 22 08:00:11 raspi4-1 airspy_adsb[342]: /!\ Lost 262144 samples /!\
Sep 22 08:00:11 raspi4-1 airspy_adsb[342]: /!\ Lost 131072 samples /!\
Sep 22 08:00:11 raspi4-1 airspy_adsb[342]: /!\ Lost 131072 samples /!\
Sep 22 08:00:11 raspi4-1 airspy_adsb[342]: /!\ Lost 393216 samples /!\
Sep 22 08:00:11 raspi4-1 airspy_adsb[342]: /!\ Lost 917504 samples /!\
Sep 22 08:00:11 raspi4-1 airspy_adsb[342]: /!\ Lost 393216 samples /!\
Sep 22 08:00:11 raspi4-1 airspy_adsb[342]: /!\ Lost 131072 samples /!\
Sep 22 08:00:11 raspi4-1 airspy_adsb[342]: /!\ Lost 524288 samples /!\
Sep 22 08:00:11 raspi4-1 airspy_adsb[342]: /!\ Lost 655360 samples /!\
Sep 22 08:00:11 raspi4-1 airspy_adsb[342]: /!\ Lost 131072 samples /!\
Sep 22 08:00:11 raspi4-1 airspy_adsb[342]: Push client connected to localhost:30004 (beast)
Sep 22 08:00:11 raspi4-1 airspy_adsb[342]: Push client disconnected from localhost:30004 (beast)
Sep 22 08:00:24 raspi4-1 airspy_adsb[342]: Push client connected to localhost:30004 (beast)
Time to try a fractional reduction in -e, I’ve been adjusting on the basis that it was still integer.
I just remembered I overclocked my Pi late last night. Wanted to see how much -e I could keep while testing higher -P with Pi at 1750MHz.
I think you’ve mentioned overclocking can cause MLAT issues. While journalctl shows no multilateral suspicious activity all day, TAR1090 history shows 25 of 33 MLAT aircraft had callsign “n/a”, most with invalid icao, yet hundreds or thousands of messages for each plane.
I guess probably best not to overclock with MLAT. My daily MLAT plane count ended up around normal with positions looking below normal for the volume.
Quick update on my “others” question earlier.
I’ve reinstalled my testing device and this time i used the Airspy default settings (RC18).
The values for “other” aircraft/positions went down to the level of my other devices.
1 Like
Oh you’re talking about FA anonymizing MLAT results …
FlightAware MLAT Network Announcement
This is normal and has nothing to do with what airspy produces as messages.
You’ll have aircraft with similar or the same altitude showing as ModeS, that will be the “real” aircraft. (unless you participate in another mlat network with full results, then the real aircraft will be MLAT as well)
Might be the compiler version, i’ll look into it.
Had to change how i build as one of my RPi bit the dust.
@JRG1956
Actually, i recompiled RC19 with compiler i was using before.
See if that changed anything CPU wise, thank you.
Apart from that i’d highly recommend -C, it works very nicely now 
And if you have issues with altitudes, just set -P 8 or something to keep that in check.
1 Like
Thanks. Just tried the new 32bit compile - looks like it has dropped cpu by about 5%, so back to around where it was before. (The chart is with -e 10 as I reduced it earlier today - going from 11 to 10.5 had very little effect.)
I know -C is working well. The only reason I’m using fixed -e values is to make me think a bit about what is happening and how it all works. You are making it too easy for us. 
@prog @wiedehopf thank you both… Some amazing numbers coming through for me since all the updates,…Hit 3000++ today !! I know the weather helps lots of small aircraft up and about around my location today… Cable gets changed tomorrow to a much higher spec one so hopefully will see some more gains but thanks
With all of the RCs it is easy to lose track of progress. I thought I would compare v2.0 against v2.2-RC19 to quantify the improvement. The samples were all 60 seconds duration recorded from an Airspy Mini with gain of 18 and running 20Msps. The RC19 settings are indicative of what I’m running now, but without -P as this setting wasn’t available in v2.0 The v2.0 settings used a preamble value that gave about the same CPU effort as RC19.
Noting that I’m in a relatively low aircraft number environment, there is a clear improvement. Two percent may not seem a lot, but v2.0 was already very good, and all of this work was about squeezing the last few messages out of the ether. Thanks @prog and @wiedehopf for all your hard work. As @caius mentioned previously, the latest RCs actually find additional aircraft - that is pretty impressive.
I tried to include the old v1.85 in this comparison, but it does not accept the -F switch to read from a file (or likely doesn’t have the ability to output the DF results in a readable format.)
I also looked at the effect of maximum preamble values on Sample 3:
The CPU time increased by more than 2.5x but yielded only one more DF17 in both cases, so not worth the effort. Also, these settings would be impossible to run in the real world on my hardware - the processing time needs to be less than the sample time, so in the case of RC19, I would need a Pi4B overclocked to around 4.5GHz 
4 Likes