Beware that this post is related to an SDK in maintenance mode
More Info: Consider nRF Connect SDK for new designs
This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

ppk2 measurements vs online power profiler (nRF52840DK, nRF5 SDK, ble_app_pwr_profiling example)

I'm running the ble_app_pwr_profiling example from the nrf5 SDK (16.0.0) and softdevice (s140 7.0.1)  on a nrf52840DK (pca10056 2.0.1) and measuring power consumption using ppk2.  The measurements rather different from the estimate from the online power profiler.  I'd really like to understand what's going on better.

I run the ble_app_pwr_profiling app (test steps 1 - 10) as described in https://infocenter.nordicsemi.com/topic/sdk_nrf5_v16.0.0/ble_sdk_app_pwr_mgmt.html

The peripheral is an nrf52840DK powered via the ppk2 in source mode.

The default configuration values in main.c are:

#define CONNECTABLE_ADV_INTERVAL MSEC_TO_UNITS(20, UNIT_0_625_MS)
#define APP_CFG_CONNECTION_INTERVAL 20
#define APP_CFG_CHAR_LEN 20

The ppk2 trace clearly shows sequence of three states and the ppk2 reports average current over these events as follows:

1) advertising (push button 1) -- mean current ~950uA, idle current 1.7uA
2) connected (connect via nrfConnect) -- mean current ~277 uA, idle current ~1.2uA
3) notification (toggle notification via nrfConnect) -- mean current ~485uA, idle current ~1.2uA

I enter the same configuration into the online power profiler.

The configuration parameters are: DCDC = off, LF clock = internal RC, TX power = 0dBm (this is ble stack default, correct?)

For the advertising (connectable) role and advertisement interval 20ms, the power profiler gives 591uA mean and 3.1uA idle. The observed values are 950uA and 1.7uA.

For peripheral (connection) role, connection interval 20ms and payload 20B, the power profiler gives 420uA mean and 3.1uA idle.  The observed values are 485uA and 1.2uA.  The log at the central show that notifications are received correctly, at intervals between 18 and 25ms (there is some ongoing BLE and other interference, but not unreasonable amounts).

Overall, the peak currents seem to be noticeably higher than those predicted by the profiler (~17mA vs 12mA).  There also seems to be some additional radio activity(?), see detailed traces below.

These differences seem large enough to be noteworthy?   Bonus question: what is the periodic behavior while the peripheral is connected, but not sending notification?

Below are the detailed traces from each measurements.  They are similar to those proposed by the profiler (I don't see an easy way to cut/paste from there), but the peak currents are significantly higher and the notification appears to include an ack (?) that does not appear in the profiler?

Advertising (measured average 950uA vs 591uA for 20ms interval)

Connected (measured average 277uA, 20ms connection interval)

Notification 20ms connection interval, 20B TX payload (measured average 485uA vs 420uA profiled).  Note the ACK (?) that follows the transmission is not seen in the profiler outpur.  (It's also strange, since notification shouldn't have an application layer ack -- it's not an indication.)

Any thoughts about what I'm observing?  Should I be concerned about the discrepancies?

Thanks!

Additional configuration:

nrf52840DK switches:  SW6 = nrf only, SW8 = ON, SW10 = Vext->nrf, USB connected on J2

ppk2 settings:  source mode, 3.0V output (2.98V measured)

power:  ppk2, nrf52840DK and laptop are all connected to a powered USB hub.

software: The ble_app_pwr_profiling app was built from the command line under ubuntu 20.04, using arm-none-eabi-gcc 9.2.1. Same results were observed using the pre-built .hex file (pca10056/s140).  nrfConnect is 3.7.0 and up-to-date.  online power profiler as of 24/08.

Parents
  • Hi Simon,

    Thanks for the reply.

    I'm using the ble_app_pwr_profiling example from nrf5 SDK (16.0.0) without any modification. So it should be using the default BLE configuration and payloads from the example.  (I get similar behavior with the pre-compiled .hex file and a command line build (ubuntu 20.04, gcc 9.2.1), so I don't think it's a build issue.)

    I'm trying to provide the online profiler with compatible parameters to the existing example: I think the example uses 20ms ADV interval, 20ms connection interval and 20B notification payload, so that's what I used for the online profiler.  Please say if it should be something different.

    I use dc-dc=off  in the online profiler because the ppk2 trace seems to not show dc-dc (that would look like pulse width modulation, right?).  Using dc-dc=on in the online profiler gives even lower estimated current and so that would suggest even bigger discrepancies, if it really is using dc-dc.

    On your suggestion,  I tried both the internal and external crystal settings in the online profiler; it makes only a small difference in the estimated current, so I don't think this is a significant part of the discrepancy.

    The ppk2 is configured to provide 3V, same as the online profiler setting.  I measure ppk2 output at 2.98V using a meter.

    Thanks for the explanation about the extraneous peaks: I agree that this would explain some, but not all of the discrepancy.  I will double check this the next time I'm in the lab.

    Thanks!

Reply
  • Hi Simon,

    Thanks for the reply.

    I'm using the ble_app_pwr_profiling example from nrf5 SDK (16.0.0) without any modification. So it should be using the default BLE configuration and payloads from the example.  (I get similar behavior with the pre-compiled .hex file and a command line build (ubuntu 20.04, gcc 9.2.1), so I don't think it's a build issue.)

    I'm trying to provide the online profiler with compatible parameters to the existing example: I think the example uses 20ms ADV interval, 20ms connection interval and 20B notification payload, so that's what I used for the online profiler.  Please say if it should be something different.

    I use dc-dc=off  in the online profiler because the ppk2 trace seems to not show dc-dc (that would look like pulse width modulation, right?).  Using dc-dc=on in the online profiler gives even lower estimated current and so that would suggest even bigger discrepancies, if it really is using dc-dc.

    On your suggestion,  I tried both the internal and external crystal settings in the online profiler; it makes only a small difference in the estimated current, so I don't think this is a significant part of the discrepancy.

    The ppk2 is configured to provide 3V, same as the online profiler setting.  I measure ppk2 output at 2.98V using a meter.

    Thanks for the explanation about the extraneous peaks: I agree that this would explain some, but not all of the discrepancy.  I will double check this the next time I'm in the lab.

    Thanks!

Children
No Data
Related