Power Profiler for Zigbee

[Jorcis]

Hi,

Is there any similar to Online Power Profiler for Zigbee? How much my nRF52840 application should consume when using zboss stack? What is the minimum expected consumption for a Zigbee nRF52840 app?

I have implemented an application as peripheral BLE, using Zephyr. It consumes an average of 100 uA, so good !!!.

I have migrated this application to Zigbee (not multiprotocol at the moment), using NCS instead; functionality is OK, initialization of the hardware components is OK, but after enabling the Zigbee stack ( zigbee_enable(); ) the consumption steps up to 10 mA, which is 100 more times than the consumption with the BLE app.

Note: I do call the function zb_sleep_now(); when sig equals ZB_COMMON_SIGNAL_CAN_SLEEP in my zboss_signal_handler, but nothing changes.

Thanks,

Jordi.

[Simonr]

Hi

I'm afraid we don't have an online power profiler for Zigbee specifically, as we haven't made a power profiler for every specification the nRF series support. 

10mA sounds very high indeed, but it will depend on what your application is doing exactly. If it just transmits a message and sleeps for some time the current consumption should be possible to get very low, while if you are constantly scanning for incoming messages or sending data, the current will indeed be high. Can you explain what your application does specifically, and when you call the zb_sleep_now() function in your application. Also do you use any peripherals other than the radio on the nRF52840, as that might consume power as well. 

Lastly, how do you measure the current consumption on your device exactly? Using a multimeter or a PPK, or some other method?

Best regards,

Simon

[Jorcis]

Hi Simon,

Thanks for your quick answer.

I have solved the consumption problem inserting the following lines:

zb_set_ed_timeout(ED_AGING_TIMEOUT_64MIN);
zb_set_keepalive_timeout(ZB_MILLISECONDS_TO_BEACON_INTERVAL(3000));
zb_set_rx_on_when_idle(ZB_FALSE);

As suggested the issue "Zigbee + FreeRTOS End Device power consumption"

The device is consuming now 60-80 uA in sleep mode, which is good, pretty good :-). And this 60 uA consumption is mainly due to external circuitry.

¿What are the possible the cons of the new configuration?

The application is a DOOR_LOCK, configured as an END_DEVICE. It has 6 input clusters, and 0 output clusters. Relevant clusters are ZB_ZCL_CLUSTER_ID_DOOR_LOCK itself, and ZB_ZCL_CLUSTER_ID_POWER_CONFIG.

The application can report 4 attributes at specific events. Reported attributes are the door lock state, deadbolt alarm, remaining battery, and battery alarm.

It also registers a callback for handling the ZB_ZCL_DOOR_LOCK_LOCK/UNLOCK_DOOR_CB_ID commands.

The function zb_sleep_now() is called inside the zboss_signal_handler. I attach the body of the zboss_signal_handler here in case you can suggest any improvement:

void zboss_signal_handler(zb_bufid_t bufid)
{
	zb_zdo_app_signal_hdr_t *p_sg_p = NULL;
	zb_zdo_app_signal_type_t sig = zb_get_app_signal(bufid, &p_sg_p);
	zb_ret_t status = ZB_GET_APP_SIGNAL_STATUS(bufid);
	// Can be used to identified if connected to zigbee net

	/* No application-specific behavior is required.
	 * Call default signal handler.
	 */
	ZB_ERROR_CHECK(zigbee_default_signal_handler(bufid));

	if(sig == ZB_BDB_SIGNAL_STEERING || sig == ZB_BDB_SIGNAL_DEVICE_REBOOT){
		if(status == RET_OK){
			if(dev_ctx.configuration.client_short_addr == 0xffff){
				LOG_INF("Steering successful!");
				steering_success = true;
				// do whatever as zigbee steering has been successful
			}
		}
	}
	else if(sig == ZB_COMMON_SIGNAL_CAN_SLEEP){
		LOG_INF("ZB_COMMON_SIGNAL_CAN_SLEEP");
		if(steering_success == true){
			zb_sleep_now();
		}
	}
	/* All callbacks should either reuse or free passed buffers.
	 * If bufid == 0, the buffer is invalid (not passed).
	 */
	if (bufid) {
		zb_buf_free(bufid);
	}
}

The peripherals used are:

CONFIG_SERIAL=n
CONFIG_GPIO=y
CONFIG_PWM=y
CONFIG_I2C=y
CONFIG_SPI=y
CONFIG_ADC=y
CONFIG_WATCHDOG=y
CONFIG_CRYPTO=y

As you can see, SERIAL driver is disabled, because when I enable it, the consumption increases to 1 mA. ¿Have any idea about that? That increasing consumption could be a handicap for me in the future if I need to use the UART.

And finally, yes you are right, I measure the power consumption using PPK2.

Many thanks for your advice and time

Regards,

Jordi.

[Simonr]

Hi

Glad you were able to reduce the current consumption.

Enabling the UART shouldn't require much current by itself, and transmitting (over TXD) will only consume current during the transmissions. What I thinks is happening, is that when you start RX data, the SoC will draw quite a bit of current since it needs to have clocks, regulators and EasyDMA channels open to handle the potential incoming data on the RXD. Using a duty cycle to start and stop RX is recommended in order to reduce current consumption here. Typically this can for instance be controlled by a GPIO input, where the peer set a pin high whenever it has data to send, and this pin will start/stop the RX on the nRF.

Best regards,

Simon