Stream1090

[jimMerk2]

Regarding the FIR filter in the RTL-SDR dongle, from the librtlsdr.c file that obj linked to above, I guess in order to change the filter coefficients (taps) you would just change the following:

static const int fir_default[FIR_LEN] = {
	-54, -36, -41, -40, -32, -14, 14, 53,	/* 8 bit signed */
	101, 156, 215, 273, 327, 372, 404, 421	/* 12 bit signed */
};

Note that FIR_LEN is 16 and is half the filter length (32) as it says in the comment. The filter is symmetrical (even number of taps).

The freq response shows a gain of approximately 70 dB at DC. The gain at DC is just the sum of the taps which is 4238 or 72.5 dB. I would think that is normalized somewhere in the RTL-SDR implementation.

[JRG1956]

@mgrone

Let me know how it goes.

I have this running at the moment.

jrg@MBPro2021 filter_utils % python3 diff_evolve_fir.py --data /Users/jrg/Desktop/samples1G.bin --fs 10000000 --fs-up 24000000 
Starting Differential Evolution...
[Stream1090] build 260120
[Stream1090] Input sampling speed: 10 MHz
[Stream1090] Output sampling speed: 24 MHz
[Stream1090] Input to output ratio: 5:12
[Stream1090] Number of streams: 24
[Stream1090] Size of input buffer: 15360 samples 
[Stream1090] Size of sample buffer: 36864 samples 
[Stream1090] Loaded 15 taps from ./diff_evolve_fir_temp.txt
-------------------------------------------------------------
|     Type |  #Msgs |  %Total |    Dups |   Fixed |   Msg/s | 
-------------------------------------------------------------
|    ADS-B |   6656 |   52.6% |   51.3% |   27.7% |   133.1 | 
|   Comm-B |   1255 |    9.9% |   34.9% |         |    25.1 | 
|     ACAS |   2760 |   21.8% |   27.6% |         |    55.2 | 
|     Surv |    502 |      4% |   33.6% |         |   10.04 | 
|    DF-11 |   1476 |   11.7% |   54.1% |   35.7% |   29.52 | 
-------------------------------------------------------------
|  112-bit |   8166 |   64.6% |   48.8% |   23.7% |   163.3 | 
|   56-bit |   4483 |   35.4% |   39.5% |   15.5% |   89.66 | 
-------------------------------------------------------------
|    Total |  12649 |    100% |   45.9% |   21.1% |     253 | 
-------------------------------------------------------------
(Max. msgs/s 253)
Messages Total 12649
19556
Eval params=[-0.3048  1.1914 -0.8946  0.7031 -0.2917] → messages=12649
Eval bounds=[[-0.8048  0.1952]
 [ 0.6914  1.6914]
 [-1.3946 -0.3946]
 [ 0.2031  1.2031]
 [-0.7917  0.2083]]
| Best so far: 19556 @ [-0.3048  1.1914 -0.8946  0.7031 -0.2917]

Does it stop after a set number of iterations?

It took me a while to work out how to compile stream1090 on macOS - for anyone else doing this, you need to edit CMakeLists.txt and add full paths to the compilers before the project line.

set(CMAKE_C_COMPILER "/opt/homebrew/cellar/gcc/15.2.0/bin/aarch64-apple-darwin25-gcc-15")
set(CMAKE_CXX_COMPILER "/opt/homebrew/cellar/gcc/15.2.0/bin/aarch64-apple-darwin25-g++-15")

project(stream1090)

This is just a test file to get it working.

One thing I would like to explore is how specific the filter is to the sample it has been “trained” on.

[mgrone]

@JRG1956 No it will never stop. You will get some indicator that it has closed down by looking at the bounds.

