Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

Zigbee Protocol

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.

What has been done to get the Xbees working?

...

XCTU

  1. XCTU is software that we can use to configure and run the xbees. We first used this software to send some test frames using the zigbee 3.0 protocol.

...

Logic Analyzer

  1. We used a logic analyzer to read the signals being sent to and from the XCTUsoftware. This is how we know how the zigbee protocol works and what needs to be sent/recieved from the xbees. The xbees are actually quit simple. They use UART to communicate with XCTU/Arduinio/STM32. And they have an easy to follow protocol for constructing frames.

  2. The difficulty with the xbees is the lack of documentation when it comes to the frames. This is where the logic analyzer was useful. We know how to construct frames for transmitting data and how to decode frames for transmit status and receiving data. XCTU also describes how to construct frames, using their frame builder software.

Ardunio

...

Overview

<not written yet>

<comms is kinda cringe sometimes 😕>

Inventory

Name

Address

Freq

Antenna

range (LOS)

range (urban)

data rate

Xbee Pro S3B

0013A20040B47E80

928 MHz

dipole

14 km

610 m

160 kbps

Xbee Pro S1

0013A20040B0EC97

2.4 GHz

dipole

x

x

Xbee Pro s1

0013a20040b0ec69

2.4 GHz

dipole

x

x

xbee pro s3b

0013a20040b47e6b

928 MHz

dipole

14 km

610 m

160 kbps

xbee pro s3b

0013a20040e47deb

928 MHz

dipole

14 km

610 m

160 kbps

xbee pro 900

0013a20040674c02

900 MHz

integrated wire

x

x

156 kbps

xbee pro s3b

0013a20040e501f1

928 MHz

dipole

14 km

610 m

160 kbps

xbee pro s3b

0013a20040e501e1

928 MHz

dipole

14 km

610 m

160 kbps

xbee pro 900

0013a20040789b2b

900 MHz

dipole

14 km

610 m

156 kbps

xbee s2c

0013a20041c0f315

2.4 GHz

small antenna

90 m

30 m

xbee s2c

0013a20041c0f209

2.4 GHz

small antenna

90 m

30 m

We also have 5 uart to usb xbee boards, and 3 dipole antennas.