Jon,
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 127.0.0.1:30104:BEAST -l 30005:BEAST -l 30001:AVR -g 21 -p -w 4
-c 127.0.0.1:30104:BEAST[/quote]
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.
Mike
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.
- 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.
- 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.
