nRF52840 ble_app_uart example using PCA10059 high current consumption

[catfish]

I have modified the ble peripheral example - ble_app_uart to run on the PCA10059 USB dongle and the demo I developed using that as a starting point works very well. The problem I am experiencing is that the I am powering the dongle with 2 - AAA batteries but they are only lasting ~3 weeks connected to a raspberry Pi 0 W. I modified the traces to configure the power input to be compatible with 3.0 Volts input and enabled the DC/DC converter to try and improve the battery life but after 2 weeks the batteries are already down to 1.4 volts per cell. The dongle is connected to the Pi 100% of the time, the communications are limited to a "proof of life" check once a minute but for the most part that's the only communications besides maintaining the connection to the Pi. I disabled the HW uart used in the example to attempt to reduce the current further but I haven't experienced much improvement. Is there something in the example that could cause excessive current draw? Should the dongle not be continuously connected?

Thanks in advance.

Dan

[Jørgen Holmefjord]

catfish said:

Is there any reason the ble_app_uart example would be continuously transmitting?

No, not without large modifications to the example and sending/receiving data over UART.

The softdevice will only enable the radio at the configured connection interval, but it is possible to configure it to send/receive more data to increase the time the radio will be on. This is an example where I reduced the connection interval to 7.5ms, increased the output power to +4dBm, and increased packet lengths to transmit and receive 251 bytes of data every connection interval:

catfish said:

I assume it doesn't TX unless data is being transferred across the BLE link.

It will transmit an ACK to the central on each connection interval (unless slave latency is enable), to tell the central that it is still present and the connection should be kept active.

[catfish]

I have been reviewing the current profile with a scope and the TxRx events appear to match the current draw you noted. My issue appears to be the steady state current in between BLE events. When not actively communicating or maintaining the connection, the nrf52840 should idle, correct? I have included a GPIOTE instance in the code, other than that my code is essentially the same as the example code (with the HW uart disabled). Can you suggest what "things" can prevent the chip from entering idle mode and result in a constant 3mA draw?

Also, I validated my test measurements by compiling and loading the PCA10059 BLE_APP_Blinky example and disabled the LED that is On while connected. I was able to confirm that while connected the current draw is ~ 40 to 50 uA. Is there something inherent in the BLE_APP_UART example that prevents low current?

thanks in advance

[catfish]

Woohoo, figured it out. the nrf_pwr_mgmt _run() was never executing because of the NRF_LOG_PROCESS check. I commented out the check and now it runs low current between the BLE events. I'm now measuring ~ 20 to 30 uA !!!!  

[Jørgen Holmefjord]

Great to hear that you figured out the issue! However, it sounds a bit strange that NRF_LOG_PROCESS should prevent your from entering sleep, as this should return false once the logs have been processed and then put the CPU to sleep. Have you modified any other parameters that would prevent the logs from being processed, e.g. set RTT options to blocking if FIFO is full?

// <o> SEGGER_RTT_CONFIG_DEFAULT_MODE  - RTT behavior if the buffer is full.
 

// <i> The following modes are supported:
// <i> - SKIP  - Do not block, output nothing.
// <i> - TRIM  - Do not block, output as much as fits.
// <i> - BLOCK - Wait until there is space in the buffer.
// <0=> SKIP 
// <1=> TRIM 
// <2=> BLOCK_IF_FIFO_FULL 

#ifndef SEGGER_RTT_CONFIG_DEFAULT_MODE
#define SEGGER_RTT_CONFIG_DEFAULT_MODE 2
#endif

I assume that you do not require logging while connected to the battery, so you can disable logging as well:

// <e> NRF_LOG_ENABLED - nrf_log - Logger
//==========================================================
#ifndef NRF_LOG_ENABLED
#define NRF_LOG_ENABLED 0
#endif

Then NRF_LOG_PROCESS() should always return false.

[catfish]

I didn't change any of the LOG settings in the sdk_config.h. I just checked it and the NRF_LOG_ENABLED was a 1 so I just changed it to 0. The SEGGER_RTT_CONFIG_DEFAULT_MODE was set to 0. Could those settings be the cause?

Thanks