Message-ID: <3384930D.551B@silver.sdsmt.edu>
Date: Thu, 22 May 1997 11:40:13 -0700
From: Dan Mulally <dmulally@silver.sdsmt.edu>
X-Mailer: Mozilla 3.01 (Win16; I)
MIME-Version: 1.0
To: Martin Lane <MLane@metrol.co.uk>
Subject: Re: Error checking
References: <19970521162741.055ba70e.in@metrol.wintermute.co.uk>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

>
> on  Wed, 21 May 1997 06:44:13 -0700 Dan Mulally wrote
>
> > I've been seeing the messages on various error checking routines such as
> > Hamming and CRC. I had a project that uses 32 bit "packets" to transfer
>
> I have dabbled with Hamming, CRC, and checksums
>
> -SNIP-
>
> > best way but it was easy. I've read that the checksum method is not as
> > sensitive to detecting errors as other methods and I have no idea of the
> > odds of this method giving a correct checksum with errors in the data.
>
> If you just fed random numbers into your system as described you
> would get bad data slipping through every 1 in 256 times. As your
> checksum could hold any of 256 combinations and one of them must be
> correct. Because of this I have used 16bit checksums to cut down on
> the chances of this happening.

        I wonder how this method would do for a specfic bit-error rate, say 1
error in 1000 bits (10E-3)? I'm actually using more than 8 bits because
I look for four good frames in a row to get frame sync and so random
data would be unlikly to cause it to acquire frame sync. If one frame is
bad after frame sync is aquired, that frame's data is discarded but it
doesn't give up on frame sync until it has 4 bad frames.

>
> >
> > Here is the code that does the checksum checking:
> >
> > ;*****************************************************
> > ;Checksum Sub
> > ;*****************************************************
> > chksum   bcf   flags, chksum_ok     ;clear checksum flag
> >          movf  frame0, 0            ;move frame0 to W
> >          addwf frame1, 0            ;add frame1 to W
> >          addwf frame2, 0            ;add frame2 to W
> >          addwf frame3, 0            ;add frame3 to W
> >          xorwf frame4, 0            ;XOR checksum frame with W
> >          btfsc status, z            ;result = 0?  q=yes
> >          bsf   flags, chksum_ok     ;if yes, set checksum flag
> >          retlw null                 ;return with null
> >
> I would be more inclined to XOR all the numbers in the frame together
> but otherwise I have used a 16bit version of what you show above.

        It seems like adding would be better than XORing because I'm
"spreading" the information within the 8 bits by the carries

>
> I have also heard that CRC is more robust. It is supposed to be less
> susceptible to added leading zeros on your message. Though this would
> not apply in your fixed message length case. But as far as hard
> facts regarding how sensitive CRC is at detecting errors - I am as
> interested as you - If anyone out there knows this I would like to
> hear.
>
> TIA
>
> p.s. I have a CRC routine written in 6502 if you are interested!!!

        I would like to see that routine. Thanks Martin.

Dan Mulally
dmulally@silver.sdsmt.edu