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. 
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])
5.4
>>> np.mean(input[5:10])
7.0
>>> taps = np.array([0.2, 0.2, 0.2, 0.2, 0.2])
>>> out = np.convolve(input, taps)
>>> out[4]
5.4
>>> out[9]
7.0
2 Likes
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 
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.
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
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.
2 Likes
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.
4 Likes
Thank you for details on the AirSpy, I am new to this, but am much more familiar with such due to the posts here. Best to everyone here, Darren Chaker