On Mon, 1 Jul 1996, Andrew Warren wrote:


> 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
>

>> Correct me if I wrong but, this is how I view this error scheme.
If I send a 32 bit word, and then an identical 32 bit word. The odds
of those words being corrupted in the EXACT same pattern are
extroadinarily low. If the two words do not match, then the packet is
discarded and the PIC simply waits for the next one. There is no
reason to request a resend. While this substantially increases the amount
of packets that may be discarded it almost perfectly assures that the
data is not corrupt, which is very important in my application.
I don't have any numerical data to substantiate this, but I am basically
approximating probability. Again, please correct me if I wrong. Thanks
for the advice.

Neil Gandler