I am building a sensor network. Remotes are battery powered so it makes sense to let the xbee(series 2) module sleep when no data needs to be send. My question is:how do I know whether an xbee module is ready to take data when I wake it up from sleep using the sleep_rq pin?
When I started off, I tried to write data into xbee module right after waking it up, it didn’t work at all. Then I tried to monitor the LED assiciation pin and waited two lowering edge, and it didn’t work well either. So I am kind of out of ideas. Right now I am using the method described in the following to get around: http://www.guiduc.org/wp/trouble-with-xbee-serie-2-sleep-mode/
I changed the SN and SP in parent module to long enough and also wait 2 second after I wake xbee module up before I send data to it. So it kind of works now. The issue is, waiting 2 second may sound not a big deal, but for a system designed to run on batteries for years, 2 more second of 50mA draw is actually real waste of power juice.
So will anyone please tell me how to avoid this waiting period?
Setting D7=1 will enable CTS flow control. With CTS enabled the radio will raise the CTS line (pin 12) whenever the radio is ready to receive data. This way you can just stream all of your data into the radio as soon as the radios UART is ready.
CTS will also go low if the radio has a full buffer you can use this to prevent buffer overruns on the radio.
Hi, Jeremy,
I think I am still having a little problem here. if I put the following pseudo code into the mcu that interfaces xbee:
while (1)
{
sleep_rq = LOW;//wake up xbee
while(CTS == high); // wait til CTS pin low
//send ascii 32 ~ 126 to base through xbee
for ( char i = 32; i < 127; i++)
{
while ((mcu_uart_buffer not ready)||(CTS == low)); // wait til mcu uart buffer is ready and xbee is ready to take data
send i to xbee through uart;
}
sleep_rq = high;// send xbee into sleep
mcu_sleep(60seconds);
}
On the receiving end of xbee, the message is always fragmentized. when the remote first powers up, 84 letters will be received by base in the first data burst. The remaining 11 letters will be received by the base in the following data burst.
I feel this must have something to do with RF packet size, but could not really figure out a solution.
Query the NP command. It will tell you how many bytes will fit in a single packet. There are a few things that can change this value so I would check page 63 of the manual http://ftp1.digi.com/support/documentation/90000976_M.pdf