OpenThread Sleepy end device failure

RE: OpenThread Sleepy end device failure

Amadeus — Mon, 07 Sep 2020 10:19:17 GMT

I tried on the latest master branch again, and at it looks like the MTD is entering sleep mode. At least, no mesh link error occurs. However, it is not obvious to me how the poll period and communication with the SED works. I am not able to communicate with the SED with multicast messages, which is sort of expected. My understanding is that the SED needs to poll its parent for data, but I am not aware of how this is done. Do you have any details on this?

RE: OpenThread Sleepy end device failure

Amadeus — Fri, 04 Sep 2020 06:34:28 GMT

Hello,

Indeed, it looks like the SED call succeeds on tag v.1.3.0. It still fails the latest release of the master branch. Do you know how the power management is handled for the SED's on tag v1.3.0 compared to the latest release? The toggle_minimal_sleepy_end_device() function is updated with power management features on the master branch.

RE: OpenThread Sleepy end device failure

Edvin — Mon, 31 Aug 2020 13:05:34 GMT

Hello,

So I tested the unmodified coap_client example from NCS, and at first I also saw the "Failed to set MLE link mode configuration", but I did an nrfjprog --eraseall, and the issue went away.

Can you please test this? If that doesn't work, I am running on NCS v1.3.0, can you please test that tag? The master may or may not work, based on when you fetched it.

Best regards,

Edvin

RE: OpenThread Sleepy end device failure

Amadeus — Wed, 26 Aug 2020 07:40:56 GMT

Hello,

I am using the nRF52840 DK. I call coap_client_toggle_minimal_sleepy_end_device() with a button press which submits the toggle_MTD_SED_work struct to the work queue. This struct is bounded to toggle_minimal_sleepy_end_device() in an init function. The function is called only once per button click; I have checked this.

I am using the latest version on the master branch; updated the repo yesterday. Still getting the same error.

Yes, I can send the project which produces this error. How do we proceed?

RE: OpenThread Sleepy end device failure

Edvin — Tue, 25 Aug 2020 14:13:24 GMT

Hello,

I spoke with the our OpenThread team. They say that this seems strange. What HW are you running this on?

Where do you call toggle_minimal_sleepy_end_device() from? And how often/fast do you call it? In case it is on a button press, may it be that it is being called many times, due to a bounce?

What NCS version are you using? 1.3.0? Is there some way for us to reproduce this on a DK? Is it possible to send a project that will reproduce this?

Best regards,

Edvin

RE: OpenThread Sleepy end device failure

Amadeus — Mon, 17 Aug 2020 07:01:40 GMT

Hello Edvin,

See attachment below.

This function is correctly submitted to the work queue and called when enabling CONFIG_OPENTHREAD_MTD_SED. However, the if statement on line 231 evaluates to true because otThreadSetLinkMode() returns OT_ERROR_INVALID_ARGS.

See attachment below for declaration of otLinkModeConfig struct returned from otThreadGetLinkMode() on line 222:

The fields of this struct are true, false, true, true (1, 0, 1, 1) when passed to otThreadSetLinkMode(). I reckon the third field, bool mDeviceType, should be false?

RE: OpenThread Sleepy end device failure

Edvin — Tue, 11 Aug 2020 10:42:50 GMT

Hello Ernst,

I am terribly sorry for the late reply. Are you still struggling with this?

Let me see if I get this right:

toggle_minimal_sleepy_end_device() returns OT_ERROR_INVALID_ARGS.

[quote user=""]and the booleans in the mode bit field returned from otThreadGetLinkMode(instance) evaluates to true, false, true, true - respectively. Thus, mode.mDeviceType indicates that the "sender" is an FTD, which i reckon is the problem here. [/quote]

What do you mean by "the sender"? Is this the device that you are trying to put in sleepy end mode? Can you clarify what otThreadGetLinkmode returns? instance is the type otInstance, right? What parameters are "true, false, true, true"?