Lets quickly make that clear. The name is “Dups” and is chosen due to its length. So what you is not being logged in the categoery dups is the following:
Two slightly phase-shifted streams contain the same: This is not logged under dups because i need numbers and that is 99.99 of the cases. And i dont like comparing 0.01 to something. So duplicates with the previous bit streams are surpressed in the stats. If the previous stream has dealt with that: we are done and that is not being counted.
bool handleExtSquitterLongMessage(int streamIndex, const uint8_t& downlinkFormat) {
auto frame = m_shiftRegisters.extractAlignedFrameLong(streamIndex);
if (phaseDupCheckLong(frame))
return false;
auto crc = m_shiftRegisters.getCRC_112(streamIndex);
// if the crc is zero, we have a correct message
if (crc == 0) {
// we consider a crc of 0 as a good message
This will never count into the dups section. The dups section is about: We missed something at x(t) and now there is new message at x(t + not directly next to t in terms of phase).
Duplicants are only created this way, because i can only repair DF-11 and DF-17 messages. Those repaired will be checked against “We did that already”.
Thanks for the explanation. In terms of noise/weak signals, I will record samples at maximum gain and see if there is a measurable further improvements vs airspy_adsb and dump1090-fa/readsb.
@jimMerk2 - it would be interesting if you recorded a sample when you have your least traffic to see what sort of a difference you get in those conditions.
Well, lower traffic occurs, of course, at night. But then another phenomenon happens. Planes will be detected at a distance, so then AWGN is a factor rather than interference from other planes. But, I will take another sample at night.
Another question, what are the transponder capabilities that you guys refer to?
Edit: not an answer to the question. @JRG1956 covered that with the link.
Two fold:
@JRG1956 has plenty of GA. Position => Send it. Thats it.
The US are way moderate to nothing about about using the secondary radar.
I am located in central Europe. Every town with an airfield basically will interrogate the plane nearby via secondary radar and ask things: what color are the pilots socks. This will have the 1090MHz at full speed during the day. Messages will overlap like crazy and you need some tool to deal with it.
Some patience, please. The stats will tell you at some point about the signal strength. Auto-gain is around the corner then. Not for airspy though this requires some more calibration.
Sorry - I wasn’t asking for signal strength in stream1090 - I actually find I don’t miss it that much. It isn’t hard to swap back to airspy_adsb / readsb to look at signal strength if I need to.
What I was referring to was the extra gain step above 49.6 in rtl-sdr dongles that can only be accessed when the internal agc is switched on. I don’t know how to fix it at that step for recording a sample. I will do some reading.
# RTL-SDR configuration. The header entry defines
# that this device uses librtlsdr. The values all
# correspond to what rtl_fm / rtl_test use. Key/value
# pairs are processed in order as they appear in the file.
[rtlsdr]
# Optional: select a specific device by serial number
# serial = 00000001
# Center frequency in Hz (default: 1090 MHz for ADS-B)
frequency = 1090000000
# Gain in dB. If AGC is enabled, this value is ignored.
# gain = 40
agc = true
# Optional: frequency correction in PPM
# ppm = 0
# Optional: enable offset tuning (can improve dynamic range)
# offset_tuning = false
# Optional: direct sampling mode (0=off, 1=I, 2=Q)
# direct_sampling = 0
# Optional: tuner bandwidth in Hz (e.g. 3000000)
# tuner_bandwidth = 3000000
# Enable or disable the 5V bias tee (if supported)
bias_tee = false
pi@raspberrypi:~ $ cat samples_dump1090-fa_g30.txt
Statistics: Fri Feb 27 00:38:29 2026 PST - Fri Feb 27 00:39:32 2026 PST
Local receiver:
1439956992 samples processed
0 samples dropped
0 Mode A/C messages received
14940558 Mode-S message preambles received
34207535 with bad message format or invalid CRC
6043958 with unrecognized ICAO address
135393 accepted with correct CRC
7721 accepted with 1-bit error repaired
----- dBFS noise power
-6.4 dBFS mean signal power
-0.8 dBFS peak signal power
23382 messages with signal power above -3dBFS
Decoder:
143114 total usable messages
15668 DF0 messages
12573 DF4 messages
249 DF5 messages
50183 DF11 messages
1385 DF16 messages
62141 DF17 messages
620 DF18 messages
233 DF20 messages
62 DF21 messages
0 surface position messages received
22175 airborne position messages received
21290 global CPR attempts with valid positions
243 global CPR attempts with bad data
0 global CPR attempts that failed the range check
243 global CPR attempts that failed the speed check
52 global CPR attempts with insufficient data
4 local CPR attempts with valid positions
0 aircraft-relative positions
0 receiver-relative positions
593 local CPR attempts that did not produce useful positions
0 local CPR attempts that failed the range check
3 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
85 unique aircraft tracks
0 aircraft tracks where only one message was seen
0 aircraft tracks which were not marked reliable
CPU load: 80.8%
42329 ms for demodulation
8413 ms for reading from USB
25 ms for network input and background tasks
But for comparison, you need to run the results of stream1090 through dump-fa to make sure that both use the same decoder. You should also probably do a range check.
