Openthread sleepy Child re-attach process

[Edward_Atam]

Hello,

I'm using NRF52840 module to make a customer device. I'm using nRF5 SDK for Thread and Zigbee v3.0.0.

I have a Thread mesh with some routers devices and one child, Periodically, the child leave the mesh when it goes out of range of any node in the network. I would like to know how to improve the current consume.

If I plot the current consume versus time (see attached figure), I can see serveral re-attach processes. The first retries are very close in time, and then the interval increases as 2^n, (n is the try number). Also, I can see that the duration timeout of each try is about 2 seconds.. Is this correct?

I would like to know if this timeout and interval period can be set or modified. 

I have taken a screen shoot with nrf Connect Power Profile, In this picture I have observed that the check timeout(T1, green arrow) is 2 seconds and the time between retries(T2, blues arrows) is 2^n seconds (n is the number of times when the child can't attach).

Can I set this periods?

Any help is wellcome. Thank you in advance.

[AndreasF]

Hi.

First:

It is against the specification changing the RX window time for the Parent Response. If you do this you might not get your device certified. You can do it for experimental reasons if you like by chaning two variables:

ttps://github.com/openthread/openthread/blob/master/src/core/thread/mle_constants.hpp#L69
https://github.com/openthread/openthread/blob/master/src/core/thread/mle_constants.hpp#L70

Second:

This can be changed as you like by modifying OPENTHREAD_CONFIG_ENABLE_ATTACH_BACKOFF, just remember to enable it. Modifying this should not be against the spec.

Best regards,

Andreas

[Edward_Atam]

Thank you for your reply.

My devices will not connecto to any third party Thread devices. Having this in mind, I guess that reducing the RX-window time to about 1 second will not have any influence in the certification. Do you think this make sense? Also, do you think that reducing this window will highly decrease the performance of the devices?

Also, I would like to ask about how to rebuild the OpenThread project:

https://infocenter.nordicsemi.com/index.jsp?topic=%2Fcom.nordic.infocenter.thread_zigbee.v2.0.0%2Fthread_intro.html&cp=4_2_0_1_0_5&anchor=thread_qsg_libraries

It is for SDK 2.0 and I assume it doesn't work for SDK 3.0 because there are not scripts .bat in the folder /openthread/project/

Is there any guide for this SDK? Can you help me?

[AndreasF]

Hi again.

If you are talking about the first thing I commented on, then it will have a influence in the certification because this window is determind by the specification and should be such value as it already is.

The second longer window can be changed as you like without any issues for the certification.

Edward_Atam said:

Also, I would like to ask about how to rebuild the OpenThread project:

 Yes, it was a bug in the last release that these scripts were missing. There was a bug related release the other day of the SDK, version 3.1.0 you can download. The script is in this release, it is a Python script.

In the external\openthread\project folder.

Best regards,

Andreas

[Edward_Atam]

Hi Andreas,

I followed your advise and I downloaded the new SDK, and I did the next steps.Everything was fine but step 5. When I tried to complie the example "simple thread client"  I got an error .Please see the screeen shot at the step 5 bellow.

Step 1:

  clone https://github.com/openthread/openthread

Step 2:

  Copy the openThread master folder to this location in the SDK: (Thread and Zigbee SDK v3\external\openthread\project)

Step 3:

   py -3 build_gcc_libs.py

Step 4:

   py -3 import_libs.py gcc

Step 5:

C:\Nordic\nRF5_SDK_for_Thread_and_Zigbee_v3.1.0\examples\thread\simple_coap_client\pca10056\blank\armgcc>make

  

What I did wrong??

Thanks in advance.

 Edward.

[AndreasF]

Hi.

Which commit did you build the libraries with?

Did you use this:

github.com/.../2279ef610eef80597bd789611d6931b95e08bf48

If you try to use master you might have problems compiling since the SDK is built upon the commit above, not on the master branch.

Best regards,

Andreas