UART After Sleep in an XBee ZB S2C Module

[CHSH]

First, the configuration. I’m using a Xbee ZB S2C SMT module and have it talking back to an X2e coordinator. On the module, the following are set:
SM = 0x5 (SM5, Cyclic with Pin Wake)
SP = 0x32 (50 x 10ms = 500ms)
ST = 0xBB8 (3000ms)
D6 = 0x1 (RTS Enabled)
D7 = 0x1 (CTS Enabled)
Other settings for baud rate, guard time, and zigbee network configuration are all working when sleep is disabled, so I don’t think they should be an issue.

On the coordinator I set:
SP = 0x32 (50 x 10ms = 500ms)
ST = 0xBB8 (3000ms)
All other setting left at factory default.

Upon powering up the Xbee module and the micro controller that drives it via UART, the micro controller is able to configure all the Xbee module settings, and any communication within ST (3s) functions normally. After 3s have elapsed, power consumption drops dramatically, and CTS is pulled high with a brief dip every 500ms (as expected).

After initialization, the micro controller is also sleep skipping along and holding the RTS line high unless it is currently awake and monitoring the UART port. If I set the monitoring time (RTS pulled low) to be really long (100ms) it seems to work most of the time, but if I shorten the monitoring timeout to 50ms I encounter a problem with almost every transmission.

I’ve included a link to an image of a session where there is both a successful transmission and a failed transmission were captured. It seems the common element is that if RTS is low at the time the Xbee module wakes up and retrieves the data, transmission occurs as expected, but if RTS is high at that time the Xbee module just holds the data indefinitely (regardless of future changes to the RTS line).

(click if the image is clipped for the full image)

I think that the Xbee module is getting the traffic because after transmission the CTS line is held constantly low, and power consumption spikes considerably, the Xbee module just doesn’t transmit the data in it’s buffer over UART on the next RTS low pulse as I would expect. Any help is greatly appreciated.

Thanks,
Jeremy

[mvut]

That is because the radio is in a sleep state. You need to connect the Pin sleep function to your processor and if CTS is not active on the radio, you need to trigger the Pin sleep pin. Then when CTS changes states, send the data.

[MikeN]

There are a couple of things that are happening in this scenario actually. One, there is a bug. Once RTS deasserts, it holds messages now in the transmit buffer. Once RTS asserts again, the transmit buffer doesn’t automatically flush like you might expect when you re-assert RTS. One way to work around this is to have the application flush the transmit buff, but that either means transmitting, or keeping the module awake longer than you want to.

The second thing that happens can only be seen in using API mode on the end device, (or an RF sniffer to see what is happening). That is, that during the period of time that the module is stuck in its awake sequence, but the data isn’t coming out the UART as expected, the module has propbably disassociated from its parent. The default [PO] command is for the end device to poll its parent once every 100ms. When an end device hasn’t heard a response to its polls after three times, the end device will assume that the parent device has left, and the end device will leave the network and attempt to rejoin. While the end device is awake, and the RTS is deasserted, it has that data sitting in its tx buffer, which hasn’t been cleared, and in there are also sitting responses to its polls. Since it never received the responses, somewhere in there, it may have left the network and not told anybody…

That is you found a bug which is rumored to be fixed in the next release…