CRC checking of Comm BDS 5.0 / 6.0

ONERA_Toulouse
Topic Author
Offline
New Member

5 years 7 months ago #543 by ONERA_Toulouse

CRC checking of Comm BDS 5.0 / 6.0 was created by ONERA_Toulouse

Hi,
I'm using java-adsb decoder for a while and i use it to decode ADSB data and ModeS Comm-B Bds 5,0 and 6,0 data.
I'm listening Mode-S data from a Radarcape and an omnidirectinnal antenna since a year and i noticed that there were a lot of lonely Comm-B messages (with only few occurences for a particular ICAO).

I compared the total amount of distinct ICAO receive from ADS-B and the total receive from CommB and there is an huge difference (x10). I have more distinct ICAO from CommB than ADSB and if all ADSB ICAOs are included in CommB ICAOs, the lonely ICAO are not present in ADS-B messages.

I deduce there is a problem with CommB messages,maybe some of them are provided with a wrong Icao ?

In Eurocontrol documentation, i could see that the ICAO adress is calculed by XOR the message calculated parity and the provided parity. These calculations seems to be done in the java-adsb decoder.

Is this possible that there is a problem with icao adress calculation or message error checking ?

I don't understand exactly how CRC is working on ModeS data but in the decoder exemple code provided on github i can see some tests concerning parity checking.

So there is a piece of code from ExampleDecoder.java :

if (tools.isZero(msg.getParity()) || msg.checkParity()) { // CRC is ok
[...] // Switch between different adsb message format
else if (msg.getDownlinkFormat() != 17) {
[...] Switch between other ModeS format whose DF20 and DF21 for CommB message
}

So if i understand parity checking is done only for ADS-B messages and if it failed we check if messages are in other format ?

I deduce parity check is not done for other Mode-S messages than ADSB ?

Please Log in or Create an account to join the conversation.

fuchs
Offline
Senior Member

5 years 7 months ago #545 by fuchs

Replied by fuchs on topic CRC checking of Comm BDS 5.0 / 6.0

The problem with transponder addresses and parity for non-ADSB messages is described in the OpenSky Report 2016 :

A. Passive Monitoring Challenges

[...] This system design is challenging for passive
observers such as OpenSky, which do not see the uplink
communication, namely the interrogations. [...]
Although Mode S messages
in SSR employ a cyclic redundancy check (CRC) to do so, the
checksum is XORed with the aircraft’s ICAO 24-bit address
or the interrogator ID (all-call replies) in Mode S replies to
save bits (see Figure 3). While this does not pose a problem
for the interrogator since it knows which address to expect,
a passive observer needs to learn the respective addresses
first in order to make use of the CRC.

The parity check for DF != 17 and DF != 11 will always fail, because the ICAO address is XOR'ed with the correct CRC. Trueb et al gives further information and a solution:

3.1.1 Address Filter. To link a received message to an aircraft, we
need to extract the aircraft address from a data field that contains
the address XOR-ed with the parity of the message. Under the
assumption that the message did not suffer from bit errors, we can
extract the aircraft address from the parity by XOR-ing the parity
with the CRC of the received message body. Of course, with this
approach the parity can no longer be used to check the integrity
of the message

Hope that helps!

Markus

Please Log in or Create an account to join the conversation.