Path: utzoo!utgpu!jarvis.csri.toronto.edu!cs.utexas.edu!usc!apple!netcom!allanh
From: allanh@netcom.UUCP (Allan N. Hessenflow)
Newsgroups: comp.sys.mac.programmer
Subject: Re: crc functions
Summary: crc fixed?
Keywords: ccitt
Message-ID: <8721@netcom.UUCP>
Date: 9 Mar 90 06:38:00 GMT
References: <8548@netcom.UUCP> <1990Mar7.065639.11927@Neon.Stanford.EDU> <1990Mar8.051028.20207@Neon.Stanford.EDU>
Organization: NetCom- The Bay Area's Public Access Unix System {408 249-0290 guest}
Lines: 35

In article <1990Mar8.051028.20207@Neon.Stanford.EDU>, kaufman@Neon.Stanford.EDU (Marc T. Kaufman) writes:
> In article <8603@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 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).
>
> Marc Kaufman (kaufman@Neon.stanford.edu)

Since my original posting, I've found another source for the CCITT CRC which
isn't equivalent to the one I had been using from Stephen Satchell.  The 
original document I had been working from contained five different routines,
three of which worked according to Mr. Satchell.  Those three are indeed 
equivalent to each other, but aren't equivalent to the CCITT CRC they claim
to be (at least they aren't equivalent to the one published in the 'C 
Programmer's Guide to Serial Communication').  I've replaced my original routine
with one from that book, and so far it appears to be less sensitive to two bit
errors (although it's too early to be certain).  

I was rather hoping to hear that no two message+crc blocks will differ by
only two bits.  I don't understand why anyone would want to know how may bits
in the message can be incorrect and still be caught if errors in the CRC itself
aren't included.  Surely in most applications the CRC is sent over the same
noisy channel as the message.


-- 
apple!netcom!allanh    allanh@netcom.uucp