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.
###Payload
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.
The payload during connection is sent using notifications, but the payload size you specify in the profiler includes any L2CAP and ATT header information. So the 27 bytes is the Link Layer's payload size. Sending a Characteristic Value Notification with a payload of 20 bytes corresponds to a 27 byte Link Layer payload because of the 4 byte L2CAP header and 3 byte ATT header.
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.
##Updates
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.
Top Comments