Open thread : Rx is always ON after communication is completed (Doesnt goes to sleep) - power consumption is high.

[Abhijith.Desai]

Using windows 10 OS, and SES v5.40.

I am using nRF52833 device in my project along with nRF5_SDK_for_Thread_and Zigbee_v4.1.0_32ce5f8 SDK.

I am using openthread protocol for radio communication and i also know that we can use the below function to know the radio state and also joiner state

otJoinerGetState(ot_instance) - Joiner state and otPlatRadioGetState(ot_instance) - Radio state.

But if i try to print the radio state : Observations

a. Before joining - the radio state is 1(radio sleep) - power consumption is around 15uA - expected to be that power consumption.

b. During joining - the radio state toggles between 1,2,3 (sleep, Rx and Tx) - power consumption is around 20mA - Expected this power consumption during pairing.

c. After joining - the radio state is 2(Rx) once pairing is completed, and it doesnt goes to sleep anymore - power consumption is around 11mA - Expected to be 15uA once the device is in sleep.

Questions :

1. I tried to put the radio to sleep manually once pairing is completed - Facing issues with communicating again once pairing is done. Also found that there is no requirement of manually switching sleep and receive states from this discussion - https://github.com/openthread/openthread/issues/1495 - Please suggest right way to handle this.

2. Also found the link mode configuration settings - otLinkModeConfig mode;
                                                                                 memset(&mode, 0, sizeof(mode));
                                                                                 mode.mRxOnWhenIdle = false;   

        We are making mode.mRxOnWhenIdle true during initialisation and again false during cyclic wakeup - is there anything wrong with this configuration setting.

Note : All i want to do is putting back the radio state to 1 (sleep) once it completes communication to reduce power to 15uA.

[Simonr]

Hi

The logging here seems a bit off to me, since the one and only time the Radio status reports back 1 (radio sleep) is after a PREPARE_WAKEUP call from the THSM? After that it seems like the state machine goes to sleep and wakes up numerous times without interfacing with the radio peripheral at all. During debugging, do you have any indication that the THSM_SLEEP_e event actually puts the radio to sleep? What does the COMWIRELESS_RadioSleep(); function do exactly, and are you sure that it is getting called?

If you add some more prints (maybe inside the if settings, we should be able to see where the application goes in each state. We're not able to see much from the sniffer log unfortunately. Are you using another masterkey/IPv6 prefix than what is default? That would make Wireshark unable to decode the packets.

Best regards,

Simon

[Abhijith.Desai]

Hi

Yes i could see in the debugger window that THSM will go to sleep and then to idle(you can get that information from the debug log i shared).

The state machine goes to sleep state but the radio state goes to sleep only once after pairing to network(that is what is my concern).

SOrry for wrong information about OMWIRELESS_RadioSleep() we are calling it but the entire part inside that function is commented (after knowing that it is not required to manually switch the sleep and receive states of radio)

ea88129601832ebc05dc06b68fe39420 or 4f42ca5cb60755cf61667e1a6beded7b or 47b314550ca8d0ef3f5842c038dd6b60 should be the key to open the sniffer data..