Working on native AirSpy support for dump1090-fa

Which is why I use a mutex around useModesMessage and similarly protect the modification of the Modes.* members.

The SEGV is in flushWrites because Modes.clients list is empty.
useModesMessage()
modesQueueOutput()
modesSendBeastVerbatimOutput()
writeBeastMessage()
completeWrite()
flushWrites()

The message is printed by modesCloseClient which must have happened on the previous output. Since there’s an explicit warning message there I thought you may have run into the issue before. I’ll toss an abort() in there after printing the message and see what it turns up. I’m guessing it’s because of a short write in flushWrites. BTW, the only client is 1 instance of view1090.

I can probably get you an x86_64 build later today. It’s just the 32-bit ARM version that’s problematic.

1 Like

That doesn’t cause a segfault:

for (c = Modes.clients; c; c = c->next) {

empty means it is NULL, thus the loop will do 0 iterations.

Also put your code up otherwise it doesn’t make sense to speculate why it’s segfaulting.

No need to speculate. I can track it down. I just thought that since there was an explicit warning about the double close that it might have been a condition that had been seen before.

A mutex around useModesMessage() is not sufficient. useModesMessage() can touch many other parts of global state and you need to protect against any concurrent access to that, which can happen from paths that do not pass through useModesMessage().

In your particular case I expect that what is happening is that useModesMessage() and the “background work” part of the main loop are running concurrently and accessing the network writer/client state.

Really, the dump1090 code was never written to be threadsafe and trying to make it threadsafe is potentially a lot of work. If you need to run decoding in separate thread(s) I’d suggest isolating them via a threadsafe FIFO and pushing the decoded data to the main thread for processing (much like how the raw SDR data works). (Also, you’ll probably need to look at how the address hash table is used, that may need special handling)

Ok where can we download the x86_64 build :smiley:

1 Like

Yep, it was backgroundTasks. I had forgotten that it did network stuff. Multi-threading isn’t strictly necessary so I’ll mess with it a bit and if I can get it working safely fine, otherwise I’ll save it for a later time.

Now that I know what the segfault issue is, I should be able to have one this afternoon.

3 Likes

@SoNic67 @TwenteRadar and others… Here’s a test release of dump1090 with AirSpy support for x86_64.

You’ll need to install the airspy libraries. On Ubuntu/Debian the package should be libairspy0. For Fedora, it’s airspyone_host.

I would suggest you NOT overwrite your existing dump1090-fa and run this separately with your airspy device.

You can run it with the following minimum options… --device-type airspy if you have only 1 device but the help text has been updated so you can used --help to see the AirSpy specific options. The following sample rate and formats are supported:

  • –sample-rate 6 --sample-format sc16 (IQ format will actually run the AirSpy at 12MS/s)
  • –sample-rate 10 --sample-format sc16 (IQ format will actually run the AirSpy at 20MS/s)
  • –sample-rate 12 --sample-format u16 (the default if neither option is specified)
  • –sample-rate 12 --sample-format sc16 (IQ format will actually run the AirSpy at 24MS/s)
  • –sample-rate 20 --sample-format u16
  • –sample-rate 24 --sample-format u16

You should probably also enable packing with --enable-packing. I’m probably going to make this the default as you don’t actually lose anything by enabling it and it reduces the USB bandwidth requirement.

Make sure you try out the gain options. For linearity and sensitivity gain, the values are 0-21, for the individual vga, mixer and lna gains, the values are 0-15.
Here are the tables for linearity-gain and sensitivity gain. The tables are actually in reverse order with the highest gain (21) first.
Example --linearity-gain 20 will set vga-gain=12 mixer-gain=12 lna-gain=14.

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 };
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 };
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 };

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 };
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 };
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 };

If you can, run dump1090 from the command line with --stats-every 1 and compare using airspy_adsb+dump1090-net-only and dump1090 with native airspy. In particular, look at “total usable messages”, and the surface and airborne positions and the global CPR attempts.

I’ve also uploaded a copy of view1090 that has features not yet published that give you summary information like so…

 Tot: 125 Vis: 125 RSSI: Max  -5.2+ Mean -23.7 Min -32.2-  MaxD:  208.3nm+     -
 Hex    Mode  Sqwk  Flight   Alt    Spd  Hdg  Dist(nm) Bearing  RSSI  Msgs  Ti
────────────────────────────────────────────────────────────────────────────────

This can give you a real-time summary of aircraft counts, signal strength, and max distance without having to use the web-apps.
You can use it like so…
view1090 --interactive-ttl 10 --lat <your_lat> --lon <your_lon> --interactive-show-distance
These features should be in the next official dump1090 release.

Looking forward to feedback!!

1 Like

I would have to wait, thank you. Work send me away from house for a month (different continent) so I can’t physically access the system, just remotely. If is a chance to mess up, I would rather be close to fix it…

Making my first test!

1 Like

I’d just like to add that I’ve been following this with interest. I don’t understand most of it but it’s fascinating to watch it unfold. Great job!

What is a default preamble value (-e option) in airspy?

Not sure but based on CPU utilization, I’d say “5”.

I just updated the x86_64 binary. I think I shaved another 10 points off the CPU utilization.
https://github.com/gtjoseph/dump1090/releases/download/v4.0-airspy-alpha1/dump1090.x86_64

OH: Use --sample-filter noise-cancel for both better capture rate and lower CPU%.

1 Like

Actually, I just uploaded armhf and aarch64 versions to github as well…

For the armhf RPi version, you’ll have to use --demod-threads 2 as 1 thread isn’t fast enough to keep up. I’ve reduced the CPU utilization about 90% but it still needs more work.

5 Likes

New install of 64bit Raspberry Pi Os.
Compiled the binaries and installed them but I am seeing no mention of Airspy with dump1090-fa --help
Currently just running with a blue FA dongle if that makes any difference.

I’m still working on cleaning up the source code so if you’ve compiled something, you’ve compiled the wrong thing. :slight_smile:

You want to download one of the binaries from the link above (aarch64 for 64 bit Raspberry Pi OS).

1 Like

That would explain, thank you.


Note: I am still experimenting with a blue FA stick.

However, when I use the aarch64 binaries, on a new install,
–device-type --airspy

produces an error

“SDR type ‘airspy’ not recognized. Supported SDR types:
rtlsdr
bladerf
hackrf
none
ifile
Unknown or not enough arguments for option ‘–device-type’.
Try ./dump1090.aarch64 --help for full option help.”

– version

| dump1090 ModeS Receiver dump1090-fa v4.0-airspy-alpha1-33-g54c5c31 |

build options: ENABLE_RTLSDR ENABLE_BLADERF ENABLE_HACKRF
There is no mention of airspy with --help
apart from
“dump1090-fa v4.0-airspy-alpha1-33-g54c5c31”

There are no dashes before the airspy. It’s just --device-type airspy. It wouldn’t matter though. I built the aarch64 version incorrectly. :slight_smile: New binaries forthcoming.

1 Like