Brent Crosby wrote:
>
> Wagner:
>
>   Say you have a 10-byte fixed length packet. Your receiving
> routine would typically wait until 10 bytes are in its buffer, then
> apply the CRC routine. If the CRC does not match, you might
> empty the buffer, saying that there is garbage coming in, not
> packets. Well, the routine may not ever synchronize if you do
> this.
>
>   As an example, say the transmitter is always sending out
> valid 10-byte packets. What if the receiver wakes up in the
> middle of a packet? It receives 5 bytes from the end of the
> first packet, then 5 bytes from the start of the next packet,
> applies the CRC, discards the data and then repeats the
> whole process, staying out of sync, even though there are
> good packets coming in.
>
>   The trick is to only discard one byte instead of the whole
> buffer or a whole packet's worth of bytes. Then the receiver
> essentially has a  sliding 10-byte window, whose CRC will
> only match up if there is a valid packet in the 10 bytes. Of
> course, once you do get  valid packet, you take the whole
> packet out at once.
>
>   Maybe this is obvious to everyone, but it had me stumped
> for a bit--once I got out of sync it would reject all packets.
>

Oh, thanks Brent, I see your point of view, but this is why we use sync
or start of packet characters, so the receiver will not start to fill
the buffer until it "sees" this sync or SOH (Start of Header)
character.  Several protocols use the SOH and EOB (End of Block), and
many other symbologies for those "start" and "end" of data block
characters.  Of course, as you said before, a receiver "waking up" in
the middle of the block will not get the sync and will not answer,
generating time-out.  Some more inteligent protocols can recognize the
end-of-block character and send a negative acknoledgement (even without
received the start of block), so it avoid the time-out and starts a fast
retransmition.

I use to develop several *special protocols* for different applications,
for several reasons as security or application customized and so on. In
every one I use those SOH and EOB (plus the CRC-16 of course), so the
receiver would ever understand when a block starts and ends.

I also use to do the software run the CRC for every char received, in
real time, so at the end of the block after receiving the 2 CRC bytes,
the resulting CRC should be zero (for CRC-16). Of course it implies a
processing window available in between of each char received.

Wagner