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 Mike

This (very high) overall current consumption would be due to the BLE timesync demo not being optimized for power at all I'd imagine. The sd_radio_request() requests a timeslot, which should not increase the power consumption by itself, but the consumption will depend on what is done within the timeslot. This sample seems to request a timeslot that use the radio. Advertising also generally draws more current than a device already in a connection, which explains the drop once you have connected to the device, as it doesn't transmit/receive data as often as if it is advertising constantly.

For example, if the radio is set to transmit continuously it will draw ~11mA (see snippet from the PS below), and so if the advertising interval is low (it advertises very often) there will be few spaces of low current consumption. The post disconnection current of ~4.5mA is likely the CPU running and not much else.

If you need to minimize the current consumption in general in your project, my colleague Scott has made a guide that covers both HW and SW here.

Best regards,

Simon

[mkurtzsd]

Hi Simon,

Thank you for the information and the link. I will read Scott's guide and see what I can apply. I'm still a bit baffled about why the current drops so much after the first connection. The power draw is just upon startup initialization until the first connection. After the first disconnect, if I restart advertising, connect, time sync, sample, notify, etc... the current does not rise back up. 

Again, thanks for the investigation starting point.

-Mike

[Simonr]

Hi again Mike

I'll test this on my end tomorrow (I don't have the right equipment at my home office) and see if I can reproduce and hopefully explain this current consumption better. 

Is this the timesync peripheral or central example that you see the high current consumption in? I don't see you mention advertising, scanning or what role the application has specifically. Also, how are you measuring the current consumption? If you're using our PPK or PPK2, can you export and upload the file from the nRFConnect Power Profiler application in a .zip here on DevZone so I can review the current consumption on my end? The looks of it might give an idea of what specifically is drawing this current (although only the radio comes to mind that can draw that amount of current).

Best regards,

Simon

[mkurtzsd]

Hi Simon,

My device is the peripheral end connecting to an iPhone and I do control advertising via a button press. When the board first boots and I see the high current, it is not advertising. When I start advertising the current goes up a little less than a mA as expected. Once it connects and begins notifying, the current consumption drops and then never goes back up to initial power on connection levels.

I am powering my board using an Instek PSS-3203 power supply in place of the battery and measuring the current by placing a Keysight 34461A digital multimeter between the power supply and the board. I'll need to investigate if I can output any type of continuous current measurements from the Keysight. I read that a multi-meter is not the best tool to profile the current consumption of the nRF5; but, it is sufficient for my purposes as the change is so dramatic.

A little more detail from some experiments I've done. It appears that when the peripheral is connected and is acting as the time-sync slave, that power is higher until the time-sync master starts sending packets. That is, while the slave is waiting for time-sync packets; it's power draw is 2x what it is once it has received at least one sync packet. If the peripheral is put into time-sync master mode; it's power immediately drops. So, there seems to be an issue with the setup before the time-sync has been established. Perhaps something in the timeslot event handler that changes when a time-sync packet has been received vs. when it hasn't? 

Best regards,

-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