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.

Bug Associate Routers loopback?

Other Parts Discussed in Thread: Z-STACK, CC2591, CC2530

Hi,

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

I have:
1) CC2530ZDK
2) Z-stack:
a) CC2530-2.5.1a;
b) Energy 1.1.0;
c) Lighting 1.0.1.

The distance between the routers 10cm.
The distance between the routers and the coordinator of 40cm.


1) Start Network:
ZC-|
   |
   |-ZR1-|
         |
         |-ZR2

2) After Reset ZR1:

ZC-|
         |-ZR1-|
         |     |
         |-ZR2-|


etc.
ZR1->_NIB.nwkCoordAddress == ZR2-> _NIB. nwkDevAddress
and
ZR2->_NIB.nwkCoordAddress == ZR1 -> _NIB. nwkDevAddress

I change function ZMacAssociateRsp in module zmac.c:

uint8 ZMacAssociateRsp( ZMacAssociateRsp_t *pData )
{
   //=========================================================================
   zAddrType_t AT;
   unDataBuf.TestOut.ui8Val1 = 0;
   unDataBuf.TestOut.ui8Val2 = 0;
   unDataBuf.TestOut.ui16Val1 = pData->AssocShortAddress;
   unDataBuf.TestOut.ui16Val2 = 0;
   osal_memcpy( unDataBuf.TestOut.dui8Data, pData->DeviceAddress, Z_EXTADDR_LEN );
   if( pData->AssocShortAddress == _NIB.nwkCoordAddress )
   {
     unDataBuf.TestOut.ui8Val1 = 1;
   }
   else if( osal_memcmp( pData->DeviceAddress, _NIB.nwkCoordExtAddress, Z_EXTADDR_LEN ) == TRUE )
   {
     unDataBuf.TestOut.ui8Val1 = 2;
   }
   else if( AssocIsParent( pData->AssocShortAddress ) )
   {
     unDataBuf.TestOut.ui8Val1 = 3;
   }
   else
   {
     AT.addr.shortAddr = pData->AssocShortAddress;
     AT.addrMode = Addr16Bit;
     if( MAC_SrcMatchAddEntry( (sAddr_t*)&AT, _NIB.nwkPanId ) )
     {
       unDataBuf.TestOut.ui8Val1 = 4;
     }
   }
   //=========================================================================
   if( unDataBuf.TestOut.ui8Val1 != 0 )
   {
     zb_SendDataRequest( 0x0000, Z2A_ZDO_TEST_RSP, sizeof(z_d_TestOut_t),     (uint8*)&unDataBuf, ui8Handle++, AF_TX_OPTIONS_NONE, 0 );
   return MAC_NO_RESOURCES;
   }
   //=========================================================================
   /* TBD: set security to zero for now. Require Ztool change */
   pData->Sec.SecurityLevel = false;

   return ( MAC_MlmeAssociateRsp( (macMlmeAssociateRsp_t *) pData ) );
}


After change take place if( osal_memcmp( pData->DeviceAddress, _NIB.nwkCoordExtAddress, Z_EXTADDR_LEN ) == TRUE )
in function ZMacAssociateRsp every 8 seconds.
It does not depend on the version of Z-stack.

I repeated this situation by using a program SensorDemo.

This error Z-Stack does not allow to build the system that uses a lot of routers
and where you need to know the address of a parent.
Also, the Z-Stack blocks the attempt to correct the error of the function ZMacAssociateRsp.

What am I doing wrong?

