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

sudo shutdown now

Then wait 30 seconds, that should be sufficient.
Or until the LED stops blinking i suppose :slight_smile:

I assume you just unplugged it?

Ah OK … I did ā€œshutdown nowā€ on most the other times but may not have this morning… One to remember then! :slight_smile:

I replaced my FA FlightStick with an AirSpy Mini on Friday, July 2. I will post a snapshot of the graphs soon. I made a few changes, so it needs to settle down for a few days. I looked in ā€˜/etc/default/dump1090-fa’ and saw this:

RECEIVER_OPTIONS="--gain -10 --net-only --write-json-every 1"

I guess I can remove that gain setting, correct? The AirSpy’s gain is set in ā€˜/etc/default/airspy_adsb’.

With airspy-conf script that shouldn’t be there i think.
The manual guide doesn’t specify having it there either does it?

Anyhow … i’m not even sure it works like this, so yes remove it.

1 Like

I think it may have been added by ā€˜autogain1090’? I just removed ā€˜autogain1090’ today. OK thanks.

Might be.

So that caused an issue?
I suppose i should check for --device rtl-sdr before adding --gain in autogain.

I don’t think so. I was just checking my config files and saw it in there.

1 Like

I installed my Airspy mini with a HABAmp 3 LNA/AMP (about 17db gain) on July 2. I’ve been playing with some settings and I’ve got it to where it’s close to matching the performance of my FA ProStick. It’s not quite there yet. I’d appreciate any tips or hints on what I might do to boost its performance. Here’s my config:

/usr/local/bin/airspy_adsb -v -f 1 -w 4 -e 18 -x -l 47787:beast -c localhost:30004:beast -g 20 -m 12

The attached picture shows a month’s worth of graphs1090. The first 10 days are with the ProStick. In the ADS-B Traffic Seen / Tracked graph I’ve marked some milestones where remarkable changes were observed.

Red arrow: Installed Airspy mini with a 12 volt 2 amp power supply I had lying around into the header of the HABAmp.
Green arrow: I swapped out the 12 volt power supply for a 5 volt 2 amp power supply from Amazon. Dang, performance improved!
Blue arrow: Switched to my current configuration.

The picture is big. You’ll have to zoom all the way into get a good look.

One last improvement in the pipeline (not sure when I’ll get to it). I bought a Proxicast 36 ft low-loss 50 ohm coax N male to SMA male.

Thanks in advance for any advice!

Thanks to [wiedehopf] for the scripts, and to everyone else who has posted in this thread. I have been experimenting with adding an Airspy Mini to my setup and have seen some big improvements. Some of the suggestions and settings in this thread worked well, and some didn’t work at all. I think that is because each station is unique: location, signals, noise, antenna, obstructions, CPU, etc.

In my case, I have a roof-mounted Flight Aware stick, 10m of good quality cable. That stays the same. I was running a FlightAware filter and a FlightAware orange stick, Piaware image on an RPI 3b.

I’m 50 nm from a major airport (Nashville), but my 200 nm circle covers the approach paths of several more including Memphis and Atlanta. An average slow weekend I see 3000 planes, 400,000 positions, up to 3500 planes on a busy day. Rarely see more than 1000 messages / second.

Swapping out the filter and stick for an Uputronics filter / LNA and Airspy Mini, just using the defaults from the install script, performance dropped about 10% and Pi temperature was up significantly. I followed the Airspy recommendations for configured a Pi 3 for performance, but it still looked like Pi3 could not keep up with the level of messages I was receiving. If others have reported this I missed it. I was not expecting the Pi to be the bottleneck. It has the official power supply, heat sinks, and has been running fine for several years in the original setup.

I did try to apply some of the airspy_adsb options from this thread, specifically the -e and -t parameters. I never ever got close to the -e 10. Anything over -e 4 resulted in dropped messages from airspy and overtemp warnings on the Pi, with CPU utilization near 100%.

So, after identifying the Pi as the problem for my particular setup, I switched it out for a Pi 4 - running a copy of the card out of the Pi 3, with just the specific Pi 3 settings removed. The point is that it is a 32 bit PiAware image. I did not install a 64 bit O/S or build any special 64 bit packages.

With this change, the Pi can keep up with Airspy Mini at my message level. Config options like -e 10 are possible. One CPU is at 85% for Airspy, Total CPU at 30%, and the Pi stays under 120 F / 50 C. I’m seeing 1500 msg / sec, and both the Airspy Mini and the Pi4 appear to have plenty of extra capacity for more volume, and for more experimenting with the configuration.

