After reviving an XBee..

Hello,

I was just able to revive a broken XBee module but now I’m experiencing other ‘random features’ where I might need some help. What made me say broken? I was neither able to change the paramters/values of this one, nor read the parameters properly, using XCTU. After contacting the support, the technician has referred me to this page (I am using an XBee ZB S2). Unfortunately, nothing had worked at first, but now is the module running again. What did I do? I have no idea…somehow I’ve managed it to revive the module just by playing with the baud rates, (manual) resets and the Write-Button in XCTU.

Why the prologue? Just for you as background information for what happend before.

My actual problem is that I’m not sure, if the XBee is really working properly as it should now. I’ve created a testbed with three XBees. One Coordinator, two routers. So far I was able to establish a connection between these three devices. I also rotated the roles to ensure that everything is really working. However, the revived XBee seems to have a consequential damage or sth. like that. I noticed it while checking the Channel-Parameter (CH). While the two devices are in channel X for example, the other one remains in channel Y. But its still possible to communicate with the other modules. The operating PAN-ID (OI) is the same, only the CH parameter always differs from the other modules. After a deeper investigation, I was able to find a pattern. When using higher channels like 0x16, the operating channel is always decreased by 7, according to the (still broken?) XBee. For example, when using 0x16, the XBee is only in channel (0x16 - 0x07 =) 0x0F. In general, the lowest possible channel is 0x0B. So what happens when I go down to other channels like 0x0C? An overflow cant occur, so I decided to test these cases as well. The result was amazing:

Real channel (-> Displayed channel)
0x0B (-> 0x10)
0x0C (-> 0x11)
0x0D (-> 0x12)
0x0E…0x12 (-> n/a)
0x13…0x1A (-> channel - 7)

Hence, the displayed channels like 0x11 is used twice: For 0x0C and for 0x18 for example.

Another interesting point is the SC (Scan Channels) parameter. There I’ve got the same offsets. If I tell the coordinator only using channel 0x16 (-> 0x800 for the mask), I have to tell the XBee to use channel 0x0F (-> 0x10 for the mask). Otherwise I’m not able to establish a connection. The XBee probably really thinks that another channel is used.

So, finally…here are my questions:

-Does anybody experienced the same behavior? Independent of the fact that my XBee was dead.

-Is this probably a consequential damage? (Repairable?)

-Ideas? Comments?

Last but not least:

-Yes, I checked and doublechecked the baud-rates, the api-modes and all other parameters whether they’re set correctly on each device.

-I use XBee Series 2 modules

-In the current testbed, the former broken device was configured as a router. However, the bug remains independent of the configuration (End-Device, Coordinator, Router). I’ve even tried to flash a complete different firmware onto the device. ZNET 2.5 instead of ZigBee. Still the same bug.

-Both of the routers in the testbed had always received the same firmware. I took a running router configuration which I’ve used for former applications. An image of the coordinator firmware also exists.

I would be glad if somebody could help me in this topic.

Kind regards

Stephan

Read over the reset notes located at http://ftp1.digi.com/support/firmware/93009373_G.txt. You will find that your issue is a result of a bug in the EM250 processor that has to do with the channel mask. Try setting the SC value on all of your nodes to the same value and have it less than 16 total channels. This will keep you from having the issues you are experiencing.