V5.0.5-airspy dump1090-fa with native AirSpy support now available

FlightAware ADS-B Flight Tracking
1

dump1090-fa-v5.0.5-airspy

dump1090-fa-v5.0.4-airspy

dump1090-fa-v5.0.3-airspy

dump1090-fa-v5.0-airspy

Way back in October of last year, I started working in integrating native AirSpy support into dump1090-fa. I actually finished it back in January/February but @obj has been swamped and just hasn’t had the time to create an official dump1090-fa release with the new sdr and demodulator. He did say though that it’d be OK if I announced it here with a link to my fork of dump1090-fa that has the updates. So…

My v5.0-airspy branch has everything the official v5.0 dump1090-fa release, plus a few extra things @obj has been working on that aren’t in an official release yet, plus the new sdr module for AirSpy and a new high rate demodulator.

This is NOT an official FlightAware release!
Having said that, I’ve been running it for months so it has been thoroughly run in.

How does it compare to running airspy_adsb+dump1090-fa? I can only tell you my experience on my hardware in my environment… I see more messages/aircraft with fewer CPU cycles used. The only way to know what it’ll do for you is to try it. If you’re a C developer, the code is open-source, so you can nose around all you want and contribute via pull requests if you like.

More info in the release notes linked above and in the following two READMEs that describe the additional stuff along with all their options…

Please report all issues in this thread for now.

10 Likes
2

I will definitely try this, I was waiting since you have announced you are working on it last year!
The various options for gain are a bit bewildering, but I guess that’s all good to have.
The hirate demodulator again has many options… sounds like fun to try out!
Lots to read in the readme!

3

I had 4.1 running for a few months tutoring myself on how things work
so having the new 5.0 airspy will certainly keep me occupied for a while
thankyou GTO i can now play hehehe

4

Would be also interesting how it does compare to running airspy_adsb+readsb from @wiedehopf

Maybe i give it a try later

5

Really doesn’t matter what you pipe the data into from airspy_adsb.
It’s just getting messages via network.
If readsb and dump1090-fa would differ significantly … that would likely be a bug and to be fixed.
But i really wouldn’t think so.

2 Likes
6

It’s all about the tuning knobs. :slight_smile: Please let me know if something in the READMEs is unclear. The parameters for the AirSpy are just pass throughs from libairspy.

I can’t remember where I got this diagram from but it shows the functional blocks of the R820T tuner.

image
image1054×733 82.6 KB

You can see the LNA, Mixer and VGA gains along the top of the path. The linearity and sensitivity gains are just pre-programmed values for those 3. I had to read the libairspy source to get what they really did.

airspy_sensitivity_vga_gains[GAIN_COUNT] = { 13, 12, 11, 10, 9, 8, 7, 6, 5, 5, 5, 5, 5, 4, 4, 4, 4, 4, 4, 4, 4, 4 };
airspy_sensitivity_mixer_gains[GAIN_COUNT] = { 12, 12, 12, 12, 11, 10, 10, 9, 9, 8, 7, 4, 4, 4, 3, 2, 2, 1, 0, 0, 0, 0 };
airspy_sensitivity_lna_gains[GAIN_COUNT] = { 14, 14, 14, 14, 14, 14, 14, 14, 14, 13, 12, 12, 9, 9, 8, 7, 6, 5, 3, 2, 1, 0 };

airspy_linearity_vga_gains[GAIN_COUNT] = { 13, 12, 11, 11, 11, 11, 11, 10, 10, 10, 10, 10, 10, 10, 10, 10, 9, 8, 7, 6, 5, 4 }
airspy_linearity_mixer_gains[GAIN_COUNT] = { 12, 12, 11, 9, 8, 7, 6, 6, 5, 0, 0, 1, 0, 0, 2, 2, 1, 1, 1, 1, 0, 0 };
airspy_linearity_lna_gains[GAIN_COUNT] = { 14, 14, 14, 13, 12, 10, 9, 9, 8, 9, 8, 6, 5, 3, 1, 0, 0, 0, 0, 0, 0, 0 };

They’re in reverse order so setting linearity gain to 21 for instance would set VGA=13, MIXER=12, LNA=14.

1 Like
7

airspy_adsb equivalent would just be using this single option:

--airspy-linearity-gain
1 Like
8

Hi all
i just cannot work out where to RUN …
./prepare-build.sh buster

after installing line
sudo apt-get install build-essential fakeroot debhelper librtlsdr-dev pkg-config dh-systemd libncurses5-dev libbladerf-dev libhackrf-dev liblimesuite-dev
where is the folder i run … -bash: ./prepare-build.sh: No such file or directory

9

Do you actually need to compile? WHat platform are you currently running on?

If you do need to compile…

$ sudo apt-get install libairspy-dev
$ git clone https://github.com/gtjoseph/dump1090.git dump1090-airspy
$ cd dump1090-airspy
$ git checkout airspy-hirate
$ make
$ make wisdom.local   ### this will take a while
$ sudo systemctl stop dump1090-fa
$ sudo cp dump1090 /usr/bin/dump1090-fa
$ sudo cp view1090 /usr/bin/view1090-fa
$ sudo cp starch-benchmark /usr/lib/dump1090-fa/
$ sudo cp wisdom.local /etc/dump1090-fa/wisdom-airspy.local
$ cd /etc/default
$ sudo cp dump1090-fa dump1090-fa.original

Now modify /etc/default/dump1090-fa using the sample in the release zip files.
When done, restart dump1090-fa with systemctl start dump1090-fa

10

Latest buster updated upgraded
then ran
sudo apt-get install build-essential fakeroot debhelper librtlsdr-dev pkg-config dh-systemd libncurses5-dev libbladerf-dev libhackrf-dev liblimesuite-dev

11

OK but if you’re running on a RPi 3 or 4, you should just download either dump1090-airspy-rpi-arm64.zip (for 64 bit) or dump1090-airspy-rpi-armv7.zip (for 32 bit) and follow the instructions on the release page. No need to compile.

12

So sorry in my excitement i just saw that link
thankyou
thankyou

john

13

Works.
I’m heavily terrain limited so i doubt i’ll notice much difference.

Had an issue restarting the service though.

Jul 06 17:41:56 pi dump1090-fa[17113]: rf_bias    : off
Jul 06 17:43:53 pi dump1090-fa[17113]: Tue Jul  6 17:43:53 2021 CEST  Caught SIGTERM, shutting down..
Jul 06 17:43:53 pi systemd[1]: Stopping dump1090 ADS-B receiver (FlightAware customization)...
Jul 06 17:43:53 pi dump1090-fa[17113]: Tue Jul  6 17:43:53 2021 CEST  Waiting for receive thread termination
Jul 06 17:43:53 pi dump1090-fa[17113]: AirSpy stopped streaming
Jul 06 17:44:36 pi systemd[1]: dump1090-fa.service: Main process exited, code=killed, status=9/KILL
Jul 06 17:44:36 pi systemd[1]: dump1090-fa.service: Failed with result 'signal'.

killed it manually

sudo pkill -9 dump1090-fa

Also /etc/dump1090-fa directory didn’t exist … creating that might need to go into your instructions.

You have a completely different signal level displayed which is kinda curious (using the same linearity gain).
I suspect your decoder might like higher gain so i increased it from 11 to 13.
(or is that a bad assumption due to the signal levels displayed?)

14

I’ve installed it and it’s running OK on 64 bit raspbian. Initially I am using the default settings in the sample config with the exception of the sample rate which I have set to 20. The gain is set to 14 as it was with airspy_adsb.

For reference, the others are:

sample format: u16o12
packing enabled
demod preamble threshold 0.9
demod smoother window 4
demod msg window -7:7

My settings for for airspy_adsb were:

-v -f 1 -w 5 -e 10.75 -t 300 and sample rate 20.

Using a pi 4 overclocked to 2GHz, that gave 80-90% cpu usage.

Initial impressions are that performance is not quite as good as airspy_adsb, but it’s certainly not far off. Range appears unaffected, which is what I would expect. Message rate is slightly lower, but I’ll need to run for longer to see how it changes with traffic. Messages per aircraft is definitely not far off at first glance.

The immediately obvious differences so far are RSSI and CPU usage. CPU usage is much lower with dump1090 - it’s using around 30-35% of one core. That gives a lot of headroom for playing with decoding options.

RSSI seems somewhat erratic at the moment. I was seeing a compressed range compared to the airspy decoder, from about -30 dB to -8 dB compared to -36 dB to 0 dB. After restarting to change an unrelated option, I’m now seeing -49 dB to -12 dB. Not sure what’s going on there, but I suspect that’s a display problem since I’m still seeing similar data.

image
image1616×432 25.9 KB

This looks quite promising, so I’m going to keep running it for a while and see whether I can improve on current performance.

15

Couldn’t reproduce the hang trying a couple of service restarts …
But i got this 2 times:

Jul 06 18:23:46 pi dump1090-fa[8359]: Tue Jul  6 18:23:46 2021 CEST  Caught SIGTERM, shutting down..
Jul 06 18:23:46 pi dump1090-fa[8359]: Tue Jul  6 18:23:46 2021 CEST  Waiting for receive thread termination
Jul 06 18:23:46 pi systemd[1]: dump1090-fa.service: Main process exited, code=killed, status=11/SEGV
Jul 06 18:23:46 pi systemd[1]: dump1090-fa.service: Failed with result 'signal'.

I’ve looked at the code in regards to the hang and can’t see anything obvious.
Might be libairspy … no clue.
To debug this i’d probably have to test on amd64 as valgrind just doesn’t seem to work on the RPi3 …

16

Odd. Is it repeatable?

Ah. That directory is created created by a standard install/upgrade of dump1090-fa to 5.0. I’ll add it (along with /usr/lib/dump1090-fa) to the instructions if you don’t already have 5.0 installed.

I can’t tell how airspy_adsb calculates the gain so there was no way to make it match. @obj and I traded a bunch of thoughts on this and what I wound up doing was taking the average of all the mark symbols in a message. The noise is then the average of all the space symbols.

17

Hmm i thought it was 5.0 when i did the apt install …
Maybe i copied over the file before i did that.
Nevermind then.

The segfault is reproducible but i’d have to look up how to hook up gdb so it does what i want and only shows details on the segfault.
Curiously no line number i could use with addr2line in dmesg.

18

I’ve restarted it about a thousand and one times during testing on my desktop and certainly 100+ times on Pis and Jetsons. Never had an issue on the desktop but on the Pis I occasionally saw an issue where the AirSpy was left in an inconsistent state on program shutdown, even with airspy_adsb. In fact, my service file for airspy_adsb had a ExecStartPost that checked that airspy_adsb successfully acquired the device and was receiving samples and restarted it if it wasn’t.

19

I’d be curious how much your airspy_adsb performance would drop going down to say 40 % CPU :slight_smile:
I doubt it would be dramatic at all.
I’ll leave the performance testing to you … my terrain limitation just make it kinda boring.

20

The default compile options are -O3 -g which isn’t very debug friendly. If you’re compiling yourself, try it with make CFLAGS='-O2 -ggdb'