nrf54l10 zigbee R23 sleepy end device behavior

Dear all 

I am developing a product using the nRF54L10 with the Zigbee add-on v1.2.0.
I have a question regarding sleep behavior.

The current measurements below show the power consumption of the actual device
when start_network_rejoin() is not started at the time of ZB_BDB_SIGNAL_DEVICE_FIRST_START after boot.
The average current consumption is about 7 µA.

However, when the device is booted and start_network_rejoin() is initiated at ZB_BDB_SIGNAL_DEVICE_FIRST_START,
and there is no network available, stop_network_rejoin() is called after 200 seconds.
What I am wondering is whether the device does not enter sleep mode after this point, because the current consumption does not drop.
My code is below 

void ws_zigbee_init(void)
{
	ws_zigbee_print_information();

	test_aes();

	set_tx_power();
	zigbee_erase_persistent_storage(false);

	zb_set_ed_timeout(ED_AGING_TIMEOUT_8MIN);
	zb_set_keepalive_timeout(ZB_MILLISECONDS_TO_BEACON_INTERVAL(120*1000));

	zigbee_configure_sleepy_behavior(true);

	app_clusters_attr_init();
	ias_zigbee_fota_init(ota_evt_handler);

	ZB_AF_REGISTER_DEVICE_CTX(&ias_zone_ctx);

	ZB_ZCL_REGISTER_DEVICE_CB(zcl_device_cb);
	ZB_AF_SET_IDENTIFY_NOTIFICATION_HANDLER(ZB_HA_IAS_ZONE_ENDPOINT, identify_cb);
	zb_zcl_ias_zone_register_cb(ZB_HA_IAS_ZONE_ENDPOINT, NULL, ias_zone_general_cb);

	LOG_INF("IAS Zone windows sensor Start");

	/* Power off unused sections of RAM to lower device power consumption. */
	if (IS_ENABLED(CONFIG_RAM_POWER_DOWN_LIBRARY)) {
		power_down_unused_ram();
	}

	zigbee_enable();
}


I have no experience with Zigbee. I am not sure whether this behavior is normal or not.
If it is not, I would like some guidance on how to reduce the current consumption.

Parents
  • Is there really no one who can tell me about this?

  • Sorry about the wait Hyojoon,

    hyojoon said:
    The part you mentioned has already been applied.

    Ah right. In that case I do not see that you are missing anything. Though it might be that you do actually have to be connected to a network first, and that start_network_rejoin() is mainly for when you were already connected. I am uncertain about that. 

    Are you seeing the same issue with something like the Zigbee: Light switch sample, which is meant to be able to demonstrate the sleeping behavior?

    Regards,

    Elfving

  • Hi Elfving 

    As you suggested, I added the code, but the issue remains the same

    The image below shows the behavior for the R22 version, not the add-on.
    As you can see, when the channel is not found, the current drops close to sleep mode levels.

    This is the behavior I want.
    Currently, the R23 add-on does not operate this way.

  • void zboss_signal_handler(zb_bufid_t bufid)
    {
        zb_zdo_app_signal_hdr_t *sig_hndler = NULL;
        zb_zdo_app_signal_type_t sig = zb_get_app_signal(bufid, &sig_hndler);
    #ifdef CONFIG_WINDOWS_ITP
        zb_ret_t status = ZB_GET_APP_SIGNAL_STATUS(bufid);
    #endif

    #ifdef CONFIG_ZIGBEE_FOTA
        /* Pass signal to the OTA client implementation. */
        ias_zigbee_fota_signal_handler(bufid);
    #endif /* CONFIG_ZIGBEE_FOTA */

        if(sig != 22) {
            LOG_INF("zboss_signal_handler sig : %d", sig);
        }

        switch (sig) {
            case ZB_BDB_SIGNAL_DEVICE_REBOOT:
                __fallthrough;
            case ZB_BDB_SIGNAL_STEERING:
                ZB_ERROR_CHECK(zigbee_default_signal_handler(bufid));
                ZB_TRANSCEIVER_SET_RX_ON_OFF(zb_get_rx_on_when_idle());
            break;
    Ultimately, if the connection fails, the current still does not drop.

  • Hmm. Making this change should be enough for it to work with eg. ncs-zigbee\samples\light_switch\ sample.

    ...
        case ZB_BDB_SIGNAL_STEERING:
            /* Call default signal handler. */
            ZB_ERROR_CHECK(zigbee_default_signal_handler(bufid));
            if (status == RET_OK) {
                /* Check the light device address. */
                if (bulb_ctx.short_addr == 0xFFFF) {
                    k_timer_start(&bulb_ctx.find_alarm,
                              MATCH_DESC_REQ_START_DELAY,
                              MATCH_DESC_REQ_TIMEOUT);
                }
            }
            ZB_TRANSCEIVER_SET_RX_ON_OFF(zb_get_rx_on_when_idle());
            break;
    ...

    it can be added to the zigbee_default_signal_handler as well, but both should work. Could you try adding it there though and see if it makes a difference on your side?

    However the call is meaningless for non-ZED devices (zb_get_rx_on_when_idle() is always true), so having it in the specific sample for ZED is enough or it can be added to the default signal handler within

    #if defined CONFIG_ZIGBEE_ROLE_END_DEVICE

    Regards,

    Elfving

  • When system gets ZB_BDB_SIGNAL_TC_REJOIN_DONE then current still does not drop

    I: zboss_signal_handler sig : 58
    I: TC Rejoin was not successful (status: -1)
    I: start_network_rejoin ZB_JOINED 0 wait_for_user_input 1 is_rejoin_procedure_started 1
    I: rejoin_the_network Network rejoin procedure stopped as scheduled.

    ZB_BDB_SIGNAL_STEERING 
    ZB_BDB_SIGNAL_DEVICE_REBOOT 
    ZB_BDB_SIGNAL_TC_REJOIN_DONE
    It works when I add it to those three signals.
    Please check with the R&D team if there are any other signals I should add it to.
    Also, I think this shouldn’t be handled through the signal but rather at the driver level.
    Is there any way to handle it within the driver or SDK itself, similar to how it was done in R22?
  • I see. It has internally been suggested that it should be added to ZB_BDB_SIGNAL_TC_REJOIN_DONE as well, didn't think about ZB_BDB_SIGNAL_DEVICE_REBOOT yet though. Like you say, it might be some other signal we've overlooked here this far.

    It has been reported to our ZBOSS provider, like you say it will likely result in a fix in the driver. 

    Regards,

    Elfving

Reply
  • I see. It has internally been suggested that it should be added to ZB_BDB_SIGNAL_TC_REJOIN_DONE as well, didn't think about ZB_BDB_SIGNAL_DEVICE_REBOOT yet though. Like you say, it might be some other signal we've overlooked here this far.

    It has been reported to our ZBOSS provider, like you say it will likely result in a fix in the driver. 

    Regards,

    Elfving

Children
No Data
Related