byte header for message packet

Status
Not open for further replies.

virtualdave

Well-known member
Hi all,
I need some advice...again :)
I'm doing a bunch of data processing on a t3 and then passing that along to a CPU via bluetooth or USB. The packet is a fixed length (50 bytes), and consists of:

header (1 byte)
sub-header (1 byte)
9 floats (each float represented by 4 bytes) (these are processed values from an IMU)
4 16-bit ints (each int represented by 2 bytes) (these are processed values from analog sensors connected to the analog inputs on the t3)
1 32-bit int (represented by 4 bytes) (a sample counter represented as an unsigned long that increments every 10ms)

My question is what to use as a header byte that will be unique, i.e. never used by the rest of the packet, so I can use it to let the software know a this is the beginning of a new packet. Or is there such a value given the type of numbers I am sending.

I'll stop here since I'm not sure what information would be helpful. Please let me know what other information I can provide.

Thanks in advance for any pointers.

Cheers,
David
 
Last edited:
There certainly is no such fixed 8-bit value.

I'd replace the sample counter with a 16-bit monotonically increasing counter (increased by one whenever a packet is sent, and it'd wrap to zero after 65535. of course), and use the remaining 16 bits (or 24 bits, if using the header for this too) for a checksum or hash. I'd drop the headers, and use 48-byte packet size.

If synchronization is lost, the checksum/hash does not match. In that case, the driver or userspace side will advance by one byte instead of one packet, until synchronization is regained. Eventually, it will resync. (If there are at least three packets' worth of data buffered already, without dropped packets in between, the code could first try offsets where the counter increments by one, and be guaranteed to resync with minimal computation.)

Also, I'd personally reconsider the floats, using 16-bit, 24-bit, or 32-bit fixed point representation instead.
 
You usualy have more then one header byte. Maybe a sequance of 3 bytes. This way it would be very unlikley this same sequance would come up in your payload.
 
I would not trust a fixed identifier. A checksum is simple and easy to implement, and usually also detects comms errors. If you intend to use the Teensy with e.g. RasPi, with its funky USB implementation, that might be important.
 
I would not trust a fixed identifier. A checksum is simple and easy to implement, and usually also detects comms errors. If you intend to use the Teensy with e.g. RasPi, with its funky USB implementation, that might be important.

Yes, there's a CRC-library in teensyduino. Is it a Teensy 3.x ?
 
Ok :) That's great, because the CRC library uses the in-built T3 CRC-Hardware and is VERY fast and small in this case.
The donwside of this approach is that it is not too easy to resync if you lost a byte.
Its more easy with a bit more overhead..i.e. header (some 0xff for example ) PLUS crc, or a kind of simple handshake like " A: hey, i want a new packet -> B: ok, here it is"
 
Last edited:
Hi all,
Thanks for the input. Since I have some overhead I think I'll use both the 2 or 3-byte header and 2 bytes for checksum. And yes, t3 = t3.x. While beta testing I've been merely passing ascii values which create a packet ~2x as big as the method I'm building now. So adding a few bytes to ensure that I have a complete packet isn't going to hurt too much.

@Nominal Animal: the 4 bytes for a float is based on the IEEE754 representation of the float using 4 bytes. It's also how I'm getting the data from one of the sensors and works quite well.

Thank you all again,
David
 
Status
Not open for further replies.
Back
Top