FlightAware Discussions

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


This command should significantly reduce any graph related problem:

sudo sed -iE -e 's/rrdtool/sleep 3.4; rrdtool/g' /home/pi/adsb-receiver/build/portal/graphs/make-collectd-graphs.sh

It will change the graph generation script so it pauses for 3 seconds before drawing each of the graphs.
That way the CPU usage is nicely split up over time and should be no issue.

Also you can make sure the graphs are not written to disk but rather kept in ram.
This can be done with these commands

sudo echo "tmpfs /var/www/html/graphs tmpfs rw,nodev,nosuid 0 0" >> /etc/fstab
sudo mount /var/www/html/graphs

I’m curious though, did you install the database / flight history with the adsb receiver project?
In that case it may be easier to try the higher sample rate with a fresh piaware sd-card :slight_smile:
That way you know if it is possible or not.

If you aren’t afraid of losing warranty on your Raspberry Pi you can also try to disable the variable cpu frequency, to do this add the following to /boot/config.txt

arm_freq=1000 #reduced by wiedehopf, the site actually uses 1200
force_turbo=1 #Voids Warranty!
boot_delay=1 #helps to avoid sdcard corruption when force_turbo is enabled.

(see this page for details: https://haydenjames.io/raspberry-pi-3-overclock/)


thanks wiedehopf, taking data now on mini with splitter removed (so only one station). i started at gain=21 but quickly saw that the mini was not happy, i had aircraft overhead at 30,000 ft that were going grey. now at gain of 20 and things seem ok (i did have a king air 200 take off from my local airport and it also overloaded but that is not surprising). i am using a nearby station to compare (since my reference is currently shut off)


this is nice wiedehopf, thanks


Raspberry Pi 3B+
Bit packing on or off does not seem to have much impact on 20 MHz sample rate working without losing samples.

Deciding factor seems to be the message rate.

A message rate of about 1400 seems to be the breaking point for my RPi 3B+, that’s when i start to lose samples.

But i’m not really sure sometimes i can provoke lost samples by loading down the system with creating graphs. Or it may be unrelated and sometimes it just decides to drop samples.

@burgdorfer That explains why it’s working for you, your message rate is not that high with all the terrain.
Would you be so kind to add -v to your airspy_adsb options.
You can then check for lost samples with
sudo journalctl -u airspy_adsb -f -n50

@retman1222 What is the typical message rate displayed in your SkyView?


with the mini it’s higher than the v3. so far i have found peak rates of almost 900 m/sec. this is around 150 messages/second higher than the peak v3 rates. my gain is currently at 19 and i am seeing 4.8% more aircraft than the site 60nm away and 18% more positions.
need to wait until the end of the day but so far the gain set to 19 seems very happy…i have never been able to get numbers like this relative to the 60nm away site with the v3.


Yeah you can probably even go down to 17 without losing any planes far away.
I have some less attenuation compared to you and don’t get planes which are that far away but some signals are still very weak due to trees.
I went down as far as 12 without losing any significant amount of messages it seems.

How are the local airplanes close by, does the track get interrupted still?


my local airport, 1.8nm away, has a scheduled departure in about 2 hours. i will watch it and advise


So it seems at least for my Raspberry Pi i have determined the problems with lost samples:
The voltage of the power supply.

I have a very good powersupply but the voltage is adjustable.
I’ve measured and i lose around 0.25 V on the cable and the input protection of the Raspberry Pi.
So i’ve upped the supply to produce 5.3 V (from 5.15 V i had previously dialed in) at its own output, before the cable and protection circuitry.

Pretty sure it will now be very stable :slight_smile:
(Maybe wasn’t even message rate related, that was just a shot in the dark to be honest)

@retman1222 do you have by chance a good powersupply lying around that you can adjust? :stuck_out_tongue:

When the RPi is running at full power the power supply circuitry just seems to be quite undersized.
And that damned mini USB connector for providing power is just inadequate.


i am using an old HP6237B (pre name change to agilent) supply for my bias-t, currently set to 5vdc. i will measure the gpio pins on the RPI and see what voltage i have there and advise


That’s beefy enough :). How will you supply the bias-t then? I guess you could just parallel the Pi and the bias-t.
Depending on how you connect the Pi the voltage required will be different. (there is some input protection via the mini usb, not if you connect via the GPIO header which with a stable powersupply should work but isn’t recommended)

Also i just tried using the frequency your RPi runs at (1200 MHz), also tried 1300 MHz and both were not sufficient for -m 20. So i’m not sure the better voltage supply is going to help you.
Might not be worth the trouble.

I’m not even sure how much better 20 MHz sample rate is compared to 12 MHz.

Maybe @navzptc can switch his airspy to 12 MHz late this evening so we can compare today and tomorrow :slight_smile:


Slippery slope. After Airspy mini… this:


Well with the power supply cranked a bit up my 3B+ is handling -m 20 quite well :slight_smile:

Also there is the Odroid C2 that should be plenty enough power. But it’s only a bit cheaper so you can just buy the XU4 then.


My 3B is not that snappy. Anyway, if you don’t include - m, will default to 12.


I’m experimenting now using beast-splitter to forward the messages.

I get the impression the main thread is also handling network connections and some other stuff.
So having multiple feeders connect to airspy directly might not be a good idea in regards to performance on the RPi.

I’ll check with reduced clock rates for any improvements.


if navzptc sees appreciable reduction from m=20 to m=12 i will buy a B+


You have 2 pis and a good power supply, you can just try overclocking one :wink:

Apart from that with the beast-splitter distributing the messages it seems airspy_adsb is running much more stable.

I’m rewriting the install script right now to use beast-splitter.
Maybe you don’t need to overclock that much then to use - m20 :stuck_out_tongue:


Aha, you slowly arrive to my config. My airspy_adsb connects just to one port (30104) and the rest is done by dump1090-fa.
Beast-splitter probably works too, but IMO adds complexity and another process.


Yeah you are right. Didn’t really think about it :slight_smile:

On the plus side beast-splitter has really nice logging to syslog.
Also i had to test it for the sd-card install where pushing to 30104 doesn’t work.

Then again i’d need different configuration for both … ah … i’ll stay with beast-splitter. Have already included automatic installation of it in my install scripts.


Beast splitter was made for case of multiple feeds like your case.


That’s the problem - running Odroid xu4’s here after my pi 3B+ couldn’t handle the traffic - get consistent 2200+ messages here during peak periods and that unit just cruises along with plenty to spare - feed 3 sites with it with no hassle!

To be honest, didn’t see much change from 20 to 12, so stick at 12 with your pi :+1:t2: