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

Yes, I can see

Have you followed section 3.1.1 in the nRF Sniffer for 802.15.4 user guide to configure the decryption keys before starting to capture. This is something that must be done before  capturing data and won't be "unlocked" by adding the correct key on a finished filter.

Regarding the log and THSM sleep. Yes I can see that the debug log is putting the THSM to sleep, but it does not seem to set the radio into a sleeping state. I'm not able to see what exactly your THSM_sleep_e and THSM_idle_e events are doing from your code snippets. What functions are they calling that puts the nRF into sleep exactly?

Best regards,

Simon

[Abhijith.Desai]

Hi

Yes for sure we are not handling any sleep and receive states of radio manually right now. the THSM_IDLE and THSM_SLEEP states are just doing the application part and switching we are not trying to put radio to sleep since they say not required to put manually to sleep of invoke receive states of radio https://github.com/openthread/openthread/issues/1495.

Please correct me if i am wrong in understanding

Yes regarding the network key you are right we cannot add it once it is finished sniffing, will see the configuration part you suggested.

Regards

Abhijith