More on Power consumption

[pbecchi]

Since long time I am fighting to lower power consumption using this library to the levels reachable with Sdk examples!
I have run several examples, testing the uA level in different type of code.
If we don't use BLE libraries uA are very near to the one expected , normally few uA when we are in low power mode.
But if we use BLE consumption get well above 1mA so about 100 times more that expected!
I have used the dual role BLE uart example and these are my findings:
-to enter low power mode you have to add delay() in the main loop , the longest the milliseconds the lowest the power drain.
-all Ble central related functions are taking quite a bit of mA
-keeping only BLE peripheral functions, with delay(100) will give about 600uA that is about what is expected (100 uA+500uA for Serial uart)
-taking out all Serial.begin and Serial.print from the example INCREASE the power drain to about 2mA while should be reduced by 500uA

I think this strange behaviour may only be due to some Serial debug statement present on the BLE libraries.
In theory Serial debug should be fully controlled by the Tools menu setting and with debug=0 slould not be executed!

[hathach]

Thanks @pbecchi for raising this issue and share your experience with the power consumption. You are right with your observation, I will throw a bit more detail where I could.

• When ble radio is active (prph and central), it will consume much more power. I haven't looked at the nordic specs on those number. So it is a TODO for us.
• delay() in your library is more than delay as you figure out, more like sleep() now. Since we implement freeRTOS tickless https://www.freertos.org/low-power-tickless-rtos.html Everytime delay() is invoke it will put mcu into decent sleep mode (waitForEvent() ) an only wake up a few ticks before the time of scheduled action. It is all handled under the hood, man we should call it sleep() :D . It is a feature point in our upcoming "coding guideline for low power" tutorial. However the longer you delay/sleep the lower responsiveness of the device.
• For serial draining, are you testing with the later revision of the power, the previous version has an hw issue that make cp2104 constantly draw power even not enabled. Too bad, I don't even have the later revision myself to test with for now :( . However with the debug = 0, the serial shouldn't ever be used. I could double check it later.

I have also wanted to test more with power consumption and write an tutorial for it. But we are too busy for now with the upcoming nrf52840, which we will need do low power, so we wait until it comes out to test with. This will serve as notes to ourself to improve it later.

[hathach]

Another way to reduce power is to go full event response aka callback and abandon the use of loop() with suspendLoop() call. ( I will take note myself for the tutorial, before I start to forget things)

https://github.com/adafruit/Adafruit_nRF52_Arduino/blob/master/libraries/Bluefruit52Lib/examples/Peripheral/beacon/beacon.ino#L59

Also you may want to tweak the ble radio timing/parameter such adv, connection interval etc ... the full list and its affect (current save) will come later when I tested them with the bench ( we may go as far as low power profile with pre-configured parameter for user). There may be more trick, but I kind of forget, will get back to this when we are done with the nrf52840 :D

[pbecchi]

@hathach Thanks for your replay!

To be more precise on my previous message:

• I use your libraries on nrf52 DK and on Fanstel BT832 modules ....so the Cp2104 cannot be the reason for the abnormal UART drain.

• The high mA start in the setup() function just after startAdv() call. I have added a 1 minute delay() after that call . When I have a Serial.begin call the consumption is 1.5 mA and after 30s 0.6 mA.
  Without Serial.begin my consumption is floating from 1.5 to 3.5 mA. This behaviour dont shows up with the nrf52 DK board.

• Is suspendLoop() a way to not start the loop task? I cannot do this since my code is a sprinkler controller and I need to spend few millisecond per minute to do GPIO controls. I can manage to use a delay(500) in my loop() that hopefully can reduce consumption to around 100uA

• I need anyhow to solve the Serial related power drain......can you help me on that?

[hathach]

Yes, suspendLoop() will put loop() task in suspend and prevent it to execute. If you need it, so just use it if you need it.

For the serial issue with power, currently I don't have any ideas why it behaves as such. I am quite sure to not print anything when debug=0. Although, I am too busy by now for upcoming nrf52840 to pull out nrf52dk to test this out. I am afraid you have to do it by yourself a little bit more until we release the nrf52840 board. Sorry since I only have 2 hands and 10 fingers :))

[pbecchi]

Thanks, I understand your problems.....
I am also very interested to the nrf52840 , since I am getting my first bt840 end of this week! :-)

So I will try to solve this power drain problem by myself and ...I will let you know!!

[hathach]

thanks, please update here if you could find out anything. Low power is mostly software thing ( hw is often too obvious and spotted out soon enough). It needs a guideline and discipline to follow. Unfortunately, we haven't got the guideline yet ( just some above tips )

[hathach]

related to #51

[Nenik]

I'd have one more data point on unexpected power consumption - FPU.
On a custom design (but still using nRF52 Feather framework, since that's what I prototype on), I have attained great idle power consumption (<0.5mA). But only till the first float multiplication.
I initially blamed ADC, since it was in the battery measurement code, but it really turned out to the the float multiplication, after which my draw was constantly over 6.5mA.
Then I have found https://devzone.nordicsemi.com/f/nordic-q-a/23242/single-float-division-causing-7x-higher-current-draw and the reference to the errata 87, which includes a workaround.
Perhaps this workaround (clearing the FPU pending IRQ) could be easily applied to the Feather codebase (I have since avoided float math, to a great effect on idle power).

[hathach]

superb !!! That is brilliant finding, we will note this and make sure including this in our soon-coming testing and tutorial.

[Nenik]

Interestingly enough, there seems to be (ifdef-outed) stub of the workaround in the waitForEvent implementation, as I have just found (looking into why my waitForEvent doesn't really sleep either, while delay() does pretty well)
0.8.3, wiring.c

[hathach]

use delay for the sleep(), it is mentioned in my above comment. waitForEvent will probably be removed
the next time we work on systematizing power stuff. Here is sum up when you call delay

• freeRTOS check scheduler for the next time a task will run
• if there is long-enough, it will skip tick, auto call wait for event, and wake up just a few tick before the runtime.

For details: https://www.freertos.org/low-power-tickless-rtos.html

[Nenik]

I am moving towards tickless, though I wonder about threading model of the platform.
Posted question on that topic at the forum (though at the end of the day, I might go with a central worker thread driving the UX that might get all the wakeup/event sources re-posted into...).

Thanks.

[hathach]

@Nenik it is rather simple, ble and soc run on their on thread, most of callback run on a worker thread ( some needs signature changes to be called in worker). Give me a couple of days, I will answer it more details in the forum topic.