nRF52-DK with HRM application - expected average current?

[Scott]

Hello, DevZone,

I have programmed an nRF52-DK with the unmodified SDK's ble_app_hrs_pca10040_s132 (heart rate monitor) BLE peripheral application.  I also have a Power Profiling Kit to measure the current.  I have cut SB9 as directed so that the PPK can measure the current, and have the DUT, Power Select, and COM switches all set to "DK" position.

I ran nRF Connect for Desktop, and have installed the Power Profiler application.  The nRF52-DK is connected to my PC via USB cable, and I started the Power Profiler.

While the board is advertising (LED1 on nRF52-DK blinking), I'm seeing an average current of around 585 uA, which seems pretty high.  Is this expected/normal, or do I have something set up incorrectly?

After connecting to nRF Toolkit's HRM app on my smartphone, I see the average current change to about 507 uA.  Again, this seems high, and I'd like to know if this is expected, or if I have something set up incorrectly on one of the boards or in the application.

Can someone please confirm that these average currents are as expected for this application?  If so, can you suggest specific steps that might help reduce the average current?

If I consider a normal CR2032 as the power source with a capacity of 220 mAh, this seems to mean that this application would be able to run for:

220 mAh * 1000 uA/mA / 507 uA = 433.9 hours, or about 18.1 days. 

Is this correct?  For reference, we would eventually like to get to an ECG monitor that can run for 30 days from a battery.  I know this application has much less data than a full ECG (even single-lead), but thought that it would be a good place to start to see if this is even feasible.

Any pointers on how this application or test setup can be configured to reduce current consumption would be greatly appreciated.  I'm still very new to the nRF52 family, and there is much that I don't know yet!

Many thanks for your help and insights!

Scott

[Kenneth]

If you disable debugging output and don't have other peripheral activity (uart, spi, twi), then the chip should draw the current shown here:
https://devzone.nordicsemi.com/power/ 

[Scott]

Kenneth, I did a quick search through sdk_config.h to see what logs are enabled.  I found the following:

C:/Nordic_Semi/nRF5_SDK_15.2.0/examples/ble_peripheral/ble_app_hrs/pca10040/s132/config/sdk_config.h:#define NRF_LOG_ENABLED 1
C:/Nordic_Semi/nRF5_SDK_15.2.0/examples/ble_peripheral/ble_app_hrs/pca10040/s132/config/sdk_config.h:#define NRF_SDH_BLE_LOG_ENABLED 1
C:/Nordic_Semi/nRF5_SDK_15.2.0/examples/ble_peripheral/ble_app_hrs/pca10040/s132/config/sdk_config.h:#define NRF_SDH_LOG_ENABLED 1
C:/Nordic_Semi/nRF5_SDK_15.2.0/examples/ble_peripheral/ble_app_hrs/pca10040/s132/config/sdk_config.h:#define NRF_SDH_SOC_LOG_ENABLED 1
C:/Nordic_Semi/nRF5_SDK_15.2.0/examples/ble_peripheral/ble_app_hrs/pca10040/s132/config/sdk_config.h:#define PM_LOG_ENABLED 1

Could these have an impact on the average current?  I am new to the nRF52 and SDK, so I am not even sure what these defines actually control.  Do they generate output via the UART, or via the Segger JLink RTT?

Apologies for the "newbie" questions, but I am trying to get up the learning curve, which seems a bit steep at the moment!

Thanks again,

Scott

[Scott]

Kenneth and DevZone,

I got some help from my local FAE, and he confirmed that he saw similar current values to what my setup was reporting.

Further, he indicated that enabling the DC-DC converter could reduce the current consumption by ~40%.  This was accomplished by adding the line:

    sd_power_dcdc_mode_set(NRF_POWER_DCDC_ENABLE);

right after the call to advertising_start(erase_bonds); in main.c.

After rebuilding the project in Release mode, reprogramming my nRF52-DK, and reinstalling the PPK, the average current during advertising dropped to about 370 uA.  Much better!  Very grateful for the excellent help on this.

Some other techniques can evidently be used to reduce power further, including disabling the UART logging, and increasing the advertising interval and connection interval.  I will continue to experiment, but this one call made a huge difference in average current draw.

Thanks for the help, Kenneth and Nordic!

[Kenneth]

Not sure how much help I was in this case, but good an FAE stepped in an found that dcdc was not enabled by default. I have reported it internally (NRFFOETT-2213). 

Best regards,
Kenneth

[Scott]

I appreciate the help, no matter how small.  Thanks, Kenneth!

[Kenneth]

I found this link that may be useful for others that find this thread in future:

https://devzone.nordicsemi.com/b/blog/posts/optimizing-power-on-nrf52-designs