Posted 2016-04-26 10:19:04 +0200

blogs->nordicers

# nRF52 Online Power Profiler

We in the Nordic Support team have created an online power profiler to estimate the power consumption during a BLE event with different parameters. The profiler gives you information about the different components in a BLE event as well as the average current over a specified interval. All data is based on actual measurements conducted on the nRF52, and they are correlated with the BLE power profiles found in the SoftDevice specification to build a model which estimates the current components involved.

You can find the nRF52 Online Power Profiler here: devzone.nordicsemi.com/power/. The tool is also available under the Resources tab at the top.

The BLE event types you can choose between are advertising mode and peripheral connection mode. You can also choose different values for the following parameters:

• Voltage (1.7 to 3.6 volt)
• BLE interval (20 to 10240 ms for advertising. 7.5 to 4000 ms for connection)
• TX payload (0 to 31 byte for advertising. 0 to 27 byte for connection)
• TX power (4, 0, -4, -8, -12, -16, -20, -40 dBm)

## Test setup

All measurements have been conducted on an nRF52 development kit using a power analyzer. You can see how to prepare the development kit for measurements here.

The equipment and software involved:

• Hardware: PCA10040 v1.1.0 Development kit
• Chip: nRF52832QFAAB0
• SoftDevice: s132 v2.0.0
• SDK: nRF5 SDK v11.0.0
• Application: ble_app_pwr_profiling
• Measuring instrument: Agilent N6705B power analyzer with a N6781A module

DCDC has been enabled in the application code:

sd_power_dcdc_mode_set(1);


The application code uses the external 32kHz crystal on the development kit and thus the sleep clock accuracy is 20ppm. In connection, the sleep clock accuracy of the central unit is also specified to be 20ppm.

In order to transmit data during connection, the application sends a characteristic value notification with a specific payload to the central every connection event. Radio notifications are used to place a payload in the TX buffer right before each connection event. The radio notification CPU processing is not a part of the results from the online power profiler, only the BLE event itself. The reason is that application CPU processing is dependent on your application and it is hard to include any general statements about current consumption in this case.

Current consumption during application CPU processing can be estimated by measuring the processing time, for example by using a timer to capture the start time and end time and print it using UART, or you could use the GPIO peripheral to turn on or off a GPIO pin and then analyze the time usage with a logic analyzer. The value can then be multiplied with the CPU and HF clock run currents, found in the nRF52 Product Specification, to get the total consumption.

## How it works

To give an example on how the measurement data has been analyzed to create a model for the profiler, we can have a look at a regular advertising event measured on the power analyzer. The image below shows a screenshot of the event using these parameters: 3.0 volt, 500 ms advertising interval, 31 byte TX payload and 0dBm TX power.

The different components of the advertising event can be found on this page in the SoftDevice specification. The length and average current of each of these components have been extracted from the measurement and is shown in the online power profiler plot. All of these components added together will give the total charge consumed during the whole BLE event.

To make things easier in this example the average current during the whole BLE event is shown in the plot above, and then the BLE event total charge consumption is found by multiplying the average current over the BLE event with the length of the event. This charge can then be used to extrapolate the average current for different advertising intervals, by dividing by the interval. Then the System ON IDLE current must be added to give the total average current. In this example we can calculate the average current to be:

The total charge of the BLE event:

BLE_charge = BLE_avg * BLE_length


The average current consumed by the BLE event for a specific interval:

BLE_avg = BLE_charge / (BLE_interval + perturbation)


The perturbation is given as a random number between 0 and 10 milliseconds added to the interval to prevent advertisers to periodically transmit at the exact same time. This averages to 5 ms.

Adding the IDLE current to the inactive part of the interval:

TOT_avg = BLE_avg + IDLE * (BLE_interval - BLE_length)/BLE_interval


Performing the calculation with the numbers from this example:

BLE_charge = 4.92 ms * 2.85 mA = 14.022 uC
BLE_avg = 14.022 uC / (500 ms + 5 ms) = 27.77 uA
TOT_avg = 27.77 uA + 2 uA * (505 ms -  4.92 ms)/505 ms = 29.8 uA


