This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

Router parent MAC - NLME_GetCoordExtAddr()

Other Parts Discussed in Thread: CC2530

Hi,

I've read posts on the subject, but didn't see any answer, so...

My project has a Zigbee network with many ZRs and ZEDs (hoping to reach ~150 devices), all communicating ONLY with the ZC: they send an application string and receive a reply.

Within each Zigbee-data sent to the ZC is the 'ParentMAC' (the Zigbee parent of each element), obtained by NLME_GetCoordExtAddr().

The ZC communicates with a remote server, forwarding the Zigbee data, so the server has the topology-tree of the Zigbee network, using their IEEE address as an ID.

As long as my network is static (nothing moves, nothing gets broken, nothing changed) - all is well.

ZEDs work fine: if its parent disappears and it finds new parent - NLME_GetCoordExtAddr() is updated.

My problem - ZRs don't update their parent!!!

If a ZR's parent disappears (for example - ZR moved during installation of the network) - there is no indication, thus the server has an incorrect topology-tree.

I guess the behavior is correct (I understand ZRs don't become 'orphans', they just 'hang-around' - ???), but I still need a solution for my problem.

Maybe what I need is the MAC Source Address (a apposed to the NWK Source Address) of the ZRs? That would be the address from the 'last hop'? How can I receive that?

I'm using CC2530, ZStack 2.5.1, ZIGBEEPRO.

There are many ZStak defines which I'm not sure are relevant: ZIGBEE_MANY_TO_ONE, NWK_MANAGER (on ZC), etc. I understand from the code that most are defined by default?

Thanks, Rami.

  • Yes, there is no indication if a ZR's parent disappears. I suggest that you can send supervision signal to coordinator periodically from ZR. In this way, the ZR will try to find a new route to coordinator while sending this supervision signal if its parent disappears.

  • My problem is not that.

    Say ZR2 is connected to ZR1, who's connected to ZC. ZR3 is also connected to ZC:

    ZC-|-ZR1-ZR2
       |
       |-ZR3

    ZR2 should notifies the server it's parent is ZR1.

    Now, say ZR1 dies (no battery???), and ZR2 manages to connect to ZR3:

    ZC-|     ZR2
       |    /
       |-ZR3

    This happens automatically, by the ZStack.

    But, when calling NLME_GetCoordExtAddr(), I still get ZR1.

    What I need is that ZR2 notifies the server it's parent is ZR3, so the server can reconstruct the same topology-tree.

    Via the sniffer, I see the correct address (short address of ZR3) in the MAC layer, in Source Address.

  • Would you want to try NLME_GetCoordShortAddr which get the parent's short address? 

  • Hi,

    I tried NLME_GetCoordExtAddr(), which is the IEEE brother of NLME_GetCoordShortAddr().

    It works for ZEDs, which go through a 'Rejoin' scenario when they loose their parent.

    With ZRs it's different - they don't care about their parent after they joined the Zigbee network.

    Looking at the beautiful sketch above, if ZR1 disappears (no power), ZR2 will send messages through ZR3, but, yet, NLME_GetCoordxxxAddr() will return ZR1.

  • I found that I can see the MAC Source Address, which is the short address of the 'last hop' of a message.

    I can extract that in MAC_CbackEvent() - msgPtr->dataInd.mac.srcAddr.addr. But I'm not sure of how to use it correctly + getting the IEEE address, etc. I see there broadcast messages and lots of 'last hop' addresses, when I need the topology-tree parent.

  • Hi,

    Understanding that digging into the MAC layer is more complicated than I hoped (messages from children complicate things as well), I tried a different approach:

    I search the Routing-Table for the ZC entry (pNwkRoutingTableItem->dstAddress == 0) and extract the 'next hop' (pNwkRoutingTableItem->nextHopAddress), which is the topology-tree parent.

    I then get the IEEE extended address from the NeighborTable, now that I have the nextHopAddress.

    But, it seems there's a ZStack bug regarding NLME_GetRequest(...) - data is corrupted...

    am I barking the wrong tree?

    Anyone has any thoughts?

    Thanks

  • Is there an answer for this? I too am trying to figure out the network structure using the API, and if this function doesn't work for Routers, I don't know how to do it. Why does NLME_GetCoordExtAddr() return incorrect parent information for a router, and how do I get the correct route for a given router?

  • Hi Bob,

    You can refer to the discussion at http://e2e.ti.com/support/wireless_connectivity/f/158/p/303183/1085197.aspx#1085197