Step by step how to integrate airspy into existing piaware


Hello everybody.
It seems that I has really brave in the last time so my wife gave me today an airspy r2. :open_mouth:
So how do I integrate in into my current “installation”. I have now the Pro Stick but it seems to me that the Airspy can do a little bit more then the Pro Stick (30 minutes test using the same antenna). Currently running Piaware 3 (SD Card). If you need more info just tell me.
I’m an greenhorn when it comes to Linux OS. So a step by step explanation will me more then welcomed. The “plug and pray” option is not working :blush:

Thanks a lot


Do you have an Amp to go with the airspy? It is rather deaf without one.

I have two, mini and R2, but have found than an RPI3 can be overloaded CPU wise by the airspy.
They are not my primary receivers.

I can put something together when I get home tonight.
I think you need to just change one line in /etc/default/dump1090-fa and add a script to run the airspy_adsb application at startup (and download it).

There is an additional step that I have found help to reduce CPU load (configure piaware to connect directly to the airspy server)


An 20 db amp is located at the 10 db 1090 antenna, my test showed a slight increase in range (I have the Alps in west, north and south-west) but more airplanes.
It will be great if you can help me but is not urgent, take your time don’t stress yourself.

Thanks again


(November 2016)
There are many ways to do it but here is my attempt. Please provide feedback and I will update this post.

Download airspy_adsb to home dir
tar xzf airspy_adsb-linux-arm.tgz

disable dump1090 using the dongle
sudo piaware-config receiver-type other

restart piaware for settings to take place
sudo piaware-config -restart

Test run airspy (remove -b if bias-t is not required. Start with gain at 21)
sudo /home/pi/airspy_adsb -c -b -g 21 -p -w 4 &

Check dump1090 to see that you can see aircraft.
If this works then add this command to /etc/rc.local
You will need to use the editor as root.
sudo vi (or whatever your favourite editor is) /etc/rc.local**

/home/pi/airspy_adsb -c -b -g 21 -p -w 4 -d 2 &

(remove -b if bias-t is not required. Start with gain at 21)
(try with -d2 on an RPI3 to reduce the CPU load)
reboot to test that it automatically starts

You can have the process listen on 30005 (and feed this into MLAT) however, you will not be able to add any other feeds (like UAT 978 or acars). To do this add -l 30005:BEAST and remember to disable port 30005 in dump1090(fa or mutability). I had to do this for a radarcape as dump1090 messed with the GPS timestamps.

Here is the help file from my Odroid version
-s <serial_number> Device serial number
-t Aircraft timeout in seconds
-g <rf_gain> RF gain: 0…21
-w Worker threads
-d Decimation factor
-f Forward Error Correction (FEC) bits
-c ::format] Add a Push Client
-l :format] Add a Server
-n Use the highest native sample rate
-b Enable Bias-Tee
-p Enable Bit Packing
-v Verbose mode
-h Display this help screen
Available output formats:

  • AVR - Raw AVR format
  • AVR-STRICT - Raw AVR format with only CRC valid frames
  • ASAVR - Raw Airspy AVR format
  • Beast - Raw Beast Binary forma



Thank you for posting that. Very helpful. So far I’m running my Airspy with success. The key [as you figured out] was to run 4 workers and split the CPU usage up among four cores so that a single core doesn’t get maxed out by Airspy + dump1090-fa + fa-mlat-client. I had tried Airspy before, but really hadn’t understood what the -w option was even though I did test -w 2.

My commandline is a little different, and I’ll post it just so others who might have questions about MLAT, etc. will know.

/home/pi/airspy_adsb/airspy_adsb -c -l 30005:BEAST -l 30001:AVR -g 21 -p -w 4


