I’m using a coordinator and a router to study how xbee APIs and packet work but i’m having some problems to understand how to read the received data.
I’m using xbee pro: XBP24BZ7WIT-004J-revE
I’m trying to send an integer “333” from my router to my coordinator and on my coordinator i receive this (i’m not able where I should have to read the 333 value):
packet not acknowledged
checksum is 25
packet length is 33
payload [0] is 7E
payload [1] is 0
payload [2] is 10
payload [3] is 10
payload [4] is 1
payload [5] is 0
payload [6] is 7D
payload [7] is 33
payload [8] is A2
payload [9] is 0
payload [10] is 40
payload [11] is 3E
payload [12] is F
payload [13] is 30
payload [14] is FF
payload [15] is FE
payload [16] is 0
payload [17] is 0
payload [18] is 1
payload [19] is 4D
payload [20] is 31
frame data [0] is 0
frame data [1] is 13
frame data [2] is A2
frame data [3] is 0
frame data [4] is 40
frame data [5] is 8C
frame data [6] is 64
frame data [7] is C8
frame data [8] is 41
frame data [9] is 30
frame data [10] is 2
frame data [11] is 7E
frame data [12] is 0
frame data [13] is 10
frame data [14] is 10
frame data [15] is 1
frame data [16] is 0
frame data [17] is 7D
frame data [18] is 33
frame data [19] is A2
frame data [20] is 0
frame data [21] is 40
frame data [22] is 3E
frame data [23] is F
frame data [24] is 30
frame data [25] is FF
frame data [26] is FE
frame data [27] is 0
frame data [28] is 0
frame data [29] is 1
frame data [30] is 4D
frame data [31] is 31
Every valid XBee frame starts with 7E (1 byte),
following by the length of the frame (2 bytes)
and a Frame Type ID (1 byte):
payload [0] is 7E // Starting point
payload [1] is 0 // Length
payload [2] is 10 // Length
payload [3] is 10 // Frame Type ID (ZigBee Transmit Request, page ~100)
The rest of your bytes seems messed up a bit. It doesn’t match exactly with the documentation. Are you sure you read the bytes sorted correctly?
E.g: This is the recepient’s 64-bit address. But this should placed after payload[4].
frame data [0] is 0
frame data [1] is 13
frame data [2] is A2
frame data [3] is 0
frame data [4] is 40
frame data [5] is 8C
frame data [6] is 64
frame data [7] is C8
frame data [8] is 41
I thinks the format is very well explained in the manual.
The format is explained in the datasheet, but i’m a little bit confused when i try to compare what is written in the datasheet with what I receive with my Xbee module.
As you specified with your previous answer, my frame is a little bit strange: do you think it can be normal under particular conditions or are there any problems with my connection?
I would suggest, that you try your XBee connection in transparent mode / AT Firmware. Sending some characters like “ABC”. To confirm that your conncetion ist correct.
If the characters were received correctly on the other side, I would say, your connection is OK.
Yes, you mean that if it works, I have to not worry about the packet format
At the moment, I have the coordinator configured as COORDINATOR WITH API and the router configured as ROUTER WITH AT MODE.
I try to send some integer values and character from the router to the coordinator and I’m able to read them without problems.
Next step, is to add 99 more routers (configured as ROUTER AT) and let them send messages to my coordinator (configured as COORDINATOR API).
With this network configuration, I’d like to receive the transmitted values and also the address for each router: do you think is it possible?
In this way, I can locate the router which has sent the value since each value is associated to the sender address.
If you send your characters and integers from a Router (AT Firmware) to a Coordinator (API Firmware), then your receiving Coordinator should send a ZigBee Receive Packet (0x90) packet out of it’s UART to your MCU.
This packet contains the character/integer and the senders address, etc.
