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

To be sure, it may seem unlikely that you'd have two identical bad packets
come down the pipe, but pathological conditions may make it happen much
more frequently than the once every 4*10^9 packets sheer chance would
suggest.  For example, eight consecutive noise-bursts could be interpreted
as eight bytes; depending upon the source of the noise-burst all eight might
very well be identical.  Even worse, the protocol you've described gives
little or no assurance that a packet won't be "off" by a byte; in fact,
if packets are sent with less than a byte time between them this could
generate systemic errors.

To be sure, sending your packet twice is probably going to be fairly
reliable if you XOR the second copy with a non-trivial data mask (to make
sure that the data bit pattern has to be different to match).  On the
other hand, there are other methods that yield the same reliability with
less overhead, or which provide better error recovery with the same over-
head.  If speed is not critical, this may not be an issue and the simplicity
of sending the data twice (with slight munging the second time) may be an
advantage.  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.