Looking for power comparison for interrupt based wakeup: running external RTC (clock) vs using RTC (counter) and the Date-Time library

[rkguy]

For my application, most of the time, the device is asleep with the exception of sensor reading and logging every 5 minutes and occasional (and infrequent) beaconing so the device can be interrogated. 

I'm trying to understand if it is better to use an external DS3231 RTC or use the library below to bring the nrf5340 out of sleep to talk to various I2C and SPI sensors, timestamp log some data, go back to sleep.

It certainly looks like date-time can be used to timestamp the data but can it also be used to come out of deep sleep every 5 minutes? How deep can the device sleep while still running the RTCounter? Is it better to just go to an even deeper sleep state and use an external clock to interrupt and wake the chip? Does Bluetooth beaconing mean that the chip can't go into very deep sleep anyway?  

Date-Time — nRF Connect SDK 2.0.99 documentation (nordicsemi.com)

[Einar Thorsrud]

Hi,

Ignoring an external RTC for now, the sensible way to keep track of time in a low-power nRF application, is using an RTC which runs of the 32.768 kHz low frequency clock. This is used by virtually all applications, and if you use zephyr APIs like for instance delayed work in a work queue or have a task that wait for a specific amount of time. So, if you have work that needs to be done regularly or some time in the future, you would normally use those mechanisms. The basic approach would be to use k_msleep() like in blinky. In the end, what you have are RTC interrupts used to wake up the device at the right times. And the default idle thread in Zephyr will cause the device to enter system ON low power mode. Such mechanisms can be used to delay/schedule any code to run a ta later point, for instance to stop/start advertising, read sensors or whatever else your code needs to do.

I'm trying to understand if it is better to use an external DS3231 RTC or use the library below to bring the nrf5340 out of sleep to talk to various I2C and SPI sensors, timestamp log some data, go back to sleep.

If you use an external RTC then then nRF could be in system OFF low power mode instead of system ON low power mode, and it could wake up on pin interrupt, LPCOMP or similar. The sleep current consumption would be in the same order of magnitude though (see Current consumption), and wakeup from system OFF involves a reset, with re-initialization etc, so in most cases that is not a good idea.

It certainly looks like date-time can be used to timestamp the data but can it also be used to come out of deep sleep every 5 minutes?

The Date-Time library is not relevant for waking up from sleep every x time. For that, just use what the normal Zephyr API as explained. Moreover, the Date-Time library specifically uses the nRF9160 cellular modem and is not generic, so it has no use on the nRF5340.) There is no out of the box solution that gives you a calendar in the nRF Connect SDK, but you have some of the building blocks (see Time Utilities).

How deep can the device sleep while still running the RTCounter?

It depends a bit on the conditions (see the current consumption table I linked to above), but we are talking about a few micro amps. (For most application the sleep current will also be just a small fraction of the average current consumption, so optimizing here might not give you much in the end.)

Is it better to just go to an even deeper sleep state and use an external clock to interrupt and wake the chip?

This is application specific, but normally not. It would increase the BOM, increase the complexity and if wake-up is too frequent, perhaps even increase the average current consumption (due to CPU time spent re-initializing after wakeup from system OFF).

Does Bluetooth beaconing mean that the chip can't go into very deep sleep anyway?  

While advertising, the BT stack needs to keep track of time in order to wake up in time for the next advertising event, so system ON low power mode is the deepest low power mode e that can be used while advertising.