HOWTO: Airspy mini and Airspy R2: Piaware / dump1090-fa configuration

I was just joking, i’m aware you need IQ for 978 MHz instead of somewhat simpler non complex data when decoding 1090 MHz :wink:

Yeah i’ll try and see where the CPU is going, is there a simple way to mark the threads or run a profiler?

Getting pretty much the same results as you.

real	0m13.465s
user	0m11.614s
sys	0m1.851s

Probably means i’ll need to tackle the soapysdr airspy interface.
I’ll try some different compile options, that’s always low hanging fruit :slight_smile:

Ok, so it’s probably not the dump978 side. Is it actually saturating a core when you see overruns? The overrun errors just mean that we got a SOAPY_SDR_OVERFLOW error, not necessarily that we’re going slow; maybe it is something further up the stack like the airspy sending a large burst of data all at once or a problem with the buffer management or something odd like that?

Yeah it was saturating a core, just compiled with -march=native and it seems to have calmed down, no longer saturating a core.

Maybe it’s using some floats and your compile options don’t use the hard float ABI?
(or something along those lines)

I think CS16H should be an all integer path now, except during init. I would have expected any problems like that to show up in the --file test though.

It’s very weird, i just recompiled with default options, and it’s not doing it anymore …

Just for reference, load level with default options and below with -march=native :

Not seeing any more overflows, but i don’t think i’ve changed anything …
(it was a different time of day, maybe the device was throttling thermally)

Anyhow that -march=native gives a nice CPU reduction, those 15% on one of the threads is a pretty substantial difference.

Hello all,

I’m hoping someone may be able to offer some advice.

I have a fairly busy site (around 3500 planes per day, around 1.5 Million messages per day about 20 NM East of London Heathrow) so recently upgraded to a Raspberry Pi 4 and an Airspy Mini so see if I could improve my site performance. There is a Uputronics filtered amp in front of the Airspy powered by the airspy bias-t and a FlightAware co-linear antenna.

The improvement has been pretty good and I have seen peak message rates up to around 2800 per second (previously not seen anything over 1700 messages per second or so).

But I’m a bit confused about the airspy_adsb settings.

I notice that one comment on the thread here suggests that the “packing” option (-p) was best off (ie option not used) for the Raspberry Pi 4. However, having removed that I’m running into “This feeder is not being used for multilateration because its timing information appears to be unreliable. This can be caused by the site location being incorrect, or because your Pi is running out of free CPU.” anomolies.

The Raspberry Pi 4 is set to use NTP timing from two local GPS receivers (part of the NTP pool) so I doubt the issue is system time. Certainly the Raspberry Pi is indicated it is correctly synced to the NTP servers.

I have only seen the “anomalies” since removing the “-p” option but (again according to threads here) it looks like I was dropping messages at peak times when the “-p” option was being used.

What is the best way to check if I am dropping messages?

I’m aware that the “-e” option potentially has a big impact. Before removing the “-p” option I had increased up to “-e 10.1” and seemed to be experiencing better performance.

With the “-p” option removed I have option I have decreased the “-e” option to “-e 8.5” and am still seeing the anomalies reported on the Flightaware site.

Is this interaction between the “-p” and “-e” option expected?

How should I try and optimize the combination of the “-p” and “-e” options?

Overall the combination of “-p -e 10.1” seems to give me better figures- but that seems doesn’t seem to match with what I’m seeing on this thread.

I notice that Airspy mini still seems to have a USB2 interface but I suspect the raspberry Pi 4 has much better bandwidth behind the USB ports.

Does anyone have any thoughts or advice for tuning my performance in my specific case?

Thank you for your time- and the amazing work everyone does.

Andy.

Piaware doesn’t use the local RPI time for MLAT. It only uses the internal timing in the dongle(Airspy or rtl-sdr).

FYI, I also run RPIs with GNSS/GPS receivers feeding NTP. I various models from $US30 to $US200 RPI hats.

I think I had to remove the -p option too. My best antenna feeds an Odroid XU4 (I have second setup that feeds an RPI4, however, the antenna is in my attic not on the chimney).

If you are in an electrically noisy area then the uputronics filter can get overloaded (I have many 1090Mhz, 978Mhz ceramic, 144Mhz etc). The newer rtl-sdr filter works much better. I have to use cavity filters when I use the uputronics amp/filters (I still use them with the rtl-sdr amp/filter as I haven’t had time to test without a cavity filter).

The RPI4 suffers from one USB 2.0 channel for all devices. It can’t handle another USB 2.0 device with the airspy. I know because I tried to run an airspy with an rtl-sdr for UAT 978 and both failed miserably.

You have to experiment to see which settings work best for your environment. I get about the same amount of traffic as you do, however, I am in NYC and my messages per second is much lower than you get (EU sends more data than the US, as we have seen in many posts).

If it works better for you with -p, just turn it on.
There is no penalty for that option.

Normally you can not connect other USB devices to the RPi while using the Airspy, otherwise MLAT can suffer.

Also make sure you have all the updates for the RPi4 (sudo apt update; sudo apt dist-upgrade)

Jon,

Thanks for that advice! I’ve learnt something there with your comments I MLAT too- I hand’t realised that so thank you.

wiedehopf,

Thank you also- again that’s useful to know. If there is no penalty from “-p” I can try different options and see what works best.

I don’t have any other USB devices connect so that’s ok and software is up to date.

However, you both may be interested to learn- a error on my part meant I was running the “stretch” 3.8.0 release.

