Checking for lost packages from Airspy

FlightAware ADS-B Flight Tracking
1

I aim to get the maximum out of my Raspberrypi 3 using an Airspy R2 radio. Some people say that running the pi with 20 MHz (option -m20 in airspy_adsb) will overload the system. Now I can check CPU load using htop and I see this is not the problem (load average only ~1). However it could be that packages are dropped on the USB bus since Ethernet is connected on the same lane in a Raspberrypi 3. It is suggested to use airspy_rx -r /dev/null -t 0 to see wether everything comes through but I only get an error airspy_open() failed: AIRSPY_ERROR_NOT_FOUND (-5)
The same happens with

$ airspy_info
airspy_lib_version: 1.0.9
airspy_open() board 1 failed: AIRSPY_ERROR_NOT_FOUND (-5)

How do I get those programs to work?

Flightaware including MLAT is working so there is communication with the airspy. I use Raspbian stretch v9.6 with packages airspy v1.0.9-1, gr-osmosdr v0.1.4-12, gqrx-sdr v2.6-1 and pulseaudio v10.0-1+deb9u1 if that is of any concern.

Edit:
The answer to the thread title shoud be:

  1. Install airspy_adsb using the howto but add -v to the OPTIONS= in /etc/default/airspy_adsb

  2. run journalctl -n50 -f -u airspy_adsb. If you continuousely have lost samples almost every second your computer is overloaded. If it happens just a few times a day it’s probably not relevant.

  3. read the full thread for all the details :sunglasses:

2

Did you stop airpsy_adsb before using the command?
The dongle is used exclusively by those programs so if one is using it the others or another instance won’t work.

Also might need to be root to work.

Another comment: If you get consistent MLAT this should be a good indication that it works.

The thing is though, there could be problems when you do an update and the ethernet is used more.
Anyway i wouldn’t worry too much as long as MLAT works :slight_smile:

3

@wiedehopf: No I did not stop airspy_adsb before. I did it now (sudo service airspy_adsb stop) and it works!

$ airspy_rx -r /dev/null -t 0
Device Serial Number: 0x1234567890123
Stop with Ctrl-C
Streaming at 9.234 MSPS
Streaming at 8.877 MSPS
Streaming at 8.574 MSPS
Streaming at 8.676 MSPS
Streaming at 8.720 MSPS
Streaming at 8.669 MSPS
^CCaught signal 2

User cancel, exiting...
Total time: 6.2940 s
Average speed 8.7942 MSPS IQ
done

However, I get an average of 8.9 MSPS, which is clearly below 10 MSPS. Does that mean I loose 11% of traffic due to a jam on the USB/Ethernet lane?
Yes, MLAT works, but I could switch to another single board computer. I have one with Freescale i.MX6 lying around…

4

I don’t know how many MSPS are used by the -m12 and -m20 options respectively.

I also don’t know how much the bit packing reduces the bandwidth used by airspy_adsb.
Can very well imagine that you don’t lose anything because of bitpacking.

Can you show the output of

airspy_rx -h

?

@prog Do you know how much MSPS in airspy_rx are required for -m12 and -m20 in airspy_adsb to work correctly?

5

“-t 0” will convert the raw ADC data into float IQ format, which is unnecessary. We don’t use IQ data for decoding Mode S frames. Instead, we use real data in int16 format.
Suggestion: airspy_rx -r /dev/null -a 20000000 -t 3 -p
Adjust for 12 MSPS and try again.

6

-p requires a parameter 0 or 1 and I assume it corresponds to the -p parameter in the airspy_adsb command.

So I get with bit packing enabled:

 $ airspy_rx -r /dev/null -a 20000000 -t 3 -p1
Device Serial Number: 0x123456789abcdefg
Stop with Ctrl-C
Streaming at 20.007 MSPS
Streaming at 20.007 MSPS
Streaming at 20.002 MSPS
Streaming at 19.996 MSPS
Streaming at 19.999 MSPS
[…]
^CCaught signal 2

User cancel, exiting...
Total time: 12.1160 s
Average speed 20.0016 MSPS Real
done

and with bit packing disabled:

 $ airspy_rx -r /dev/null -a 20000000 -t 3 -p0
Device Serial Number: 0x123456789abcdefg
Stop with Ctrl-C
Streaming at 19.636 MSPS
Streaming at 19.347 MSPS
[…]
Streaming at 18.985 MSPS
^CCaught signal 2

User cancel, exiting...
Total time: 12.0054 s
Average speed 19.1189 MSPS Real
done

So there is no packet loss with bit packing and a slight 4.5% packet loss without bit packing at 20 MSPS.

Conclusion: A raspberrypi model 3 is perfectly able to handle Airspy R2 as long as there are no other heavy loads. airspy_adsb should be run with options -m20 -p by default on those computers.

Thanks for your advice, @prog and @wiedehopf.

7

You didn’t load down the ethernet at the same time though.

So if there is lots of ethernet traffic there might be some packet loss.
So for example the instant you load the local map there might be packet loss :slight_smile:

