End Device reports bad behavior on low power device

[sjf]

Hi,

We have been working with an end device based on nRF52840 with nRF5_SDK_for_Thread_and_Zigbee_v4.0.0_dc7186b, Softdevice and FreeRTOS.

We built 2 configurations for this device: normal and low power. The last one contains some considerations like:

- At FreeRTOSConfig.h we set configUSE_TICKLESS_IDLE to 1

-We enabled SoftDevice Low power mode and enabled DCDC mode

-Also set SCB_SCR_SLEEPDEEP_Msk flag

Once joined to a Zigbee network, some cluster bindings are performed automatically to the coordinator and some reports are automatically being sent. The max time for each one is 60 seconds while the min timeout is 0.

On normal configuration, attribute reporting is accomplished without problem every 60 seconds. But in the low power configuration, times get longer and seem to increase with the time.

Is there any special consideration or appropiate setting for low power mode?

Regards,

Santiago

[Marte Myrvold]

Hi Santiago,

Is the problem that attribute reporting takes longer than 60 seconds when in low power mode? Is the time it takes the same every time or is it a random delay, so the time it takes changes every time?

How are you implementing the low power mode on the end-device?

Best regards,

Marte

[sjf]

Hi Marte,

The attribute reporting takes more than max time (60 seconds) and seems to increase on further reports (not random)

The low power mode is implemented with the changes detailed above. Also we are implementing this in the Zigbee Task (FreeRTOS):

zb_void_t zb_osif_go_idle(zb_void_t)
{
    /* Intentionally empty implementation */
#ifdef LOW_POWER
    nrf_802154_sleep_if_idle();
    /*do not set long timeout if joining*/
    if(ZIGBEE_STATE_JOINING != zigbee.state)
    {
      zigbee.cmd_queue_timeout = ZIGBEE_QUEUE_LONG_TIMEOUT;
    }
#endif
}

And also calling nrf_802154_sleep_if_idle() function on ZB_COMMON_SIGNAL_CAN_SLEEP signal handler.

Regards,

Santiago

  

[Marte Myrvold]

Hi Santiago,

I have asked our Zigbee team internally and will come back to you when I get a response from them.

Best regards,

Marte

[sjf]

Thanks Marte,

Is there any update on this?

Regards,

[Marte Myrvold]

Hi,

No, sorry, I'm still waiting for a response from the Zigbee team. They're quite busy right now, so it might take some time, but I've asked them if there are any updates dates on this case.

Best regards,

Marte

[Marte Myrvold]

Hi,

I got a reply from the Zigbee team now. They're not sure what the problem is, but they would start with these steps:

• Make sure that sleepy behavior is enabled for the end device
• Get rid of calls to nrf_802154 radio API - Sleepy End Device manages radio state and with sleepy behavior enabled, the radio is in standby when not used by the end device
• ZBOSS uses TIMER3 to keep time - make sure that its configuration is not changed

Some more information about the application would be helpful, as well as the traffic dump of the End Device reporting.

Best regards,

Marte

[sjf]

Hi Marte, thanks for your explanation.

I understand that if configUSE_TICKLESS_IDLE mode is set, then Timer3 will be stopped every time we get into deep sleep mode. 

I've checked that there is a non documented function called zb_zcl_adjust_reporting_timer(). Maybe it is related to this issue...

How can we avoid stopping Timer3 when going to sleep?

regards,

[sjf]

Hi Marte,

Is there any comment on this?

We need to get a response to get it work as soon as possible.

Regards,

[Marte Myrvold]

Hi Santiago,

I apologize for the late response.

The reason for the delay in attribute reporting might be caused by the fact that ZBOSS, or the Zigbee stack, is not aware of the fact that FreeRTOS sleeps, and as such, it will take longer time.

Please note that the examples with FreeRTOS in the Zigbee SDK are experimental, and are therefore not power optimized. However, I got some tips from the Zigbee team on how to implement low power with FreeRTOS and Zigbee:

In order to suspend the task, while the timer is disabled, you have to implement ZB_COMMON_SIGNAL_CAN_SLEEP ZBOSS signal handler. Otherwise, you are simply leveraging only the ZBOSS IDLE state, not the ZBOSS SLEEP state (more information about those states can be found here).

For some guidance and ideas how to implement this, it might be good to look at the OSIF implementation in NCS:

- CAN_SLEEP handler
- sleep routine (will be called by zb_sleep_now())
- Poll function

The signalling mechanism is used to wake up ZBOSS task by other tasks that wants to send something over Zigbee, as well as to wake up the ZBOSS task earlier than the sleep period, passed to the sleep function as an argument.

Best regards,

Marte

[sjf]

Hi Marte, 

I will try to do some measurements with Power Profiler as well as changing the source code with your recommendations.

. Just to be sure: Sleepy End Devices are set by just calling zb_set_rx_on_when_idle(ZB_FALSE).

. You suggest to implement ZB_COMMON_SIGNAL_CAN_SLEEP. I'm thinking on implement a modified version of zb_osif_sleep() on configPRE_SLEEP_PROCESSING and configPOST_SLEEP_PROCESSING.

Do you agree with this? Any other recommedation?

Regards