# ==================== END OF RUN ====================
# Time: 2026-01-21 22:13:51
# Instance: ../../samples/balcony_6M_5.raw
# FS: 6.0 MHz → FS_UP: 12.0 MHz
# Number of taps: 15
# Best params: [-0.3599117653819717, 1.235708371398938, -0.8997009318804052, 0.7212277112049269, -0.25219918068664177]
# Best ext-squitter count: 12070
# Best message count: 10564
# Current bounds:
# [-0.396989, -0.296989]
# [1.192245, 1.292245]
# [-0.940674, -0.840674]
# [0.664777, 0.764777]
# [-0.296020, -0.196020]
# Best taps:
-0.0019240524852648377
0.049912694841623306
0.037688665091991425
0.017241165041923523
0.03471251204609871
0.026454921811819077
0.2121589183807373
0.2475104182958603
0.2121589183807373
0.026454921811819077
0.03471251204609871
0.017241165041923523
0.037688665091991425
0.049912694841623306
-0.0019240524852648377

It is currently hard coded that the upper and lower bounds are 0.1 apart. The above example is one of those, where it has narrowed down things (the bounds have closed in). You can safely stop it or restart it by putting the best parameters into the python file:

CENTER_SEED = [-0.30480078491692353, 1.191383872925207,
               -0.8946397241760973, 0.7031294489517014,
               -0.29172370808888537]

[mgrone]

Yep and you will quickly figure out that the current stuff will be in a different league.

[mgrone]

OS X question: Isn’t it easier to install the official command line tools from apple instead of going the hombrew path for the compiler?

[JRG1956]

I have OSX command line tools installed.

The problem is with the compiler it uses - when I tried make I got errors:

