Incorrect callsign reported
Closed this issue · 2 comments
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
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.
Thanks for the detailled explanation !