FlightAware Discussions

Working on native AirSpy support for dump1090-fa

It should be identical to your “average 5” method (assuming you’re not running into precision issues). My point was not “reimplement it as a FIR”, my point was “this is a FIR already and you can analyse it as one to understand the frequency response”.

And that’s where getting a DSP book helps.

1 Like

Well, not quite identical. The FIR is a moving average and mine is a “average a block of 5, output a sample, move on to the next block of 5, output a sample” , tc.

I know. I got it. I just wanted to see what would happen and it took all of 5 minutes to implement as a FIR.

and it has helped. Unfortunately, it just makes me want to try more things that may or may not be useful. :slight_smile:

It’s identical.

>>> import numpy as np
>>> input = np.array([1, 7, 4, 3, 12, 4, 8, 3, 17, 3])
>>> np.mean(input[0:5])
>>> np.mean(input[5:10])
>>> taps = np.array([0.2, 0.2, 0.2, 0.2, 0.2])
>>> out = np.convolve(input, taps)
>>> out[4]
>>> out[9]

I see some discrepancy here.


I can do a side-by-side test later today.

Statistics: Mon Oct 19 10:40:16 2020 MDT - Mon Oct 19 12:19:26 2020 MDT

The 5 tap FIR had a slight edge in usable messages but used more CPU cycles than the the 5 tap simple average. Looking at view1090 in real time, the number of aircraft each was tracking bounced back and forth but it seemed that the FIR was more often the winner in that respect although they were always within an aircraft or 2 of each other.

I’m a little dubious about the 5.5% CPU utilization for the 5tap average though. In real time looking at the stats, it always showed about 18%. I might have caught it just as the stats were rolling over.

Summary stats printed after dump1090-fa exited.

Parameter 5tap FIR 5tap Average
samples processed 14515452066 14521687698
samples dropped 0 0
Mode A/C messages received 0 0
Mode-S message preambles received 110639770 99708503
with bad message format or invalid CRC 68593753 61006782
with unrecognized ICAO address 37751148 34493909
accepted with correct CRC 4002848 3922569
accepted with 1-bit error repaired 292021 285243
dBFS mean signal power -22.9 -22.9
dBFS peak signal power -10.9 -10.9
messages with signal power above -3dBFS 0 0
Mode A/C messages received 0 0
Mode S messages received 0 0
with bad message format or invalid CRC 0 0
with unrecognized ICAO address 0 0
accepted with correct CRC 0 0
accepted with 1-bit error repaired 0 0
total usable messages 4294869 4207812
surface position messages received 77348 76383
airborne position messages received 627070 612658
global CPR attempts with valid positions 692467 677115
global CPR attempts with bad data 20 21
global CPR attempts that failed the range check 11 12
global CPR attempts that failed the speed check 4 4
global CPR attempts with insufficient data 591 557
local CPR attempts with valid positions 8946 8862
aircraft-relative positions 0 0
receiver-relative positions 0 0
local CPR attempts that did not produce useful positions 2974 3037
local CPR attempts that failed the range check 1 1
local CPR attempts that failed the speed check 13 11
CPR messages that look like transponder failures filtered 0 0
non-ES altitude messages from ES-equipped aircraft ignored 0 0
unique aircraft tracks 1203 1162
aircraft tracks where only one message was seen 249 211
aircraft tracks which were not marked reliable 337 289
CPU load 27.7% 5.5%
ms for demodulation 299472 286656
ms for reading from USB 1305782 599
ms for network input and background tasks 45330 39827
1 Like

@obj Are you OK with me producing binaries for folks to test? If so, I assume you don’t want them to use it in a real feeder correct?

Sure if you want. So long as it’s not producing garbage I don’t see any problem with feeding.

Re comparisons, it’s best to do those by feeding in identical data. That is, take a capture of raw data and feed that same data to the two things you want to compare. Without a controlled input it’s too hard to rule out random variation.

You’re only messing with the signal going into the preamble filtering / decoder.
If you were messing with the preamble filtering / decoder you could screw up much much more in comparison.
I think even with full blast random data the filtering / decoder shouldn’t put out too much crap :wink:

Good point. I could capture with airspy_rx and feed it to dump1090 but I’d have to move the filtering and decimation to a converter (which is probably the right place for it anyway) or add ability to read from a file to sdr_airspy. The former is probably the better way to go.

That’s what I figured but I erred on the side of caution. Best to ask. :slight_smile:

This is kinda interesting… On a RPi 4 on 32-bit Raspian Buster with a 59Mb/s USB throughput, I get 15-25% MORE aircraft than on my x86_64 desktop with 141 Mb/s USB throughput.

Bah. I was connected to the wrong machine :slight_smile:

I used a few capture files from @caius, @wiedehopf and @navzptc to optimize the decoder. Maybe they are still available in some file share.

1 Like

I can definitely capture some but yeah, if anyone’s got any that demonstrate tricky scenarios, send links.

I still have the file I generated for that. Downloadable here for a while: https://we.tl/t-3QvqRKh2bG

I don’t know that it’s a tricky scenario, but I think it’s from a reasonably busy time. It’s about a minute of samples.


@caius What rate and format are those samples?

They should be 20MHz sample rate, captured on my mini but I don’t know what the format is. I didn’t use it personally, just passed it on to Wiedehopf when he was working on the decoder.

Edit - I found the command line I used to generate it:

airspy_rx -r /tmp/ramdisk/dump.bin -t 4 -a 20000000 -f 1090 -g 16

Should be 20MHz, U16 real samples with gain at 16.
Options for the -t switch are:
0=FLOAT32_IQ, 1=FLOAT32_REAL, 2=INT16_IQ(default), 3=INT16_REAL, 4=U16_REAL, 5=RAW

OK, thanks. Can’t use it now but I’ll hang on to it for later.

Just FYI… I haven’t given up… I’m working on the decoder.