TX Example leads to: "local XBee did not provide a timely TX Status Response -- should not happen"

[GoogleCodeExporter]

I have spent some time now on trying to get the TX example to work. 
Unfortunately everytime I run into this error according to my led:  // local 
XBee did not provide a timely TX Status Response -- should not happen

I have a series 1 Xbee mounted to the libelium XBee shield; and have tried AP=1 
and AP=2 modes.

Any suggestions on what might be the cause of this?

Original issue reported on code.google.com by E.Marges on 7 Sep 2010 at 10:42

[GoogleCodeExporter]

I'm having this exactly same problem...

Tomorrow I'll plug an LCD display to see what my xbee is receiving because it's 
not a TX_STATUS package.

Original comment by wsart...@gmail.com on 13 Mar 2011 at 6:34

[GoogleCodeExporter]

it's not a defect, it's a documentation and error on example code. You HAVE to 
set frame_id > 0 or you don't receive an ACK from receiver.

Original comment by wsart...@gmail.com on 13 Mar 2011 at 8:58

[GoogleCodeExporter]

Tx16Request defaults to frame id  1 (#define DEFAULT_FRAME_ID 1), which sends 
an ACK, so this would never occur unless you explicitly set the frame id to 0.

Original comment by andrew.rapp@gmail.com on 3 Apr 2011 at 2:35

• Changed state: Invalid

[GoogleCodeExporter]

I am experiencing the same problem.  I am using the Series 2 xbee modules (ZNET 
2.5 coordinator and end points in API mode).  The packets (sent by the end 
point) are received by the coordinator but the coordinator does not send an 
ACK.  I have not explicitly set the frame ID, I went through all of my code and 
your code and see that what you have mentioned above is in fact correct (about 
the defined DEFAULT_FRAME_ID 1).

I also went barebones back to your example and the packet sent by the end point 
is this:

7E 00 24 95 00 7D 33 A2 00 40 2C 7C E1 00 01 02 00 01 00 7D 33 A2 00 40 2C 7C 
E1 4E 4F 44 45 31 00 00 00 02 03 C1 05 10 1E 1A 

Indeed the 5th byte is 00, which is the frame ID.  There is definitely a bug 
here.

Original comment by kademil...@gmail.com on 23 May 2011 at 11:51

[GoogleCodeExporter]

I have now tried to hard program the frameID into XBeeRequest as follows, but I 
still get the frameId as 00?

XBeeRequest::XBeeRequest(uint8_t apiId, uint8_t frameId) {
    _apiId = apiId;
    _frameId = 1;
}

I have now reverted this change, so would appreciate knowing what the 
documentation error might be?  I really need this to work for me.

Cheers guys.

Original comment by kademil...@gmail.com on 23 May 2011 at 12:06

[GoogleCodeExporter]

There are a couple issues here.  First, this issue concerns Series 1.  The 
series 1 code won't work for series 2.  Second issue, the packet you provided 
is API ID 0x95 (4th byte).  This is ZNET_IO_NODE_IDENTIFIER_RESPONSE, so not a 
TX request.

Original comment by andrew.rapp@gmail.com on 23 May 2011 at 1:31

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

Delving further into it and realising my error, I looked at the UART on the TX 
and it is in fact correct:
7E 00 10 10 01 00 00 00 00 00 00 00 00 FF FE 00 00 06 06 E5 

which is a TX request to the Coordinator (0x00000000, 0x00000000) (FFFE) with 
FrameID = 1 (ACK requested)

The UART at the RX end outputs the RX PACKET:
7E 00 0E 90 00 7D 33 A2 00 40 2C 7C E1 33 A5 01 06 06 0C 

which looks correct and suggests that it has sent the ack (01 before the 06 06 
payload).

The problem is that the end point times out waiting for the response from the 
Coordinator (UART is silent), no matter how long I set the ReadPacket timeout.  
 Is there a setting somewhere that I needed to enable/disable to get this ACK?  
Is it possible that I have a hardware problem?  

I couldn't find any hint in the digi manual as the ACK should be at the MAC 
level. Am now completely lost.

I very much appreciate your help and hard work.

Original comment by kademil...@gmail.com on 24 May 2011 at 4:40

[GoogleCodeExporter]

I am experiencing very similar problems.
The two XBee v2 modules communicate and data is flowing from tx to the remote 
rx modules. The communication on the transmitter side when viewed on the UART 
is:
7E 00 29 10 01 ...
And on the the recieving side:
7E 00 29 90 00 ...
According to the documentation if frameID is 1 then ACK should be sent, but 
none recieved. I increased the timeout from 500 in the sample code to 2000 with 
no success. Is there anything need to be done in order to get the ACK back?

Original comment by zmash...@gmail.com on 7 Sep 2011 at 11:02