NEIL GANDLER <PICLIST@MITVMA.MIT.EDU> wrote:

> I plan on using the SCI modules of two PIC16c74 for full duplex
> asychronous communication. .... I was wondering if the 9th bit
> parity option is adequate for error detection. Just to be safe, I
> designed my software to send a 32 bit packet and then resend an
> identical copy. If they both matched, the receiver will assume all
> bits are correct. That would achieve excellent error detection yet
> eat up quite a bit of transmission time, but still could be
> practical.

Neil:

What you're doing, essentially, is sending an even-parity bit for
every bit of your original 32-bit message.

You may want to examine this solution... Let's say, for the sake of
argument, that each bit has a 99% probability of getting through
correctly.

If you send the message with no error-checking at all, your error
rate (the odds of undetectable incorrect reception) will be about
17.5%. Obviously, SOMETHING must be done.

Let's say that you just use the built-in "9th-bit parity" option.
The error rate for each byte is about 0.34%, so the error rate for
the whole 32-bit message will be about 1.36%... A significant
improvement, and achieved with only four bits of overhead.

Now let's do the math for your "parity bit for each data bit"
solution:  Each bit has an error rate of 0.01%, so the error rate for
the whole packet will be approximately 0.32%.

Out of 10,000 messages sent, the "9th-bit parity" method will ensure
that 9,863 messages get through correctly.  Your method improves this
to 9,968 messages -- about 1% more -- but at a cost of eight times
the overhead.

Keep in mind that all of the above assumes that when a detectable
error occurs, the receiver can signal the transmitter to re-send the
message.  Given our 99%-per-bit probability of sending the correct
message, this means that ALMOST 50% OF ALL MESSAGES WILL NEED TO BE
RE-SENT.

Of course, 99%-correct probability is pretty low... Most
communication channels are much more reliable than this.  Still,
it's something to think about.

Something else to consider is that there's a certain error
probability for the "resend the last message" signal that the
receiver sends to the transmitter.  If THAT message has undetectable
errors, God only knows what your communication system will do.

Ok.  What you might want to do is investigate alternative
error-control coding methods.  My suggestion for this application
would be a (7,4) Hamming code, in which 3 parity bits are added to
each nibble of your original data.  This means that there will only
be 24 bits of overhead versus the 32 bits that your scheme requires,
BUT...

You'll be able to correct any single-bit error without asking the
transmitter to resend, OR you'll be able to detect any double-bit
errors and ask for a re-transmission.

As an added bonus, you'll be able to detect a few triple-bit errors.
However, these are very rare -- even with our unrealistically-high 1%
error rate per bit, a 3-bit error in a 56-bit message will happen
only once in 20,280 messages -- so I wouldn't get too excited about
the capability.

I posted a message about Hamming codes here a few months ago... If
you're interested, let me know and I'll dig it up.  Hamming codes (at
least the little ones like the one I'm suggesting you use) are real
easy to implement on a PIC.

-Andy

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