Tell’s the Airspy to connect to port 30104 (net-bi-port # beast input port) of dump1090-fa. My dump1090-fa is listening on port 30104 for BEAST-formatted input, which includes (a) the data from my Airspy and (b) the data from fa-mlat-client.

-l 30005:BEAST

Tells the Airspy to listen on TCP 30005 (net-bo-port # beast output port) for anything that wants to connect and obtain BEAST-formatted data from it, such as PlanePlotter and VRS running on a separate machine.

Jon: I’ve seen you [and maybe others] specifically suggest that the Airspy is “deaf” on 1090 and needs an amp. I’m considering this. I’ve only been running the Airspy for a day, and it seems to be on par with my NESDR dongle. I might get a filter / amp combo to put up at the antenna in the attic, although I’m not sure I really need the filter.

I’m vary familiar with using the Airspy for VHF/UHF digital decoding, and when used for that the Airspy beats anything I’ve ever used hands down, especially when one runs 10 msps with a decimation of 64. I see there is an option in airspy_adsb to use decimation, but thus far any decimation value seems to [oddly enough] decrease the amount of data that i get on 1090 from the Airspy. I need to play with that a little more.

Prog: Youssef, if you read this, is airspy_adsb set by default to use [what you feel] are optimum values for sample rate / decimation on 1090 mhz? Or should I really try and “tweak” things.

Again, thanks to everyone who has posted so much useful information.



Hello friends,
first of all thank you a lot for your support.
Unfortunately I don’t have good news. I can see locally the airborne airplanes but Piaware reports that no receiver is delivering data.
I will try with a new image (Piaware) and report back.
I reverted the system to the normal dongle that I use (the pro stick) so at least Im back online after a 30 minutes blackout
I will report back

Take care


I have taken a slightly different approach (mutability) - for FA use as jonhawkes2030 instructed above:

cd /usr/local/bin
sudo wget
sudo tar xzf airspy_adsb-linux-arm.tgz && sudo rm $_
sudo chmod 755 airspy_adsb
sudo sh -c "sed -i 's/DEVICE=\".*\"/DEVICE=\"none\"/' /etc/default/dump1090-mutability"
sudo /etc/init.d/dump1090-mutability force-reload

Then to run, I use the following:

sudo airspy_adsb -c localhost:30104:beast -d 2 -p -n -w 4 -g 18 -f 0 &

For whatever it’s worth anyhow. To change back to “normal” use with an rtl device, I simply run the following:

sudo sh -c "sed -i 's/DEVICE=\".*\"/DEVICE=\"\"/' /etc/default/dump1090-mutability"
sudo /etc/init.d/dump1090-mutability force-reload

EDIT: So far as CPU use, airspy_adsb takes the grunt of the load and dump1090 will only eat up maybe 2-3% on it’s own, so don’t need to look at it like you are adding a huge load on top of whatever you regularly see when dump1090 is chomping through the raw input. airspy_adsb is doing the heavy lifting here. Also note that I have found gain at 18 with decimation 2 to work best with my test system, but I recommend doing as jonhawkes2030 instructed and to start gain at 21 and test from there.


I have a lot of familiarity with Airspy + SDRSharp and using decimation to my advantage. In the case of airspy_adsb, on a few occasions I briefly played around with decimation values, and every time I did the results were significantly worse than omitting -d #.

But, since you’ve found some differing [better] results with something other than 21 and no decimation, I’m going to play around some more and see what happens.

I ordered one of HAB/nevis amp-filters and am anxious to receive it and see if an amp and/or filter make any difference here. I’m using a DPD Productions ADSBOut antenna up in my attic. A filter is unlikely to make a difference, but the amp [at the antenna of course] may.



Hi Mike,

I just read your message. I think I should definitely write a proper documentation for the airspy_adsb utility. Here are a few things you need to know.

  1. Setup
    Airspy is optimized for use with an external preamp. The noise figure is about just adequate for VHF and UHF (main market), but you will definitely need external amplification over that. Having the preamp in the mast near (or within) the antenna is the optimal setup.

I personally prefer the Active Diapason from F5ANN - may God rest his soul in peace. This little antenna beats everything I have tried so far. It has a built-in dual stage ADSB preamp and a SAW filter. It can be powered directly from Airspy or through external Bias-tee for other receivers.
The Nevis ADSB preamp is the next best thing I tested. This preamp + a good collinear would cost a fraction of the price of the Diapason, but it’s close enough in performance.

  1. ADSB decoder for Airspy
    The ADSB decoder for Airspy operates at 20 MSPS real signal (not 10MSPS IQ signal like in other SDR programs). This allows some fancy detection algorithms to be used, and of course, it increases the timing resolution.
    Internally, the decoder has a polyphase structure. This means the signal is decomposed to multiple phases (streams of data), and each phase is processed individually. The processing tasks are then scheduled over the processing threads (Cores), then the results are consolidated into a single stream of detected frames. The detected frames are then dispatched to the TCP listeners and clients.

a) Threads
In low cost computers like the Raspberry Pi, 20 MSPS is a lot of traffic to handle. For this purpose, the original decoding algorithm in ADSBSpy was rewritten to run in multiple threads (cores) to exploit the CPU as efficiently as possible. It’s the "-w " option. W stands for Worker Thread.
In general when using airspy_adsb on weak CPUs, the number of threads should match the number of cores. In Desktop computers, one thread is sufficient to run everything and adding more threads just increases the CPU usage without any benefit.

b) Decimation
The decimation option "-d " can be used to force the decoder to process one phase every other N phases. Unlike the decimation done in SDR#, the decimation here is a trade-off between the accuracy of the detection and the total CPU usage. If you are running in a desktop computer or even a tablet, you will want to not use the decimation.
In some cases, having more room for other tasks helps the system to behave better despite the lower detection resolution, but it depends on what’s running in the RPi and the USB/Network traffic.
In the decimation is needed, N should be picked so that the sample rate of the device divided by N is still a multiple of 2MSPS.

