Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 4 Next »

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.

Good steps when debugging Comms

  1. use an oscilloscope to read the uart signals on the sending and receiving end. You want to ensure that there is a good signal going to the sender, a good response (no error codes) from the sender to the stm32, and then the receiver sees the message.

  2. use breakpoints and figure out what your raw message looks like. Compare with this guide to ensure that its in order. Check the length value and the checksum value. IF THE CHECKSUM IS WRONG YOU WONT SEE ANYTHING ON THE RECEIVER SIDE. Use the XCTU frame builder and recreate your message, itll calculate a length and checksum for you, to compare with the actual frame being sent (if there is something wrong with your frame this will expose that).

What has been done to get the Xbees working?

  1. 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.

  2. 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.

  3. Ardunio

    1. We got the xbees to work with an ardunio! One Xbee was plugged into a computer, listening for data, the other was wired to an ardunio. We then sent a transmit request to the Xbee from the ardunio! The xbee that was connected to the computer, recieved the message.

  • No labels