Automatic installation scripts:
GitHub - wiedehopf/airspy-conf: Configure airspy_adsb for use with readsb or piaware.
9 Likes
Moved to github due to editing restrictions, scroll up to post 1 for the links 
2 Likes
Good work @wiedehopf. 
This updated and clear how-to was needed.
Observation:
- At the second option (Configuration if you installed piaware/dump1090-fa via apt / apt-get), the code snippet has at the end bo port 0 instead of 30005. In the following text is correct, but the snippet has to be corrected.
- The service route to start airspy is cumbersome. I use the “sudo nano etc/rc.local” to stat it.
1 Like
Command line option explanations
I’ll collect some explanation on the command line option for airspy_adsb in this post:
-r Reduced IF bandwidth
This option limits the bandwidth of the signal visible to the ADC to about 3.5 MHz instead of the default 9 MHz. This can be useful in some situations when you have some broadband noise right over the 1090 MHz band. But mind you, reducing the bandwidth of a signal also smooths the transitions between 0 and 1 levels in the time domain. This makes the detection harder or even impossible in some cases.
(written by prog the developer of airspy_adsb here: Thoughts on optimizing gain - #73 by prog)
-x Enable DX mode
-x is unrelated to oversampling. It simply tells the decoder to trust more frames that are likely to be good.
(written by prog here: Planes but not feeding - #25 by prog)
-m <mlat_freq> MLAT frequency in MHz: 12 or 20
This option name is a little misleading, more accurate would be: Sample Rate.
Basically it determines how often the ADC is read. Setting this to 20 will use a lot more USB bandwidth and CPU power for decoding. On a Raspberry Pi using 20 therefore might not work.
-p Enable Bit Packing
In short if -m20 is not working properly you can try adding -p to the options (actually i included it by default when you use my configuration file)
Also, what exactly does bit packing do and is it ever a bad thing?
Bit packing tells the hardware to pack every 2 x 12bit samples into 3 bytes instead of sending every samples as a 16bit integer. This saves 25% of the USB bandwidth, but leaves less headroom in the MCU for synchronizing the USB with the ADC. In general, it helps with some old computers or SBCs.
(Answer by prog HOWTO: Airspy mini and Airspy R2: Piaware / dump1090-fa configuration - #49 by prog)
No, both 1090-fa need to be 30005. Airpsy doesn’t need to output on 30005.
Take a look at this too:
FlightAware Integration
The easiest way to integrate Airspy into an existing FlightAware PiAware system is to feed dump1090 through its “MLAT result” port.
mkdir airspy cd airspy wget https://airspy.com/downloads/airspy_adsb-linux-arm.tgz tar xzf airspy_adsb-linux-arm.tgz sudo ./airspy_adsb -c localhost:30104:beast -c sdrsharp.com:47806:avr -p &
I wanted to keep the configuration consistent with the piaware sd-card.
So i chose this configuration.
It is different from yours but it is correct.
And airspy really doesn’t care if it needs to provide the data via one or two ways.
You can either have a daisy chain where the data goes to dump1090 then to piaware.
Or you provide the data to dump1090 via 30104 as a push client and provide piaware the data via listening on 30005.
The push client only method does not work with the piaware sd-card image and i wanted to have a single airspy configuration for my HOWTO
You might want to add to this information that it won’t work with the piaware sd-card image.
Feel free to copy my HOWTO to your web page after testing/verifying it
Well… I guess is more than one way to skin a cat.
Personally I wanted to keep consistency with what manufacturer of airspy recommends on their site for FA compatibility (link above), to eliminate confusions. In my dump1090-fa add-on, I think the default was for bo 30005, not 0. But I can’t guarantee now and I don’t feel like reinstalling it.
Also, the push method worked if the piaware config file was set on “relay”. Obj presented that clearly:
relayconfig "OUTPUT_OPTIONS=\"--listen 30005:R --connect localhost:30104:R\""
::fa_config_generator::generate_file "/etc/default/beast-splitter"
The relay config only means beast splitter will be pushing any data it gets into dump1090-fa via 30104 while also offering them on 30005.
beast-splitter INPUT is configured like this:
lappend relayconfig "INPUT_OPTIONS=\"--net [$config get receiver-host]:[$config get receiver-port] $force\""
So it connects to the IP receiver-host on the port receiver-port. (Even if you would enter localhost:30104 here this would not work as dump1090-fa only accepts but does not provide data on that port)
dump1090 is configured for net-only and bo-port of 0:
lappend receiverOpts "--net-only" "--net-bo-port 0" "--fix"
Data makes it way to dump1090-fa but not to beast-splitter or piaware.
Very good job
Linked in the Quick Start guide.
1 Like
Yep, that’s how Obj did it on his SD card install - to use beast splitter instead of dump1090-fa built-in.
Personally I have left the default config for the dump1090-fa as installed - that is with “bo 30005”. That takes the data from bi and mirrors it to bo port.
Like I said, that’ show the airspy people choose to show it too. No big deal, as long as is understood.
Haha, the airspy people linked this thread on their “Quick Start” page, instead of what they had there previosly! Good job!
Scroll down to " FlightAware Integration".
I guess you didn’t get the memo, prog who posted above you is literally THE airspy guy 
Anyway i thought about also including the rc local method for startup but actually in regards to logging errors to syslog and also restarting/stopping the service, the systemd service is quite nice.
And i don’t think the setup is much harder.
1 Like
I didn’t get the memo 
To me that does not make too much sense. If you type systemctl status airspy_adsb you will get a message like airspy_adsb.service - airspy_adsb, the description of the service as the name of the service. I suggest you provide a more meaningful text similar to the one in my file. I.e. the description for piaware is FlightAware ADS-B uploader.
1 Like
Impressed how quickly the reactions are in this forum. Actually, we could even add
Documentation=https://discussions.flightaware.com/t/howto-airspy-mini-piaware-dump1090-fa-configuration/44343
in the [Unit] section. 
And may I suggest a rename of the thread? It’s not very Airspy mini specific, virtually all of it also applies to the Airspy R2. I’d just leave the mini. It may change the documentation link however. Note most people find this thread through search engines.
¯_(ツ)_/¯
The number displaying new posts in the website title is sure useful.
Anyway the thread is linked on the manufacturers website now so … that’s where people might check.
Could this be included in the debian package airspy? Then the howto would crunch down to making some decisions in the /etc/default/airspy_adsb-file.
Didn’t know airspy had a debian package.
(The binary is just dowloaded and extracted)
Anyway it’s not that complicated and the howto is rather detailed
So i don’t see a upside of including it to be honest.
If it had a debian package it could of course just install a service itself and leave it to the user to enable it.
The package is there but I found out only after downloading manually.
$ apt-cache showpkg airspy
All the common packages (piaware, gpsd, ntp, …) have their corresponding service file and default configuration file included so why not this one. I am sure you agree that googling for additional files in a forum, copying them in a new file is not the most straightforward way of installing a program. Yes the user should have the choice whether to enable the service during startup. Just as i.e. GPSD.