Xbee-pro API mode ACK

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.

D.

Dasman,
It sounds like what you are really asking is:
-what is the turn around time (from transmission to ACK receival) of my transmission?

This is going to vary on a case by case basis with a variety of factors: noisy network, message sizes, etc.

Also, the zigbee protocol by default will resend any message not ACK’d up to 3 times. This can be changed by increasing the RR value.

Hi

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:

7E 00 10 00 2D 00 7D 33 A2 00 40 31 20 E8 00 74 65 73 74 00 E4

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?

@gkarv1976

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

Original 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?

excuse me, i want to ask
how to process only data,data ony wihtout print the ack in xbee s2???

First off, the packet 7E 00 10 00 2D 00 7D 33 A2 00 40 31 20 E8 00 74 65 73 74 00 E4 is invalid. The length byte should be 11 instead of 10.

As for not sending an ACK. There are two ways. First, leave the Frame ID 00, the second is to set the Options bit to 01.

where i will find the frame id or option bit set?? in xctu?
i used software serial and i set the baudrate 9600,
thankz

You are not going to find that information out in XCTU. You need to look in the product manual for that kind of data.

do you know how to get the transmit status using java digig xbee api? if you do, please tell me how to.