Home/Support/Support Forum/XBee Orphan Scan Behavior

XBee Orphan Scan Behavior

0 votes
I'm using the Xbee ZB SMT modules in an end device application and having some problems with the orphan scan.

The desired behavior for the device is that it comes online, associates with a router/coordinator, and transmits data. If the end device powers down (for battery replacement) and comes back online, it should seek out the same parent it was previously connected to. If the parent fails and has to be replaced, I would like the child device to recognize the parent is missing on it's next power-up, and fall back to a default scan for any other router/coordinators it can connect to establishing a new parent.

Orphan scan behavior sounds like it does exactly this, but in practice I've had some difficulty making it work.

Scenario 1:
Write security parameters to persistent memory, but allow channel and PANID to default. The security parameters ensure the device only connects to a valid coordinator that is part of our system, but if multiple coordinators are in range it arbitrarily joins any of them regardless of the previous time it was powered on.

Scenario 2:
Write security parameters to persistent memory, allow channel and PANID to default, but once connection is established read back the 64-bit operating PANID ("OP"), write that back to "ID" and commit that to persistent memory with a "WR" (using an external microcontroller on the device). This ensures that the device will always connect to whichever coordinator it connects to on the first attempt, but it will 'connect' to that same PANID even if the coordinator is removed.

Scenario 2 is the closest to a solution, but it needs to be able to fall through and connect to another coordinator. In the event of a coordinator failure we can't effectively brick an entire floor worth of devices (requiring manual re-flash).

asked Jul 29, 2014 in IEEE 802.15.4 by CHSH New to the Community (10 points)

Please log in or register to answer this question.

1 Answer

0 votes

Scenario 1 still behaves as described above and it appears that orphan scan isn't working as described, at least to my understanding.

However, this morning I realized what was going on with Scenario 2 and I can make it work, resolving my issue. Yesterday, to verify some of the settings on the XB module, I had been using a USB test board as a XBee modem to connect and probe the modules in the system. When I turned off the coordinator, I neglected to unplug the USB modem. When I was thinking the end device (that had the coordinator PANID written to persistent memory) had been connecting to a network that no longer existed, I neglected to consider that the USB modem had joined the network as a router and was continuing to keep the network alive.

Unplugging the modem and turning off the coordinator completely removes the old PAN, and under these conditions the XBee module throws 0x22 "AI" errors as expected (no valid PANs found based on current SC and ID settings). To work around the automatic orphan issue I can catch this "AI" code on the external microcontroller, manually reset the "ID" value back to all zeros, and allow the end device to automatically connect to any valid network again.

It isn't an automatic orphan scan, but if you have an external microcontroller talking to the XBee, polling "AI" and manually setting "ID" is a successful workaround.

answered Jul 30, 2014 by CHSH New to the Community (10 points)