Comparing this to the average value we get from the power analyzer we can see that the number we get is the same as the calculated value above, 29.8 uA:

We can also see that this is the same value we get from the online power profiler:

### Peak current

Because of the rise and fall time of the different components the average current will be lower than the peak current. In the profiler plot the peak currents for TX and RX are added on top of the bars for reference.

The advertising payload can be chosen to be from 0 to 31 bytes, and the connection TX payload can be from 0 to 27 bytes.

Choosing a zero payload size for the peripheral connection mode will show an empty connection packet without any notifications sent.

## Accuracy

The tool is based on a model of the measured values, and is not showing the actual measurement. The results are therefore estimates of the expected value. It is meant for evaluation purposes only, and will not give the exact numbers in every use case. Testing shows that the estimated average current is typically within 5% of the actual value for the reference parts. The device to device variations will add to this inaccuracy. Please refer to the nRF52 Product Specification for expected min/max values for the different current components.

If you experience any issues with the tool, please post a question in the Questions section here on Devzone. Any feedback is appreciated.

The tool will be updated whenever there is a new SoftDevice major update or a new Chip revision is released. The numbers can therefore change without notice.

Right now the tool only includes the advertising and peripheral connection modes. Scanner and central connection modes will be included later.

Posted May 3, 2016, 12:01 p.m.

Based on my understanding, the TX payload in one connection interval can be 6 x 20= 120 bytes. How come only max 27 bytes are allowed for the power calculation tool?

Posted May 3, 2016, 12:36 p.m.

@Lakerno The tool shows only one packet per connection interval. It will be updated with multiple packets soon.

Posted May 3, 2016, 2:48 p.m.

@Stian, Thank you. Waiting for the update. Would it be possible to include the Slave latency in the calculation?

Posted May 20, 2016, 8:01 p.m.

@Stian Please provide the instructions for measuring current with the power analyzer. These are not provided in the infocenter. Thank you.

Posted May 26, 2016, 9:43 a.m.

@Lakerno Slave latency is a planned feature

@ahedin25 Have you seen this tutorial? https://devzone.nordicsemi.com/tutorials/28/ You connect the power analyzer as if it was an ammeter. If you want to use the power analyzer as a voltage source as well, you will need to do modifications to the DK to isolate the nRF chip from the rest of the circuitry.

Posted July 26, 2016, 9:51 a.m.

Hi @Stian, Could you provide the specific parameters that should be modified in power profiling example code in order to follow this guide? Thank you.

Posted April 21, 2017, 9:20 a.m.

The link to the "test setup for measurements using the dk" is not working. Can someone please direct me to the correct one.

Thanks Bhagath

Posted April 21, 2017, 10:34 a.m.

@bhagath Sorry, I've updated the link now.

Posted Aug. 15, 2017, 10:40 p.m.

Will there be updates for multiple packets per interval, DLE and RX events?

## Recent blog posts

• ### 6 Things to Know about Bluetooth Beacons

Posted 2017-09-22 08:27:00 by Rose Martin
• ### Creating a Keil project for a Bluetooth Mesh example

Posted 2017-09-19 12:08:11 by Kristian Skordal
• ### Using millis() like in Arduino.

Posted 2017-09-18 11:58:04 by schef
• ### Flashing nRF5x firmware using any dumb terminal program via standard serial COM port

Posted 2017-09-18 03:53:40 by Nguyen Hoan Hoang
• ### How to Debug the nRF52 Interrupts — Useful Tips

Posted 2017-09-13 15:15:22 by Yaniv Nis

## Recent questions

• ### Is there a way of capturing 8 GPIOs and transfer data to easydma

Posted 2017-09-23 16:31:41 by Antonio
• ### fds problems sdk14

Posted 2017-09-23 16:19:07 by Stas
• ### EVENT_ADDRES and EVENT_END timing on coded phy

Posted 2017-09-23 13:56:07 by Andrzej Kaczmarek
• ### UART interrupt event handling on SDK14.0.0

Posted 2017-09-23 12:11:40 by Kasper Leonhardt
• ### Programming an nrf52832 board with ST link V2 and keil issue

Posted 2017-09-23 12:02:19 by MikeLemon