You could put a file in /var/www/html and download that from your main computer while the test is running.
Then you could test that :stuck_out_tongue_winking_eye:

As i said i don’t think it’s a problem but your testing methodology doesn’t guarantee it.
Anyway i will still recommend -m12 as a default in the other thread for now :slight_smile:

Also you have model 3b+, no telling how the earlier model 3 perform.

8

No I did not but this makes no sense to me. My setup is a standalone pi dedicated for flightaware and I think this is the case for most of us here. Ethernet traffic caused by flightaware is minimal (~2 kB/s). There is just ntp and gpsd running on it.
If you run a heavily loaded webserver or fileserver there will be a point where it can’t catch up anymore. But this will be the case even on an expensive professional-grade server, just at a higher level.

The test above was with the old raspberrypi model 3 without +. I just repeated the test with a raspi model 2B and here is the result:

$ airspy_rx -r /dev/null -a 20000000 -t 3 -p1
Device Serial Number: 0x123456789abcdefg
Stop with Ctrl-C
Streaming at 20.009 MSPS
[…]
Streaming at 20.001 MSPS
^CCaught signal 2

User cancel, exiting...
Total time: 12.8922 s
Average speed 20.0017 MSPS Real
done

So no packet loss on an old raspberrypi 2. CPU load is unsurprisingly much higher here. htop shows one fully loaded core and a load average of 1.6 which equals to 40% CPU load. So even a Raspberrypi 2 model b is able to handle an Airspy R2 at 20 MSPS. No need to artificially throttle speed by leaving the -m20 option in airspy_adsb.

9

That’s interesting. I’ll change it in the guide.

@prog I guess your command line mainly originates from the days when the decoding was much more CPU heavy?
Or did you run into MLAT problems on your setup with -m20?

1 Like
10

The decoder changed many times. The current one is efficient enough for the modern ARM SBC’s but the decoding thread should not hit 100% utilization of one core.
You can use the htop command to check the highest core utilization of (decoding thread). The objective is to stay below ~95%. If you find 100% utilization on any thread, then you are starving the decoder. In this case, better use -m 12.

11

I’ll leave -m12 in the howto thread and link this thread.

1 Like
12

I agree. Now there are two ways of avoiding this: 1st buy modern hardware such as the Rpi 3 or 2nd code the program so it uses the cores more evenly…

The average reader of a howto today has at least a Rpi 3, the model 2 became obsolete three years ago.

13

I’ve got a Raspberry Pi 3 Model B V1.2, and running -m20 pegs one of my cores at 100%.

14

i just installed a mini. when i change to 20MHz i get “clock unstable” and MLAT quits. i have an RPI 3B…any comments or suggestions???

15

You could try to add a heatsink and fan to the CPU. I found this worked well a few years ago. It may give you enough CPU to run at 20Mhz.

16

What else do you run on your RPi? A desktop? I don’t. Which options in airspy_adsb have you enabled?

17

Nothing else running on it. I did make the performance settings changes as recommended in the quickstart guide on airspy.com:

From /etc/rc.local:

echo performance > /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor
echo performance > /sys/devices/system/cpu/cpu1/cpufreq/scaling_governor
echo performance > /sys/devices/system/cpu/cpu2/cpufreq/scaling_governor
echo performance > /sys/devices/system/cpu/cpu3/cpufreq/scaling_governor
sudo nice -n -19 -- /home/pi/airspy_adsb -l 31104:BEAST -g 19 -f 1 -x -m 12 &

From /boot/cmdline.txt:

dwc_otg.fiq_fix_enable=0

Edited to add:
From /boot/config.txt:

arm_freq=800
force_turbo=1

With this configuration all cores average about 30%, with one occasionally jumping to about 65%. Setting -m 20 pegs one of the cores at 100%.

18

Does MLAT fail when you use -m 20 ?

Also with some passive cooling, arm_freq=900 or =1000 shouldn’t be a problem.
Apparently some people just run RPi 3B at 1200 MHz permanently (Raspberry Pi 3 Overclock and Turbo Config)

Prog said it’s not recommended having one of the cores at 100%, also it may indeed lead to problems with MLAT. So i guess that’s why he is not using -m 20.

19

Hm, right now I have a load factor of 1, highest loaded core 65% and 350 messages/s. I do not have the overthrotteling enabled. But I have bit packing (-p). My pi does not get warm and there is no fan. Airspy R2 gets pretty warm though. Is the load expected to be the same for an airspy mini and an airspy R2?

20

The chipset is the same as far as i know. So yes.

load factor of 1, highest loaded core 65%

That’s not what i’m talking about :slight_smile:
You need to check the CPU usage of the main airspy thread.
That thread can change CPU so it can be limited without one of the cores being at 100%. Does that make sense?

Anyway just add the option -v and then you can check with

journalctl -n50 -f -u airspy_adsb

if you are losing any samples.
That’s easier than finding the correct thread in top :slight_smile:
Anyway it might be related to the message rate i’m not quite sure yet what the exact bottleneck is.