Confused by power usage changes in firmware

[mkurtzsd]

Hello,

I could use some guidance on where to look for a power draw that I am not understanding. I am not a hardware engineer but have been tasked with completing firmware for a custom board based on the nRF52832 chip. The system is built using SDK 16.0.0 with SD S132 v7.3.0. I am puzzled by the following power changes:

When the board boots and initializes the system, the power draw jumps from around 7mA to 10+mA after a call to sd_radio_request(). The power consumption remains at 10+mA until I begin advertising at which point it rises to around 11mA. Once I connect to the device, the power drops back down to 10+mA. Once connected, I write to a characteristic to begin sampling the ADC. The samples are acquired at 1KHz, buffered, and sent via BLE notification back to the central. During this time, the power consumption drops to 5mA (drops by 50%). When I disconnect, sampling stops. What is baffling to me is that the power draw remains at ~4.5mA post disconnect. The state of the device, at least from the top level firmware perspective, is the same as during the initial power-on scenario when the device was drawing 10+mA. What could possibly be occurring during and post connection to cause the sudden power savings?

The code was originally derived from the time-sync demo (https://github.com/nordic-auko/nRF5-ble-timesync-demo) and expanded from there to add ADC acquisition based on timers and PPI events.

I am not necessarily asking for solutions; but areas of possible SoftDevice / BLE configuration that could account for such a change in power consumption pre-initial connection, connection, and post connection. Once I am past the initial connection, the power draw never rises above 5mA. I see the same behavior on my PCA10040 DK board as well only the power consumption goes from 14mA at initial run down to ~8mA while acquiring and sending, and then down to ~1.2mA when disconnected.

Thanks for any advice and/or direction to take in my investigation.

-Mike

[Simonr]

Hi again

So I see what's happening here. It took me a moment to understand what the readme actually says, but it describes it correctly. 

By default, the examples (both peripheral and central) is in receiver mode by default, and will continuously scan (drawing ~10-11mA). If you press button 1 on the DK, it will switch to transmitter mode and only advertise. The transmitter will begin toggling a GPIO and all 4 onboard LEDs will light up, and the current consumption will go down drastically (to ~2.7mA) as the device will only be advertising and toggling this one GPIO.

However I'm not able to see the current consumption going down as you describe initially. It is either around 10-11mA in receiving mode, or ~2mA in advertising mode. It will also stay the same if I connect to the board with my nRFConnect app for Android. Are you sure you put the device to advertising mode and that it doesn't actually try to scan for other timesync peripherals while it is not connected on your end, as it does indeed advertise while in receiver mode as well by default.

Below are snippets from the Power Profiler application where you can see the two current consumption modes I'm able to replicate with the as-is timesync example project on an nRF52832 DK. You will see some dips in the current consumption in receiving mode, this seems to be because of some timeslots in the application where it sets off some ms to do an advertising event in receiver mode.

Default receiver mode: 

Advertising mode:        

Best regards,

Simon

[mkurtzsd]

Hi Simon,

Thank you for this information. It was very helpful. I found the when my peripheral booted up it initialized the time-sync code and turned the radio on which is why it immediately was pulling ~11mA after boot. When the device disconnected, the time-sync mode was turned off which is why the power stayed low after the initial connection. I have modified this behavior to only enable time-sync when needed and the idle power draw is now down around 3.6mA.

Thanks for the clarifications on what/how the time-sync code actually handles the radio power.

-Mike