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]

Hi Dan,

Have you modified the connection interval configurations in the example? By default, this is set to between 20ms (MIN) and 75ms (MAX) in the ble_app_uart example. If it gets set to 20ms, the average current of maintaining the connection will be between 226-320uA (with/without DCDC enabled) according to our Online Power Profiler for BLE. If you can accept longer latency in transfers, you can increase these parameters to reduce the current consumption, or you could enable slave latency to allow the slave to ignore a given number of connection intervals.

What is the capacity of the AA batteries you have tested with, to allow us to give better calculations of battery life?

Have you measured the current consumption by the example when running on the Dongle? Note that use of the LEDs will also increase the current consumption of the system.

Best regards,
Jørgen

[Jørgen Holmefjord]

The connection intervals depends on how low current consumption you want, and how much latency you can accept.

You can play around with the numbers in the Online Power Profiler yourself to see how the average current is affected by different numbers. For instance 100ms will give 48uA average current, while 500ms will give 12uA. The interval can be increased up to 4000ms.

[Jørgen Holmefjord]

No, those configs should not cause this kind of issue. Actually, I have never experienced that NRF_LOG_PROCESS have prevented the CPU from going to sleep.

If you can post your full project with the issue present, I can review/debug it to look for the cause of this behavior.

[catfish]

I have verified the issue follows setting NRF_LOG_ENABLED to 1 in the sdk_config.h. If it's set to 0 then the main.c NRF_LOG_PROCESS check can remain in the idle_state_handle function. How would you like me to send you the project? Can I send it to you directly? I zipped SES project into a zip file.

[Jørgen Holmefjord]

You can upload it directly in this ticket using "Insert->Image/Video/File". If you do not want to share it in public, I can convert the ticket to private.

[catfish]

water sensor_noSleep.zip

The code example is attached for your review. thanks

[Jørgen Holmefjord]

I see that log_init() function is commented out in the code. This will lead to the issue you are seeing, where the CPU is not able to go to sleep.

There is a NRF_LOG statement in one of the modules in the SDK (components\libraries\timer\drv_rtc.c:108), which causes the log buffer to be filled with this log. Since the logger module have not been initialized, there are no buffers where the logs can be stored for later processing. When you call NRF_LOG_PROCESS() to process the logs, the process tasks are not able to allocate buffers either, generating a new log entry (components\libraries\log\src\nrf_log_frontend.c:904). This will happen every time NRF_LOG_PROCESS() is called, causing the log queue to be constantly filled and never fully emptied/processed.

[catfish]

Ok, understood. So I should allow the log_init() function to execute but leave the logging disabled in the sdk_config.h?

Thanks for the update

[Jørgen Holmefjord]

Yes, that would be the the best approach. Then it is easy to enable logging later if you should need it. Alternatively, you can remove the call to NRF_LOG_PROCESS as well, but it would still be beneficial to disable the logger module in your sdk_config.h file, to make sure logs are not compiled into the application (which would increase firmware size).