Why there is no CRC-3 on Wiki?

On Sat, 26 Oct 2013 11:28:14 -0700 (PDT), dvsarwate
<dvsarwate@yahoo.com> wrote:

>On Saturday, October 26, 2013 10:49:59 AM UTC-5, Verictor wrote:
>
>>Also, from Glen's point, CRC-1 is in use, which results in 50% code rate.
>
>CRC-1, also known as an overall parity bit, was in use even in
>the very first computers, long before anyone had dreamt of
>data transmission between computers and CRCs. It does not
>result in a 50% code rate: the overall parity bit is usually
>confined to use with one (8-bit) byte of data, except for those
>who read Matthew 5:37 literally and insist on following each
>data bit by one (even) parity bit. One translation gives this
>verse as
>
>"But let your communication be, Yea, yea; Nay, nay:
>for whatsoever is more than these cometh of evil." 
>

I've always interpreted that to mean that all communication should be
done in binary.    But, since the Bible wasn't published digitally for
many centuries, it then seemed to be calling itself into question and
therefore subject to question as a trusted or reliable source.


Eric Jacobsen
Anchor Hill Communications
http://www.anchorhill.com

On Sat, 26 Oct 2013 11:19:15 -0700 (PDT), dvsarwate
<dvsarwate@yahoo.com> wrote:

>On Saturday, October 26, 2013 12:24:14 PM UTC-5, Tim Wescott wrote:
>
>> 
>> I'm not sure what reasoning you're going by to say the packet length 
>> 
>> should be limited to such a large number.
>> 
>> 
>> 
>> A CRC is still going to detect a few bit errors in packets longer than 
>> 
>> your magic length, and it is still going to fail to detect just the right 
>> 
>> (wrong?) combination of enough bit errors in packets that are shorter.
>> 
>
>
>With CRC-16, say, and a packet length less than 2^15 - 1,
>the **smallest** number of bit errors that could possibly
>give an undetected transmission error is 4 bits. Readers
>please note carefully, I am not saying that **every**
>possible 4-bit error pattern will cause an undetected
>transmission error (packet is received with bit errors
>but CRC says packet is OK), but that there are **some**
>4-bit error patterns that will cause an undetected error.
>This is in contrast to the fact that **all* 1, 2, and 3
>bit error patterns will cause a CRC failure and thus are
>detected.
>
>If the packet length exceeds 2^15 - 1, then there are
>2-bit error patterns that are **not** detected by CRC-16.
>For example, x^{2^15-1} + 1 is divisible by the CRC-16
>polynomial (as well as by the CRC-CCITT polynomial for
>that matter), and x^{2^32-1} + 1 is divisible by CRC-32
>should you really want to push your luck and have a
>data payload of approximately 2^32 bits protected by a
>measly 32 bits of CRC.
>
>Dilip Sarwate

This is why a good system design (and there aren't that many of them)
takes into account the FEC/ECC behavior, both error probability and
distribution, jointly with the CRC (or whatever) outer error
detection.   Even doing so usually does not provide a basis for
claiming absolute reliability, so upper layers will often
understandably still do their own error detection in addition to
whatever the PHY/MAC provides.

Basically, there is no such thing as a completely reliable
communication system.   There are systems that can meet practically
determined specs, though.  ;)


Eric Jacobsen
Anchor Hill Communications
http://www.anchorhill.com