Path: utzoo!utgpu!jarvis.csri.toronto.edu!rutgers!cs.utexas.edu!usc!zaphod.mps.ohio-state.edu!think!mintaka!ogicse!decwrl!shelby!neon!kaufman
From: kaufman@Neon.Stanford.EDU (Marc T. Kaufman)
Newsgroups: comp.sys.mac.programmer
Subject: Re: crc functions
Keywords: ccitt
Message-ID: <1990Mar7.065639.11927@Neon.Stanford.EDU>
Date: 7 Mar 90 06:56:39 GMT
References: <8548@netcom.UUCP>
Organization: Computer Science Department, Stanford University
Lines: 25

In article <8548@netcom.UUCP> allanh@netcom.UUCP (Allan N. Hessenflow) writes:

-I've been using a crc routine from a document by Stephen Satchell which
-is supposed to be the same one used in xmodem.  I seem to remember reading
-about the properties of this crc a long time ago that it would catch all
-single bit errors and all double bit errors for messages < n bytes long,
-where n is significantly larger than 6.  However, I've recently discovered
-that this is not the case.  Specifically, 
-$41 76 03 01 00 09 has a crc of 37fb, while
-$41 76 03 01 00 08 has a crc of 37fa.
-Is this normal for the CCITT CRC, or is the function I'm using faulty?  I'm
-fairly certain it's not a coding/translation error, as I've tried two
-different functions from the same document with the same results.

The last time I looked, 37fb and 37fa were different numbers, so the CRCs of
the two input strings were, in fact, different.  What's the problem?

The way CRCs are meant to be used is:  Initialize the CRC to all 1's, then
compute the CRC of the message.  Send the message with the CRC appended to it.
On the receiving side, initialize the CRC to all 0's.  Compute the CRC of the
entire message PLUS the message CRC.  The result should be 0.  If not, you
have an error.  The CRC alone is not strong enough to enable you to correct
the error.

Marc Kaufman (kaufman@Neon.stanford.edu)