The syndrome is calculated by passing all packet bytes (including the three CRC bytes) through the CRC algorithm: the outcome is a 24-bit value, which is all-zeros for a correctly received packet.
Now, the CRC has an important property: when one of the packet bits gets flipped then the syndrome is non-zero and it has always the same value for the given bit number, regardless of the content of the packet. Here are the CRC syndromes listed for the first four bytes of the packet – this is a part of an actual code for correcting transmission errors.

So, to make it clear with examples: if the 1^st bit of the packet gets flipped the CRC syndrome is 0x7ABEE1 and it does not depend on the value of any of the packet bits, it is always the same.
This property is absolutely essential and you can already see how one can fix single bit errors: compute the CRC syndrome and look it up in the table: if it is there, you flip the corresponding bit and you are done !

Now, there is a small chance this CRC syndrome was produced by flipping many other bits or simply came “out of the noise”, then by flipping the bit we would “over-correct” and get a packet with correct CRC but incorrect content – we shall see later how to filter out such cases.

Multiple bits

What happens when two or more bits of a packet get flipped: then the CRC syndrome becomes a bitwise XOR of the syndromes for the bits flipped. For example if the 1st and 3rd bit of the packet get flipped then the CRC syndrome becomes 0x7ABEE1^0x6152BA = 0x1BEC58. It as well would be same value regardless of the value of those or other bits in the packet.

Thus you get the idea how multiple bit errors could be corrected. The CRC was designed to be an error detecting not correcting code thus there is no (known) regular way to find the flipped bits and so you need to do a search over candidate error patterns, which can become quite extensive for multiple bits. But, there are ways to speed up the search by pointing to the “suspected” bits for example by looking at Manchester decode errors or at weakest decoded soft bits from the demodulator.

Manchester decoder example: if you get a packet and there are four bits with decode errors thus 00 or 11 (while Manchester should only be 01 or 10) then you check all 16 combinations of those bits to see if they make the CRC syndrome all-zeros. Note: you don’t need to recalculate the CRC every time you flip a bit in the packet, you can use the syndrome table and property described above: the process is very quick and often leads to success.

Likewise when you have soft bits from the demodulator you take a number of weakest ones and check the CRC syndromes in the same way – this is called soft-assisted syndrome decoding of a CRC code.

Over-corrected packets

The more bits you attempt to correct, the more chances are you get a packet with correct CRC but content different from the original, as you have chosen to flip the wrong bits, not those which were corrupted by the transmission channel. Here the scrambling of the packet is of great help.

Good scrambling has the property that if you get even one bit wrong on reception then after undoing the scrambling you obtain a pseudo-random packet content and so when you try decode the elements of the packet like device address, address-type, position, etc. you get pseudo-random values which, you notice immediately, don’t fit other packets: the easiest elements to check are device ID and position.

Without scrambling/unscrambling stage you might not be able to spot that some bits had been corrupted in the packet, expecially in the lowest bits of the position/altitude/speed, etc. but with the scrambling in place you will spot immediately the bad packets – the check serves a kind of additional CRC which practically eliminates issues with overcorrection.

As an illustration of importance or usefulness of error corrections with ADS-L in the following chapters we present test results from a laboratory setup and from a test flight where is the range plot where with the green color are marked packets which would not be received without error correction. You can see at the extremities of the range how most if not all packets contain errors which were correctable and helped to extend the range or fill the gaps in perfect (without errors) reception.

In-the-lab measurement

A set of measurements have been performed in the lab using a test generator with variable output power and an OGN receiver based on RTLSDR USB receiver. A constant 25Hz stream of packets has been sent and number of correctly received packets recorded together with number of bits corrected per packet and SNR reported by the receiver.

The setup: (white) signal generator, (black) attenuator, (blue) RTLSDR USB receiver, (black) PC running the OGN-receiver code and controlling the generator to perform scans and received packet rates.

The results are illustrated on the plot below, for ADS-L and OGN packets to compare error correction performance based on the CRC24 for ADS-L and regular Low Density Parity Check (LDPC) FEC code for OGN.

It is worth noting that the effective gain obtained by applying data correction was 4dB at PER of 10% and even 1.5dB more for OGN packets due to a stronger and regular forward error correcting (FEC) code. Both systems have similar packet sizes: ADS-L packets are 21 byte of user data plus 3 bytes of CRC24 while OGN packets are 20 bytes of user data with 6 bytes of LDPC FEC. It can be observed that without correcting for errors the performance is nearly identical, but when running error correction algorithm the CRC 24 could correct up to 8-9 bits per packet and LDPC up to 14 bits.

For those interested, here is how the packets of various strength appear on the spectrogram.

ADS-L/OGN packets on the spectrogram: visual representation of the Signal-to-Noise ratio. The top row indicates the applied signal level and the SNR reported by the receiver.

In the field performance

Practical, in the field, importance of error corrections: the above plot illustrates reception range, SNR and number of bits corrected for HDR packets received by a selected receiver during a test flight on 12.02.2026.

The traces represent, top to bottom:

red: aircraft altitude
magenta: receiver-aircraft distance for packets received error-free
green: receiver-aircraft distance for packet where error correction was needed
blue: Signal-to-Noise Ratio (SNR) for received packets
dark-green: number of bits corrected in the packet

It can be observed how error corrected packets filled the gaps and what role they played in extending the reception range. Up to 7 bits were correct per 24-byte data packets.

Conclusion

Although the 24-bit CRC used in ADS-L packets was designed primarily for error detection, its linearity enables practical single- and limited multi-bit correction via syndrome based search constrained by demodulator reliability information: Manchester errors or soft bits.

Gain achieved by the error correction algorithm was 4dB for ADS-L at 10% packet error rate.

A comparison to the OGN protocol where packets are of roughly same size but have larger 48-bit LDPC check shows an additional coding gain of 1.5dB thus totalling to 5.5dB coding gain at 10% PER – this corresponds to almost quadrupling the transmission power.

The final summary: where the receiver without error correction approaches a complete loss of reception, the receiver with error correction is only just beginning to lose its first packets.

Authors of the study:

Sylwester Barański, sylw.bar@gmail.com
Paweł Jałocha, Pawel.Jalocha@gmail.com