XBee Frame Structure
- Kaveet Grewal
The following doc will outline the structure of frames sent between XBees using the Zigbee/Zigbee 3.0 protocol.
When sending data to and from one device to another, it’s always done so in data packets. Traditionally, you’d have to define a protocol, and do a lot of extra work just to get communication set up.
With XBee’s, you have the option of using their API mode. This API mode involves structuring the data packets in a specific way (called a Frame). This means you can accomplish more complex communication without having to define a protocol.
The Structure of an API frame is as follows:
This might look like a lot of random info, so let’s go one by one to see what each thing means:
Start Delimiter: By convention, each frame will start with 0x7E, this essentially tells the XBee that a new frame is coming in.
Length: How many bytes are in the frame. Excluded the start delimiter, length, and checksum.
Frame data is variable and length and can vary. A typical order is as follows:
Frame Type: Shows what type of frame this is (transmitted, received, status)
Common Types: 01 (tx packet), 90 (rx packet), 8B (transmit status)
Frame ID: Each frame has an ID to help keep track of them
64-bit Address: This is the 64-bit address of the other XBee you wish to send data to.
16-bit Address: If it’s ‘FF FE’ then it’ll broadcast
Broadcast Radius: Keep this at 00.
Options: Keep this at 0.
Message: The actual data you want to send, in hexadecimal.
Checksum: Represents the number of bits in a transmission message. This is used to help detect errors.
The checksum is calculated as follows:
1) Sum the bytes in the packet, not including the start delimiter, length, and checksum.
2) Keep the lowest 8-bits of the result (ignore everything else)
3) Subtract that value from 0xFF.