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

[gorka]

Hello again, 

Finally I have discovered what was that consumption, and is not related to the BME688, is related to the BMM150.

I don't know exactly why but I suppose is related to the devicetree of the Thingy:53. Even if I don't use anywhere it looks like it activates. To disable it I have to write the CONFIG_BMM150=n in prj.conf.

After that, the consumption spikes disappear.

Thank you for your attention and help!

Gorka.

[AHaug]

Hi,

gorka said:

Finally I have discovered what was that consumption, and is not related to the BME688, is related to the BMM150.

Happy to hear that you discovered the cause of consumption! I was looking around some yesterday afternoon with the BME680 sample, but I could not find the cause myself. But thats not a wonder if it was caused by another peripheral

gorka said:

I don't know exactly why but I suppose is related to the devicetree of the Thingy:53. Even if I don't use anywhere it looks like it activates. To disable it I have to write the CONFIG_BMM150=n in prj.conf.

This is the way to do it. You must disable it like this and/or you should disable it in the overlay in a similar fashion as the example below (which disables the QSPI peripheral):

CONFIG_NORDIC_QSPI_NOR=n

And in your overlay file you should set

&qspi {
	status = "disabled";
};

So i.e the same goes for the sensor you have set up, given that the sensor is a part of your board files. Also remember to double check with any board files within child images that you have disabled the peripherals there as well. Sometimes there are configurations that selects or implies that a configuration should be selected, even though you've disabled it in your prj.conf (kconfig fragments and child overlay configurations override the settings in prj.conf).

gorka said:

After that, the consumption spikes disappear.

Good job navigating down where the true cause for the consumption was!

gorka said:

Thank you for your attention and help!

Happy to help you get there!

Kind regards,
Andreas