ATNR0 not working as expected

XBee & XBee Gateway XBee - Zigbee
1

I am haveing a problem using the ATNR0 command as discribed bellow, When tring to migrate a node from one pan to another.
(I have seen the same affect with ATCB4 as well)

CASE ONE - (ONE ROUTER NODE) - GOOD case

  1. Set up a PAN(A) on COORDINATOR(A) with Pre shared NETKEY and Static LINKKEY (Randum PAN and CHANNEL)
  2. Join Router(A) to COORDINATOR(A)
  3. Power OFF COORDINATOR(A)
  4. Set up up a PAN(B) COORDINATOR(B) with Pre shared NETKEY and Static LINKKEY (Randum PAN and CHANNEL)
  5. Issue ATNR0 on ROUTER(A)
    a) Assosiation indicator will go solid to indicate that it is searching for a new PAN
    b) After some time it start to Flash indicating has Assosiated to a PAN
    c) It will Now be Joind on PAN(B)

CASE TWO - (TWO ROUTER NODE) - BAD case

  1. Set up a PAN(A) on COORDINATOR(A) with Pre shared NETKEY and Static LINKKEY (Randum PAN and CHANNEL)
  2. Join Router(A) to COORDINATOR(A)
  3. Join Router(B) to COORDINATOR(A)
  4. Power OFF COORDINATOR(A)
  5. Set up up a PAN(B) COORDINATOR(B) with Pre shared NETKEY and Static LINKKEY (Randum PAN and CHANNEL)
  6. Issue ATNR0 on ROUTER(A)
    a) Assosiation indicator will go solid to indicate that it is searching for a new PAN
    b) After some time it start to Flash indicating has Assosiated to a PAN
    c) It will Now be Back on PAN(A) - Even though There is no Coordinator for this PAN

I am using

XBEE PLUSS ZB S2B
AT
2270

XSTICK ZB
API
2170

2

Router A is trying to mesh to PAN A, and connects to Router B as a hop to the coordinator, since router B is a part of PAN A, even though Coordinator A is no longer there. I’ve ran into this as well, where changing a coordinator leaves an “orphan” network of all of the old PAN A devices. It will even happen if Coordinator B uses the same PAN as coordinator A (I always use a fixed PAN). Since all of my devices are routers (no end points), and all are attached to microprocessors, I have the microprocessor reset the module and bring up a new connection whenever the high level messaging fails (the layer above the Zigbee protocol). This is done in API mode, and with a fixed PAN, though, so it might not be applicable to your situation. It’s taken two years, but I’ve finally got something that is somewhat reliable and fault tolerant.