Path: utzoo!utgpu!jarvis.csri.toronto.edu!cs.utexas.edu!tut.cis.ohio-state.edu!ucbvax!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: <1990Mar8.051028.20207@Neon.Stanford.EDU>
Date: 8 Mar 90 05:10:28 GMT
References: <8548@netcom.UUCP> <1990Mar7.065639.11927@Neon.Stanford.EDU> <8603@netcom.UUCP>
Organization: Computer Science Department, Stanford University
Lines: 27

In article <8603@netcom.UUCP> allanh@netcom.UUCP (Allan N. Hessenflow) writes:
>In article <1990Mar7.065639.11927@Neon.Stanford.EDU>, kaufman@Neon.Stanford.EDU (Marc T. Kaufman) writes:
-> In article <8548@netcom.UUCP> allanh@netcom.UUCP (Allan N. Hessenflow) writes:
-> 
-> -$41 76 03 01 00 09 has a crc of 37fb, while
-> -$41 76 03 01 00 08 has a crc of 37fa.
 
-> 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 problem is that there are only two bits different between the two
>messages, including the crc.

I understand your concern.  However, I must unfortunately report that
the CRC is a checksum of the Message, only.  Not the Message+CRC.  If you
need to be able to discover 2-bit errors in the message+CRC, you will need
to compute a CRC on the original Message+CRC (or use a longer CRC, say 32 bit).

It is also the case that the few bits very near the end of the message have
less effect on the resultant CRC than earlier bits do.  Maybe just
padding the message with some '1' bits will work, though I haven't tried it.

By the way:  It is certainly true that some 4-bit errors will leave the CRC
unchanged -- and the length of the bit substring in error can be as short as
17 bits for a 16 bit CRC.

Marc Kaufman (kaufman@Neon.stanford.edu)