Incorrect callsign reported

[apc005]

Hi

I'm using dump1090-fa to retreive raw data from tcp/30003 stream (SBS format / BaseStation)

I've noticed that sometimes there's a problem with the reported callsign: In rare cases I get the callsign for another flight

Here's an example of received messages :

MSG,6,1,1,3C496A,1,2024/11/27,15:32:07.912,2024/11/27,15:32:07.961,TUI8EG  ,,,,,,,1000,0,0,0,
.../...
MSG,6,1,1,3C496A,1,2024/11/27,15:32:13.882,2024/11/27,15:32:13.915,TUI6G   ,,,,,,,1000,0,0,0,
.../...
MSG,5,1,1,3C496A,1,2024/11/27,15:32:14.545,2024/11/27,15:32:14.570,TUI8EG  ,34350,,,,,,,0,,0,

Two callsigns are associates to ident 3C496A : TUI8EG and TUI6G

But callsign XXXXX is actually from flight with id 3C4969 :

MSG,1,1,1,3C4969,1,2024/11/27,15:36:06.949,2024/11/27,15:36:06.953,TUI6G   ,,,,,,,,,,,0
MSG,5,1,1,3C4969,1,2024/11/27,15:36:07.262,2024/11/27,15:36:07.280,TUI6G   ,32000,,,,,,,0,,0,
MSG,5,1,1,3C4969,1,2024/11/27,15:36:28.200,2024/11/27,15:36:28.250,TUI6G   ,32000,,,,,,,0,,0,
MSG,6,1,1,3C4969,1,2024/11/27,15:36:35.478,2024/11/27,15:36:35.514,TUI6G   ,,,,,,,1000,0,0,0,
MSG,1,1,1,3C4969,1,2024/11/27,15:36:46.100,2024/11/27,15:36:46.111,TUI6G   ,,,,,,,,,,,0
MSG,5,1,1,3C4969,1,2024/11/27,15:36:49.143,2024/11/27,15:36:49.168,TUI6G   ,32000,,,,,,,0,,0,

This happens around 4 or 5 times per hour (I receive data from around 100 to 150 planes)

This is not a single plane emitting with two id as the positions differ from more than 300 km

Regards

I'm running this version of dump1090-fa on Debian Bookworm

-----------------------------------------------------------------------------
| dump1090 ModeS Receiver                                   dump1090-fa 9.0 |
| build options: ENABLE_RTLSDR ENABLE_BLADERF ENABLE_HACKRF ENABLE_LIMESDR  |
-----------------------------------------------------------------------------
  detected runtime CPU features: AVX AVX2
  selected DSP implementations:
    magnitude_uc8                            lookup_unroll_4_x86_avx2
    magnitude_uc8_aligned                    lookup_unroll_4_x86_avx2
    magnitude_power_uc8                      twopass_x86_avx2
    magnitude_power_uc8_aligned              twopass_x86_avx2_aligned
    magnitude_sc16                           exact_float_x86_avx2
    magnitude_sc16_aligned                   exact_float_x86_avx2_aligned
    magnitude_sc16q11                        exact_float_x86_avx2
    magnitude_sc16q11_aligned                exact_float_x86_avx2_aligned
    mean_power_u16                           u32_x86_avx2
    mean_power_u16_aligned                   u32_x86_avx2_aligned
    count_above_u16                          generic_x86_avx2
    count_above_u16_aligned                  generic_x86_avx2_aligned

[mutability]

This is, unfortunately, a problem inherent to DF4/5/20/21 messages (which correspond to message types 5/6 in Basestation output).

These messages don't have proper CRC coverage (for a passive receiver like dump1090) - the CRC is xored with the aircraft address. If you're the SSR, then you know who you interrogated so it's easy to recover the CRC. But for a passive receiver like dump1090, all we can do is:

• assume the message is correct, compute a CRC over the contents
• find (transmitted CRC) xor (computed CRC) = (aircraft address)
• validate that we're actually expecting to hear data from that aircraft (because we heard some other message type like DF11 from that address recently)

However if there are two aircraft in the air at the same time nearby with similar addresses (few bits different -- for example, in your case there is a two bit difference between the addresses) then damage to the CRC part of the message could result in the wrong aircraft address being derived, but actually still matching a nearby active aircraft -- and that leads to the contents of the message being misattributed to the wrong aircraft, as you saw.

All you can really do here is be extra paranoid about the data quality for data derived from those message types.
e.g. dump1090's internal aircraft state tracking strongly prefers callsign data from DF17 ADS-B messages and will only use Comm-B callsigns if no ADS-B data is heard.

[apc005]

Thanks for the detailled explanation !