At 11:27 PM 23/08/99 -0400, you wrote:
>James Cameron wrote:
>>
>> Assuming I'm going to be generating between two to eight words of twelve
>> bits each in a data stream over a remote control UHF link, what sort of
>> checksum or CRC is appropriate?
>>
>> I get the impression that calculating a checksum or a CRC on such small
>> data streams might be ineffective, because of the probabilities
>> involved.
>>
>> For example; sending 24 bits of data followed by a 12 bit arithmetic
>> checksum ... the chances of corruption affecting one of the 24 bits and
>> then also one of the 12 bits of checksum to mask the corruption seem to
>> be higher.
>>
>> I'm not exactly sure how to express this ... but is there a concern?
>
>
>James, CRC's (8,16 or 32) offers a high confidence to your data
>transmission, doesn't matter if is only one byte or one million bytes.
>If your transmission media corrupts one bit of data (or CRC), it means
>you have a *corrupted* data, nothing else, and you need to retransmit
>the thing.  Except, of course, if you use an inteligent protocol and
>correction codes to *de-corrupt* the bit (or bits).
>
>Your worries about to have a higher probability of data corruption
>because transmitting just two data bytes followed by 2 CRC bytes
>(CRC-16), meaning that you will double the corruption probability, is
>not ... hmmm... nice, since your transmission media should be clean. You
>can not think of it as a machine gun shooting gallery, while if your
>data is skinny better the chances to survive across the bullets.
>
>If you suspect your media is dirty and noise poluted, this is a strong
>reason to use a good CRC system. This is the price to pay.

The tradeoff is between correctness and efficiency, longer CRCs increase
chance of
detecting corruption but also decrease throughput because more packets will
have errors.



>Some time ago I saw a check system, silly but functional, (I don't
>recommend, but...), send every bit followed with its binary complement.
>Noise could change just one or multiple bits, and probably, (I will
>repeat), probably, noise will not change the complement bit to the right
>level, so it will be easy to identify the discrepancy between the
>original and the complement bit... it doubles the transmission data size
>and not ensure a good check system.

Useful whene you have lots of bandwidth and not much computing power though.


Nic