• State
  • Locked Locked
  • Replies 3 replies
  • Subscribers 55 subscribers
  • Views 633 views
  • Users 0 members are here
Support feedback
Options
Options
Related

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.

self healing not working in mesh mode

Hugo Morais
Prodigy 170 points

Other Parts Discussed in Thread: CC2530, CC2430

Hi,

I am using:

One CC2531 USB dongle (with ZStack-CC2530-2.4.0-1.4.0 adapted to it, according to CC2531 Dongle Firmware compilation guide and ZigbeePro deactivated) as coordinator.

Two CC2430s (with ZStack-1.4.3-1.2.1) as routers (that I will call R1 and R2).

The coordinator and both routers are in mesh mode.

There is no problem having R1 and R2 sending directly to coordinator (COO<--R1 and COO<--R2)

However if I put R2 outside coordinator range but inside R1 range, the coordinator does not receive any message from R2 that should come through R1 (COO <-- R1 <-- R2), which means that self-healing is not happening.

I even tried to perform healing at application level:

“case AF_DATA_CONFIRM_CMD:

          afDataConfirm= (afDataConfirm_t *)MSGpkt;

          if (afDataConfirm->hdr.status!=ZSuccess)

                NLME_RouteDiscoveryRequest(SampleApp_Periodic_DstAddr.addr.shortAddr,TRUE);“

But without success.

However if I use ZDApp_NetworkInit():

“case AF_DATA_CONFIRM_CMD:

          afDataConfirm= (afDataConfirm_t *)MSGpkt;

          if (afDataConfirm->hdr.status!=ZSuccess)

                ZDApp_NetworkInit(2) ;“

 

It works and healing happens, getting R2 messages routed through R1: COO <-- R1 <--R2

 

Can someone tell me why self-healing and even NLME_RouteDiscoveryRequest are not working ?

 

Thank you for all the help you can provide

  • 0
    Guru 735695 points

    Are you sure that R2 is inside the communication range of R1. I would suggest you to use packet sniffer to analyze first. Check what happens to R2 when it is out of the communicating rang of coordinator. By the way, Zigbee router can work alone without coordinator after network is formed. Since R2 is lost contact with coordinator, it will work alone anyway.

  • 0 in reply to YiKai Chen
    Prodigy 170 points

    Dear Yikai,

     First of all thank you for your answer. I used, as you suggested, the packet sniffer.

    R2 is inside R1 range because if I reset R2, its messages get routed through R1 to the coordinator.

    I noticed, with the help of the packet sniffer, the following situation:

    If I reset R2 (with short address:0x02), its messages get routed through R1(with short address:0x01).

    After that, If I power down R1 and put R2 near coordinator:

    R2 makes requests to get a new route, but it seems that without sucess because after that it continues trying to send packets to coordinator through R1, as you can see in the anexed document.

    8688.Packet.doc

    What can be the problem?

    Is there something wrong in the router compilation options I am using?:

    CC2430DB

    RTR_NWK

    xSOFT_START

    xNV_RESTORE

    xNV_INIT

    NWK_AUTO_POLL

    ZDO_ENDDEVICE_ANNCE_GENERATE

     

    Does it have to do with the options of af_datarequest I am using for the messages sent from R2 ?:

    SampleApp_Periodic_DstAddr.addr.shortAddr = 0x0000;

    AF_DataRequest( &SampleApp_Periodic_DstAddr, &SampleApp_epDesc,

                           SAMPLEAPP_PERIODIC_CLUSTERID,

                           (byte)osal_strlen(dataToBeSent)+1,

                           (uint8*)&dataToBeSent,

                           &SampleApp_TransID,

                           AF_ACK_REQUEST|AF_DISCV_ROUTE,

                           AF_DEFAULT_RADIUS )

  • 0 in reply to Hugo Morais
    Guru 735695 points

    I suspect that it is caused by your obsolete CC2430 and ZStack-1.4.3-1.2.1. I have no such problem using ZStack 2.5.1a which runs ZigbeePro on it. I would suggest you using CC2530 and new ZStack to test again.