Hi,
I was wondering what is the expected delay for receiving a transmit status in api mode?. I am using Xbee pro series 1.
I need to check if the message frame I just sent to the module from the Microcontroller needs to be resent. For that I have to get the transmit status message from the module. But I feel it is taking too long to send back a transmit status.
I do not know if I should be posting my problem in this thread, but I haven 't found any appropriate place and help is needed…
I have two xbee pro modules, both configured in api mode 2. First one is coordinator (connected to pc using devel board) and second one is end device. I am trying to send a small amount of data (for testing) from coordinator to end device using a TX api frame (64 bit address). Here is my frame:
The above frame is passed to coordinator from pc using x-ctu. However I do not get any response to my frame (not even one indicating that something is wrong with the transmition). The frame is silently droped.
Note: I am able to send other simple commands to the module from xctu (like Hardware Version e.t.c.)
Is something wrong with the frame that I am sending? Any ideas on something else that could be wrong?
You might have done better to start a new thread, but let’s not worry about that.
It’s a valid packet - here’s the transcript from running it through packet-check.
[john@eccles ~]$ packet-check -api2
API Packet analyzer version 1.2 for XBees (802.15.4, DigiMesh, ZNet, ZB)
Escape characters enabled (AP=2)
Note: if it prompts for more bytes and you’re done, hit return
Enter packet: 7E 00 10 00 2D 00 7D 33 A2 00 40 31 20 E8 00 74 65 73 74 00 E4
Unescaped packet: 7E 00 10 00 2D 00 13 A2 00 40 31 20 E8 00 74 65 73 74 00 E4
7E // Correct packet header byte
00 10 // payload length (decimal 16)
00 // Packet type: TX request with 64-bit address
// Valid for 802.15.4
2D // frame id: non-zero so response packet expected
00 13 A2 00 40 31 20 E8 // 64-bit destination address
00 // TX options
// TX data (5 bytes) [1]
74 // transmitted data ‘t’
65 // transmitted data ‘e’
73 // transmitted data ‘s’
74 // transmitted data ‘t’
00 // transmitted data NUL
E4 // checksum - correct
Notes:
[1] Max 100 bytes on 802.15.4, or 72 on DigiMesh or ZNet2.5
So that tells us that it’s not the packet at fault. Whatever’s connected to the end device should be receiving the corresponding RX Data packet, and X-CTU should be receiving a TX status packet.
Given that you can send other commands I don’t know what the cause of this would be, so I’ll fall back on the standard question in such cases: what firmware version are you running on the XBees?