Current consumption on Thingy:53 Zigbee SED

[gorka]

Hello everyone,

I'm working on a Zigbee project that has the Thingy:53 as an end node. The program of the Thingy is a variation of the Zigbee Weather Station. 

I'm measuring the current consumption of the board in different states, and I have some doubts about it's current consumption when is in sleep mode. The application has the SED (Sleepy End Device) configuration is used.

• As can be seeing in the image below, that is taken when the device is in sleep mode, there are times when the device consumes more. Possibly because it has some tasks to do, but I want to know why this happens if possible.

• And about Zigbee, the device often sends data requests to the coordinator. Searching about that I have found that there is some type of polling that end device does, and that the period of this can be changed. Is it necessary for the end device to poll often? Or is it not a problem for example setting this on hours period or if its possible to delete it.

Thanks for your help.

[AHaug]

Hi,

As can be seeing in the image below, that is taken when the device is in sleep mode, there are times when the device consumes more. Possibly because it has some tasks to do, but I want to know why this happens if possible.

It's not really easy to see whats happening on the image since the image does not give any insight to the axis sizes, and also it could be a better indicator to measure µAs rather than the µV w.r.t measuring currentconsumption

s taken when the device is in sleep mode, there are times when the device consumes more. Possibly because it has some tasks to do, but I want to know why this happens if possible.

Yes, this is correct, the device has things that it is required to to. What you're seeing is that the device regularly polls its parent device for data 

See for instance this page for some insight into what https://developer.nordicsemi.com/nRF_Connect_SDK/doc/latest/nrf/protocols/zigbee/configuring.html#sleepy-end-device-behavior as well as download the Zigbee specification from CSA https://csa-iot.org/developer-resource/specifications-download-request/.

From the first link: "By default, the end device regularly polls its parent for data. When the SED behavior is enabled and no frames are available for reception after the last poll, the SED disables its radio until the next scheduled poll. The Zigbee stack’s own scheduler informs the application about periods of time when nothing is scheduled for any of the device roles. This allows the stack to enter the sleep state during these periods, which also powers off some peripherals for the SED."

These are parameters and settings that you can set yourself, given that you comply with the keep alive routines that is required based on the specification. Most samples have a 

Or is it not a problem for example setting this on hours period or if its possible to delete it.

Yes, you can increase this interval, but you can't delete it. If you do there are no ways to wake the device and for it to poll its parent so the network will consider this device as "dead" and remove it from the network unless it lets the network know it is alive and present.

Kind regards,
Andreas

[gorka]

Thanks for the answer,

AHaug said:

Yes, this is correct, the device has things that it is required to to. What you're seeing is that the device regularly polls its parent device for data

I think that's not the case because that occurs even when the device is not connected. In the image below can be seen that in sleep mode, sends a data request (left) and my doubt is the consumption of the right part.

The zigbee polling part cleared, thanks,

Gorka

[AHaug]

Hi,

gorka said:

I think that's not the case because that occurs even when the device is not connected.

There should not be anything other than the keepalive and polling w.r.t Zigbee that causes Zigbee activity and current draw, but as you mention you're using a weather station sample. There could be sensors gathering sensor data or similar. Have you verified if this activity occurs and is ongoing?

