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

Noise looks more like a preamble than messages do, comparatively.
If something looks like a preamble, a decode is attempted for the following data.

More decode attempts means more CPU used.

The higher the preamble setting, the more pronounced this is.

1 Like

Perfect explanation as usual. Thank You!

hello wiedehopf and others, are there any issues feeding FR24 when using Airspy Mini (currently running piaware 6.0 on SD card, 2.2 RC30 on buster)? i can’t remember if there were any warnings/comments re this and i’m getting old and forgetful!

when i ssh into my pi and run the fr24 install i get

E: Repository ' buster InRelease ’ changed its ‘Suite’ value from ‘testing’ to ‘oldstable’
N: This must be accepted explicitly before updates for this repository can be ap plied. See apt-secure(8) manpage for details.

any recommendations

1 Like
sudo apt-get update --allow-releaseinfo-change

Then you should be OK.

See this post:

lawrencehill, that did it (OBJ’s post re sudo apt update (not sudo apt-get update)…many thanks

1 Like

The weekend brought increased air traffic thanks to the first nice weather in maybe 8 months. I noticed what looked like a DF4 messages burst for a little while on Sunday. I don’t think this happens too often here. Traffic was much denser than usual for this region at the time. Tons of GA aircraft. Interesting (to me).

1 Like

Reactivated my Airspy in combination with the Uputronics filter, connected to a Raspi 4

Any tips for optimization or is it already good to go?

OPTIONS= -v -t 90 -f 1 -w 5 -P 8 -e 10.0 -C 75 -E 60

Graphs (so far):

Nice :slight_smile: much like mine

Have there been any updates to airspy_adsb v2.2-RC30? Is this still the best of the code changes?

As an RC, airspy_adsb v2.2-RC30 is the latest - but there is a 2 month younger test version of it. This latest has slight improvements, at least on my station and circumstances.
See: GitHub - wiedehopf/airspy-conf: Configure airspy_adsb for use with readsb or piaware.

sudo bash -c "$(wget -O -"
sudo bash -c "$(wget -O -"

If you’ve already installed the airspy-conf stuff … you can choose your poison.


Hello @wiedehopf ,

  • Is there a natural cap of msgs/sec rate around 2400-2600 at 20MSPS ? (higher is rarely spotted here)

Not inherently.

My suspicion is also that ATC radars will start reducing interrogation rates as the message rate ramps up.
Then you have more overlaps as the number of messages increases.
Do some math :wink: (i’m not sure exactly how to even approach that haha).
But you have some message rate and a message is a certain duration: Radartutorial
Note that there are short and long messages depending on DF type. (64 and 120 us i believe)

For 120 us long messages the absolute maximum theoretical rate is 8333 but the probability to get some overlap is obviously present at lower rates.
I have no stats on how many ModeAC messages are present which are on the same frequency.


Thank you for taking the time to respond.
I wanted to avoid studying the math background like any typically lazy guy, hoping you’re past the calculations and have a ready answer. :slight_smile:
ATC can actually reduce the query rate over a given amount of traffic, as this is for security, but beyond this phenomenon, the tendency is that the number of decoded DF17 packets may increase further, but the number of positions per second peaks at a certain value. Typically, a value of around 150-160 (RHS) can be read during the day.

Well you can do some very simplified models in your mind.

Say we have a rate of 2400 messages per second and they’re all long and there is one message, then some free air. (for simplicity)
That will cover 29 % of available airtime.

So if you send an extra message at a random time, you have a 29 % chance of overlap.
Again that’s much simplified but it gives a decent ballpark figure i think?

airspy_adsb tries decoding multiple phase offsets and due to the higher sample rate has a better chance to decode overlapping messages with phase offset.

If someone feels like doing some better math or wirte a simple program to just simulate the whole thing with random numbers, go ahead :slight_smile:

The simplified model you have outlined is perfectly sufficient for me to associate an illustration with it in an easy imagination.
lol It’s better to save on expensive paper :slight_smile:

Indeed, the chance of finding the preamble is proportional to the sampling rate - and the high number of overlaps and the imperfect signal-to-noise ratio have the opposite effect. … in addition, as traffic increases, the number of ACAS (DF0 and DF16) increases, further increasing the number of overlaps.

I think, we can simply enjoy the fact of having a working decoder - thanks for the great dev work behind.
For some reason, I am always tempted to complicate my otherwise quiet work day. :slight_smile:

Thank you

1 Like

The current math is heavily optimized. The small tweaks in the internal parameters (filters) can have different effects depending on the receive conditions. We have a good average, I would say. To get better results, we will need a completely different approach, from the hardware to the DSP. As of today, I don’t think it’s economical.

1 Like

If we skip the economic factor, what kind of improvement do you think is possible? And would there be different solutions for a busy site close to Heathrow compared to a site in a less aircraft-dense area?