Example1: The default decoding sample rate, regardless of the device used, is 20MSPS. You can decimate by 2, 5 and 10.
Example2: The Native decoding sample rate of the Airspy Mini is 12MSPS. You can decimate by 2, 3 and 6.
Example3: The Native decoding sample rate of the Airspy R2 is 20MSPS. You can decimate by 2, 5 and 10.

The native sample rate can be forced with the “-n” switch.

c) Packing
Use the data packing if you encounter USB bandwidth problems. This is mandatory for the RPi at 20MSPS, however, 12MSPS can be OK without packing (Airspy Mini with its native sample rate).

d) FEC
The default behavior is to attempt fixing 1 bit in the corrupted CRC frames before throwing them away. This can be changed to 0 (conservative) or 2 (cowboy mode - too many false positives).

I hope this helps.



Hi Youssef,

That information definitely helps. I appreciate you taking the time to write it up. As I mentioned before, without any preamp I’m picking up the same number of planes as I was using a non-FA 820T2 dongle with 0.5 ppm deal. I only have a 50 foot cable run (LMR-400) cable run to the attic, but it sounds like I might eek out a few more planes and/or better mlat results with the amp. I’ve already ordered the amp, so I’ll see how that goes. Considering what you said about the Airspy receiver at 1090 mhz, I’m impressed that it’s doing as well as it is.

I’m using “-p -w 4 -g 21” right now, on an RPI3. I’m not using decimation right now on airspy_adsb, and I won’t bother trying it based upon your detailed info above. I’m assuming that once I get the amp installed at the antenna, I am going to want to cut down the gain on the Airspy significantly at that point and not run “-g 21” anymore.

Thanks for your insight. You already know how I feel about your [great] Airspy products!



Hello friends,
unfortunately I still don’t have good news. I tried a different card with a vanilla Jessie installed. But still getting no connection between dump and receiver.
I followed your instructions everything installed without problems but not working.

Anyway I really appreciated your help and I want to thank you for your time taken to help me.

Take care


What are the error messages?
check :-
/var/log/dump1090-fa or /var/log/dump1090-mutability
You may be able to read some of this information from the card itself.

What was the exact airspy_adsb command that you used? Did it give you any error message?
What does sudo piaware-config -showall display(remove usernames and passwords)
What does /etc/default/dump1090-fa look like?

It is pretty hard to diagnose with some basic information.
Do aircraft show up in the dump1090 local website?


You can do it this way too, however, you should not need to. I have to feed my radarcape this way as dump1090(and modes deco/mixer) mess with the gps time stamps. It is a bit of a pain as I cannot add my uat978 feed to the device.

I have found that in my busy location, an RPI3 cannot handle the airspy. I have to run it on an Odroid XU4 (more memory CPU and better usb bus).


Youssef, thanks for breaking some of that down. A cmd breakdown on your site much like you listed above would go a long way to answer some of the questions for those who want to play around with the Airspy gear. Hopefully you find the time to make it happen.

I should have mentioned above that I have an LNA with about ~30db gain ~.7db NF at the antenna and a very sharp cavity filter right in front of the dongle, so for this reason, I was able to etch out a lower noise floor (subsequently more messages) by dropping gain down a few notches and using decimation of 2 (Airspy-Mini). I tried the same setup with a 20db gain LNA and I had to keep gain pegged and decimation disabled for best results. I also kept FEC disabled, so this may have contributed to lower CPU strain (Pi3). That said, with those settings, airspy_adsb hangs at about 30% CPU with 200-250 aircraft in range. The R2 at 20 MSPS would be a different story than the Mini at 12 MSPS and I failed to mention that I was testing the Airspy-mini.

@Emil - Also curious what your logs show and what the answers are to John’s questions. It has to be something simple - post all the information you can concerning what you did exactly and there are plenty here who can help get you sorted out. Airspy is a very nice radio - it would be shame to not be able to at least test it out on your setup for the fun of it.


I had a post about my Airspy experience, Its been a while so I swapped out my FA pro stick for my Airspy-mini, will let it run for a few days and see if there is any massive difference.


Hi Emil, hope you have already worked out integrating Airspy. I had the same problem: Airspy feeds to dump1090-fa, and the results can be observed on local display (http:///dump1090-fa/), but the positions are not uploaded to FA as part of statistics.

My way of reading this ( is that data received at port 30104 is not uploaded to FA via port 30005 (green path excludes synthetic mlat messages). Therefore the Airspy decoded messages are not uploaded to FA.

Earlier I tried “-c” in lieu of “-c” but to no avail.

My workaround is as follows. Strictly speaking, my method does not “integrate airspy into existing Piaware”-

  1. Start with a working Rpi (e.g. with official OS)

  2. Follow the steps 2 & 4 on this page: (i.e. dump1090 is not installed)

  3. Install and run Airspy: follow the “Standard setup (non FlightAware)” steps (
    mkdir airspy
    cd airspy
    tar xzf airspy_adsb-linux-arm.tgz
    sudo ./airspy_adsb -l 30005:beast -l 47806:asavr -p -n -w 4 &

    (adjust airspy_adsb parameters as deemed fit, re. parameters “-g 21”, “-b”, “-d 2” etc.)

  4. After a while, claim the Piaware at

  5. You should see positions being uploaded.

  6. Set airspy_adsb to start at boot

If “sudo piaware-status”, I can see
PiAware master process (piaware) is running with pid xxx.
PiAware ADS-B client (faup1090) is running with pid xxx.
PiAware mlat client (fa-mlat-client) is running with pid xxx.
Local ADS-B receiver (dump1090) is not running.

. (pid xxx) is listening for connections on port 30005.
faup1090 is connected to the ADS-B receiver.
_piaware is connected to lightAware.

dump1090 is producing data on localhost:30005.

(I have already set location information for MLAT)

Unfortunately, I could not work out the local live view and status page (the page showing the four green status boxes).

I am very new to Airspy, Piaware (the internal mechanism) and Linux. I would love to hear other ways to enable live view page. Perhaps the whole strategy outlined above is not a very bright one. Happy to hear from others.



You can put airspy_adsb on a different port and set receiver-type relay, receiver-host localhost, receiver-port <whatever the airspy port is> in your piaware config. This will end up running dump1090-fa in --net-only mode, and run a beast-splitter to feed data from airspy_adsb to dump1090-fa. Skyview is then provided by dump1090-fa.

This is a special case of “get receiver data from somewhere else”, which is what the “relay” setting does.

Airspy Mini on a Raspberry Pi for ADS-B flight tracking

Thanks, obj, for quick response. Will try and report back.—Roy
EDIT: I am afraid that I have to work on other projects in the coming months so setting up Airspy more properly would be secondary. Meanwhile, please feel free to see a live comparison of how well Airspy does vs NooElec NESDR SMArt - Premium RTL-SDR (Comparison starts at 23:00 18 Sept 2017 local time):

Airspy R2:
NooElec NESDR SMArt - Premium RTL-SDR:

Brief description of system configuration:
Two copies of the same model of antenna are within half foot of each other. (I don’t have a splitter.) Length of antenna cables are virtually the same. The antenna comes with LNA and band-pass filter.

Airspy setting: -b -p -d 2 -n -w 4 & (i.e. gain setting not tested)
NooElec: --gain -10

Both are connected to RPi 3.


I downloaded a different distro for the tinkerboard and integrated the piaware into it.
So far so good.
Command used (the standard from aispy website
sudo ./airspy_adsb -l 30005:beast -l 47806:asavr -c -p -n -w 4 &

I got this

[2017-10-08 21:00 CEST] Started faup1090 (pid 1696) to connect to .
[2017-10-08 21:00 CEST] mlat-client(1627): Beast-format results connection with ::1:30104: [Errno 111] Connection refused
[2017-10-08 21:01 CEST] mlat-client(1627): Beast-format results connection with [Errno 111] Connection refused
[2017-10-08 21:01 CEST] mlat-client(1627): Beast-format results connection with ::1:30104: [Errno 111] Connection refused
[2017-10-08 21:02 CEST] mlat-client(1627): Lost connection to localhost:30005
[2017-10-08 21:02 CEST] mlat-client(1627): Reconnecting in 30.0 seconds

Secondary after a reboot I have to manually start the airspy program…

linaro@linaro-alip:~/airspy$ piaware-status

PiAware master process (piaware) is running with pid 529.
PiAware ADS-B client (faup1090) is running with pid 1083.
PiAware mlat client (fa-mlat-client) is running with pid 1062.
Local ADS-B receiver (dump1090) is not running.

. (pid 1024) is listening for connections on port 30005.
faup1090 is connected to the ADS-B receiver.
piaware is connected to FlightAware.

dump1090 is producing data on localhost:30005.


If used station goes offline

sudo piaware-config receiver-type beast

Station back online

linaro@linaro-alip:~$ piaware-status
PiAware master process (piaware) is running with pid 3381.
PiAware ADS-B client (faup1090) is running with pid 3442.
PiAware mlat client (fa-mlat-client) is running with pid 3433.
Local ADS-B receiver (dump1090) is not running.

. (pid 1686) is listening for connections on port 30005.
faup1090 is connected to the ADS-B receiver.
piaware is connected to FlightAware.

dump1090 is producing data on localhost:30005.

Skyview still not working, stays in loading status

Errors in log (flightaware control panel).

[2017-10-11 13:02 CEST] mlat-client(3433): Beast-format results connection with ::1:30104: [Errno 111] Connection refused

Any idea how should I solve this?