It could also be that the device tries to join a network. Could you check with a Zigbee sniffer (https://docs.nordicsemi.com/bundle/ug_sniffer_802154/page/UG/sniffer_802154/intro_802154.html) and verify if the device sends any Zigbee data packs? If you've enabled attribute reporting it will also send this in addition to the other Zigbee packs when it is connected to the network.

I would also like to suggest that you test the sleep current might be to use a sample that does not do as many things in addition to Zigbee sleep activity to avoid having other sources interfering in your measurement. You can for instance select one of the other Zigbee ED samples mentioend in https://developer.nordicsemi.com/nRF_Connect_SDK/doc/latest/nrf/samples/zigbee.html#zigbee-samples 

Kind regards,
Andreas

[gorka]

Hi,

As you mentioned I try to measure the SED with other samples, and you're right the device consumes the same all the time. It has to be something related to the sensor.

So to test that, I measure when is not connected to any coordinator and is not sending any kind of packets (checking it with the sniffer), and the same consumption continues. In the image below I capture a reading of the sensor, and you can see the consumption of the sensor reding temp, hum and press, and you can notice that it seems to have the same consumption spikes that the device has when is sleeping (circles in red).

Do you know why it can be?

Thank you,

Gorka

[gorka]

Hello,

I have conducted further tests, and it appears the consumption issue is related to the BME680 sensor. As you mentioned, when using the switch example with SED, this consumption is not present.

Additionally, using the BME680 sample, I observed that upon activating the BME680 sensor, the consumption manifests with a 100ms period, which I suspect is due to sensor fetching. Could you advise on how to power it down? I currently fetch data manually before reading from the channels.

Thank you,

Gorka

[AHaug]

Hi,

gorka said:

I have conducted further tests, and it appears the consumption issue is related to the BME680 sensor. As you mentioned, when using the switch example with SED, this consumption is not present.

Glad to hear that you've verified this-

gorka said:

I observed that upon activating the BME680 sensor, the consumption manifests with a 100ms period, which I suspect is due to sensor fetching

The BME680 sample is set up to fetch and print the output every 3000 msec, are you certain that the period is 100 msec? Does the sensor_sample_fetch match the consumption spikes intervals?

gorka said:

Could you advise on how to power it down? I currently fetch data manually before reading from the channels.

Some advice/hints: IF the sampling is set in the device driver, you should be able to either create your own custom version of the device by creating a device binding and make your changes there.

Uses this driver https://github.com/nrfconnect/sdk-zephyr/tree/main/drivers/sensor/bme680 

Alternatively I would recommend that you investigate this topic https://academy.nordicsemi.com/courses/nrf-connect-sdk-fundamentals/lessons/lesson-6-serial-com-i2c/ and this exercize https://academy.nordicsemi.com/courses/nrf-connect-sdk-fundamentals/lessons/lesson-6-serial-com-i2c/topic/exercise-2-12/ 

gorka said:

I currently fetch data manually before reading from the channels.

Could you share the code of the bme680 sample where you do this?

Kind regards,
Andreas

[gorka]

Thank you for your response!

AHaug said:

The BME680 sample is set up to fetch and print the output every 3000 msec, are you certain that the period is 100 msec? Does the sensor_sample_fetch match the consumption spikes intervals?

You are correct that the sample is set up to fetch al 3000msec, but the spikes are at 100ms period.

AHaug said:

Could you share the code of the bme680 sample where you do this?

The sensors reading in my application are done like in the Zigbee weather station:

static void check_weather(zb_bufid_t bufid)
{
	ZVUNUSED(bufid);

	int err = weather_station_check_weather();

	if (err) {
		LOG_ERR("Failed to check weather: %d", err);
	} else {
		err = weather_station_update_temperature();
		if (err) {
			LOG_ERR("Failed to update temperature: %d", err);
		}

		err = weather_station_update_pressure();
		if (err) {
			LOG_ERR("Failed to update pressure: %d", err);
		}

		err = weather_station_update_humidity();
		if (err) {
			LOG_ERR("Failed to update humidity: %d", err);
		}
	}

	zb_ret_t zb_err = ZB_SCHEDULE_APP_ALARM(check_weather,
						0,
						ZB_MILLISECONDS_TO_BEACON_INTERVAL(
							WEATHER_CHECK_PERIOD_MSEC));
	if (zb_err) {
		LOG_ERR("Failed to schedule app alarm: %d", zb_err);
	}
}

AHaug said:

Uses this driver https://github.com/nrfconnect/sdk-zephyr/tree/main/drivers/sensor/bme680 

Alternatively I would recommend that you investigate this topic https://academy.nordicsemi.com/courses/nrf-connect-sdk-fundamentals/lessons/lesson-6-serial-com-i2c/ and this exercize https://academy.nordicsemi.com/courses/nrf-connect-sdk-fundamentals/lessons/lesson-6-serial-com-i2c/topic/exercise-2-12/ 

I'm going to try both solutions and came back to inform you,

Thanks!

Gorka