simple example for measuring power consumption

[bios-bob]

i'm looking for a simple example which i can run on nRF9151 DK (v0.9.0) where i can profile power consumption....

ideally, the example would repeatedly send packets over a cellular content -- and then enter a "low-power" sleep mode in between....

is the nrf/samples/cellular/udp application my best choice here???

if so, what current consumption numbers might i expect to see (using my PPK) -- as a sanity check for me....

[bios]bob

PS -- the AI answer gives me a place to start....  my let's keep this ticket open in case i have a follow-up question.... 

---------------------

Recommended Sample

The Cellular: UDP sample (samples/cellular/udp) in the nRF Connect SDK is the best choice for power profiling on the nRF9151 DK [Cellular: UDP Overview].

Key benefits of this sample for power measurements:

• Transmits simple UDP packets to a server at configurable intervals [Cellular: UDP Overview].
• Requests low-power network parameters, including Power Saving Mode (PSM) and eDRX [Cellular: UDP Overview].
• Logging output is disabled by default to minimize baseline current consumption [Cellular: UDP Overview].

---

Expected Current Consumption Benchmarks (PPK Sanity Check)

Note: Power consumption numbers vary depending on network conditions, signal quality, and network timers (such as RRC inactivity timers). [Power consumption]

1. PSM Floor (Low-Power Sleep):

   • ~2.7 µA to ~4 µA: Baseline current when the device enters PSM between transmissions [Real-time power measurement; YouTube: How to Power Profile].
   • During this mode, internal DC/DC converter charging cycles cause brief mA spikes, but quiet periods drop below 1 µA [Power consumption].
   • Troubleshooting: If you measure ~400 µA to 700 µA at idle, ensure that logging/UART is fully disabled [YouTube: How to measure power].
2. Active Transmission Event:

   • Peak Current: Spikes up to ~300 mA to 400 mA during maximum RF output bursts [Real-time power measurement; Power consumption].
   • Event Charge: A typical data upload sequence (including network setup, transmission, and RRC inactivity time) consumes around ~115 mC to 117 mC over ~12 seconds [Real-time power measurement; Real-time power measurement].
3. Average Current Over Time:

   • ~1.0 mA to 2.3 mA: When transmitting frequently (every 30 to 40 seconds) [Testing RAI feature; YouTube: How to measure power].
   • < 100 µA (e.g., ~80 µA to 90 µA): When transmitting infrequently (every 15 to 20 minutes), as the device remains in PSM sleep for most of the duration [YouTube: How to Power Profile].

---

Helpful References

• Cellular: UDP Sample Documentation [Cellular: UDP Overview]
• Power Profiling Cellular Applications Guide [Real-time power measurement]
• nRF9151 Hardware Verification Guidelines: Power Consumption [Power consumption]
• Online Power Profiler for LTE [Power Class 3 modem current consumption]

[Tomas M]

Hi Bob,

Definitely start out with the resources the AI recommended if you find them helpful. I wanted to just add on that we have a course on developing low-power applications on DevAcademy here. Now, it's not entirely applicable to your use-case since it targets BLE applications specifically, but the majority of concepts transfer over directly. Especially check out Lesson 3 for information on profiling. It's especially easy if you have one of our Power Profiler Kits (PPK).

Let me know if you have any questions!

Best regards,
Tomas

[bios-bob]

hi tomas,

the UDP example is working fine for me, with idle current in the ~2uA range....

i'm bringing up my own "bare-metal" environment on the nrf91 M33 core -- similar to what i already have on the nrf52 and nrf54....

everything is working functionality -- though my idle current is over 4mA !!!

here's a simple standalone program that illustrates my startup sequence before WFI....

#include <stdint.h>
#include "nrf9120.h"

int main(void)
{
    /* Ensure modem domain is off */
    NRF_POWER_S->LTEMODEM.FORCEOFF = 1;
    while (NRF_POWER_S->POWERSTATUS != 0) {
    }

    /* Select low-power / variable-latency mode */
    NRF_POWER_S->TASKS_LOWPWR = 1;

    /* Start 32.768 kHz crystal */
    NRF_CLOCK_S->EVENTS_LFCLKSTARTED = 0;
    NRF_CLOCK_S->LFCLKSRC = CLOCK_LFCLKSRC_SRC_LFXO;
    NRF_CLOCK_S->TASKS_LFCLKSTART = 1;

    while (NRF_CLOCK_S->EVENTS_LFCLKSTARTED == 0) {
    }

    NRF_CLOCK_S->EVENTS_LFCLKSTARTED = 0;

    /* Release any explicit HFXO request */
    NRF_CLOCK_S->TASKS_HFCLKSTOP = 1;

    /* Sleep forever */
    while (1) {
        __asm volatile ("wfi");
    }
}

i've verified that the WFI does *not* return....

presumably, i've left "something running" that's consuming the 4mA....  again, this is directly out of reset.... (no zephyr!!!!)

[bios]bob

[Tomas M]

Hi Bob,

Thank you for your patience with this topic. Can you tell me about the bare-metal environment for the nRF9151? As far as I'm aware, the nRF Connect SDK bare-metal is for the nRF54L series devices.

Best,
Tomas

[bios-bob]

hi tomas,

by "bare-metal", i mean *NO* SDK....  as i've done with other nordic devices, i have my own (very, very small) runtime environment which i'm currently porting to the nrf91....

i've actually gotten a little further -- now having ported the core environment to the nrf91....

my original question came from my first power measurements -- which showed a 4mA sleep current!!!!

in the meanwhile, i've kept investigating the protocol between the M33 and the MODEM....  at this point, i understand enough to perform the initial "handshake"....  my goal is to essentially reproduce the zephyr UDP example -- but in just a fraction of the code!!!!

in the very near-term, i'm using the tfm_s.hex image as a "bootloader" for my own (very small) app....  for reasons i'm still trying to understand, this image is putting the M33 into some NS state that is *necessary* to communicate with the MODEM....

so, at this time i'm not "blocked" -- though always looking to better understand the "bare-metal" interaction between M33 and MODEM...

[bios]bob

[Tomas M]

Hi Bob,

Admittedly this is not my area of expertise, but are you aware of these commands?
west build -t initlevels
west build -t dashboard
They might be useful for tracing the different initalization calls and hardware configurations that are done in the background in a minimal firmware. Hopefully you'll be able to find something relating to misconfigured GPIOs or other things that might be causing the 4mA current draw.

Another thing to look into is whether the 4mA current draw is present always or just during sleep mode. Maybe that will be another useful hint.

Let me know if there's anything I can answer!

All the best,
Tomas