Xbee in Api Mode Randomly Fails to Respond with TransmitStatus Frame

XBee & XBee Gateway XBee - 802.15.4
,
1

Hi I am using xbee3 to communicate to a network that has one coordinator and 6 end devices. I am using HW Flow Control for UART on the coordinator side, but not on the end device side.I am using an stm32f413 on a custom PCB to communicate to the xbees. I am having an issue where after thousands of successful transmissions the xbee fails to respond with the expected Extended Transmit Status Frame.

I couldn’t attach the xbee profiles, so I have listed the changed settings below:

Xbee Firmware:
Product Family = XB3-24
Function Set = Digi Xbee3 802.15.4
Firmware Version = 2012 (Newest)

If the setting isn’t listed below it is set to the default value for the Function Set.

Coordinator:
CH = 1A
ID = 1111
CE = Coordinator [1]
MY = FFFF
PL = Lowest [0]
AP = API mode Without Escapes [1]
AO = API Rx Indicator - 0x90 [0]
BD = 23040 [8]
DIO6/RTS Configuration = RTS flow control [1]
DIO7/CTS Configuration = CTS flow control [1]

End Device (same for all 6):
CH = 1A
ID = 1111
CE = End Device [0]
MY = FFFF
PL = Lowest [0]
AP = API mode Without Escapes [1]
AO = API Rx Indicator - 0x90 [0]
BD = 115200 [7]
DIO6/RTS Configuration = Disable [0]
DIO7/CTS Configuration = CTS flow control [1]
DIO8/DTR/Sleep_Rq Configuration = Disabled [0]

The xbees are configured to run in API mode and I am using the Transmit Request (0x10) Frame Type to send data between coordinator and end devices. I read back the Extended Transmit Status (0x8B) from the coordinator to ensure the message sent as expected. If I don’t get the expected Extended Transmit Status Frame within 100 ms, I try again. If this fails 3 times in a row I flag an error and my application stops.

For the most part this has been working as expected, but randomly I will fail to get the Extended Transmit Status frame back from the coordinator xbee over UART even after attempting to send 3 times. This seems to happen randomly during my application, for example the last time it was seen was after 10,632 successful transmissions, that were all met with the expected Extended Transmit Status response.

Looking at the UART reception, when this happens there is no sign of any received data, even malformed as I originally thought maybe it was due to noise on the bus, but no data was received after the TransmitRequest made it out.

I’m wondering if there is anything I can do to debug the health of the xbee firmware when this happening, maybe resetting the module would fix the issue, but I’m not sure if our application can wait for the module to reset in this circumstance. Any advice is helpful!

2

Also, I am always setting the Frame ID field of the outgoing Transmit Request Frame equal to 1.

3

I would suggest double checking the API frame that fails to ensure it is a valid frame.

Try using API mode 2. Doing so would allow the module to disregard a malformed packet when a new packet is received.

I would also suggest trying to simply read an AT command to see if you can talk to the module.

4

Thanks for the response! I’ll try your suggestions and get back to this thread!

5

Perhaps the xbee has locked-up. Can you make a serial connection with XCTU? Can you discover the device from a local node that is connected to XCTU?

6

Matthew, It is not highly likely that the radio is locked up. The higher likely hood is that a incorrect API packet was fed into the radio which will then mess up any following API frames.

7

Sure, but he didn’t say whether once he lost comm’s that he was able to reestablish them.

8

With API mode 1, you would not be able to. You would need to trigger a reset to be able to. The other option is to use API mode 2. This way, the module will auto start on a new frame if a 7E is received that is not escaped.

9

Really? I would have expected that the Xbee time out and clear its buffer if a frame wasn’t received within the anticipated time frame. At my end, I start a timer when I receive the start byte, and if the frame hasn’t finished in 100ms I scrap it.

I can’t believe that the xbee doesn’t do something similar.

10

So, I tried it. I sent an incomplete frame, waited, and then sent a new complete frame. The second frame didn’t receive a reply, Xbee considered it the tail end of the first. But, sending another complete frame did receive a response.

I can see how you could get into trouble if you continually sent frames with a start byte in the data.

11

No it does not do that.

This possibility is just one for why you would want to use API mode 2 instead.

12

I have implemented Xbee API Mode 2 with the escaped characters in my application. It is successfully receiving Receive Packet frames from the xbee and it is transmitting as expected (the coordinator xbee is receiving a response from the end device), how ever the end device xbee doesn’t seem to be responding with the TransmitStatus frame as it was before. Is there any special handling with that frame as a result of API Mode 2?

13

True! Interestingly, tech support told me that all their firmware testing is done in API1. I initially used API2, but I have problems with successive Digimesh releases locking up, I changed to API1 but it hasn’t made any difference. I will definitely revert to API2, when I get a reliable release.

15

ryanprescott Huntnation does not work for Digi.

From the sounds of it, it has to do with the API frame you are sending as to why you are not seeing a status frame. Perhaps you can post your API frame to me and I will take a look at it for you. I suspect it is either being sent to the broadcast address or you are setting the frame ID to 0.

16

It was actually due to a bug in my receiving code, it happened to be working for the ReceivePacket frame but not for the TransmitStatus, the outgoing TransmitRequest frames were correct, anyways its working now.

Running some tests to see if the Escaped Characters mode will fix the situation I first described in the post, thanks for your help!

17

I found many answers to my development on this topic, I appreciate the quality of information involved and technical diligence. :face_with_monocle:
2024-05-24T18:35:00Z