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,

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