XBee Series 2 module enter undefined state/freeze

XBee & XBee Gateway XBee - Zigbee
, , , ,
1

I have serveral XBee modules in a low power sensor design based on the following setup:

XBEE hardware version: 0x1944
XBee firmware: 0x288c (sleeping end-node, AT mode)
SM: 5
SO: 0
SP: 500*10mS
ST: 300mS
SN: 10 (typical)
D7=1 (CTS)

The XBee is conneted to an Arduino Fio as host controller.
The operation is based on the following principle:
Both the Arduino controller and Xbee are in sleep mode. The arduino is wake up by
the On-signal from the XBee at regular intervals (controlled by the SN*SP time)
When the arduino wakes,it starts its data collection routine and, when finished, asserts the DTR (pin 9) to wake the XBee,
When the arduino receives the CTS signal from the XBee, the serial data is sent to the XBee for transmission inn the XBee Radio network.

This seems to work fine for longer periods of time, but after a day or tree, the XBee seems to enter an undefined state.
The XBee can no longer be discovered on the network.

The only way to recover is to cycle power or send a hw-reset to the XBee.

I suspect that this problem is related to receive-buffer overflow. A similar issue is described on stackoverflow

I admit that my serial line CTS handshake can be improved, but my main concern is if a serial buffer overflow can lead to a crash of the Xbee controller.
Is there a better way to do this or is it some kind of workaroud to improve the reliabilty?

2

What are you using to power the XBee module? When this occurs, what is the last frame you have issued to the radio?

3

The XBee, and the arduino host controller is supplied from a 3.6v litium battery.
The host controller is at a rate of typically a few minutes, sending a short data message at a nmea like format. Eg. $DHT,12.33,40.0,*

I do not know what kind of situation that is leading to a lock of the XBee but I should really like to know.

4

Problem solved…

As I suspected a serial buffer overflow problem, I tried to improve my CTS handshake but without any success, the XBee still got stucked after some days of running.

After further searching for any solution at the internet forums, I found some interesting statements in
http://www.digi.com/support/kbase/kbaseresultdetl?id=2193

The SP of the Coordinator must be greater than or equal to the SP of the longest sleeping remote. The ST of the Coordinator must be less than or equal to the ST of the longest sleeping remote.

I was aware of the contstraint related to the SP, but the second statement regarding the ST seems strange to me. I could not access the ST parameter for the
Coordinator.
However, I tried to increase the ST time for my sleeping end nodes to default settings. After implementing this change, I have not got any issue with freezing end nodes.