Doubts on Implementing a Simple Protocol for XBee Comms

A system that I'm developing will use XBee modules for a point to point connection between a micro-controller and a PC. Data will only be sent only in one direction -Micro to PC and at 10-20fps. The data portion of each frame will be 4 Bytes. XBee modules will be run in transparent mode(to begin with at least). On the PC side I'm using python to grab the data from the serial port.

Initially I wrote a very simple python program to grab data 4 Bytes at a time from the serial Port, which worked fine when tested with a virtual com connection (I haven't run any real world tests yet though), but I decided to experiment and ended up implementing a simple frame structure like this.

sync_flag | Payload_length | frame_number | payload


After some research I discovered HDLC and now I'm considering implementing something similar albeit simpler. Before I endeavor to do so Id like to hear what others have to say.

When is such a protocol merited?

What have you done when you implemented your XBee networks?

Being somewhat new to this area I'm sure there's some relevant specifics Iv left out, but at the same time I didn't want to make the question too narrow / system specific, but if necessary Ill update the question.

• To test your data format you can simulate what radio will do to it. Drop random bytes and flip random bits. By doing this, you should be able to test your sync and checksum systems – Toby Jaffey Oct 31 '10 at 0:53

I'm going to be using Xbee modules. I'll be trying to use a point to multipoint network.

At the moment, I plan to have a transmitter identifier, payload type, payload length, payload and checksum - it would look something like this:

Field            Type    Description
transmitter_id   uint8   Identifies the transmitting module (0-255)
type             uint8   Type of data (GPS coordinates, hit status, etc.)
length           uint8   Length of payload in bytes
checksum         uint16  CRC16 of everything before


That's how I imagine it, the format might change but this will be the basic protocol in use.

• Thanks this the type of info Im looking for. How will you identify the start of the frame? – volting Oct 30 '10 at 12:12
• Probably use some sequence like 0xff 0x00 0xff 0x00, or, I could use only a serial interface (Xbees transmit up to 8-bit parallel) and have a wire to specify when a radio is talking. – Thomas O Oct 30 '10 at 12:18

When you come out of transparent mode, I assume that the XBee exposes the payload of 802.15.4 frames to your application. However, it's possible that your data will be packed into a ZigBee APS/NWK frame too.

(source: freaklabs.org)

Data is sent in packets - so there is no need for a sync header

There is already a 2 byte checksum field (FCS) - so there is no need to add your own

The maximum allowed payload size will be less than 128 bytes

Frame delivery and reception are unreliable

The XBee API may allow you to read the sequence numbers from the underlying packets. If not, you will need an incrementing sequence number and a retry mechanism.

• Thanks, some useful points if I end up using the API mode. – volting Oct 31 '10 at 23:09

My situation is a bit more complex (Home Automation system), so this might be an overkill for you, but I've decided to go with Binary JSON-based protocol. It's flexible, extensible and really easy to implement.