> NEIL GANDLER <
PICLISTKILLspamMITVMA.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 -
.....fastfwdKILLspam.....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.