Thanks, Michael.

  • Hi YiKai Chen,
    I use ZStack-CC2530-2.5.1a and SensorDemo application.
    Hardware:
    1) CC2530ZDK(SmartRF05EB);
    2) CC2530DK(http://item.taobao.com/item.htm?spm=a230r.1.14.14.gc1JnZ&id=24220052974);
    3) CC2530-MDK-Q1(http://item.taobao.com/item.htm?spm=a230r.1.14.64.X5R6wb&id=10503164823)
    with module with cc2591.

    I made the following changes in SensorDemo:

         Options->C/C++ Compiler->Preprocessor:
    xNV_RESTORE

         f8wConfig.cfg:
    ///-DZDAPP_CONFIG_PAN_ID=0xFFFF
    -DZDAPP_CONFIG_PAN_ID=0x7777

         DemoCollector.c:

    void zb_HandleKeys( uint8 shift, uint8 keys )
    {
    ...
         if ( keys & HAL_KEY_SW_5 )
         {
    #if defined ( LCD_SUPPORTED )
    HalLcdWriteStringValueValue( "C/P:", _NIB.nwkLogicalChannel, 10, _NIB.nwkPanId, 16, HAL_LCD_LINE_2 );
    HalLcdWriteStringValueValue( "A/PA:", _NIB.nwkDevAddress, 16, _NIB.nwkCoordAddress, 16, HAL_LCD_LINE_3 );
    #endif
         }
         //=======================================================================
       }
    #if defined ( LCD_SUPPORTED )
    #if ( DEV_ID == CC2530Q ) || ( DEV_ID == CC2530DK ) || ( DEV_ID == CC2530MDK )
    HalLcdWriteStringValueValue( "K/S:", keys, 16, shift, 16, HAL_LCD_LINE_4 );
    #endif
    #endif
    }
    ...
    static void sendDummyReport(void)
    {
    ...
    /// zb_SendDataRequest( 0xFFFE, DUMMY_REPORT_CMD_ID, SENSOR_REPORT_LENGTH, pData, 0, txOptions, 0 );
       zb_SendDataRequest( 0x0000, DUMMY_REPORT_CMD_ID, SENSOR_REPORT_LENGTH, pData, 0, txOptions, 0 );
    }


    SmartRF05EB has an antenna.
    CC2530-MDK-Q1 has no antenna.
    CC2530DK has no antenna.

                SmartRF05EB
                     ^
                     |
                     |
                     |

    ...             70cm
                     |
                     |
                     |
                     v
                    5cm
       CC2530DK <--------> CC2530-MDK-Q1


    All the devices I program as Collector.

    1) I turn on (SW5 press) SmartRF05EB. Set Mode = Gateway

    2) I turn on (SW5 press) CC2530DK:
          SADDR = 0x5E92, PSADDR = 0x0000. Set Mode = Collector.

    3) I turn on (SW5 press) CC2530-MDK-Q1:
          SADDR = 0xD441, PSADDR = 0x5E92. Set Mode = Collector.

    4) Reset CC2530DK:
           CC2530DK: SADDR = 0x36F2, PSADDR = 0xD441.
      CC2530-MDK-Q1: SADDR = 0xD441, PSADDR = 0x36F2.

    5) Reset CC2530-MDK-Q1:
           CC2530DK: SADDR = 0x36F2, PSADDR = 0x69B8.
      CC2530-MDK-Q1: SADDR = 0x69B8, PSADDR = 0x36F2.

    Thus, we have the loopback.

    Thanks.
    Michael.

  • Currently, I doesn't play with sensor demo. DO you try other example, GenericAPP for example, and see the sample problem?


  • Hi YiKai Chen,
    I use ZStack-CC2530-2.5.1a and GenericApp application.
    Hardware:
    1) CC2530ZDK(SmartRF05EB);
    2) CC2530DK(http://item.taobao.com/item.htm?spm=a230r.1.14.14.gc1JnZ&id=24220052974);
    3) CC2530-MDK-Q1(http://item.taobao.com/item.htm?spm=a230r.1.14.64.X5R6wb&id=10503164823)
    with module with cc2591.

    I made the following changes in GenericApp:

    Options->C/C++ Compiler->Preprocessor:
    Add:
    DEV_ID=CC2530EB // or CC2530DK, CC2530MDK
    HAL_PA_LNA // for CC2530-MDK-Q1
    ISR_KEYINTERRUPT

    f8wConfig.cfg:
    ///-DZDAPP_CONFIG_PAN_ID=0xFFFF
    -DZDAPP_CONFIG_PAN_ID=0x7777

    GenericApp.c:

    static void GenericApp_ProcessZDOMsgs( zdoIncomingMsg_t *inMsg )
    {
    ...
      GenericApp_DstAddr.addrMode = (afAddrMode_t)Addr16Bit;
    /// GenericApp_DstAddr.addr.shortAddr = pRsp->nwkAddr;
      GenericApp_DstAddr.addr.shortAddr = 0x0000;
    ...
    }

    static void GenericApp_HandleKeys( uint8 shift, uint8 keys )
    {
    ...
        if ( keys & HAL_KEY_SW_5 )
        {
    #if defined ( LCD_SUPPORTED )
    HalLcdWriteStringValueValue( "C/P:", _NIB.nwkLogicalChannel, 10, _NIB.nwkPanId, 16, HAL_LCD_LINE_2 );
    HalLcdWriteStringValueValue( "A/PA:", _NIB.nwkDevAddress, 16, _NIB.nwkCoordAddress, 16, HAL_LCD_LINE_3 );
    #endif
        }
        //=======================================================================
      }
    #if defined ( LCD_SUPPORTED )
      #if ( DEV_ID == CC2530Q ) || ( DEV_ID == CC2530DK ) || ( DEV_ID == CC2530MDK )
    HalLcdWriteStringValueValue( "K/S:", keys, 16, shift, 16, HAL_LCD_LINE_4 );
      #endif
    #endif
    }
    ...
    static void GenericApp_SendTheMessage( void )
    {
      unsigned char theMessageData[] = "A/PA:XXXX, XXXX";
      _itoa( _NIB.nwkDevAddress, theMessageData + 5, 16 );
      theMessageData[ 9 ] = ','; theMessageData[ 10 ] = ' '; theMessageData[ 11 ] = 0;
      _itoa( _NIB.nwkCoordAddress, theMessageData + 11, 16 );
      if ( AF_DataRequest( &GenericApp_DstAddr, &GenericApp_epDesc,
        GENERICAPP_CLUSTERID,
        (byte)osal_strlen( (char*)theMessageData ) + 1,
        (byte *)&theMessageData,
        &GenericApp_TransID,
        AF_DISCV_ROUTE, AF_DEFAULT_RADIUS ) == afStatus_SUCCESS )
    ...
    }

    SmartRF05EB has an antenna.
    CC2530-MDK-Q1 has no antenna.
    CC2530DK has no antenna.

             SmartRF05EB
                  ^
                  |
                  |
                  |

    ...         50cm
                  |
                  |
                  |
                  v
                 5cm
     CC2530DK <--------> CC2530-MDK-Q1

    Programming Module function:
    SmartRF05EB - CoordinatorEB;
    CC2530DK - RouterMDK (clone RouterEB);
    CC2530-MDK-Q1 - RouterDK (clone RouterEB).

    1) I turn on SmartRF05EB.

    2) I turn on CC2530DK:
         SADDR = 0xFB7A, PSADDR = 0x0000.

    3) I turn on CC2530-MDK-Q1:
         SADDR = 0x7F49, PSADDR = 0xFB7A.

    4) Reset CC2530DK:
           CC2530DK: SADDR = 0x7726, PSADDR = 0x7F49.
      CC2530-MDK-Q1: SADDR = 0x7F49, PSADDR = 0x7726.

    5) Reset CC2530-MDK-Q1:
           CC2530DK: SADDR = 0x7726, PSADDR = 0x575D.
      CC2530-MDK-Q1: SADDR = 0x575D, PSADDR = 0x7726.

    Thus, we have the loopback.

    Thanks.
    Michael.

  • 1. Is your smartrf05 coordinator? Do you turn off it?

    2. After you turn on CC25320DK and CC2530-MDK-Q1. Do you bind them with coordinator and make them to send Hello message? If yes, do CC25320DK and CC2530-MDK-Q1 still send message to coordinator?

  • Hi YiKai Chen,
    1) Yes, smartrf05 is the coordinator. It is always on.
    2) No, I do not associate with the coordinator of the routers.
    I press SW4(Joystick left) on both routers and coordinator begins to periodically receive
    post: A/PA: SADDR, PSADDR
    3) Reset CC2530DK and press SW4.
    4) Coordinator continues to periodically receive a message: A/PA: SADDR, PSADDR from routers.

    Thanks.
    Michael.

  • Do you check if it is still loop back in the latest test?

  • Yes, I checked.
    Loopback can be seen on the LCD coordinator or (pressing SW5) on the LCD routers.

  • Coordinator should not have parent but you can see its parent address? It is strange.

  • Address parent coordinator always 0x0000.
    The Coordinator's LCD shows messages from routers:
    unsigned char theMessageData [] = "A / PA: XXXX, XXXX";
    _itoa (_NIB.nwkDevAddress, theMessageData + 5, 16);
    theMessageData [9] = ','; theMessageData [10] = ''; theMessageData [11] = 0;
    _itoa (_NIB.nwkCoordAddress, theMessageData + 11, 16);

    These reports show loopback routers:
    A/PA: 7726, 7F49 (from CC2530DK)
    A/PA: 7F49, 7726 (from CC2530-MDK-Q1)

  • Actually, I think this might be bug in ZStack so I can't help. However, it seem doesn't matter because the message still send to destination successfully.

  • Thanks for the help , YiKai Chen.
    Yes, it is a bug Z-stack.
    I tried ZStack-CC2530-2.5.1a, Energy 1.1.0, Lighting 1.0.1, SensorMonitor, GenericApp.
    The result is the same.
    For small networks with a number of devices to 5-10 is not critical.
    But the big networks ( from 20 to 1000 devices ) with this error is impossible to build.
    Such networks will be have unpredictably.
    For example, the ChildDevice in my system synchronizes the time with their ParentsDevice.
    Also based on data received from the device I can not build a hierarchical view of the network.

    I spent on the development of the system ( software and hardware ) one year of age , and 4000 dollars.
    I started testing the system and immediately got this error.
    I only use 5 of my 26 devices and a problem.
    My system should consist of 10 coordinators. Each coordinator shall serve 2000 devices.
    I'm trying for almost two weeks to get help from TI, but my questions ignore. :-(
    Now I am considering the option of using STM32W108 instead CC2530.
    YiKai Chen, you have practice of using STM32W108?

  • No, I don't have experience on STM32W108. I will try to post on this forum about your issue to see if any TI employee can help.

  • Hi DarkSide,

    Michael has posted this problem but there is no TI employee who can provide help. Is it a real problem or Michael test ZStack with wrong steps? Could you help to verify this issue? 

  • Hi Michael,

    first of all the scenario you describe where routers is re-associated after power up is due to wrong configuration settings in the system. 

    You should always have NV_INIT and NV_RESTORE set so that the routers, at power up, won't re-associate but just resume normal operation with the previous nwk address and without re-associating.

    The behavior you observe is the expected one, when those compilation flags are not set.

    By design, all entries in the association table, linked to the same IEEE address (as it happens in this case) get updated when there's an address update (like in this case, again this is the consequence of not setting NV_INIT and NV_RESTORE). If this wasn't the case, then R2 would have in the association table an entry as parent which is an invalid NWK address. So in this case R1 selects R2 as new parent because is the closest node and R2 has an open network when R1 tries to re-associate.

    Also i wanted to mention that in ZigBee Pro routers do not make use of the parent-child relationship anyhow to route packets. In other words, the fact that there's a loop between two routers in terms of parent-child relationship does not mean that the two nodes are isolated from the system at all, which i think is what is of concern here (i think you are assuming that packets would loop infinitely going back and forth and never getting out of the loop).

    In fact, routes are built on demand upon request, using AODV scheme, and are maintained upon time by routers through the LINK-STATUS message that they periodically send out. The parent-child relationship is not used to build the route

    In other words, even if there's a parent-child loop (which may seem to be like a nasty relationship), in your case still R1 and R2 could talk to the coordinator and they would see him as a neighbor and send him directly the packets.

    In a larger network scenario, again this is not an issue because as mentioned the fact that there's a parent-child relationship between two routers does not mean that the packets will go every time from child to parent to read other nodes in the network. 

    Again, routers are different than end devices so they could select the next hop based on the total best cost to reach a final node and not necessarily go through their parent to reach the final destination.

    Thanks,

    TheDarkSide

     

  • Hi Michael,

    I think TheDarkSide has given you a thorough answer and you should always enable NV_RESTORE in your test. According to my experience, CC2530 is my first choice in Zigbee protocol not STM32W108. I hope your project can keep moving now.

  • Hi TheDarkSide. Hi YiKai Chen.

    I do not understand why when you disable NV_RESTORE router must show incorrect Parent.

    I turned on NV_RESTORE coordinator and all routers and continued testing.
    All devices in the test do not have antennas (to reduce the distance between the devices).
    For testing, I use the following scheme:
    ZC(SmartRF05EB)
    ^
    |
    |
    | ~2m
    |
    v              ~5cm
    ZR1(CC2530DK) <---> ZR2(CC2530DK)
    ^
    |
    |~2m
    |
    |
    v
    ZR3(CC2530-MDK-Q1)

    1) I include the ZC in GATEWAY MODE.
        ZC: 0x0000/0x0000
    2) I run the program SensorMonitor and connect with the ZC.
    3) I turn on the ZR1 and ZR2. Enables sending reports.
        ZR1: 0x1111/0x0000
        ZR2: 0x2222/0x0000
    4) I turn ZR3. Enables sending reports.
        ZR3: 0x3333/0x1111
    5) I turn off the ZR1. The ZR3 continues to send reports via the ZR2. The LCD ZR3 shows : 0x3333/0x1111.
    6) I turn off the ZR2. The ZC ceases to receive reports from the ZR3.
    7) I turn on the ZR2. After 10 seconds, the ZR3 starts sending reports on the ZC. The LCD ZR3 shows : 0x3333/0x1111.

    Explain please me how I can find out the current Parent device?
    It is very important for my system .
    When I developed a system I relied on the fact that the device will have the correct address Parents.
    That's only four issues that arise due to lack of valid addresses Parents :
    1) All devices synchronize their system time with the system time to the Parents .
    2) According to the reports from the devices the system builds a graphical representation of the hierarchical network.
    3) According to change the address in the records of the Parent Device I identify problems with the former Parent.
    4) I have developed a my system of "Over Air Download". If I give the device to upgrade from the parents, but parents will be incorrect then the system will not work.

    How do I solve this problem?

    Thanks.
    Michael.

  • Hi Michael,

    first of all, you need to turn on both NV_INIT and NV_RESTORE.

    Then, what you observe and capture is the expected behavior. When you turn off ZR1, ZR3 finds the path to the collector via R2, which is on. This shows the self healing behavior of ZigBee and shows why you don't need to go through your parent to reach the final destination. When you turn off R2, obviously since there's no direct radio path between R3 and ZC, you can't reach ZC anymore.

    One thing that i would like to mention is that routers can exist in the network without parent (a coordinator or a top of the network can even be turned off). So, when you turn off a parent of the router, since the router does not re-associate if he has NV enabled, he won't change the parent information but anyway he doesn't even need that to send/receive data.

    I do honestly believe the design for the features you would like to have should not depend on the presence of a parent (as mentioned, routers do not re-parent because they don't need to). Routers could be off the network. What happens in your system if a parent is off? Then your device would be completely stalled and not receive any system time synchronization or able to receive the firmware to be upgraded anyway.

    In a scenario like the one you describe, i would identify one node which is always on and should be the most authoritative server (in this case, it should be the coordinator). It should maintain the time base as well as store the image for the nodes to be upgraded.

    Nodes would always talk to/from the coordinator (and be able to automatically form a route to it and from it, on demand or even through the many-to-one scheme) and receive time sync updates/firmware update.

    Topology/graphical representation of the network should be discovered from the coordinator using LQI_mgmt_req ZDP messages (and responses intercepted), where each node would report the parent/children and the list of neighbor (which for a router are important because they represent all devices the routers can directly talk to and use as next hopes for routes).

    Other customers have successfully implemented this scheme.

    Thanks,

    TheDarkSide

  • Hi TheDarkSide.
    In the experimentation that I described above NV_INIT and NV_RESTORE were included (this is evident from the behavior of routers ).

    You correctly describe what happens when I turn off and turn on the routers.
    That's what I wanted to show this experimentation.

    I have no complaints to the algorithm self-healing network.
    I ask you about what the value of the variable stored current Parent device.
    Suppose that, the ZR1 turned off forever (broken, stolen, etc.).
    Why the router Child remembers address of the router Parent to which it was connected when its turn on?
    Parent to whom he joined when turn on the already never will be.
    The ZR1 died, but the child continues to send his address.
    I do not see the logic.
    What am I wrong?

    On my system, the Coordinator serves as a bridge , it does not produce any information processing and does not send any commands.
    Coordinator can not completely control a network of thousands of devices (it does not have enough resources ).
    Network manages the program on the computer via the coordinator.
    This software coupled with the database.
    According to the database , I build the topology/graphical representation of the network.

    I do not understand why I have to ask for topology/graphical representation of a network consisting of several thousands of devices if the data I have in my database.

    I do not like update scheme devices that you suggested.
    I found (in my opinion) more fun way to update the firmware of devices.
    My method takes less time and traffic volume.

    Are you sure that when using the LQI_mgmt_req ZDP message is received address real Parent?
    It is clear that the device is turned off , unable to report on the event management program.
    I want to understand how to make the child informed about the change of its parent.
    All I'm asking is how you can find out about the change Parent variable and from what I can read the address of the new Parent.

    Tell me, please , where you can read about your customers that have implemented the scheme of a thousand or more devices?

    I can not create a system of devices that I can not fully control.

    Thanks. Michael.

  • Hi Michael,
    I repeated your experiment and got the same results - in the Z-Stack have a mistake.
    It's sad because , the Z-Stack is used for 7 years.
    I am developing a network in which all routers communicate with each other.
    My routers should always know exactly who their parents.
    The router may break, etc.
    A child should not send information to a "dead" parent.
    This error does not allow the use of Z-Stack in projects with a high level of interaction between devices.
    This error, and that it was not corrected within 7 years of operation
    the Z-Stack leads me to believe that there are other errors in the code Z-Stack.
    I watched your correspondence with TI employees.
    For three weeks in a few topics you raised the issue of this error.
    Only the intervention of YiKai Chen made TI employees to wake up.
    But TI employees do not understand the criticality of this error for their clients.
    Thank YiKai Chen, he fights in this forum with the reluctance of TI employees to work.
    I searched the internet for information on large projects where used CC2530,
    but found only :http://www.aimir.com/about/successes-Goteborg-Energi.php
    You calculated how much time and money need for transfer your project to use STM32W108?
    Why you gave an example of this chip?
    What alternatives you have considered?
    I would be grateful for your response.
    Inna.

  • Hi Inna,

    I don't fight with TI employees. I just try my best to help anyone comes to this forum. For this issue, theDarkSide has give a clear explanation and I also don't think this is a ZStack bug. TI ZStack has already been approved by Zigbee alliance and has interoperating test with other Zigbee solutions without problem. In a zigbee mesh network, the communication between two devices  need to do binding first and zigbee stack is in charge of find new communication path if it finds the communication is broken. The parent of ZR or ZED doesn't matter from my point of view. I won't say whose ZStack is better and suggest you to try them to choose one that fits you best. I think any SW has bugs. I am here to help and try to report any bug to make ZStack complete.

    Regards!

    YK

  • Hi YiKai Chen.

    You will not deny that, the router may break, etc.
    Why _NIB.nwkCoordAddress variable and function NLME_GetCoordShortAddr () return the address of the "dead" router?
    Explain to me please, why do you need to know the address of the "dead" router?
    I'm just asking how do I know the real address of the Parent.
    Any software contains bugs.
    They need be corrected or explained why this error is needed or how this feature can be bypassed.
    Error correction improves software.
    Zigbee alliance proposed the concept.
    Each firm is implementing the concept in their own way.

    Regards!
    Inna.

  • I suppose it depends on your network, for example, if you have a network like the followings:

    ZC-------->ZR_A------------>ZR_C

          |

          |------->ZR_B------------>ZR_D

                               |

                               |------------->ZR_E

    If ZR_E will send message to ZR_D, ZC is dead or turned off one day. I don't see why ZR_B need to update its parent and it isn't indeed if there is no message needs to go through ZR_B's parent, which is ZC. If ZR_D or ZR_E will send message to ZR_C and ZC is dead, the communication path is broken and ZStack will do healing automatically. In this case, I suppose that the new communication path will be built, for example the ZR_B's parent becomes ZR_A. In this case, the parent node of ZR_B is updated. This is my understanding of ZStack for your reference.

  • Hi YiKai Chen.
    You're talking about an automatic algorithm that supports Z-Stack.
    These algorithms is working.
    I do not argue.
    How do you determine the address of the Parent?
    Regards!
    Michael.

  • As I describe in my previous post, I don't concern the parent of my ZED or ZR in my mesh network application. If you want to get parent short address of device, you can use NLME_GetCoordShortAddr. It is described in Z-Stack API.pdf

    3.4.2.1.3  NLME_GetCoordShortAddr()
    This function will return the device's parent’s network (short - 16 bit) address. This is NOT the Zigbee
    Coordinator’s short address (it’s always 0x0000).  In MAC terms, the parent is called a coordinator.

  • Hi YiKai Chen.
    The NLME_GetCoordShortAddr() function returns the address of the "dead" Parent.
    Which the function allows to get the address real parent?
    Regards!
    Michael.

  • As I said in my previous post, Zigbee router can still work even it loses contact with its parent. So, the short address of dead parent won't be updated unless there is any message that need to be communicate through router's new parent. For example:

    1. original mesh: ZR_C keeps sending message to ZR_A and ZR_E keeps sending message to ZR_D

    ZC-------->ZR_A------------>ZR_C

          |

          |------->ZR_B------------>ZR_D

                               |

                               |------------->ZR_E

    2. Turn off ZC: the parent address of ZR_A and ZR_B won't be update even ZC is turned off. This is because there is no message needed to be transmit through their parent ZC.

                     ZR_A------------>ZR_C

                     ZR_B------------>ZR_D

                               |

                               |------------->ZR_E

    3. If I make ZR_D to send message to ZR_C, the ZStack will start network healing and ZR_A might be the parent node of ZR_B. After this healing is done, the short address of ZR_B  should be updated and you should get correct short address of parent node using NLME_GetCoordShortAddr.

                   ZR_A------------>ZR_C

                     ^

                     |

                     |

                     ZR_B------------>ZR_D

                               |

                               |------------->ZR_E

  • Hi YiKai Chen.

    I probably explain bad on English?
    I use translate.google.ru.
    I have no claims to the self-healing algorithm.
    I want to have a real address Parent.

    I tested your algorithm.
    1) I turned off ZR_A.
    2) The ZR_C sent a message to the "dead" ZR_A and to the "living" ZC.
    3) The ZR_C executed the NLME_GetCoordShortAddr () and got the address of the "dead" Parent.
    Conclusion: The algorithm does not work.

    Regards!
    Michael.

  • 2) The ZR_C sent a message to the "dead" ZR_A and to the "living" ZC.???

    How do you let ZR_C send message to ZR_A? Binding? What do you mean "to the living ZC"? Since ZR_A is dead, ZR_C won't get MAC ack when sending message to ZR_A. ZR_C is a router and there is no need to find a new parent in this case so I suppose the short address is not update.

  • I do not use the binding.
    I do not use the Cluster Library.

    ZC --------> ZR_A ------------> ZR_B ------------> ZR_C
    1) I turned off the ZR_B.
    2) The ZR_C sent a message to the "dead" ZR_A and to the "living" ZC.
         zb_SendDataRequest (ZR_B, MSG_ID, MSG_LENGTH, (uint8 *)&MsgData, 0, AF_MSG_ACK_REQUEST, 0);
         zb_SendDataRequest (0x0000, MSG_ID, MSG_LENGTH, (uint8 *)&MsgData, 0, AF_MSG_ACK_REQUEST, 0);
    3) The ZR_C executed the NLME_GetCoordShortAddr() function and got the address of the "dead" Parent (ZR_B).

    What am I doing wrong?

  • Hi,

    Since ZigBee 2007 and ZigBee 2007 Pro, topology based on the relationships between routers has had very little or none of importance when a route between two nodes is established. Any node can move, die, or reappear after it joined a network and there is no need to find a new parent because routing doesn't rely on the topology. With ZigBee 2007 non-Pro, there is a backup routing using the tree topology in case of mesh routing failure, but I won't consider this assuming you are using Pro stack profile as it is enabled by default in f8wConfig.cfg.

    I think all the confusions come from the function sendReport() in SensorDemo as it put the parent address in the payload of the report message. Anyway, it is just a parent address, not a next-hop address in terms of routing. The parent address will not change because it doesn't have any meaning unless the device is an end device in Pro network. Even is the parent is dead, it is still the parent of the child router and the fact that the parent is dead doesn't make any effect to the child router's running in the network. I suppose the SensorDemo was written as an example of ZigBee 2006-based application where tree routing is supposed to be used.

    If you want to know a full end-to-end routing path of each message, you can use any one of the following methods:

    1. Call  RTG_GetNextHop() to get the next hop address and put it in the payload instead of parent address. The usage of this function would be as following.

    nextHopAddr = RTG_GetNextHop( DstAddr, SrcAddr, SelfAddr, INVALID_NODE_ADDR, 0);

    Where, DstAddr is the destination address the local device wants to send the message to, the SrcAddr is the source address the message was originated from if the local device is an intermediate router, and SelfAddr is the address of the local device itself. If the local device is the originator, just use INVALID_NODE_ADDR for SrcAddr.

    2. Use Many-To-One/Source Routing scheme and register a callback for ZDO_SRC_RTG_IND_CBID on the coordinator(concentrator). Please refer to section 5.4 of Z-Stack Developer's Guide regarding Many-To-One/Source Routing mechanism. You will get the full path of a received message when the callback is called.

    If you just want to know the topology regardless of routing path, I think using ZDP_MgmtLqiReq() in a recursive way would be the best as DarkSide mentioned.

    - Cetri

  • Hi  Cetri,

    Thanks for the explanation to make it more clear.

  • Hi Cetri,
    Thank you for the answer.
    The function RTG_GetNextHop () works very well.
    That's what I was looking for.

    Where can I read the description of the functions of rtg.h?

    Help me, please, to solve another problem.
    The Z-Stack have the NWK_LINK_STATUS_PERIOD definition which determines the time between Link Status messages.
    I want to analyze the received Link Status messages and update the value of the variable _NIB.nwkCoordAddress.
    What function can I do this?

    Regards!
    Michael.

  • Hi Michael,

    Basically functions related to routing are not exposed to application layer because applications don't have to take care of how packets are handled underneath and we hardly believe application layer's having the access to routing functions helps improving any application feature. Unfortunately we don't provide a document about routing functions for that reason.

    Also, neighbor table management including processing Link Status messages is done on NWK layer which doesn't provide application layer with the access.

    Anyway, _NIB.nwkCoordAddress is supposed to be handled by the stack associated with joining/rejoining actions, so what effect arbitrary change of _NIB.nwkCoordAddress may bring is not guaranteed. We wouldn't recommend changing _NIB.nwkCoordAddress.

    - Cetri

  • Hi Cetri,

    Thank you for your help.

    Why routers must to know the real address of the Parent - defined specifics of my system.
    Routers in my system at the same time serve as the end device.
    But the function RTG_GetNextHop() solves this problem.

    Once again, thank you! Good luck to you!

    Regards!
    Michael.

  • Excellent post. I am using MTOR and hence I think #2 will work for me. But at the same time I wanted to understand LQI between routing nodes. I know I have an option to send LQI request, but I do not want to generate unnecessary traffic. As per my current requirement, I am already sending attribute packets every few minutes and want to send out its link quality status to next hope in the same packet. Can I use #1 to determine next hope address and use it in routing table to find out LQI of next hope? would it work?

  • Excellent post. I am using MTOR and hence I think #2 will work for me. But at the same time I wanted to understand LQI between routing nodes. I know I have an option to send LQI request, but I do not want to generate unnecessary traffic. As per my current requirement, I am already sending attribute packets every few minutes and want to send out its link quality status to next hope in the same packet. Can I use #1 to determine next hope address and use it in routing table to find out LQI of next hope? would it work?

    Would this command work to find out LQI with next hope?

    nxt_hop_addr = RTG_GetNextHop( 0 (for concentrator), INVALID_ADDR, self_addr of node, INVALID_ADDR,0);

    find pAssoc for (nxt_hop_addr)

    pAssoc->link_lqi;