jrg@MBPro2021 build % cmake ../ -DEND_STATS=ON
-- The C compiler identification is AppleClang 17.0.0.17000603
-- The CXX compiler identification is AppleClang 17.0.0.17000603
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Check for working C compiler: /usr/bin/cc - skipped
-- Detecting C compile features
-- Detecting C compile features - done
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Check for working CXX compiler: /usr/bin/c++ - skipped
-- Detecting CXX compile features
-- Detecting CXX compile features - done
-- Build type not specified: defaulting to release.
-- Configuring done (2.8s)
-- Generating done (0.0s)
-- Build files have been written to: /Users/jrg/SynologyDrive/Scratch/Aircraft Tracking Notes/Stream1090_Dev/stream1090/build
jrg@MBPro2021 build % make
[ 16%] Building CXX object CMakeFiles/stream1090.dir/main.cpp.o
clang++: warning: argument '-Ofast' is deprecated; use '-O3 -ffast-math' for the same behavior, or '-O3' to enable only conforming optimizations [-Wdeprecated-ofast]
In file included from /Users/jrg/SynologyDrive/Scratch/Aircraft Tracking Notes/Stream1090_Dev/stream1090/main.cpp:12:
In file included from /Users/jrg/SynologyDrive/Scratch/Aircraft Tracking Notes/Stream1090_Dev/stream1090/include/SampleStream.hpp:16:
/Users/jrg/SynologyDrive/Scratch/Aircraft Tracking Notes/Stream1090_Dev/stream1090/include/DemodCore.hpp:491:31: error: non-constexpr declaration of 'currTimeTo12MhzTimeStamp' follows constexpr declaration
  491 | inline uint64_t DemodCore<8>::currTimeTo12MhzTimeStamp() {
      |                               ^
/Users/jrg/SynologyDrive/Scratch/Aircraft Tracking Notes/Stream1090_Dev/stream1090/include/DemodCore.hpp:449:21: note: previous declaration is here
  449 |         constexpr uint64_t currTimeTo12MhzTimeStamp() {
      |                            ^

I decided to try GCC. (Note I know very little about compilers, so this was just my usual trial and error approach tp problem solving.)

[mgrone]

I pushed some fixes to the repo that hopefully fixes the issues with clang. Make sure that you do a proper rebuild with cmake ../ --fresh in the build directory.

[JRG1956]

Thanks - for each new version in the repository, I always rename the stream1090 directory and start from scratch. Just have to copy any files I have added to the new stream1090 directory.

Out of interest, was the problem that Apple’s gcc is version 17?

I saw that the raspberry pi was using gcc14 and the deprecated warning mode me think I needed an earlier version, so that led me to gcc15 in Homebrew.

While searching for the error in the console log I came across this:

jrg@MBPro2021 build % brew install gcc
✔︎ JSON API cask.jws.json                                                                                                                                                                                              Downloaded   15.3MB/ 15.3MB
✔︎ JSON API formula.jws.json                                                                                                                                                                                           Downloaded   32.0MB/ 32.0MB
Warning: gcc 15.2.0 is already installed and up-to-date.
To reinstall 15.2.0, run:
  brew reinstall gcc
jrg@MBPro2021 build % gcc --version
Apple clang version 17.0.0 (clang-1700.6.3.2)
Target: arm64-apple-darwin25.2.0
Thread model: posix
InstalledDir: /Library/Developer/CommandLineTools/usr/bin

I realise that I was wrongly thinking clang was a non gcc compiler, but it is.

Should I expect to see any change in results with the newer version?

[mgrone]

Uhhh now i have to reactivate old brain cells. So i am trying not to spread misinformation. If i remember correctly, there is a gcc interface for clang/llvm. You can compile c++ code with clang by using a gcc like interface. The underlying compiler however is not gcc, it is clang with plenty of apple spice in there.

I was a bit sloppy with the rules of the c++ standard and clang complained while gcc did not. You can have a look if the clang code is quicker or not. Earlier versions of stream1090 were actually a bit quicker using clang on a raspberry pi 5 (which of course you can do).

[JRG1956]

@mgrone

restart it by putting the best parameters into the python file:

I did some runs yesterday and give some feedback on the filter optimisation. Running on my Mac reduced the processing time per iteration, so I decided to use my 48G raw sample (72GB file size) for these tests too.

================================================================
# Instance: /Users/jrg/Desktop/samples48G.raw
# Time: 2026-01-22 15:54:20
# FS: 10.0 MHz → FS_UP: 24.0 MHz
# Number of taps: 15
# Best score: 743147
# Best total: 472425
# Best params: [0.13953630154199936, 0.7176180363178011, -1.3410863726578264, 0.48233009854454334, -0.23376920999061102]
# Current bounds:
# [-0.804801, 0.195199]
# [0.691384, 1.691384]
# [-1.394640, -0.394640]
# [0.203129, 1.203129]
# [-0.791724, 0.208276]
# Best taps:
0.00032130509498529136
0.0349586196243763
0.006381621118634939
-0.04742264375090599
0.028139382600784302
0.1774853616952896
0.23915433883666992
0.12196401506662369
0.23915433883666992
0.1774853616952896
0.028139382600784302
-0.04742264375090599
0.006381621118634939
0.0349586196243763
0.00032130509498529136

This was achieved on the 8th iteration.

I then confirmed the filter’s improved results by running it against the 260115 filter you provided in Custom filters as JRG1956_0.txt.

jrg@MBPro2021 stream1090 % ./run_stream1090.sh     
start time 17:33:15 22-01-26
[Stream1090] build 260120
[Stream1090] Input sampling speed: 10 MHz
[Stream1090] Output sampling speed: 24 MHz
[Stream1090] Input to output ratio: 5:12
[Stream1090] Number of streams: 24
[Stream1090] Size of input buffer: 15360 samples 
[Stream1090] Size of sample buffer: 36864 samples 
[Stream1090] Loaded 15 taps from custom_filters/JRG1956_0.txt
-------------------------------------------------------------
|     Type |  #Msgs |  %Total |    Dups |   Fixed |   Msg/s | 
-------------------------------------------------------------
|    ADS-B | 266513 |   56.7% |   51.6% |   29.3% |   148.1 | 
|   Comm-B |  51985 |   11.1% |   35.7% |         |   28.88 | 
|     ACAS |  71155 |   15.1% |   27.6% |         |   39.53 | 
|     Surv |  15317 |    3.3% |   33.6% |         |   8.509 | 
|    DF-11 |  64902 |   13.8% |   55.1% |     37% |   36.06 | 
-------------------------------------------------------------
|  112-bit | 321400 |   68.4% |   49.5% |   25.4% |   178.6 | 
|   56-bit | 148472 |   31.6% |   43.2% |   20.4% |   82.48 | 
-------------------------------------------------------------
|    Total | 469872 |    100% |   47.6% |   23.9% |     261 | 
-------------------------------------------------------------
(Max. msgs/s 261)
Messages Total 469872
finish time 17:39:36 22-01-26
jrg@MBPro2021 stream1090 % ./run_stream1090.sh 
start time 17:52:23 22-01-26
[Stream1090] build 260120
[Stream1090] Input sampling speed: 10 MHz
[Stream1090] Output sampling speed: 24 MHz
[Stream1090] Input to output ratio: 5:12
[Stream1090] Number of streams: 24
[Stream1090] Size of input buffer: 15360 samples 
[Stream1090] Size of sample buffer: 36864 samples 
[Stream1090] Loaded 15 taps from custom_filters/260122_OptFilter.txt
-------------------------------------------------------------
|     Type |  #Msgs |  %Total |    Dups |   Fixed |   Msg/s | 
-------------------------------------------------------------
|    ADS-B | 267985 |   56.7% |   51.2% |     29% |   148.9 | 
|   Comm-B |  52227 |   11.1% |   35.4% |         |   29.01 | 
|     ACAS |  71451 |   15.1% |   27.2% |         |   39.69 | 
|     Surv |  15394 |    3.3% |   33.1% |         |   8.552 | 
|    DF-11 |  65368 |   13.8% |   54.6% |   36.8% |   36.32 | 
-------------------------------------------------------------
|  112-bit | 323123 |   68.4% |     49% |   25.1% |   179.5 | 
|   56-bit | 149302 |   31.6% |   42.7% |   20.3% |   82.95 | 
-------------------------------------------------------------
|    Total | 472425 |    100% |   47.2% |   23.7% |   262.5 | 
-------------------------------------------------------------
(Max. msgs/s 262.5)
Messages Total 472425
finish time 17:58:39 22-01-26

The optimised filter provides about a 0.5% improvement over the previous best result I’ve seen for the sample. Here is a summary including performance against the airspy_adsb benchmark.

[mgrone]

The results seem to make sense to me. The objective function favours long messages, especially ADS-B. This will also pull up DF-11 messages, because stream1090 requires these besides DF-17 to keep entries alive. If you are able to use the big sample sets, well good for you. This will reflect better the behaviour of stream1090. Running something like 500MB with 10Msps will mostly ignore any timeouts in stream1090’s plane cache and stuff like that.

[JRG1956]

I forgot to add that I also tried using the seed from the optimised filter to do a further optimisation. This came up with a slightly better result on the 4th iteration, with no better result over 24 total iterations.

Eval params=[-0.3602  0.4798 -0.9801  0.5763  0.1064] → messages=426300
Eval bounds=[[-0.3605  0.6395]
 [ 0.2176  1.2176]
 [-1.8411 -0.8411]
 [-0.0177  0.9823]
 [-0.7338  0.2662]]
| Best so far: 743147 @ [ 0.1395  0.7176 -1.3411  0.4823 -0.2338]
[Stream1090] build 260120
[Stream1090] Input sampling speed: 10 MHz
[Stream1090] Output sampling speed: 24 MHz
[Stream1090] Input to output ratio: 5:12
[Stream1090] Number of streams: 24
[Stream1090] Size of input buffer: 15360 samples 
[Stream1090] Size of sample buffer: 36864 samples 
[Stream1090] Loaded 15 taps from ./diff_evolve_fir_temp.txt
-------------------------------------------------------------
|     Type |  #Msgs |  %Total |    Dups |   Fixed |   Msg/s | 
-------------------------------------------------------------
|    ADS-B | 268176 |   56.7% |   49.3% |   27.7% |     149 | 
|   Comm-B |  52185 |     11% |   34.8% |         |   28.99 | 
|     ACAS |  71440 |   15.1% |   25.8% |         |   39.69 | 
|     Surv |  15411 |    3.3% |     31% |         |   8.562 | 
|    DF-11 |  65416 |   13.8% |   52.8% |   35.7% |   36.34 | 
-------------------------------------------------------------
|  112-bit | 323262 |   68.4% |   47.3% |   23.9% |   179.6 | 
|   56-bit | 149366 |   31.6% |     41% |   19.5% |   82.98 | 
-------------------------------------------------------------
|    Total | 472628 |    100% |   45.4% |   22.6% |   262.6 | 
-------------------------------------------------------------
(Max. msgs/s 262.6)
Messages Total 472628
743532
Eval params=[ 0.3177  0.4227 -0.906   0.4446  0.2011] → messages=472628
Eval bounds=[[-0.3605  0.6395]
 [ 0.2176  1.2176]
 [-1.8411 -0.8411]
 [-0.0177  0.9823]
 [-0.7338  0.2662]]
| Best so far: 743532 @ [ 0.3177  0.4227 -0.906   0.4446  0.2011]

I’m happy to run large samples - as you say, they are more representative of real world performance. Now that I can test on the Mac, the time to test is much reduced and I can probably reduce it further by moving the tests to a Mac mini M4 that I only use view streamed material on my TV. It is the base model, but the single core performance of the M4 exceeds that of the M1 Pro chip in the MacBook, and it spends most of its time idle.

Once I get that set up, I will record some new large samples - that will let me test if relative performance remains the same across different samples with different traffic densities and distance/altitude distributions.

I haven’t had a chance to run the new make code yet. Will report when I do.

[JRG1956]

@mgrone

I pushed some fixes to the repo that hopefully fixes the issues with clang.

Apologies for bombarding you with messages this morning.

I’ve just tried compiling with the latest version - still one error:

jrg@MBPro2021 build % cmake ../ -DEND_STATS=ON
-- The C compiler identification is AppleClang 17.0.0.17000603
-- The CXX compiler identification is AppleClang 17.0.0.17000603
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Check for working C compiler: /usr/bin/cc - skipped
-- Detecting C compile features
-- Detecting C compile features - done
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Check for working CXX compiler: /usr/bin/c++ - skipped
-- Detecting CXX compile features
-- Detecting CXX compile features - done
-- Build type not specified: defaulting to release.
-- Configuring done (1.0s)
-- Generating done (0.0s)
-- Build files have been written to: /Users/jrg/SynologyDrive/Scratch/Aircraft Tracking Notes/Stream1090_Dev/stream1090/build
jrg@MBPro2021 build % make
[ 16%] Building CXX object CMakeFiles/stream1090.dir/main.cpp.o
In file included from /Users/jrg/SynologyDrive/Scratch/Aircraft Tracking Notes/Stream1090_Dev/stream1090/main.cpp:12:
In file included from /Users/jrg/SynologyDrive/Scratch/Aircraft Tracking Notes/Stream1090_Dev/stream1090/include/SampleStream.hpp:17:
/Users/jrg/SynologyDrive/Scratch/Aircraft Tracking Notes/Stream1090_Dev/stream1090/include/MathUtils.hpp:38:25: error: constexpr variable 'iq_sqrt_table' must be initialized by a constant expression
   38 |                 inline constexpr auto iq_sqrt_table{ fillSqrtTable() };
      |                                       ^            ~~~~~~~~~~~~~~~~~~~
/Users/jrg/SynologyDrive/Scratch/Aircraft Tracking Notes/Stream1090_Dev/stream1090/include/MathUtils.hpp:18:4: note: constexpr evaluation hit maximum step limit; possible infinite loop?
   18 |                         return (curr == prev) ? curr : constSqrtNR(x, 0.5 * (curr + x / curr), curr);
      |                         ^
/Users/jrg/SynologyDrive/Scratch/Aircraft Tracking Notes/Stream1090_Dev/stream1090/include/MathUtils.hpp:18:35: note: in call to 'constSqrtNR(7.762245e-01, 8.881123e-01, 7.762245e-01)'
   18 |                         return (curr == prev) ? curr : constSqrtNR(x, 0.5 * (curr + x / curr), curr);
      |                                                        ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
/Users/jrg/SynologyDrive/Scratch/Aircraft Tracking Notes/Stream1090_Dev/stream1090/include/MathUtils.hpp:31:85: note: in call to 'constSqrtNR(7.762245e-01, 7.762245e-01, 0.000000e+00)'
   31 |                                         table[(static_cast<std::array<float, 65536>::size_type>(i) << 8) | q] = (float)constSqrtNR(sq, sq, 0.0);
      |                                                                                                                        ^~~~~~~~~~~~~~~~~~~~~~~~
/Users/jrg/SynologyDrive/Scratch/Aircraft Tracking Notes/Stream1090_Dev/stream1090/include/MathUtils.hpp:38:40: note: in call to 'fillSqrtTable()'
   38 |                 inline constexpr auto iq_sqrt_table{ fillSqrtTable() };
      |                                                      ^~~~~~~~~~~~~~~
1 error generated.
make[2]: *** [CMakeFiles/stream1090.dir/main.cpp.o] Error 1
make[1]: *** [CMakeFiles/stream1090.dir/all] Error 2
make: *** [all] Error 2

[mgrone]

@JRG1956

Apologies for bombarding you with messages this morning.

I am always thankful for this feedback. I maintained some c++ library for some years for the apple eco system. And these are the annoying things. Since my rig is nvidia based, i had to retire OS X.

Edit: i hope the current repo version compiles now.

[cnuwer]

Thanks for continuing to share all of your work and especially the filter tools @mgrone ! I finally had a chance to toy with this a bit today, and I’m not sure I’m following the results or if I’m going about this the wrong way.

Ran my 15 minute example (yes, smaller sample file as a first choice would have been smarter) against the Python script and let it run for ~11 hours while I was at work. Got the taps from the output and created a filter file.

root@filter:~# python3 /root/stream1090/filter_utils/diff_evolve_fir.py --data /root/15MinSamples.raw --fs 10000000 --fs-up 24000000
[...]
[...]
root@filter:~# tail -31 /root/stream1090/filter_utils/de_log.txt > /root/stream1090/custom_filters/cnuwer001.txt
root@filter:~# cat /root/stream1090/custom_filters/cnuwer001.txt
# ================================================================
# Instance: /root/15MinSamples.raw
# Time: 2026-01-22 07:07:09
# FS: 10.0 MHz → FS_UP: 24.0 MHz
# Number of taps: 15
# Best score: 2519819
# Best total: 1977977
# Best params: [-0.169702051479235, 1.676668775363666, -1.3759099216484203, 0.5766241245214132, -0.3951782547055311]
# Current bounds:
# [-0.804801, 0.195199]
# [0.691384, 1.691384]
# [-1.394640, -0.394640]
# [0.203129, 1.203129]
# [-0.791724, 0.208276]
# Best taps:
-0.0030879799742251635
0.05674010515213013
0.04358011484146118
-0.022907666862010956
-0.05117682367563248
0.06843779981136322
0.3068680167198181
0.20309285819530487
0.3068680167198181
0.06843779981136322
-0.05117682367563248
-0.022907666862010956
0.04358011484146118
0.05674010515213013
-0.0030879799742251635

Ran my sample file against the default filters and got the following results:

root@filter:~# cat /root/15MinSamples.raw | /root/stream1090/build/stream1090_10M -q -u 24 > /dev/null
[Stream1090] build 260120
[Stream1090] Input sampling speed: 10 MHz
[Stream1090] Output sampling speed: 24 MHz
[Stream1090] Input to output ratio: 5:12
[Stream1090] Number of streams: 24
[Stream1090] Size of input buffer: 15360 samples 
[Stream1090] Size of sample buffer: 36864 samples 
-------------------------------------------------------------
|     Type |  #Msgs |  %Total |    Dups |   Fixed |   Msg/s | 
-------------------------------------------------------------
|    ADS-B | 528098 |   26.7% |   59.6% |   40.3% |   586.8 | 
|   Comm-B |   2099 |    0.1% |   26.6% |         |   2.332 | 
|     ACAS | 536448 |   27.1% |   33.4% |         |   596.1 | 
|     Surv |  96374 |    4.9% |   41.5% |         |   107.1 | 
|    DF-11 | 815959 |   41.2% |   63.5% |   35.9% |   906.6 | 
-------------------------------------------------------------
|  112-bit | 547247 |   27.7% |   59.1% |   39.4% |   608.1 | 
|   56-bit | 1431731 |   72.3% |   54.9% |   25.2% |    1591 | 
-------------------------------------------------------------
|    Total | 1978978 |    100% |   56.2% |   29.4% |    2199 | 
-------------------------------------------------------------
(Max. msgs/s 2199)
Messages Total 1978978

Then included my custom filter, but the results were actually slightly lower. Not sure if I’m missing something but expect a change in the stats to be higher and not lower?

root@filter:~# cat /root/15MinSamples.raw | /root/stream1090/build/stream1090_10M -f /root/stream1090/custom_filters/cnuwer001.txt -u 24 > /dev/null
[Stream1090] build 260120
[Stream1090] Input sampling speed: 10 MHz
[Stream1090] Output sampling speed: 24 MHz
[Stream1090] Input to output ratio: 5:12
[Stream1090] Number of streams: 24
[Stream1090] Size of input buffer: 15360 samples 
[Stream1090] Size of sample buffer: 36864 samples 
[Stream1090] Loaded 15 taps from /root/stream1090/custom_filters/cnuwer001.txt
-------------------------------------------------------------
|     Type |  #Msgs |  %Total |    Dups |   Fixed |   Msg/s | 
-------------------------------------------------------------
|    ADS-B | 525198 |   26.6% |   55.6% |   41.4% |   583.6 | 
|   Comm-B |   2099 |    0.1% |   22.3% |         |   2.332 | 
|     ACAS | 537218 |   27.2% |     27% |         |   596.9 | 
|     Surv |  96190 |    4.9% |   33.8% |         |   106.9 | 
|    DF-11 | 817272 |   41.3% |   60.6% |   34.6% |   908.1 | 
-------------------------------------------------------------
|  112-bit | 544075 |   27.5% |   55.1% |   40.5% |   604.5 | 
|   56-bit | 1433902 |   72.5% |   51.1% |   24.5% |    1593 | 
-------------------------------------------------------------
|    Total | 1977977 |    100% |   52.3% |   29.2% |    2198 | 
-------------------------------------------------------------
(Max. msgs/s 2198)
Messages Total 1977977

[mgrone]

Haha. You are unlucky. You are the only one in this forum thread who has to compete against a default filter in the repo that was exactly fitted for you. I optimized the default for you. Your instance gave me nightmares before, so it was a challenge to get results for your instance (that you provided to me) back on track. You should really not doing this filter optimization. I did that for you for multiple days and also fine tuned it.

[JRG1956]

@mgrone

Edit: i hope the current repo version compiles now.

Glad you know something about OS X

make is still complaining:

jrg@MBPro2021 build % make
[ 16%] Building CXX object CMakeFiles/stream1090.dir/main.cpp.o
In file included from /Users/jrg/SynologyDrive/Scratch/Aircraft Tracking Notes/Stream1090_Dev/stream1090/main.cpp:12:
In file included from /Users/jrg/SynologyDrive/Scratch/Aircraft Tracking Notes/Stream1090_Dev/stream1090/include/SampleStream.hpp:17:
/Users/jrg/SynologyDrive/Scratch/Aircraft Tracking Notes/Stream1090_Dev/stream1090/include/MathUtils.hpp:41:27: error: constexpr variable 'iq_sqrt_table' must be initialized by a constant expression
   41 |     inline constexpr auto iq_sqrt_table = fillSqrtTable();
      |                           ^               ~~~~~~~~~~~~~~~
/Users/jrg/SynologyDrive/Scratch/Aircraft Tracking Notes/Stream1090_Dev/stream1090/include/MathUtils.hpp:20:13: note: constexpr evaluation hit maximum step limit; possible infinite loop?
   20 |             curr = 0.5 * (curr + x / curr);
      |             ^
/Users/jrg/SynologyDrive/Scratch/Aircraft Tracking Notes/Stream1090_Dev/stream1090/include/MathUtils.hpp:35:58: note: in call to 'constSqrtNR(7.249212e-01)'
   35 |                 table[(i << 8) | q] = static_cast<float>(constSqrtNR(sq));
      |                                                          ^~~~~~~~~~~~~~~
/Users/jrg/SynologyDrive/Scratch/Aircraft Tracking Notes/Stream1090_Dev/stream1090/include/MathUtils.hpp:41:43: note: in call to 'fillSqrtTable()'
   41 |     inline constexpr auto iq_sqrt_table = fillSqrtTable();
      |                                           ^~~~~~~~~~~~~~~
1 error generated.
make[2]: *** [CMakeFiles/stream1090.dir/main.cpp.o] Error 1
make[1]: *** [CMakeFiles/stream1090.dir/all] Error 2
make: *** [all] Error 2

I have commitments for the rest of the day, so you don’t need to bother about this on my account. Whenever, suits you would be good.

[mgrone]

All good, no hurries. I replaced the dynamic variant with a static array. It should be fine now.

[mgrone]

If you want to plot your filter against the default, remove the colon “,” from the stuff in LowPass.hpp and all the c++ crap and paste it into a new textfile.

template<>
    constexpr auto getTaps<Rate_10_0_Mhz, Rate_24_0_Mhz>(){
        return std::array<float, 15>{   
            -0.008151337504386902,
            0.07549969106912613,
            0.10143674910068512,
            -0.047200191766023636,
            -0.1384957879781723,
            0.17454688251018524,
            0.3371904194355011,
            0.01034723874181509,
            0.3371904194355011,
            0.17454688251018524,
            -0.1384957879781723,
            -0.047200191766023636,
            0.10143674910068512,
            0.07549969106912613,
            -0.008151337504386902,
        };
    };

Afterwards something like:
Add as many filter files as you want here while being in the stream1090 directory:

../python/bin/python filter_utils/plot_filter.py --fs 10000000 custom_filters/JRG1956_0.txt

[cnuwer]

@mgrone

default filter in the repo that was exactly fitted for you

Ahh, I didn’t know that - thanks so much for doing this! The default filters are fantastic as they are now, even outperforming my airspy_adsb binary by quite a bit, but my nerd brain is always looking to push the envelope. I even toyed with the python script to make it run on all my cpu cores instead of just the one.

One curious, maybe remedial, question for you on this. My guess is that a hardware change in my ADS-B rig could affect the results here. Is that reasonable? My RTLSDR Triple Filter died a couple of weeks ago (there was a moment of silence, a burial in my backyard, and maybe even a tear lol) after years of faithful service. Now that I’m back up and running, could capturing a different sampleset produce different results? My guess is yes, but I’m fine if you answer with “Why not try it for yourself.”

Thank you again for all your work on this, mgrone!