Zigbee 3.0 protocol

Owned by Aaditya Chaudhary
2022-06-27
3 min read

The two major frames we care about are transmit/receive frames and response frames.

Example Transmit Frame:

7E | 00 19 | 10 | 01 | 00 13 A2 00 41 B1 6D 1C | FF FE | 00 | 00 | 53 45 4E 54 20 46 52 4F 4D 20 42 | D1

Breakdown of the message:

  • Start Deliminator: signifies that the message is starting, always use 7E

    • 1 byte

    • 7E

  • Length of message: the number of bytes between length and checksum, not including length and checksum

    • 2 bytes

    • 00 19

  • Frame type: should be 10 for transmit, 90 for receive, and 8B for transmit response (but responses will be covered after transmit frames)

    • 1 byte

    • 10

  • Frame ID: lets you order messages, and associate transmit frames with their appropriate responses. (optional as far as I know, I was able to send out frames with the same IDs one after another

    • 1 byte

    • 01

  • 64 Bit address: for transmit frames, it is the destination, for receive frames its the source

    • 8 bytes

    • 00 13 A2 00 41 B1 6D 1C

  • 16 bit address: use FF FE for this. As far as we can figure that is the default value for when you dont have a 16 bit address, which we don’t.

    • 2 bytes

    • FF FE

  • Broadcast radius: represents the number of hops in a mesh network the message should make before giving up if it cant reach the target. leave it at 00, which means no limit (best guess on this)

    • 1 byte

    • 00

  • Options: leave at 00.

    • 1 byte

    • 00

  • Message: this will contain the data that is actually being sent

    • variable bytes

    • 53 45 4E 54 20 46 52 4F 4D 20 42

  • Checksum: the sum of the bytes between length and checksum, not including length and checksum

    • 1 byte

    • D1

Example response Frame:

7E | 00 07 | 8B | 01 | FF FE | 00 | 00 | 00 | 76

Breakdown of the message:

  • Start Deliminator: signifies that the message is starting, always use 7E

    • 1 byte

    • 7E

  • Length of message: the number of bytes between length and checksum, not including length and checksum

    • 2 bytes

    • 00 19

  • Frame type: should be 10 for transmit, 90 for receive, and 8B for transmit response (but responses will be covered after transmit frames)

    • 1 byte

    • 10

  • Frame ID: lets you order messages, and associate transmit frames with their appropriate responses. (optional as far as I know, I was able to send out frames with the same IDs one after another

    • 1 byte

    • 01

  • 16 bit address: use FF FE for this. As far as we can figure that is the default value for when you dont have a 16 bit address, which we don’t.

    • 2 bytes

    • FF FE

  • TX retry count: the number of times the message was resent

    • 1 byte

    • 00

  • Delivery Status: 00 for success, anything else is failure

    • 1 byte

    • 00

  • Discovery status: 00 for success, 25 means root not found, which as far as I can figure, means that the destination wasnt found

    • 1 byte

    • 00

  • Checksum: the sum of the bytes between length and checksum, not including length and checksum

    • 1 byte

    • 76

How do the two frame types work together?

To receive a message, it’s simple. You receive a receive frame (which has the same basic structure as a transmit frame) that you can decode and use.

To send a message, you must first construct a transmit frame, send it to the Xbee. Then listen for transmit response to ensure that the packet was sent properly.