I mean, so is the dump1090 demodulator. A RSSI measurement is still useful?
Have you considered feeding stream1090’s output through dump1090 for comparison purposes? (In particular, feed in the uncorrected messages)
You either did some magic there that is way different from readsb. However, the simple answer is: no. I have tracked for a few hours the output of readsb in comparison with stream1090 and it is basically the same. While at the same time stream1090 is a demodulator and the other is a full decoder with a demodulator.
Regarding your other comment:
It is not comparison-based. You need some threshold for things to get going aka the preamble. That is not in that sense what i described as comparison-based. The task of dump and readsb is to sync up at a predefined time and then get through the crap to figure out if there is a message or not.
That is not how it is done here. Sieve through all the crap, and see what we can get. “The message starts now”.
These are two very different concepts. One of them can take much more “noise” than the other one.
Edit: I dont run my stuff against the others. Others did.
@obj You can put now many arguments forward. The bottom line is: Stream1090 does its job. You can scroll up. There are people from across the world who actually get better results.
With respect, I think I know how the dump1090 demodulator works, given that I wrote it. This is the same demodulator that readsb inherited.
Here is where the comparisons happen: dump1090/demod_2400.c at 4f47d12a18db24238ab2d91c8637dae25937fd98 · flightaware/dump1090 · GitHub
Note how this is, generally, subtracting later-in-time samples from earlier-in-time samples. The caller then looks at the sign of the returned value. So this is a comparison between the two half-bits.
dump1090 and stream1090 are doing fundamentally the same operation to decide on message contents. The difference is, essentially, that stream1090 is considering every possible window of samples received, while dump1090 only considers a subset of windows (those where there’s something that looks like a preamble before the message body)
There are two reasons why dump1090 does this:
-
CPU cost, it’s not doing a rolling CRC as stream1090 does, so checking a particular window is relatively expensive. stream1090 does better here.
-
garbage output. If you consider more windows (a lot more windows in the stream1090 case) then you get more bad demodulations of something that’s not actually a usable message. I know you’re aware of this problem. dump1090 makes different tradeoffs, generally leaning towards “don’t produce garbage data”
Point (2) is why I suggested feeding stream1090’s output through dump1090’s decoder. dump1090’s decoder has quite a bit of logic dedicated to throwing out bad data, because even though the demodulator is less aggressive than stream1090’s, a lot of junk still gets through. So using the same decoding stage might let you make better comparisons of whether stream1090’s demodulator is actually producing more good data, without a lot of extra work.
With all respect, this has been tried by you?
This is not a few messages “Oh the guy is producing garbage”.
With respect,
Martin
Maybe I am misunderstanding what jim tested, but I read that as comparisons between the dump1090 message count and the stream1090 message count directly.
What I am suggesting is to compare
dump1090 --stats --ifile <samples>withstream1090applied to<samples>, with the demodulated output fed intodump1090 --stats --net-only
(and/or variations with different stream1090 options)
Then the same cleanup rules are being applied to both demodulators. i.e “what if I replaced dump1090’s demodulator with stream1090’s demodulator, but kept the same decode rules?”
unfortunately I have a fairly terrible antenna setup at the moment, and not a lot of spare time, so running this experiment myself probably won’t happen soon
1 Like
Yes, that’s correct.
I’m happy to try this on my samples - step1 done, but I’m struggling with step 2 - advice appreciated.
(Stopped with CTRL C after 30 minutes)
jrg@pi44:~/projects $ cat rtl_sample20260217-2.4M_30m.raw | stream1090 -s 2.4 -u 12 -q | socat -u - TCP4:localhost:30001 | dump1090-fa --stats --net-only --net-ri-port 30001 --interactive
[Stream1090] build 260223
[Stream1090] Input sampling speed: 2.4 MHz
[Stream1090] Output sampling speed: 12 MHz
[Stream1090] Input to output ratio: 1:5
[Stream1090] Number of streams: 12
[Stream1090] Size of input buffer: 8196 samples
[Stream1090] Size of sample buffer: 40980 samples
2026/02/25 18:14:24 socat[3867984] W connect(5, AF=2 127.0.0.1:30001, 16): Connection refused
Wed Feb 25 18:14:24 2026 AEDT dump1090-fa 10.2 starting up.
2026/02/25 18:14:24 socat[3867984] E TCP4:localhost:30001: Connection refused
Net-only mode, no SDR device or file open.
Statistics: Wed Feb 25 18:14:24 2026 AEDT - Wed Feb 25 18:30:34 2026 AEDT
Local receiver:
0 samples processed
0 samples dropped
0 Mode A/C messages received
0 Mode-S message preambles received
0 with bad message format or invalid CRC
0 with unrecognized ICAO address
0 accepted with correct CRC
----- dBFS noise power
----- dBFS mean signal power
----- dBFS peak signal power
0 messages with signal power above -3dBFS
Messages from network clients:
0 Mode A/C messages received
57 Mode S messages received
0 with bad message format or invalid CRC
0 with unrecognized ICAO address
57 accepted with correct CRC
Decoder:
57 total usable messages
57 DF18 messages
0 surface position messages received
38 airborne position messages received
37 global CPR attempts with valid positions
0 global CPR attempts with bad data
0 global CPR attempts that failed the range check
0 global CPR attempts that failed the speed check
0 global CPR attempts with insufficient data
0 local CPR attempts with valid positions
0 aircraft-relative positions
0 receiver-relative positions
1 local CPR attempts that did not produce useful positions
0 local CPR attempts that failed the range check
0 local CPR attempts that failed the speed check
0 CPR messages that look like transponder failures filtered
0 non-ES altitude messages from ES-equipped aircraft ignored
1 unique aircraft tracks
0 aircraft tracks where only one message was seen
0 aircraft tracks which were not marked reliable
CPU load: 0.2%
0 ms for demodulation
0 ms for reading from USB
1512 ms for network input and background tasks
Wed Feb 25 18:30:34 2026 AEDT Normal exit.
Yeah, I was going to say that I don’t know exactly how to do step 2 either.
1 Like
This looks about right, but try running dump1090-fa in a separate shell
i.e. in one shell run dump1090-fa first (and let it initialize and open the listening port)
and then in a second shell run cat .. | stream1090 ... | socat ...
and then control-C dump1090-fa when stream1090 is done
1 Like
Thanks have got that working. Here are the results. First with dumap1090-fa:
jrg@pi44:~/projects $ dump1090-fa --stats --fix --ifile rtl_sample20260217-2.4M_30m.raw >> sample3_dump1090-fa.txt
Wed Feb 25 17:22:43 2026 AEDT dump1090-fa 10.2 starting up.
Wed Feb 25 17:25:57 2026 AEDT Waiting for receive thread termination
Wed Feb 25 17:25:57 2026 AEDT Abnormal exit.
jrg@pi44:~/projects $ tail -n 50 sample3_dump1090-fa.txt
Statistics: Wed Feb 25 17:22:43 2026 AEDT - Wed Feb 25 17:25:57 2026 AEDT
Local receiver:
4318035968 samples processed
0 samples dropped
0 Mode A/C messages received
32709291 Mode-S message preambles received
74269723 with bad message format or invalid CRC
13648752 with unrecognized ICAO address
305094 accepted with correct CRC
12212 accepted with 1-bit error repaired
----- dBFS noise power
-13.0 dBFS mean signal power
-0.8 dBFS peak signal power
3610 messages with signal power above -3dBFS
Decoder:
317306 total usable messages
58893 DF0 messages
2630 DF4 messages
3336 DF5 messages
39319 DF11 messages
3864 DF16 messages
162852 DF17 messages
44 DF18 messages
25939 DF20 messages
20429 DF21 messages
215 surface position messages received
64137 airborne position messages received
63401 global CPR attempts with valid positions
205 global CPR attempts with bad data
0 global CPR attempts that failed the range check
205 global CPR attempts that failed the speed check
275 global CPR attempts with insufficient data
34 local CPR attempts with valid positions
0 aircraft-relative positions
0 receiver-relative positions
687 local CPR attempts that did not produce useful positions
0 local CPR attempts that failed the range check
9 local CPR attempts that failed the speed check
0 CPR messages that look like transponder failures filtered
0 non-ES altitude messages from ES-equipped aircraft ignored
133 unique aircraft tracks
0 aircraft tracks where only one message was seen
0 aircraft tracks which were not marked reliable
CPU load: 73.8%
117579 ms for demodulation
25790 ms for reading from USB
85 ms for network input and background tasks
Then with stream1090 into dump1090-fa. The stream1090 part:
jrg@pi44:~/projects $ cat rtl_sample20260217-2.4M_30m.raw | stream1090 -s 2.4 -u 12 -q | socat -u - TCP4:localhost:30001
[Stream1090] build 260223
[Stream1090] Input sampling speed: 2.4 MHz
[Stream1090] Output sampling speed: 12 MHz
[Stream1090] Input to output ratio: 1:5
[Stream1090] Number of streams: 12
[Stream1090] Size of input buffer: 8196 samples
[Stream1090] Size of sample buffer: 40980 samples
-------------------------------------------------------------
| Type | #Msgs | %Total | Dups | Fixed | Msg/s |
-------------------------------------------------------------
| ADS-B | 172828 | 52.2% | 24.6% | 28.8% | 96.06 |
| Comm-B | 48589 | 14.7% | 0% | | 27.01 |
| ACAS | 61167 | 18.5% | 0% | | 34 |
| Surv | 6245 | 1.9% | 0% | | 3.471 |
| DF-11 | 42574 | 12.8% | 31.9% | 39.8% | 23.66 |
-------------------------------------------------------------
| 112-bit | 224968 | 67.9% | 20% | 23.5% | 125 |
| 56-bit | 106435 | 32.1% | 15.8% | 19.7% | 59.16 |
-------------------------------------------------------------
| Total | 331403 | 100% | 18.7% | 22.3% | 184.2 |
-------------------------------------------------------------
(Max. msgs/s 184.2)
Messages Total 331403
DF 0 : 57616
DF 4 : 2761
DF 5 : 3484
DF 11 : 42574
DF 16 : 3551
DF 17 : 172743
DF 18 : 38
DF 19 : 47
DF 20 : 26905
DF 21 : 21684
1799182505 iterations @1MHz
The dump1090-fa part:
jrg@pi44:~ $ dump1090-fa --stats --net-only --net-ri-port 30001 --interactive
Wed Feb 25 20:35:45 2026 AEDT dump1090-fa 10.2 starting up.
Net-only mode, no SDR device or file open.
Statistics: Wed Feb 25 20:35:45 2026 AEDT - Wed Feb 25 20:48:29 2026 AEDT
Local receiver:
0 samples processed
0 samples dropped
0 Mode A/C messages received
0 Mode-S message preambles received
0 with bad message format or invalid CRC
0 with unrecognized ICAO address
0 accepted with correct CRC
----- dBFS noise power
----- dBFS mean signal power
----- dBFS peak signal power
0 messages with signal power above -3dBFS
Messages from network clients:
0 Mode A/C messages received
331403 Mode S messages received
10 with bad message format or invalid CRC
47 with unrecognized ICAO address
331346 accepted with correct CRC
Decoder:
331346 total usable messages
57607 DF0 messages
2761 DF4 messages
3484 DF5 messages
42574 DF11 messages
3551 DF16 messages
172743 DF17 messages
38 DF18 messages
26904 DF20 messages
21684 DF21 messages
432 surface position messages received
67523 airborne position messages received
66960 global CPR attempts with valid positions
119 global CPR attempts with bad data
0 global CPR attempts that failed the range check
119 global CPR attempts that failed the speed check
462 global CPR attempts with insufficient data
35 local CPR attempts with valid positions
0 aircraft-relative positions
0 receiver-relative positions
841 local CPR attempts that did not produce useful positions
0 local CPR attempts that failed the range check
61 local CPR attempts that failed the speed check
0 CPR messages that look like transponder failures filtered
0 non-ES altitude messages from ES-equipped aircraft ignored
142 unique aircraft tracks
80 aircraft tracks where only one message was seen
83 aircraft tracks which were not marked reliable
CPU load: 0.8%
0 ms for demodulation
0 ms for reading from USB
5984 ms for network input and background tasks
Wed Feb 25 20:48:29 2026 AEDT Normal exit.
I’ve suffered the “old bloke on a ladder” problem a couple of days ago and am nursing a couple of fractured vertebrae, so I leave the analysis to the rest of you.
Thanks! The headline comparison is this:
317306 total usable messages (dump1090-fa)
331346 total usable messages (stream1090 → dump1090-fa)
so stream1090 is about +4.4%
some notes:
dump1090’s decoder is not discarding many (<0.1%) of stream1090’s messages; compare:
Messages Total 331403 (pre-decoder)
331346 total usable messages (post-decoder)
That’s good!
some comments on corrected messages:
dump1090 will usually repair 1-bit errors, but trusts those messages less. stream1090 is currently producing corrected messages in its output (AFAIK), so in the stream1090 case dump1090 never sees any messages with errors and will tend to over-trust versus when using its own internal demodulator. Also, I believe stream1090 does >1 bit correction for some cases, which dump1090 doesn’t do by default (you can turn it on with --fix-2bit, but I don’t recommend that for normal operation because it produces quite a lot more bad messages). These will tend to inflate the stream1090 numbers. If stream1090 could produce uncorrected message output (like dump1090’s “verbatim” output mode) then that would produce a more accurate comparison.
The “single message” stats from stream1090 are quite different to the dump1090-fa case, but this is probably a stats measurement problem rather than anything real (IIRC these stats are only updated when aircraft are expired from the recently-seen-aircraft state, which is timing-dependent and probably didn’t happen consistently in the two runs .. another thing to add to my todo list)
fractured vertebrae
oh, that is very much not fun, hope your recovery goes well and that you have some good painkillers!
1 Like
@JRG1956 Sorry to hear of your fall. You gotta be careful about falls after reaching a certain age – even on terra firma, much less a ladder. Hope you are on the mend.
I will collect some data this afternoon to compare results.
1 Like
Well, I’m getting significantly different results than @JRG1956 got. Following the same order that he presented:
pi@raspberrypi:~ $ dump1090-fa --fix --stats --show-only aaaaaa --ifile samples2.4_12.raw >> samples_dump1090-fa.txt
Wed Feb 25 14:34:13 2026 PST dump1090-fa 10.2 starting up.
Wed Feb 25 14:35:18 2026 PST Waiting for receive thread termination
Wed Feb 25 14:35:18 2026 PST Abnormal exit.
pi@raspberrypi:~ $ tail -n 50 samples_dump1090-fa.txt
Statistics: Wed Feb 25 14:34:13 2026 PST - Wed Feb 25 14:35:18 2026 PST
Local receiver:
1468530688 samples processed
0 samples dropped
0 Mode A/C messages received
10490616 Mode-S message preambles received
23196927 with bad message format or invalid CRC
4128066 with unrecognized ICAO address
307169 accepted with correct CRC
24892 accepted with 1-bit error repaired
----- dBFS noise power
-9.3 dBFS mean signal power
-0.7 dBFS peak signal power
28234 messages with signal power above -3dBFS
Decoder:
332061 total usable messages
76402 DF0 messages
31517 DF4 messages
858 DF5 messages
88183 DF11 messages
2398 DF16 messages
129636 DF17 messages
2244 DF18 messages
720 DF20 messages
103 DF21 messages
11 surface position messages received
49561 airborne position messages received
45913 global CPR attempts with valid positions
1042 global CPR attempts with bad data
0 global CPR attempts that failed the range check
1041 global CPR attempts that failed the speed check
44 global CPR attempts with insufficient data
33 local CPR attempts with valid positions
0 aircraft-relative positions
0 receiver-relative positions
2566 local CPR attempts that did not produce useful positions
1 local CPR attempts that failed the range check
50 local CPR attempts that failed the speed check
0 CPR messages that look like transponder failures filtered
0 non-ES altitude messages from ES-equipped aircraft ignored
305 unique aircraft tracks
0 aircraft tracks where only one message was seen
0 aircraft tracks which were not marked reliable
CPU load: 69.7%
36809 ms for demodulation
8625 ms for reading from USB
32 ms for network input and background tasks
pi@raspberrypi:~/stream1090 $ sudo cat /home/pi/samples2.4_12.raw | ./build/stream1090 -s 2.4 -u 12 -q | socat -u - TCP4:localhost:30001
[Stream1090] build 260222
[Stream1090] Input sampling speed: 2.4 MHz
[Stream1090] Output sampling speed: 12 MHz
[Stream1090] Input to output ratio: 1:5
[Stream1090] Number of streams: 12
[Stream1090] Size of input buffer: 8196 samples
[Stream1090] Size of sample buffer: 40980 samples
-------------------------------------------------------------
| Type | #Msgs | %Total | Dups | Fixed | Msg/s |
-------------------------------------------------------------
| ADS-B | 170677 | 39.2% | 30.6% | 41.2% | 278.9 |
| Comm-B | 894 | 0.2% | 0.1% | | 1.461 |
| ACAS | 100636 | 23.1% | 0.1% | | 164.5 |
| Surv | 37266 | 8.6% | 0% | | 60.9 |
| DF-11 | 126108 | 29% | 39.3% | 37% | 206.1 |
-------------------------------------------------------------
| 112-bit | 174688 | 40.1% | 30.1% | 40.6% | 285.5 |
| 56-bit | 260893 | 59.9% | 23.8% | 22.4% | 426.4 |
-------------------------------------------------------------
| Total | 435581 | 100% | 26.5% | 30.1% | 711.9 |
-------------------------------------------------------------
(Max. msgs/s 711.9)
Messages Total 435581
DF 0 : 97519
DF 4 : 36681
DF 5 : 585
DF 11 : 126108
DF 16 : 3117
DF 17 : 167833
DF 18 : 2826
DF 19 : 18
DF 20 : 855
DF 21 : 39
611889455 iterations @1MHz
pi@raspberrypi:~ $ dump1090-fa --stats --net-only --net-ri-port 30001 --interactive
Wed Feb 25 14:41:58 2026 PST dump1090-fa 10.2 starting up.
Net-only mode, no SDR device or file open.
Statistics: Wed Feb 25 14:41:58 2026 PST - Wed Feb 25 14:49:05 2026 PST
Local receiver:
0 samples processed
0 samples dropped
0 Mode A/C messages received
0 Mode-S message preambles received
0 with bad message format or invalid CRC
0 with unrecognized ICAO address
0 accepted with correct CRC
----- dBFS noise power
----- dBFS mean signal power
----- dBFS peak signal power
0 messages with signal power above -3dBFS
Messages from network clients:
0 Mode A/C messages received
435581 Mode S messages received
37 with bad message format or invalid CRC
18 with unrecognized ICAO address
435526 accepted with correct CRC
Decoder:
435526 total usable messages
97492 DF0 messages
36673 DF4 messages
585 DF5 messages
126108 DF11 messages
3116 DF16 messages
167833 DF17 messages
2826 DF18 messages
854 DF20 messages
39 DF21 messages
18 surface position messages received
63829 airborne position messages received
61458 global CPR attempts with valid positions
443 global CPR attempts with bad data
0 global CPR attempts that failed the range check
443 global CPR attempts that failed the speed check
25 global CPR attempts with insufficient data
226 local CPR attempts with valid positions
0 aircraft-relative positions
0 receiver-relative positions
1720 local CPR attempts that did not produce useful positions
0 local CPR attempts that failed the range check
236 local CPR attempts that failed the speed check
0 CPR messages that look like transponder failures filtered
0 non-ES altitude messages from ES-equipped aircraft ignored
331 unique aircraft tracks
33 aircraft tracks where only one message was seen
42 aircraft tracks which were not marked reliable
CPU load: 1.1%
0 ms for demodulation
0 ms for reading from USB
4592 ms for network input and background tasks
Wed Feb 25 14:49:05 2026 PST Normal exit.
332061 total usable messages (dump1090-fa)
435581 total usable messages (stream1090 → dump1090-fa)
stream1090 is +24% !!
1 Like
[Edit to clarify interpretation or “real”]
I think the single message stats are real, but not significant in terms of total messages. That is I think most, if not all, of these singles are message candidates that stream1090 finds and pass all other its testing criteria, but are actually false positives. The numbers are actually quite small in terms of the total messages in the sample. Excluding the DF19 count, 78 single messages in 331355 is only 0.024% of the total (156 spurious messages per hour in my case.)
Here is the tail end of an analysis of the number of messages per icao for the sample I used - this was produced with plane_msg_stats.py from the other_utils directory in the stream1090 repository - it uses rs1090 to validate the messages.
rs1090 also ignores the 47 DF19 messages that stream1090 reports and comes up with 78 single message tracks compared with the 80 reported by dump1090-fa.
The difference between the number of unique aircraft with more than one message (62) in this table is equal to dump1090-fa’s unique aircraft tracks (142) minus aircraft where only one message was seen (80)
I’m trying to understand the huge difference in the gain of stream1090 vs dump1090-fa in our data samples. In your case it’s 4.4%, in mine it’s 24%. The only thing I noticed is the signal levels:
Your setup:
-13.0 dBFS mean signal power
-0.8 dBFS peak signal power
3610 messages with signal power above -3dBFS
My setup:
-9.3 dBFS mean signal power
-0.7 dBFS peak signal power
28234 messages with signal power above -3dBFS
Hard to believe signal level would matter that much though.
I think we need to be careful drawing conclusions from just two samples - I think that there is no doubt that stream1090 is finding more valid messages than dump1090-fa for rtl-sdr receivers at 2.4 MSMP. But the benefit is probably normally distributed and we could be sitting on opposite sides of the bell curve.
Gain is probably one factor - @mgrone has mentioned that stream1090 likes to hunt in the noise.
Another is the mix of short and long messages - I have a much higher proportion of 112 bit messages in my samples, and lower message rates.
Another issue he mentioned a few days ago was that my samples contain a lot of DF17 messages from general aviation aircraft that have the lowest level of capability - Level 1 transponders and that the has not handled this properly yet. So my results may improve in future.
People in other geographies / traffic mixes / densities will probably see different results to either of us.
So here are my 5 cents on this:
First of all comparison-based means in the terms of Manchester encoding with x(t) being the signal at time t, you get a bit = x(t) > x(t + 0.5us)
- Let’s start with the unpopular topic: thresholds. Preamble detection (as far as i understood) looks for the 4 preamble pulses being sent ahead of the real message. h = high, l = low.
h l h l l l l h l hmsg starts. This of course is not sample rate aligned in any way, and the firsthpulse may be at the center between two samples.
This does not change the fact that you need to define what is “h” and what is “l”. This will be done with a threshold, dynamic or not. The next step should then be to maximize alignment with the sample stream (by maximizing energy or so). Based on some interpolation scheme, you will have to say something like “message starts at sample 2039.378”, that is, it starts between sample 2039 and 2040, which you decided is the most precise starting position.
Up to this point you can even take parts of Stream1090 to do this. It does interpolation by upsampling. Like in the rtl-sdr case, it will upsample from 2.4 MHz to 12MHz for example. Just by interpolating to something that is a multiple of 2 MHz. It is not too difficult to do preamble detection there.
So why am i not doing this? There is more than one reason. - The first intuitive rule is: “if i do that, i will have to check the message anyways. Let’s see what happens when we just check every possible message.”. So if there is a way to not check for a preamble, what is the problem? Answer: crap! Tons of crap. But with the preamble approach …
- You may miss the preamble: If the definition of “h = high” is too high, a preamble-based approach will not trigger for weak signals.
- The preamble is overlapping the tail of a strong message. What’s preamble, what’s the payload of the preceeding message?
- The phasing might actually be a bad idea. Yes, the preamble might be perfectly aligned, but some other message is overlaying the payload of the message while being phase shifted slightly trashing the payload. Same for HF noise. A slightly “beeing off” in terms would have resulted in a successful parsing of the message.
- So what is stream1090 actually then doing? It is doing things in parallel. It will upsample to a certain frequency (12 MHz for example) and evaluates all results in prallel. The interpolation is fixed. So for upsampling to 12 MHz you will have in the 2 MHz signal stream from the planes, 6 points inbetween. In total 12 mio message candidates have to be checked per second and that is a ton of crap.
I put many hours into this crap-sieve. This is tricky, but the above numbers and also my personal numbers support that i am on the right path.
Regarding your experiments @JRG1956 and @jimMerk2:
- The msg/s are way different and at some point this becomes a problem, because when two messages overlap, stuff gets very complicated. With a rather low message rate of 185 in @JRG1956 sample set, things are smooth. Messages are nicely separated. All cool. With 722 msg/s in the @jimMerk2 sample set on a 2.4 Msps rtl-sdr, stuff is already very different. You may have one message ruining itself and the preceeding one with overlapping.
- Regarding other stats: Stream1090 notoriously cheats when it comes to DF-11. For DF-11 and DF-17 the internal plane table does not only use the icao hex code. It puts also the transponder capabilities on top of this (3 bits). If now a DF-11 message arrives according to the first 5 bits (indicating that it is a DF-11), and the transponder capabilities + icao hex match a plane that is already confirmed, the message is being fixed up so the CRC is 0. Reason: the payload (DF correct, transponder caps correct, icao hex correct) has been verified.
Once you diggest the above text, you may actually get the idea. A preamble-based approach will require the 4 pulses to get past the threshold while at the same time the lows aka noise have to stay below. However, this depends on the details how preamble detection is being implemented. For stream1090 x(t) > x(t + 0.5us) only this counts within the payload part.
It does not matter if the ADC of your hardware sends you something that will result in x(t) = 99% and x(t + 0.5us) = 98% or x(t)=2% and x(t + 0.5us) = 1%. The problem is however that once you tune down your LNA that 2% and 1% will not be distinguishable anymore you are taking away the opportunity to dig through much possibly weaker messages.
In other words: If you raise the noise level, stream1090 does not care. It has to sieve through crap anyways. You are just giving it the option to find something in the noise.
1 Like
So, those 12 streams represent 12 different timing hypothesis, and you look at this 12 outputs to see which one (or more) have 0 CRC ? If the signal from a given aircraft is particularly good, more than one good identical message could be detected, hence the “dups” (or duplications) in your output table. But only some messages have a high percentage of dups (ADS-B and DF-11). Others have virtually no dups (Comm-B, ACAS, and Surv). Why is that? Also the Fixed column represents fixed 1-bit errors ?
Regarding “noise” I guess you’re talking about overlapping message interference from other aircraft rather than classical additive white gaussian noise. So the jrg1956 sample has less noise than my sample because there’s less traffic there. And that’s the reason the jrg1956 sample showed stream1090 had less improvement compared to dump1090-fa than mine did because stream1090 works better in a high noise environment than dump1090-fa. At least that’s my long winded explanation of things.
There’s still things I don’t understand – like how you can just interpolate 4 samples between each input sample (for the case of 2.4 Msps interpolated to 12 Maps) and recover more information. But I guess it does.
Also, you guys talk about “transponder capabilities”, not sure what that is, but I could look it up.
1 Like