This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

peripheral uart power consumption

So,

I've got  a working framework for my project - a battery powered appliance that will occasionally trigger one of two solenoids, timestamping the operation and subsequently reporting them to a bluetooth connected phone.

I developed initially on a nRF52 DK (PCA10040 - nRF52832), putting together a heavily modified peripheral_uart sample with I2C and ADC support.

On the nRF52, when idling (Advertising only at a 2 second interval) I measured current consumption at 8 uA  at the current measurement pins while supplying 3.0V at the External Supply pins..

I ported to a newly received nRF5340 DK with minimal changes (GPIO port assignments moved from gpio 0 to gpio 1).  At the same idle state as the nRF52832 (the main loop is a k_sleep(K_FOREVER); statement), current consumption at P22 with power supplied at P21 at  3.0V from a regulated power supply) at about .37 mA.

I had to compile and load  hci_rpmsg to get bluetooth connectivity - as delivered  the nRF5340DK did not seem to have a network core.

Where do I go from here to get reasonable current consumption?

  • I would suggest to test using very simple application without any peripheral, you can try only toggling an LED for example. 
    Just so that you make sure you can get to the base current consumption of a few uA. 

    How did you measure the current consumption ? Please try recording using a PPK it would help showing what may draw the current. 

    You can have a look at my webinar here at minute 50th that I showed some tips on measuring current consumption on a BLE application on nRF53: 
    https://webinars.nordicsemi.com/get-started-on-your-advanced-1

  • Hi.

    I'm  providing power from a regulated power supply at 3.0V through the "External Supply" pins on the DK.

    I'm measuring current with a BK Precision Bench DMM on. the NRF Current Measurement pins on the DK (I've cut solder bridge SB40).

    In the context of what I'm trying to do, I'm running the simplest possible configuration I can. It's a slimmed down version of peripheral_uart that starts advertising, then does a k_sleep(K_FOREVER).

    In fact, it's unrealistic. I want my main loop to idle, waiting for either a GPIO interrupt or a Bluetooth connection. The k_sleep is the only mechanism I could make work on the 52832.

    I've attached a zip file of the top of my project (the build directories are empty)peripheral_uart-4-20 - Copy.zip

  • Depends on the advertising interval you have you may have different power consumption. 

    I would suggest to turn off all functionality and only sleep to get to the base sleep current before testing with BLE. Having UART running would also draw current as it keeps the clock running. 

  • The advertising interval is set to 2 seconds.

    I commented out everything in main() except for the loop

           for(;;)

                 {k_sleep(k_forever);

                 }

    When

    CONFIG_HAS_POWER_STATE_DEEP_SLEEP_1=y is set

    power consumption is 3.5uA. An nearly as I can tell from my DMM this is unchanging.

    When

    CONFIG_HAS_POWER_STATE_DEEP_SLEEP_1is not set

    power consumption is 53uA.

    Uncommenting the balance of main, which enables I2C, ADC, and GPIO, connects to blue tooth and starts advertising, power consumption is 53uA, with a visible spike every two seconds.

  • According to this  CONFIG_HAS_POWER_STATE_DEEP_SLEEP_1 would put the device to deep sleep (system off) after a power down timeout. But I don't see it would reduce current consumption if you just simply use k_sleep() (it retain in Idle mode which is System ON)

    3.5uA base current is expected when staying in System ON. When you turn on peripheral (i2C, ADC, GPIO input) it's expected to have power consumption increased. So I don't see any abnormal here after you turn off the logging in the netcore module.

    The best way IMO to verify the power consumption is to use a PPK and can visualize the power consumption over time. 

Related