Rich Leggitt <PICLIST@MITVMA.MIT.EDU> wrote:

> > [Quoting John Payson:]
> > Note that for the packet sizes you're using, there really isn't
> > any practical way to use an error-correcting code; most bit errors
> > will likely cause framing errors, and ECC's are likely to botch on
> > those.
>
> John, you sure got that right.
> ....
> UART serial? Not a chance. Data looks just like framing except for
> context. Lose the context, and you'll lose the data, and all the
> ECCs in the world won't help.

Guys:

Error-correcting codes actually work BETTER with this sort of error.
Assuming that you're performing the low-level communications in
software (or that your hardware allows you to deal directly with the
incoming signal), you'll have three possibilities for each bit:

    1.  Correct reception,
    2.  A binary error (in which a "1" bit is incorrectly read as a
       "0" or vice-versa, or
    3.  An "erased" bit (in which you read neither a 0 nor a 1).

While a simple (7,4) Hamming code like the one I proposed can
correct only one "type-2" error per 7-bit codeword, it can correct
TWO "type-3" errors.

The reason for this somewhat-unintuitive behavior is that the
error-correcting code normally has to do two jobs:  It has to both
FIND the error and CORRECT it.  If your errors are of the "erasure"
variety, the "FIND" half of its job is already done.

If Neil used a (7,4) Hamming code and interleaved the bits of his 8
code words, he'd be able to properly reconstruct his data even if
28% of his transmission were wiped out by burst noise.

-Andy

Andrew Warren - fastfwd@ix.netcom.com
Fast Forward Engineering, Vista, California
http://www.geocities.com/SiliconValley/2499