Detecting the end of a packet

[Guest]

My project is sending data wirelessly over bluetooth in both directions between a dsPIC and a PC using packets of varying size. Currently, I have a 10ms inactivity timer, that is reset every time a new byte is received. When the timer times out, the packet is finished and parsed.

There are two problems with this method. First, the packet most frequently sent from the PIC takes about 10 ms to transmit. Then the PC waits 10ms before determining that the packet has ended. The PC sends an acknowledgment packet (negligible amount of time), and the PIC waits 10ms before parsing the packet. So effectively, my data rate is only a third of my baud rate. This 10ms delay works fine over a serial cable. But over bluetooth, some of the packets are broken up into two separate packets once received. This tells me that even 10ms is too short of a timeout.

What other methods can be used to signify the end of a packet? The bytes of the packet's payload can be anything from 0x00 to 0xFF, so I dont think I can use a specific byte or sequence of bytes. I do have a byte in the packet that holds the number of bytes in the packet, but that byte is just as susceptible to corruption as any other.

Any ideas?

[bkamen]

Count the number of bytes you are receiving.
If the packet is fixed... there you go.
If the packet if variable, include in the packet a packet length... and there you go.

Consider why you might count the timeout from the beginning of packet reception as opposed to the last byte received.

Consider putting in headers to identify the start of a packet. Don't count the timeout until you're in the next state that a packet has begun.

I did a wireless protocol for someone in which the packets were fixed length. So I just counted... and then did a checksum (included in packet) as well as some other checks to make sure the packet was sane and then either dumped it or processed it. If the packet stalled out (I counted timeout from the last BYTE received) I reset the state of the packet receiver.

In a real sense, you're building a state machine. So consider how you would program that.

Cheers,

-Ben
_________________
Dazed and confused? I don't think so. Just "plain lost" will do. :D

[John P]

I can't quite answer your question, but I use a method for starting a packet, which might be good enough. If you use packets of fixed length, or if the packet itself contains information telling the receiver how long it is, it should work.

The scheme is that each packet begins with a "start of packet" character. I use 0xFF, but it could be anything. Then if a data byte within the packet happens to be 0xFF, that byte must be sent twice. If 0xFF is only seen once, it's always interpreted as the start of a new packet. Combined with a checksum, this is a reasonably foolproof system.