NRF52840 Thread example power down 10 mins after USB disconnect

[meetandyhere]

Hello,

I am trying the Thread Cloud COAP Client

<InstallFolder>\examples\thread\experimental\cloud_coap_client

on a NRF52840 PDK. I'm using Thread SDK v0.10.0. The example works as described.

However, when I unplug the board from USB, it goes into some kind of power down mode in approx. 10 minutes and loses connection to the Thread network. I can see LED1 is still on, but it is extremely faint. It is flickering, so trying to connect to the network, but it cannot do so. After a further 5-6 minutes of this, LED1 goes completely off.

I had a few questions about this behaviour:

1. Where in the code can I set the time between USB disconnect and going in power-down mode?
2. I know that the NRF52840 has System ON and System OFF power modes. Where in the code can I set which mode it should go in?
3. Is the behaviour of it not being able to connect to the Thread network when in low power mode expected? If so, can I change this behaviour or is there a fix planned?

Thanks in advance!

Regards

Andy

[Krzysztof Loska]

Hi,

Thread Routers are not meant to be baterry-powered devices. Routers have their radio turned on and listening all the time when not transmitting. If you need energy optimization you have to use Thread Sleepy End Device role.

This new website is an official place which documents OpenThread project but it also includes very good guides on Thread itself e.g. about node roles and types.

[meetandyhere]

Thanks for the information! So the Cloud COAP client example in the Thread SDK is by default setup to assign router roles to nodes? I saw in the MTD COAP client some lines of code to make a node sleepy end deivce:

 otLinkModeConfig mode;
    memset(&mode, 0, sizeof(mode));
    mode.mRxOnWhenIdle       = false	; // Join network as SED.
    mode.mSecureDataRequests = true;
    assert(otThreadSetLinkMode(p_instance, mode) == OT_ERROR_NONE);

However, when I try to do this in the Cloud COAP client example, hostname resolution always fails. So I'm assuming that sleepy end devices do not do any hostname resolution themselves, but depend on the router?

[Robert Lubos]

Hi, my guess is that there is a mismatch between SED data poll period and DNS query timeout. The poll period is a time between consecutive polls for the data from SED to the parent. If the DNS query timeout is lower than the poll period, the query will fail before SED would even attempt to get the response (which will happen for default value of poll period). What you can try to do is to lower the pool period just after sending the DNS request, the same way we do in Thread MTD CoAP Client before sending CoAP requests: otLinkSetPollPeriod(m_app.p_ot_instance, DNS_POLL_PERIOD);. Just set the DNS_POLL_PERIOD to some reasonable value (default DNS response timeout is 3000 ms, so setting poll period to 500 ms should be fine).

[meetandyhere]

Setting poll period to 500 ms after just after sending DNS request solved it! Thanks!