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
information. In order to ensure the data was not corrupted (and also to
obtaing frame sync) an 8 bit checksum was added to make a 40 bit frame.
The checksum of the 32 bits was then compared to the last byte of the
frame to determine the validity of the data. I'm not sure if it was the
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.
Does anyone know of any references that would discuss this or know the
answer. Thankyou in advance.
Here is the code that does the checksum checking:
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
|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
> 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 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.
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
p.s. I have a CRC routine written in 6502 if you are interested!!!
Metrol Technology Ltd
Tel. +44 1224 772771
Fax. +44 1224 772660
As I recall, various types of error checking do better jobs of
detecting various types of errors (and, of course, error correcting codes
can correct up to a certain number of errors in the packet, then just
detect errors, then just give up). In another project I did about 15
years ago, I was sending packets that were variable length, but often up
to 32 bytes. I originally included an 8 bit checksum. Errors would
occasionally get through undetetected. Since the 8 bit checksum only has
256 possible values, it SEEMS there is a 1 in 256 possibility of an
erroneous packet getting through the checksum. I then tried increasing
the checksum to 16 bits, but the sum of all the bytes rarely got to
anywhere near such a big number. The method I settled upon involved
doing a left shift of the existing checksum value, then adding in the new
byte. This was repeated each time a byte was added to the packet.
Overflow was discarded. Now that I think about it, perhaps discarding
overflow resulted in discarding error checking on the first bytes in the
packet, but the system vastly improved operation.
by the way, this was a networked system based on audio links
between sites (which could be hundreds of miles away) using Bell 202 half
duplex modems. It used a minislotted access method where each site was
allocated 50 mS to bring up carrier and start transmission if it had any
traffic. If it did not have any traffic, it just left its carrier off
and all sites advanced their "site counter" to the next site that was
authorized to transmit. Site counters were advanced 50 mS after
receiving the last byte, and every 50 mS thereafter. During reception,
site counter advances were held off. Thus the 50 mS "minislot" was
expanded into a "slot" that was large enough to handle whatever traffic
this site had. Further, to keep the site counters in sync, each site
fully demodulated all traffic. On receiving a valid packet from a site,
it was assumed that this site was indeed authorized to transmit at this
time, so the site counter was loaded with the address of the originating
site. This insured that when the traffic ended, all sites incremented
their site counters to the same number, all authorizing the same site to
transmit. the protocol handled up to 100 sites, though the largest
installation I know of is 15 or 20 sites. Part of the setup of the
system is to put in the highest site number. The boxes then reset their
site counters after that number is reached so they don't allocate time to
At 12:50 PM 5/21/97 EDT, you wrote:
>transmit. the protocol handled up to 100 sites, though the largest
>installation I know of is 15 or 20 sites. Part of the setup of the
>system is to put in the highest site number. The boxes then reset their
>site counters after that number is reached so they don't allocate time to
That was a pretty ingenious token system. Not bad!
The left-shift you were doing is starting to approach CRC, but in a
simplistic manner. I use this myself to be better than a checksum w/o the
complexity of a CRC, and it only takes three opcodes:
(assuming W holds next char to process)
bcf C ; Only needed if you aren't sure...
Andy Kunz - Montana Design - 409 S 6th St - Phillipsburg, NJ 08865 USA
Electronics for Industry & R/C Hobbyists
"Go fast, turn right, and keep the wet side down!"
|On Wed, 21 May 1997 13:09:30 -0400 Andy Kunz <FAST.NET> writes: montana
>That was a pretty ingenious token system. Not bad!
Thanks! I acutally called it "absence of data token passing"
when I first came up with it. Since then, I've found (I think) that it's
called "minislotted". In a "slotted" system, a fixed amount of time is
available for each site to transmit, whether it has data or not. In a
minislotted system the fixed slot is used to indicate an intention to
transmit data, then it is expanded as necessary to transmit the data.
This gives "bandwidth on demand" that a slotted system doesn't do.
My "absence of data token passing" idea was an adaptation of
typical token passing, but using the lack of data as a token to avoid the
possibility of a token getting lost and having to reconfigure the system.
I agree that shifted checksum might be considered a simplistic
CRC. I was never able to completely figure out CRC, so I invented my
own. Standards often seem to try to anticipate every possibility,
burying us in details. Because of that (and my not being able to figure
out the standard!), I invent my own. Not necessarily the best way to do
stuff... but it gets it done.
At 07:13 PM 5/21/97 EDT, you wrote:
>On Wed, 21 May 1997 13:09:30 -0400 Andy Kunz <FAST.NET> writes: montana
>>That was a pretty ingenious token system. Not bad!
One should BSF C prior to rotate to force some bits in. Takes care of
leading zeros properly then.
Andy Kunz - Montana Design - 409 S 6th St - Phillipsburg, NJ 08865
Hardware & Software for Industry & R/C Hobbies
"Go fast, turn right, and keep the wet side down!"
More... (looser matching)
- Last day of these posts
- In 1997
, 1998 only
- New search...