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.

CC2530: Zigbee End devices Retries message

Part Number: CC2530
Other Parts Discussed in Thread: Z-STACK

Hi, 

I'm working with Z-Stack version 1.2.1 and I have one doubt related with number of retries messages that ZED send to is parent after a failure communication. 

When a ZED lost the connection to is parent device, for different reasons (parent was shuting down, or ZED stay in out of range), it sends every 3 retries messages, and after that it stay in orphan mode and start to send orphan notifications to find another parent.

I want to increase the number of retries messages to 8 retries, to force the communication to is parent, but I can't find in Stack where I can change it!

Please, if someone have answer to my question, please share.

Best regards 

Nalves

  • You can adjust maxFrameRetries inside macpibdefauls in mac_pib.c file, u can set values from 0 to 7.
  • Hi YiKai Chen,

    Thank you for your replay and useful information, it works perfectly!

    I take the log I have created and show that the change has success, to raise another doubt about the operation of the ZED.

    In the packet sniffer log attached you can see a communication that ZED try to have with is parent that was turn it off. After the 7 retries, it change is state to orphan device as you can see with orphan notifications.

    It sends 4 orphan notifications, but some times it send more that 4 retries! Why it happens? Why it takes so long time to send the orphan notifications and start sending beacon requests? 

    I want to accelerate this process, for the users can wait a minimum possible for can had ZED available again after exchange is parent device!

    I try to find this tunning information on the Z-Stack documentation but I can't find it!

    Please, if you can help me, I will appreciate that.

    Best regards.Packet sinffer ZED lost parent.psd

    Nalves

  • You can revise MAX_RESUME_RETRY defined in ZDApp.c to change orphan notification retries.
  • Hi YiKay Chen,

    On the target! I reduce the MAX_RESUME_RETRY to 1 and the process seems to be more faster. Is that what i looking for.
    It is supposed have "colateral damages" with this changes?

    Best regards.

    Nalves
  • What do you mean “colateral damages”?
  • Hi Yikai Chen,

    The meaning of collateral damages is if this change (reduce the number of MAX_RESUME_RETRY ) could interfere whit other devices operations! Or this is applicable only for rejoining and resume process of ZED?

    Best regards.

    Nalves
  • I don’t see any damage by changing this.
  • Ok YiKai chen

    thank you for your feedback!

    Best regards.

    Nalves
  • Hi YiKai Chen,

    I have one last doubt, that could be resolved in the same theme of this post.

    I create a scenario test, with one coordinator, 4 ZR and 1 ZED. After join the network, the ZED chose as a device parent one of ZR. I turn of the ZR parent and click in one button of ZED to force a communication to network. The ZED detects that parent doesn't response and enter in orphan mode and chose ZC as is device parent. After that I shut down the ZC and click on the ZED button to force one communication, and it detects a failure communication with is parent and join another parent device, another ZR og the network.
    In this last parent exchange the the beacons request sended by ZED doesn't have any response for the ZR that are turned on!
    It have only one response of beacons request after 4th beacon. the ZR are near from the ZED, so that reason it can receive the beacons from ZED!
    I test dis several times and in some cases I detect this situation, which makes me think that it may be something that is blocking the answers to the beacons in the ZR.

    Can you have a feedback from someone that have the same issue?

    The ZR and ZC have some time period to answer of Rejoining beacons requests?

    Best regards

    Nalves
  • I forgot to attach the packet sniffer log of the descripton of my last post.

    Orphan notify-Rejoining process_doubt 2.psd

    You can find the issue after packet 174.

    Best regards

    Nalves

  • It seems there is something wrong on ZED so it cannot rejoin to original network. I know there are some fixes are related to such issue in latest Z-Stack and I can only suggest you to update your Z-Stack to latest one.

  • Hi YiKai Chen,

    No you scare me. The product is on the market, I can not make such radical changes.

    Can you tell me what changes have been made, or where can I find this information that solved this problem?

    Best regards

    Nalves
  • You can check release note of every Z-Stack to know the details.
  • Hi YiKai,

    I'm trying to check all the changes that are implemented on the different versions of stack and I still thinking in your expression:
    "It seems there is something wrong on ZED so it cannot rejoin to original network."

    What you mean with it can't rejoin to original network? Where did you seen that ZED is trying to rejoin other network?

    best regards,
    Nalves
  • Hi,

    A lot of the packets are encrypted. If possible, please provide the NWK key so we can further analyze the logs.


    Regards,
    Toby
  • Hi Toby,

    Of course. For this network, the key available is: B4:34:14:4C:B6:F7:84:A0:FB:41:70:27:18:C9:56:FF

    Please check is everything is correct.

    Best regards

    Nalves
  • The 802.15.4 MAC does have CSMA-CA for collision avoidance, so it could be the case that there is some interference on that channel and the ZR doesn't send a beacon yet. This would explain why it happens sometimes, not all the time.

    You mentioned that this scenario is for testing purposes, but generally I would not recommend powering off the ZC.