Automatic Identification System CRC-CCITT : DSP

I have GMSK-demodulated an AIS-burst (ship navigation system), dediffed
it, and removed bitstuffing zeroes. AIS is transmitted in a HDLC-frame.
The resulting dataframe looks like this:

_________________________________
01111110 --> Start symbol
0000100000000000101110010111000000 ---> Data...
1010101011111011101110110011000111
0101001111100110000010001101011110
1100010000110001101110110010000001
00000011100000000000001100011000
1110100000011111 --> Checksum
01111110 --> Stop symbol
_______________________________


My problem is that when I try to calculate the Cyclic Redundancy Check, it
does not seem to be correct with any of the bursts I collect, even if they
are very strong and very clear. My calculation gives a CRC value of
0xe5cc on this frame. I assume that it uses a CRC-16-CCITT like other
HDLC-frames. Anyone have any suggestions about what may be wrong? Could it
be that I have done something wrong in the demodulation steps? Have I
missed something, or is simply my CRC-calculation method wrong? I have
been stuck too long with this problem.


Thanks!

On Fri, 06 Jul 2007 22:58:48 +0200, Ruben wrote:

> I have GMSK-demodulated an AIS-burst (ship navigation system), dediffed
> it, and removed bitstuffing zeroes. AIS is transmitted in a HDLC-frame.
> The resulting dataframe looks like this:
>
> _________________________________
> 01111110 --> Start symbol
> 0000100000000000101110010111000000 ---> Data...
> 1010101011111011101110110011000111
> 0101001111100110000010001101011110
> 1100010000110001101110110010000001
> 00000011100000000000001100011000
> 1110100000011111 --> Checksum
> 01111110 --> Stop symbol
> _______________________________
>
>
> My problem is that when I try to calculate the Cyclic Redundancy Check, it
> does not seem to be correct with any of the bursts I collect, even if they
> are very strong and very clear. My calculation gives a CRC value of
> 0xe5cc on this frame. I assume that it uses a CRC-16-CCITT like other
> HDLC-frames. Anyone have any suggestions about what may be wrong? Could it
> be that I have done something wrong in the demodulation steps? Have I
> missed something, or is simply my CRC-calculation method wrong? I have
> been stuck too long with this problem.
>
>
I know that AX.25, and I believe X.25 and HLDC, reverse the bit-order
of the checksum. This was a very sensible thing to do back in the day,
because it simplified the hardware -- there was a way to feed the
checksum bits into the linear shift register that made the result come
out to zero for a 'good' packet.

Are you sure that's not happening here?

--
Tim Wescott
Control systems and communications consulting
http://www.wescottdesign.com

Need to learn how to apply control theory in your embedded system?
"Applied Control Theory for Embedded Systems" by Tim Wescott
Elsevier/Newnes, http://www.wescottdesign.com/actfes/actfes.html

Ruben wrote:
> I have GMSK-demodulated an AIS-burst (ship navigation system), dediffed
> it, and removed bitstuffing zeroes. AIS is transmitted in a HDLC-frame.
> The resulting dataframe looks like this:
>
> _________________________________
> 01111110 --> Start symbol
> 0000100000000000101110010111000000 ---> Data...
> 1010101011111011101110110011000111
> 0101001111100110000010001101011110
> 1100010000110001101110110010000001
> 00000011100000000000001100011000
> 1110100000011111 --> Checksum
> 01111110 --> Stop symbol
> _______________________________
>
>
> My problem is that when I try to calculate the Cyclic Redundancy Check, it
> does not seem to be correct with any of the bursts I collect, even if they
> are very strong and very clear. My calculation gives a CRC value of
> 0xe5cc on this frame. I assume that it uses a CRC-16-CCITT like other
> HDLC-frames. Anyone have any suggestions about what may be wrong? Could it
> be that I have done something wrong in the demodulation steps? Have I
> missed something, or is simply my CRC-calculation method wrong? I have
> been stuck too long with this problem.

I just pumped that message through the ITU-16 CRC algorithm, and it is
correct. The test code I threw together is at
http://www.soft-switch.org/crc_test.c

Steve

On Fri, 06 Jul 2007 22:58:48 +0200, Ruben wrote:

> I have GMSK-demodulated an AIS-burst (ship navigation system), dediffed
> it, and removed bitstuffing zeroes. AIS is transmitted in a HDLC-frame.
> The resulting dataframe looks like this:
>
> _________________________________
> 01111110 --> Start symbol
> 0000100000000000101110010111000000 ---> Data...
> 1010101011111011101110110011000111
> 0101001111100110000010001101011110
> 1100010000110001101110110010000001
> 00000011100000000000001100011000
> 1110100000011111 --> Checksum
> 01111110 --> Stop symbol
> _______________________________
>
>
> My problem is that when I try to calculate the Cyclic Redundancy Check, it
> does not seem to be correct with any of the bursts I collect, even if they
> are very strong and very clear. My calculation gives a CRC value of
> 0xe5cc on this frame. I assume that it uses a CRC-16-CCITT like other
> HDLC-frames. Anyone have any suggestions about what may be wrong? Could it
> be that I have done something wrong in the demodulation steps? Have I
> missed something, or is simply my CRC-calculation method wrong? I have
> been stuck too long with this problem.
>
>
> Thanks!

Thank you both! It works correctly now.

I did not know that the bits in
each byte in the HDLC frame where ordered least significant bit first,
while the bytes where ordered most significant byte first. That was not
what I expected. I think I tried everything except this case.. reversing
the whole bitstream, bytes as LSB and bits as MSb etc.

Ruben

Hi Ruben
Can you please tell me how did u got the correct CRC bytes
I have used two online calculators and one code but they dont give the same bytes
I have reversed the bits as well and new array of data is
%10%00%9D%0E%54%7D%77%33%AE%7C%06%B1%DE%08%63%37%81%C0%01%C0%18
% is used to separate hex value