The newer Series 1 Rev B XBees are supposed to be 100% compatible with Rev A. I have found that cyclic sleep on Rev B does not work the same as on Rev A. I have not had heard back from Digi support on my questions about this, so I thought I’d post my findings here and see if there are others that can help.
In cyclic sleep mode (SM=4) the remote XBee wakes up periodically and polls for the coordinator. This process continues indefinately. At least, this is how Rev A hardware works. On Rev B hardware, it initially works this way, but after a random time of a few seconds to a few hours, the XBee stops sending polls and its processor appears to be hung. You need to do a reset or power cycle to get the module to respond.
Here’s the setup for seeing this:
Take a Rev B module (says “revB” on the white label in back) and set it to defaults with the Digi USB programmer (read the module, click Show Defaults, Write)
Change SM to 4 and SP to 2. Write the settings. Reset or power-cycle the module.
The red Associate LED on the USB programming board should flicker quickly. This is normal - it does this whenever it wakes up in Cyclic Sleep.
Within a few minutes, the red LED will flash more slowly. At this point the module is unresponsive and no further RF or serial communications are possible without a reset or power cycle.
Other observations:
Either firmware 1.084 or 1.0A5 on Rev B will do this.
No coordinator is needed to see this effect.
The problem does not occur in non-sleep mode (SM=0)
If the radio is sent data often enough that it does not sleep, the problem will not occur.
SP can be set to any value but smaller values make the problem happen more quickly. At SP=2, it usually takes a few minutes to fail. At SP=1000, it usually takes hours to fail.
I have not yet discovered any combination of other settings that will prevent the end device from eventually locking up.
If you sniff the RF signal, you will see the polls go away at the same instant that the red LED stops flickering quickly.
I have tested 3 Rev B units from 2 batches - same results.
So, my question is :
Has anyone else gotten cyclic sleep to work reliably on Rev B?
An update:
It took 3 emails and 3 weeks to get any response from Digi support on this. Their response was to say that they had replicated my observations and confirmed it to be a bug. They said that they would get back to me with a “some kind of time table for a resolution” [their words]. Based on this, I would not expect that the newly released firmware (dated December 2007) will help. In the mean time, I have had to ship product, so I have reprogrammed all new units to not use cyclic sleep, with the corresponding increase in power consumption. I am now frantically working on designing XBee’s out of the product, which I suspect will happen more quickly than a resolution from Digi, so it may be a moot issue for me going forward.
You may have found a bug, since both 1084 or 10A5 would be the earliest firmware versions compatible with the rev. B chip.
Since this may be a bug but there’s a newer firmware version available in 10C8, I’m curious if any testing has been done with that firmware revision, i.e. if the bug has already been fixed.
An upgrade to 10C8 will fix this.
Upon further extended testing the bug was also reproduced on the XBIB-R interface board. The fix was implemented in version 10C6 but was unintentionally left off of Digi’s online release documentation. 10C8 will work regardless of the Digi interface board.
I’m running firmware 10c8, and I have a couple of XBees on a breadboard so I thought I’d try this. I set SM=4 and SP=2, after attaching a LED to the Assoc line. The LED flickered away for 18 minutes before flashing more slowly (a bit faster than 1Hz). But the module still responds to commands. And yes, it’s a Rev-B. Ordinary XBee, not Pro.
Before it started flashing more slowly, I’d been testing its responsivensss by reading the state of the DIO1 line (D1 command). Here’s where I admit I should have been paying more attention, but to vary the experiment I set DIO1 to be an output HI, and I think that could be what triggered the slower flashing. Or it could be coincidence.
There’s no serial connection to this XBee: I used remote AT API commands for the settings.
My conclusion: the change of flashing rate seems strange, but the fact that the module remains responsive to commands suggests that the firmware is acting differently to the original report. Also I can imagine that the change of flashing rate may indicate a deliberate piece of design, in that if the module doesn’t find a coordinator within a certain time period it slows down its rate of requests. But that’s just conjecture on my part.
I’d suggest to the OP that it’d be good to update an XBee to 10c8 and see how it behaves in your setup. I imagine the support team will be happier to get queries based on the latest firmware as opposed to older versions where bugs may already have been fixed. (Can you guess I used to run a software support team?
This thread has worrying implications: would it be possible to get a bit of clarification?
The Original Poster found the problem on older versions of the firmware, and the OP says that Digi support replicated the problem.
I tried the experiment on a newer version of firmware (see my earlier post), and failed to replicate the problem.
Does that mean:
a) Digi support replicated the problem on only the older versions quoted by the OP, or
b) Digi support did replicate the problem on the most recently released firmware version, implying (perfectly possible) that my attempt at replication was flawed?
In the latter case, the problem is clearly unfixed. In the former case, a firmware upgrade could perhaps cure it.
I think posterity might be grateful for an informed answer here. I know that I personally would be grateful, because the ability to use cyclic sleep is an important future part of my own project.
From testing so far, it looks like there is no specific sleep issue with the module itself, but with the USB interface board and it’s ability to handle the sleep mode of the Rev B module. To this point the bug cannot be replicated using the module outside of the USB interface. This may explain your inability to re-create it.
Thanks Jay - that’s a helpful response. I’ll keep watching this thread. I was using the serial board for the experiment, so your explanation is consistent with my experience.
