Transcript
GitHub/Nordic| nordicsemi.comQuestions | Blogs | Tutorials | Resources | Tour | About WRITE BLOG POST allnordicersadvertisingfollowing search in blogs... User menu Username or e-mailPassword Sign in or sign up Recent blog posts6 Things to Know aboutBluetooth Beacons Posted Sep 22 '17 by Rose Martin Creating a Keil projectfor a Bluetooth Meshexample Posted Sep 19 '17 by KristianSkordal Using millis() like inArduino. Posted Sep 18 '17 by schef Flashing nRF5x firmwareusing any dumb terminalprogram via standardserial COM port Posted Sep 18 '17 by NguyenHoan Hoang How to Debug the nRF52Interrupts — Useful Tips Posted Sep 13 '17 by Yaniv NisStian Nordic employee 5216 ●5 ●9 Posted Apr 26 '16 nrf52blecurrent consumption blogs->nordicers nRF52 Online Power Profiler We in the Nordic Support team have created an online power profiler to estimate the powerconsumption 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. Alldata is based on actual measurements conducted on the nRF52, and they are correlated with the BLEpower profiles found in the SoftDevice specification to build a model which estimates the current components involved. You can find the nR F52 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) est setup All measurements have been conducted on an nRF52 development kit using a power analyzer. You cansee 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 moduleDCDC 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 clockaccuracy is 20ppm. In connection, the sleep clock accuracy of the central unit is also specified to be20ppm. Posted October 9th 2014 by StefanBirnir Sverrisson Posted October 23rd 2014 byscytulip Posted October 30th 2014 byStefan Birnir Sverrisson Posted December 18th 2014 byDavid Edwin Posted April 14th 2015 by StefanBirnir Sverrisson Posted June 25th 2015 by ble_Man Posted July 28th 2015 by ØyvindKarlsen Posted September 9th 2015 byPrithviRaj Narendra Recent questionshid keyboard demo irkquestion Posted 7 hours ago by micele Central receiving morethan 23 bytes as anotification Posted 8 hours ago by DavidC In BLE Central code, isthere a way to get peeraddress from storage? Posted 8 hours ago by nordicdev In BLE Central code, is itpossible to delete bondinfo after connection? Posted 8 hours ago by nordicdev I want generating a16MHz clock to outputfor extend ic,how to doit? Posted 8 hours ago by chenlmm Related posts by tagHow different BLEpacket types influencethroughputNordic SemiconductornRF51822 Firmware forBackground DataRecordingnRF51822/nRF51422getting started anddocumentation overviewBaby steps withBluetooth SmartnRF51 currentconsumption forcommon scenariosnRF52832-QFN EaglePart/FootprintROM and RAMManagementCurrent vs Voltage fornrf51 CPUQuick Link Test for PCBAwith Nordic chips In order to transmit data during connection, the application sends a characteristic value notificationwith a specific payload to the central every connection event. Radio notifications are used to placea payload in the TX buffer right before each connection event. The radio notification CPU processingis not a part of the results from the online power profiler, only the BLE event itself. The reason isthat application CPU processing is dependent on your application and it is hard to include any generalstatements 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 itusing UART, or you could use the GPIO peripheral to turn on or off a GPIO pin and then analyzethe time usage with a logic analyzer. The value can then be multiplied with the CPU and HF clockrun 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 theprofiler, we can have a look at a regular advertising event measured on the power analyzer. Theimage below shows a screenshot of the event using these parameters: 3.0 volt, 500 ms advertisinginterval, 31 byte TX payload and 0dBm TX power.The different components of the advertising event can be found on this page in the SoftDevicespecification. The length and average current of each of these components have been extractedfrom the measurement and is shown in the online power profiler plot. All of these components addedtogether 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 inthe plot above, and then the BLE event total charge consumption is found by multiplying the averagecurrent over the BLE event with the length of the event. This charge can then be used toextrapolate the average current for different advertising intervals, by dividing by the interval. Thenthe System ON IDLE current must be added to give the total average current. In this example we cancalculate 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) Posted November 16th 2015 byJohn So Posted November 8th 2015 byDaniel Veilleux Posted January 22nd 2016 byMichael Dietz Posted January 24th 2016 byMarco Russi Posted February 4th 2016 byDaniel Veilleux Posted March 9th 2016 by MartinBørs-Lind Posted March 5th 2016 by Jason Posted March 15th 2016 byMichael Dietz Posted March 25th 2016 bycaram5555 Posted by keio Posted May 19th 2016 by OleBauck Posted May 23rd 2016 by OleBauck Posted June 15th 2016 by BLECube Posted June 17th 2016 by Globuloz Intro toShockBurst/EnhancedShockBurstSEGGER EmbeddedStudio Part 2 - MonitorMode DebuggingBLE nrf51 - Multilink NUScentral - Connect tomany peripheralsthrough NUS service -with Arduino hostBLE-to-SB quadcopterbridgeGeneral PCB designguidelines for nRF52Scope your BluetoothRSSIMonitor Mode Debugging- Revolutionize the wayyou debug BLEapplicationsPreparing nRF5x massproduction.Getting started withnRF52 and Eddystone™ Hexapod usingnRF52 DK - Part 1: Introand hardwareMeasuring Lithiumbattery voltage withnRF52BLE-Cube — A BachelorProjectNRF52 debugging withQtCreator on Windows The perturbation is given as a random number between 0 and 10 milliseconds added to the intervalto 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 numberwe 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: Posted July 6th 2016 by wbober Posted July 13th 2016 by Audun Posted August 1st 2016 by DanielVeilleux Posted August 1st 2016 by DanielVeilleux Posted August 12th 2016 by JanTore Guggedal Posted September 3rd 2016 by Tim Posted September 7th 2016 byEirik Midttun Posted November 3rd 2016 bywilhelmsen Posted November 11th 2016 byDavid Edwin Posted November 14th 2016 byHung Bui Posted November 21st 2016 byTony Wu Posted December 9th 2016 by KenL Posted January 30th 2017 byDaniel Veilleux Setting up IPv6 over BLEusing nRF52 Series andContiki OSWireless timersynchronization amongnRF5 devicesGetting More Out of MakeShow And Tell: Lys - AnAutomation ExamplenRF52 QuadcopterProfiling the Softdeviceand FreeRTOS withSegger SystemViewnRF5 Series - a popularplatform for opensource RTOSThe Power Profiler KitGet started on PCSoftware for Mesh andMesh DFUWhat to keep in mindwhen developing yourBLE Android appnRF52 Rocket: Part I –Introduction to ModelRocketry and its UXProblemFast ProductionScreening based uponBluetooth DTMSimple Application-levelAuthenticationMonitor Mode Debuggingwith J-Link andGDB/Eclipse Peak current Because of the rise and fall time of the different components the average current will be lower thanthe peak current. In the profiler plot the peak currents for TX and RX are added on top of the barsfor reference. Payload The advertising payload can be chosen to be from 0 to 31 bytes, and the connection TX payload canbe from 0 to 27 bytes.The payload during connection is sent using notifications, but the payload size you specify in theprofiler includes any L2CAP and ATT header information. So the 27 bytes is the Link Layer's payloadsize. Sending a Characteristic Value Notification with a payload of 20 bytes corresponds to a 27 byteLink 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 connectionpacket 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 averagecurrent is typically within 5% of the actual value for the reference parts. The device to devicevariations will add to this inaccuracy. Please refer to the nRF52 Product Specification for expectedmin/max values for the different current components.If you experience any issues with the tool, please post a question in the Questions section here onDevzone. Any feedback is appreciated. Updates
