This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

Trying to reduce power consumption

I have a small project on a custom board using an nRF51824 processor. 

The code basically initializes the BLE stack timer and GPIO and then falls into a loop

while (true) sd_app_evt_wait(); 

The timer (using RTC) fires every 5 seconds to kick the watchdog and check for a connect timeout condition (15 minutes). 

When I connect I'm responding to one of a half dozen commands.

While advertising for a connection I see the board draw 0.92 - 0.97 milliamps. When connected I draw 1.01 - 1.10 milliamps. 

Whether connected or not, 99.99% of the time my application is not doing anything other than sleeping. 

What I'd like to do is reduce the power draw when advertising and connected as much as possible. 

My advertising interval is 250ms.

Thoughts where I should look? 

Parents Reply Children
  • Also, there are a bunch of references to "https://devzone.nordicsemi.com/index.php/why-does-my-nrf51822-consume-1-ma-in-sleep" but that link is dead too... Do you have a current link for that? 

  • Hi,

    You can find the examples from the nRF51 series current consumption guide here. The SDK has evolved significantly (SDK 12.3 is the latest release for nRF51), so they may not work out of the box unless you use SDK 11 for the test. You can also use the Power Profiling Application example from to test current consumption in most scenarios (BLE advertising with system ON sleep mode between BLE events, BLE connection with system ON sleep mode between events and system OFF).

    You can make very simple firmware examples to test the basic low power modes. This simple main function will go immediately to system OFF low power mode. If you see a current consumption larger than a few micro amps, this comes from either 1) other components on your BPS, or 2) the nRF51 is in debug mode.

    int main(void)
    {
        // Enter system off low power mode mode.
        NRF_POWER->SYSTEMOFF = 1;
    
        while (true)
        {
            // Should never arrive here
        }
    }

    You can make a similar system ON example by taking a BLE example, and only initialize the SoftDevice before you go to sleep (see code snippet below). Initializing the SoftDevice will start the LFCLK and RTC0, which is the only resources you need enabled during sleep for a simple BLE application. It would look something like this (SDK 12.3). The nRF will stay in system ON low power mode indefinitely if a 32 kHz crystal is used. If not, it will wake up regularly to calibrate the 32 kHz RC oscillator (depending on the configuration when you initialized the SoftDevice).

    int main(void)
    {
        // Call ble_stack_init implemented in the main.c file of a BLE peripheral examples
        ble_stack_init();
        
        // Enter main loop.
        for (;;)
        {
            power_manage(); // System ON low power mode.
        }
    }

  • Thanks.

    I implemented the following:

    int main(void)
    {
       NRF_POWER->SYSTEMOFF = 1;

       while (true)
       {
          __WFI();
       }
    }

    And I'm pulling 0.84 mA

    The hardware engineer checked and the 1K resistor is on the SWDCLK line. There is no debugger attached, as I program the code and then move the device from the debugger socket. 

    I will let him know definitively that there are other things on the board that are drawing power. 

    Thanks for your help. I'm going to leave this open until the hardware engineer either changes the hardware or tells me that he won't be doing so. 

  • Also, FWIW, I tried your second code snippet:

    int main(void)
    {
         ble_stack_init();

     
         while (true)
        {
           __WFI();
        }
    }

    And my power consumption went from 0.84mA to 0.90mA.

    And now another question. I was given this code using the 10.0.0 SDK and in the spirit of not changing too many things at one have continued using it. It seems to work fine for what I need to do (advertise, connect, send a few bytes back and forth) but I'm happy to change to 12.3.0 if there is a good reason. Better BLE handling, errata handled, etc.

    I know it's not going to help my power issue, but it may help my application.

    Thoughts?  

Related