Power Optimization for Softdevice BLE+ Sensor Processing

[mujeeb]

Hi,

We are developing an IoT sensor application using nRF52832 dev kit as a starting point. We have a sensor that we need to read once every second for 10 milliseconds (using PPI) and then transmit its data via BLE client to a PC using a second nRF52 DK as a master. We need to run the client with a coin cell battery for few months. We are using SDK UART example as a basis for the starting code on the client. 

I figured how to decrease the startup current by putting the system in sleep mode before BLE connection is made and any sensor processing starts. I also figured how to use idle_state_handle to minimize power after BLE connection is made but before sensor data transmission starts. 

However, it seems after we start reading the sensor, even when I use the idle_state_hanlde between sensor reads, the system still runs at around 3mA which is high for our intended application and limits battery lifetime.

I would like to know how to further decrease the power. I would also like to know how to use a timer to time the 1 second interval without using the CPU all the time as the CPU is consuming most of the power. 

I would like to know if there is an example that I can look at as a starting point that may be more relevant than the UART example I am currently using. Also, if 1 seconds is too fast and I should go to once every 10 seconds or 1 seconds, I can do that although doesn't seem to decrease the current consumption with the UART example. 

Thank you so much.

[Einar Thorsrud]

Hi,

However, it seems after we start reading the sensor, even when I use the idle_state_hanlde between sensor reads, the system still runs at around 3mA which is high for our intended application and limits battery lifetime.

I do not know enough about your application to say what causes the power consumption between the sensor reads. What resources do you use at this point? Have you tried to comment out / disable to narrow down what contributes the most?

I would like to know how to further decrease the power. I would also like to know how to use a timer to time the 1 second interval without using the CPU all the time as the CPU is consuming most of the power. 

Generally, you should disable all HW peripherals (particularly those that rely on the HF clock), and sleep as much of the time as possible. In practice that means using the app_timer to wake up regularly, as this uses a low power RTC that runs of the 32.768 kHz clock. Then, you should make srue to call sd_app_evt_wait() in your main loop, either directly or like most SDK examples do, via nrf_pwr_mgmt_run().

 Have you disabled UART? If not, that would explain a significant part of the current consumption as keeping the UART peripheral active increases the current consumption significantly. You should also enable the DC/DC if you have the required inductors in your custom HW, by calling sd_power_dcdc_mode_set(NRF_POWER_DCDC_ENABLE).

Most SDK examples can be made low power by the above adjustments.

[mujeeb]

Thanks Einar, I have tried to sequentially disable/comment the peripherals.

I am using the DC/DC regulator (it helps the most by decreasing current from 7mA to 3mA).

It seems that the CPU is consuming most power as the current draw only drops from 3mA to 2.7mA after running nrf_pwr_mgmt_run(). 

I use UART for programming and then disconnect it before testing power consumption. I reset the hardware before doing so via a power cycle. Is there anything else I should do regarding UART?

I am using app_timer. 

Even when I transmit via BLE after 1 minute and even when I disable the peripherals using nrf_pwr_mgmt_run(), the system still remains at using 2.7mA current. 

Is there a similar sensor+BLE example with all the recommended low power techniques implemented and documented that I can look at for better understanding these methods?

I appreciate the community's support in getting a solution to this issue. 

[Einar Thorsrud]

Hi,

mujeeb said:

It seems that the CPU is consuming most power as the current draw only drops from 3mA to 2.7mA after running nrf_pwr_mgmt_run(). 

That seems correct. If you call nrf_pwr_mgmt_run() the CPU will be put to sleep, and wake up on the next event. So if the CPU virtually always runs, then you have something waking it up all the time. Either that an event, interrupt happens very frequently, or that you do not clear an event. There are several ways to try to narrow down this, but I would think that the easiest would be to comment out most of your code until you get a low power consumption, and then gradually uncomment again until you see current consumption increase. Then you know roughly what part of your code cause the increase and can look more closely into that.

mujeeb said:

I use UART for programming and then disconnect it before testing power consumption. I reset the hardware before doing so via a power cycle. Is there anything else I should do regarding UART?

If you have the UART peripheral enabled on the nRF, you will get a high current consumption, regardless of it is being used or not. Not as much as 2.7 mA though, so this certainly not the whole explanation and may not be an issue at all in your application.

mujeeb said:

I am using app_timer. 

The app timer itself is very low power (using an RTC that runs of the 32.768 kHz clock) and does not contribute to any significant current consumption.

mujeeb said:

Is there a similar sensor+BLE example with all the recommended low power techniques implemented and documented that I can look at for better understanding these methods?

The most natural here would be to look at the BLE peripheral examples, for instance peripheral NUS that you are using. With that, you only need to enable the DC/DC and disable UART logging to make it low power. The sensor part typically means you communicate with a sensor using TWI or SPI, and as long as you clean up after that does not cause a significant current consumption when in idle.

Can you show a plot of how you measure, and confirm that you are trying to measure the idle current consumption? I want to stress that I think the next step must be to detect what causes your high current consumption, by excluding parts of your application as suggested above. After knowing what causes the problems solving them is typically much simpler.