FlightAware Discussions

HOWTO: Airspy mini and Airspy R2: Piaware / dump1090-fa configuration

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 :slight_smile:
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. :slightly_smiling_face:

@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:
Screen Shot 2021-09-23 at 10.18.33
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 :thinking:

4 Likes

That’s great analysis. 2.3% messages is pretty significant over the course of the day. As is the probably few more aircraft per hour. Curious what 12 Msps samples would reveal. I may try on the weekend.

1 Like

I did a similar test on a 20s sample taken during a busy time of day with about 220 aircraft.

I saw 0.6% more DF17 messages and 1.2% more messages in total, with one more aircraft.

Getting a 1 or 2% increase is still a very good result - it’s not like the decoder performed poorly on 1.85, but v2.0 was quite a bit more cpu efficient allowing a more permissive preamble filter.

2 Likes

Like winning milli seconds on a F1 lap.

3 Likes

@caius As we seem to have hit a lull in RC’s, what are the Options you have settled on for a busy area?
The options I have are giving me better counts, aircraft numbers and distance. I keep fiddling with -P and -e but don’t know what I’m doing. Pi 3 Model A, Airspy Mini
Gain= auto
OPTIONS= -v -t 60 -f 1 -w 5 -e 4 -P 20 -C 50 -b
SAMPLE_RATE= 12
Thanks

Which can gain lots of positions and finally lots of money :wink:

Definitely.

Not so sure.

[OT]
It is. Every position a driver gains or loses means pure money to the team.
In case of the qualifying session, every milisecond counts here and can have an impact on the race result
[/OT]

I’m using these settings at the moment along with auto gain.

OPTIONS= -v -t 300 -f 1 -w 5 -P 10 -e 10 -C 90

I have a pi 4 which is overclocked to 2GHz. The -e setting is set to just below where the preamble filter usually ends up so it reaches the operational value more quickly on startup. CPU target is set to 90% because the cpu cycles might as well be used for something. I have -P set to 10 because without it I got a small amount of bogus altitude messages and that is enough to remove those without limiting the number of other messages decoded.

2 Likes

Mine are very similar to this and I’m in a slightly busier area. The only difference is that I have -C set to 85 because any higher and I start getting a few lost samples.

Also overclocked to 2GHz.

I’m also happy with something close.
OPTIONS= -v -t 300 -f 1 -w 5 -P 10 -e 9 -C 90

Airspy mini@20, PI4, no overclock (only “force_turbo=1” in /boot/config.txt, so max frequency is forced).

@caius @keithma Thanks both, I’ll give caius’ options a try and see if I can squeeze the last milli second out of it! I would swap to a Pi 4 but they seem in short supply at the moment.