My observation from my environment is that a Pi 3 can’t keep up with the Airspy Mini at much more than 500 msg / sec sustained rate. Anything over that and the Pi performance becomes the limiting factor. Maybe with a case fan for active cooling and other tweaks you could squeeze more out of it.

I also tried the original FlightAware filter and stick on the Pi 4 for comparison, but I did not see any difference in performance so the Pi 3 was not limiting my original setup. It is once the Airspy is in the mix.

For anyone considering experimenting with an Airspy, keep this in mind as you read all the other comments and advice. The settings that work for someone else may be totally dependent on the computer that is running the Airspy, and the expected message rate for their location.

I suspect that the Airspy may only offer dramatic improvements when you are already nearing the 1000 - 1200 msg / sec range where the performance of the typical RTLSDR starts to roll off. And at that point, you need more than a Pi 3 to run it. Maybe someone else with a lower local message rate can chime in about how the Airspy improved their situation and which Pi they are using.

1 Like

I’m running on a pi3b+ with a fan.
As i’m terrain limited i can run -e 7 easily (on 12 MHz of course).
-e 8 is around the limit.
Gain can change how much CPU is used, so can noise.
I’m reaching up to 1700 messages per second on some days.

Thank you, that explains a lot. Maybe I can move the Pi4 back to it’s original project (not ADS-B) and just add a fan to the Pi3 instead.

Remember though that there is a difference between a Pi3b and a Pi3b+.

Sure enough - added a cheap little 5V fan to my Pi 3b and it is working fine with -e 7. ADS-B CPU utilization is at 80% and temp 50 C so there may be room to adjust the airspy config a little more.

When I experiment and fail and try again, I remember the lessons better than if I just follow someone else’s settings without knowing why.

Airspy Mini running on Linux Mint with Debian add-on package and airspy_adsb. Is there any setting I can tweak to try to refine some of these ā€œotherā€ aircraft? MLAT is synchronized with 251 nearby receivers.

ā— airspy_adsb.service - Airspy ADS-B receiver
     Loaded: loaded (/lib/systemd/system/airspy_adsb.service; enabled; vendor preset: enabled)
     Active: active (running) since Wed 2021-08-04 20:34:02 EDT; 1 day 13h ago
       Docs: https://discussions.flightaware.com/t/howto-airspy-mini-piaware-dump1090-fa-configuration/44343
   Main PID: 2709264 (airspy_adsb)
      Tasks: 4 (limit: 9235)
     Memory: 8.2M
     CGroup: /system.slice/airspy_adsb.service
             └─2709264 /usr/local/bin/airspy_adsb -p -v -f 1 -w 4 -e 16 -x -t 300 -l 47787:beast -c localhost:30004:beast -g 21 -m 12

Aug 04 20:34:02 adsb1 systemd[1]: Started Airspy ADS-B receiver.
Aug 04 20:34:02 adsb1 airspy_adsb[2709264]: airspy_adsb v1.85
Aug 04 20:34:02 adsb1 airspy_adsb[2709264]: Listening for beast clients on port 47787
Aug 04 20:34:02 adsb1 airspy_adsb[2709264]: Acquired Airspy device with serial A74068C837805E93
Aug 04 20:34:02 adsb1 airspy_adsb[2709264]: Decoding started at 12 MSPS
Aug 04 20:34:06 adsb1 airspy_adsb[2709264]: Push client connected to localhost:30004 (beast)
Aug 05 10:26:11 adsb1 airspy_adsb[2709264]: Client connected from 192.168.1.150:64420 (beast)
Aug 05 10:26:22 adsb1 airspy_adsb[2709264]: Client disconnected 192.168.1.150:64420 (beast)

oa

pr

Thanks!

Reading options before enabling them is recommended.

-x: dx mode, improves reception of weak messages, introduces bogus messages (opinion: not worth it)

-e 16 seems unnecessary high but if you want to use lots of CPU, up to you :slight_smile:

You can also go to -w 5 that should reduce ā€œotherā€ further.

2 Likes

Doesn’t the law of diminishing returns really start coming into play if -e is above about 10 or is that my imagination?

One could say that diminishing returns is above -e 7 and beyond -e 10 is almost pointless :wink:

Thanks! I’ve changed to -w 5, -e 10 and removed -x.

The reason I chose -e 16 (and before that -e 18) was because I saw a post where you suggested to someone to push -e up to where ADS-B CPU gets to 80%. At -e 18 the CPU was at 80%. Or did I misunderstand?

I think you must have.
See this post: