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

[gtj0]

@bive

The CPU usage was between 90 and 100%.

Maybe you’re hitting the edge when the message activity slows down and the CPU goes up,
Are you running the 32 bit Raspbian or the 64 bit?
Try the other rate/format options I posted above and see how they do.

I think I know what’s causing the hang on shutdown and am working on a fix.

[bive]

@gtj0

Maybe you’re hitting the edge when the message activity slows down and the CPU goes up,

Yes, that might be the case. I’m keeping track of the logs and number of aircrafts the receiver can see.

@gtj0

Are you running the 32 bit Raspbian or the 64 bit?

32-bit.

@gtj0

Try the other rate/format options I posted above and see how they do.

Yes, I’ll do that. So far I see quite a drop in performance compared to my regular station.
But there are a fair number of parameters to experiment with, so who knows how it ends up

@gtj0

I think I know what’s causing the hang on shutdown and am working on a fix.

Great!

[LawrenceHill]

@gtj0

Please try different sample rates and formats!

Also remember the native reference frequencies of the Airspy Mini (24MHz) and the R2 (20MHz).
See these posts:

Airspy Mini - New investment?

In the case of the Mini, the reference frequency is 24 MHz. To get 12MSPS, it’s a simple binary counter, but for 20MSPS, a whole PLL is run at a few hundreds of MHz, followed by many clock dividers. This adds noise and adds a few milliamps of current drain. The data throughput is also something to consider. More data means everything runs at a higher speed: ADC, DMA, USB transceiver, interrupts, etc. This all translates in more current and a higher thermal envelope.

Airspy Mini - New investment?

Same story. The ref clock in the R2 is 20 MHz, which means 20 MSPS is native and doesn’t require any extra PLL. To get any rate that is not an integer division of 20 MHz, (for eg. 24MSPS,) a PLL + dividers are required. Furthermore, an extra effort is required for packing all the data at 24MSPS to fit within the transfer budget of USB 2.0. The MCU is clocked to allow these configs to run smoothly if the host computer is fast enough, but again… more data => more current => higher temperature.

[prog]

@LawrenceHill

Airspy Mini (24MHz)

It’s 12MSPS (derived from the 24MHz clock.)

[gtj0]

Oh boy. Now I’m confused.

Here’s the Mini Airspy Mini - airspy.com

• 12bit ADC @ 20 MSPS (10.4 ENOB, 70dB SNR, 95dB SFDR)
• 10, 6 and 3 MSPS IQ output – Optimized for portable and tablets

And here’s the R2 Airspy R2 - airspy.com

• 12bit ADC @ 20 MSPS (10.4 ENOB, 70dB SNR, 95dB SFDR)
• 10MSPS IQ output

I thought the R2 had the higher native sample rate. Did that change? I also just noticed that the pages have R820T2 crossed out and replaced with R860. When did that occur?

[bive]

@gtj0

Try the other rate/format options I posted above and see how they do.

Tested with a sample rate of 6, sample format sc16, demod-smoother-window 2 and demod-msg-window -7:7:

Offset   Count
-7:             117
-6:             127
-5:              70
-4:              58
-3:              57
-2:             503
-1:          261211
0:          936815
1:           50528
2:            1420
3:              48
4:              84
5:           20011
6:           64347
7:           25934

This has been (according to the reported data to FA) the best setting so far. Still a bit lower (approx 10-15%) of what I would expect when running airspy_adsb.

How do I interpret the low numbers in 3 and 4 compared to 5-7?

[gtj0]

@bive

How do I interpret the low numbers in 3 and 4 compared to 5-7?

With a sample rate of 6 there are only 3 samples per symbol so scanning beyond -3:3 you’re actually decoding messages from a little earlier and a little later than the one you’re supposed to be decoding, and spending extra cycles to do it. Narrow the window down to -3:3 and see what happens.

[caius]

@gtj0

I also just noticed that the pages have R820T2 crossed out and replaced with R860. When did that occur?

The R820T2 was discontinued, and the R860 is the replacement. It is basically the same chip with the same specifications and performance however.

[bive]

@gtj0

With a sample rate of 6 there are only 3 samples per symbol so scanning beyond -3:3 you’re actually decoding messages from a little earlier and a little later than the one you’re supposed to be decoding, and spending extra cycles to do it. Narrow the window down to -3:3 and see what happens.

Great! I’ll try that out and see how it goes.

[gtj0]

New release with fix for segfault on exit…

Release v5.0.1 with Native AirSpy Support and SEGV Fix · gtjoseph/dump1090

[gtj0]

Another little tip… Make sure you’re using the wisdom file appropriate for your architecture. The difference between using and not using it can be dramatic!! I was just testing on my Rpi4 32-bit and I’m using 24% CPU with the wisdom file and 47% without.

[bive]

Followed your instructions about the wisdom file, so I should be good.

Will install the new version later today.

[bive]

What parameter can I tweak to get a better reception of weaker signals?
I’m running two stations of the same antenna, my main station is a PC with an Airspy R2. I’m running dump1090 with airspy-support on an RPi4.
There is a noticable difference between the R2 (airspy_adsb) and the mini (dump1090-fa) in reception of weaker signals. Aircrafts that are partially blocked by objects surrounding me are picked up by the R2 but not the mini. When both systems are running airspy_adsb they both pick up the same aircrafts.

Is it --demod-preamble-threshold that I should tweak? Or the preamble strictness? Or should I change from linearity gain to sensitivity gain?
Does the linearity gain values correspond to the gain-values in airspy_adsb (I suspect that they do)?

[suffolk3000]

Hi all
can fix this some how seem to get this problem over and over TIA

clang: error: the clang compiler does not support ‘-march=armv7-a+neon-vfpv4’
make[2]: *** [dsp/generated/makefile.arm:25: dsp/generated/flavor.armv7a_neon_vf pv4.o] Error 1
make[2]: Leaving directory ‘/home/pi/dump1090’
dh_auto_build: error: make -j1 RTLSDR=no BLADERF=no HACKRF=no LIMESDR=no AIRSPY= yes DUMP1090_VERSION=6.0~dev returned exit code 2
make[1]: *** [debian/rules:54: override_dh_auto_build] Error 255
make[1]: Leaving directory ‘/home/pi/dump1090’
make: *** [debian/rules:63: build] Error 2
dpkg-buildpackage: error: debian/rules build subprocess returned exit status 2

[Humpfrey]

Have a look at
https://discussions.flightaware.com/t/native-airspy-support-for-dump1090-fa-is-now-available/78115/50

The package is on the page that gtjoseph links to

[suffolk3000]

I think clang is the problem
i did compile manually last night only got 1 error
i will keep trying all day see if i can get it running
Thanks Humpfrey

[prog]

Rafael Micro R820T/2 was planned to be discontinued, so we (Airspy, RTL-SDR Blog, Nooelec, and probably FlightAware behind the scenes,) asked for an extended production period. The R860 is basically the exact same silicon as the original R820T2 fabricated at a different facility with a new QA and branding. The price is also higher (about 3x). Apart from this folklore, it’s basically the same tuner. The most recent tuner design from Rafael Micro as of today is the R850, but it’s another league of complexity.

[suffolk3000]

i did try the new 5.0.1 file
got same errors as before
going to try 32bit later after a nap

[gtj0]

@suffolk3000

clang: error: the clang compiler does not support ‘-march=armv7-a+neon-vfpv4’

The message is clear… The version of clang you have doesn’t support that instruction set. gcc does however so just do a regular make without the CC=clang-9

@suffolk3000

going to try 32bit later after a nap

The error was for the 32 bit version. On 64-bit Raspbian you won’t get that error.

I’ll see if I can tweak the rules so 32-bit clang doesn’t use that instruction set.

[gtj0]

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

Also remember the native reference frequencies of the Airspy Mini (24MHz) and the R2 (20MHz). See these posts:

@gtj0

I thought the R2 had the higher native sample rate.

@prog Can you clarify the native sample rates? I could have sworn the R2 had the higher native sample/clock rate over the Mini but I may be mis-remembering.