I’ve just followed the instructions properly and have the buster version installed now.

I guess that’s the downside of changing two things at the same time (or two things too quickly perhaps?)!

For now, it looks more stable (and I have gone back to “-e 10.1”) so I’ll monitor that and see how it goes.

Thank you both again for your rapid help :slight_smile:

Andy.

Hello Everybody.
Anybody here with a PI4 4GB and a airspy mini that upgrade to PiAware 3.8.0 ?
Screenshot from 2020-01-07 20-25-14
I did this and now nothing is working anymore.
sudo journalctl -u airspy_adsb
Screenshot from 2020-01-07 20-02-30
Airspy up to date
Screenshot from 2020-01-07 20-04-45
cat /etc/default/airspy_adsb


Done sudo apt-get update and sudo apt-get upgrade and mlat-client not updating
Screenshot from 2020-01-07 20-22-48
piaware-config -showall


Anybody any ideas?

Thanks, Marc

Re-run the airspy install script, reconfigure it.

Thanks @wiedehopf . That worked!
Thanks again.

I’ve tried the manual script on the latest version of PiAware (3.7.2) and Raspbien all fully updated and get:

pi@piaware:~ $ sudo systemctl status airspy_adsb
● airspy_adsb.service - Airspy ADS-B receiver
Loaded: loaded (/etc/systemd/system/airspy_adsb.service; enabled; vendor preset: enabled)
Active: active (running) since Wed 2020-01-08 16:24:37 EST; 10h ago
Docs: HOWTO: Airspy mini and Airspy R2: Piaware / dump1090-fa configuration - #2 by wiedehopf
Main PID: 11034 (airspy_adsb)
Tasks: 1 (limit: 4915)
CGroup: /system.slice/airspy_adsb.service
└─11034 /usr/local/bin/airspy_adsb -v -f 1 -p -l 29999:beast -l 47806:asavr -g 21 -m 12

Jan 09 03:12:33 piaware airspy_adsb[11034]: Acquired Airspy device with serial 644064DC304E91CD
Jan 09 03:12:33 piaware airspy_adsb[11034]: airspy_set_samplerate() failed: AIRSPY_ERROR_LIBUSB (-1000)
Jan 09 03:12:34 piaware airspy_adsb[11034]: Acquired Airspy device with serial 644064DC304E91CD
Jan 09 03:12:34 piaware airspy_adsb[11034]: airspy_set_samplerate() failed: AIRSPY_ERROR_LIBUSB (-1000)
Jan 09 03:12:35 piaware airspy_adsb[11034]: Acquired Airspy device with serial 644064DC304E91CD
Jan 09 03:12:35 piaware airspy_adsb[11034]: airspy_set_samplerate() failed: AIRSPY_ERROR_LIBUSB (-1000)
Jan 09 03:12:36 piaware airspy_adsb[11034]: Acquired Airspy device with serial 644064DC304E91CD
Jan 09 03:12:36 piaware airspy_adsb[11034]: airspy_set_samplerate() failed: AIRSPY_ERROR_LIBUSB (-1000)
Jan 09 03:12:37 piaware airspy_adsb[11034]: Acquired Airspy device with serial 644064DC304E91CD
Jan 09 03:12:37 piaware airspy_adsb[11034]: airspy_set_samplerate() failed: AIRSPY_ERROR_LIBUSB (-1000)
pi@piaware:~ $ uname --all
Linux piaware 4.19.66-v7+ #1253 SMP Thu Aug 15 11:49:46 BST 2019 armv7l GNU/Linux

I’ve rechecked all of my work and don’t see any errors.

Any suggestions?

3.7.2 is not actually the current image, not that it should really matter in this case.

Let’s try this:

echo blacklist airspy |sudo tee /etc/modprobe.d/airspy-blacklist.conf ; sudo rmmod airspy

The kernel module is not require for the airspy application afaik, this can cause some problems.
I’m not sure why those problems happen sometimes.
Try rebooting as well … it’s somewhat of a strange bug/error.

This is what I get:

pi@piaware:~ $ echo blacklist airspy |sudo tee /etc/modprobe.d/airspy-blacklist.conf ; sudo rmmod airspy
blacklist airspy
rmmod: ERROR: Module airspy is not currently loaded

I thought PiAware 3.7.2 was the latest version however I see from the current download page it’s now 3.8.0.

If you think it would be easier I can easily get my FeederID and then download the latest version and create a new SD card and start over from scratch.

With the issues you’re having, this would be my preferred method. At least that way you’re starting with a clean image.

2 Likes

I’d just start with Raspbian Buster Lite, unless you require the piaware sd-card for configuration purposes.
Again that’s just personal preference and not necessarily the root of your problem.

I believe the Airspy Mini has a little switch you can move around, it needs to be in the right position if i’m not mistaken.

Anyhow start fresh and check what happens.
I can’t offer you any advice as i don’t know what could be the problem.
So my only advice: try again/ try with a fresh image.

Your device is running a very old version of the firmware. Try downloading the latest version from the website at the bottom of the page of your product (R2 or Mini).

1 Like

prog - That was the issue. I’m running an R2 and once I updated to the latest firmware the issue was resolved. I did a lot of Googling before I asked the question and nothing suggested this could be a firmware issue on the AirSpy R2.

wiedehopf - May I politely suggest you update your documentation so instruct users to upgrade to the latest firmware BEFORE they try either your automated or manual scripts. Once the firmware upgrade is completed this works fine with either the manual or automated process.

1 Like