DK energy usage data


#1

I have captured and plotted some energy usage data for a DK running with the LED turned off and loop() consisting solely of:

void loop()
{
	/*
	 * All we do here is go to sleep
	 */
	System.sleep(SLEEP_MODE_CPU);
}

The first chart shows the current consumption and total charge used over approx 200mS. I think you can click on the image for the original, which is much larger. You can clearly see the BLE radio doing stuff @ 30mS intervals, and there is a second set of activity at a 100mS cadence.


[NOTE: edited, new image uploaded - y2 axes scale was wrong, calculations & numbers in the commentary are correct]
The data suggests that the DK asleep like that consumes approximately 2.8 milliCoulombs per second, or about 10 Coulombs per hour. AA alkaline calls offer approx 7200-9000 Coulombs total capacity, which equates well to your expected life of ~1month on AA Alkaline cells.

Here is a detail of the 30mS BLE-driven events:


Note the change in horizontal scale (natch - it’s a detail.)


NRF Connection interval
Wake on interrupt
Best way to power digital input (switch)?
#2

Thanks for sharing the results!

That all looks exactly as I would expect. The BLE radio is waking up each connection interval to talk with the gateway, which is ~30mSec in this case. The 100mSec activity is the software timer waking bluz up to check the Particle cloud connection, check the RGB LED and see if it needs to be turned on, run the user loop function, etc. In between those things, the power draw should be very limited, which it is.

As you can see, the connection interval is the main driver for the current draw. That interval can be set as long as 4 seconds. Once we get that exposed as a parameter on the gateway (it is always set by the gateway, the DK can suggest values, but the gateway defines it), we will be able to significantly extend the battery life. One of the main features we will get up and running in the gateway console as soon as we can.


#3

Integrating the detailed current data suggests the charge used by each BLE episode is ~ 84uC [note: I edited the graph in the opening post, the y2 axes was off by an order of magnitude - all other numbers remain unchanged.]

That suggests that maxing the connection interval to 4 seconds would result in ~ 1.8 Coulombs per day used for BLE, plus the quiescent current and whatever sensor/activator activity was required.

But, the sleep energy consumption is not that low by many standards, you’re still looking at around 330uC/Sec (e.g. ~330uA sleep current) - that’s very significant over the long term.
You need to consider efficiency: over 24 hours, that adds up to ~29 Coulombs. Using 29 Coulombs unproductively sleeping while using 1.8 Coulombs to stay in touch with the outside world is a pretty poor trade-off. If we could improve quiescent by an order of magnitude, the balance would be much better.

I ignored the 100mS blips waking up to service LEDs and loop(), for the purposes of these approximations; but they will make the numbers worse, and should be eliminated when possible too.


#4

You’re seeing 330uA when sleeping between BLE events? That does seem a bit high. How were you powering it? Through the regulator? Or with an already regulated 3.3V?


#5

I’m powering from a pair of AA alkalines.

I can put more effort into measuring quiescent (this was a quick estimate from a quiet patch of the trace) but even if it is 220uA, it will still be 19 Coulombs per day - 10x the energy expended on BLE comms, so my statement still stands.

If you think it should be 25uA, then we’re in the right ball park; but I do not think it is that low at present.


#6

I’m sure we can probably tweak it in places to save power. Remember too that the external SPI flash is always on and that consumes 20uA in standby mode, so we may not get that low for the whole system.

As a note to the original post, you should get WAY more life from AA batteries than 1 month, even today with the current connection intervals. I haven’t done any exacting measurements, but I have run bluz boards for many weeks on a single coin cell. CR2032 have between 200-240mAh capacity, whereas AA will have ten times that. You should easily be able to get many months of life from AA.


#7

I do not get many weeks with 2032 cells (with my current test config, with the LED on the 2032 board off, and the code disabling the RGB LED) I get between 7-10 days life (when connected via a GW to the particle cloud), which jives with my measurements within expected tolerances…

I’ve been running one DK on AA batteries for about a week now, and it’s happy as a clam.

Next time I put an order in to a supplier, I will order some 0.1% sense resistors (I use 10 Ohm), at present I believe I’m using 1% resistors, not a big issue, but the errors are cumulative.


#8

Hmmm, I would expect, and have seen, much more than 7-10 days. I currently have several DK connected through a gateway that has been running for just about two weeks and everything is still going strong.

Just out of curiosity, are the batteries brand name that were purchased at a local store? I have gotten so many counterfeit batteries from Amazon it is kind of insane. One time, we ordered a bunch of Energizer and they came in packs of 10. In one of the packs, every battery was already dead.

Still, 7-10 days on a CR2032 should get you 70-100 days on AA. But you should still see more than that from CR2032.


#9

Well, let me get more accurate measurements and we’ll see where it goes.

I have a stock of known good Sanyo 2032s, they are a couple of years old, but have shown no signs of problems in other uses.


#10

OK - I have some more careful measurements of the quiescent current between the BLE episodes, does 80uA +/- 10uA seem more in line with your expectations ?

That would put quiescent charge used around 6.9 Coulombs per day. Much better than the numbers I was bandying about above (although still > 3 times more than the energy used by the BLE radio over the same period (assuming 4 Sec poll rate).)


#11

Yes, that sounds much closer to what I would expect. We can probably tweak that a bit to get it a little lower.

The other obvious way to reduce power is to lower the transmit power of bluz. It currently defaults to 0dBm, but we can take that down much lower if your application only needs short range. That will give you another boost in battery life.


#12

On a similar note, I’ve been thinking about the requirement that the DK check the particle cloud connection. Would it be possible for the gateway device to send a “interrupt/wakeup” signal to the DK, so that it could basically remain BLE connected, but not cloud connected, and only wake up when requested, e.g. a variable check or function call? I don’t know much about the BLE protocol, so there’s that, and I’m thinking that the Particle protocol would also have to be modified/hacked somehow or another on the gateway to make that work. Anyways, just a thought.


#13

I think having the GW spoof the particle cloud is a great idea, if at all possible,


#14

@mumblepins it’s an interesting idea, but it won’t save you much power. The big power loss for now is the BLE connection being maintained, a packet must be sent at each connection interval. The cloud connectivity is only maintained by sending one packet of data every 15 seconds, the extra power to maintain that is negligible.

For now, the DK will get woken up whenever a function call or variable check happens, that is built in. So the cloud connection is very minimal overhead, the only time it is “stressful” is during the handshake as a lot of data needs to pass quickly. I would say keeping the cloud connection on all the time and minimizing the handshakes is most important.

Unless there was another reason behind the idea? Was I missing something?


#15

No, not missing anything. I just realized I was misinterpreting the graph and what you said about the connection intervals, and was thinking that the bigger spikes were the wakeup check every 100ms, not the other way around. Whoops! @AndyW, if you got a chance, I’d be curious to see a trace from that cloud packet call and response. I need an oscilloscope :disappointed:


#16

You want the power profile trace around a cloud->DK function call, and a DK->cloud variable update ?

Let me see if I can capture these beasts.

@eric, I hear what you’re saying, I’m probably falling into the trap of needless/premature optimization.


#17

Well, that would be interesting too, but I was more asking about the every idle cloud checkup that it does every ~15 seconds. It basically sends up 18 bytes, and then the cloud sends down 18 bytes in response.


#18

OK - will see if I can either identify those exchanges from the data, or if I can’t then I should be able to add a trigger event to the photon gateway code.

Stay tuned (but don’t hold your breath.)


#19

This is amazing Andy, thanks for teaching me about the Coulomb unit!
Gustavo.


#20

Hi Andy, thanks for this! I know is old, but I’m just getting into Bluz and going through these calculations now. Please forgive the noob questions, I’m just a hobbyist.

Are the units on the right-side Y axis correct? Looks like you ended up finding the quiescent current to be 80uA, but the graphs are dipping below that if the Y axis is in mA.

The CR2032 shield page says that a CR2032 lifetime is affected by current spikes. So I’m wondering… are we hitting it with sub-microsecond draws of ~130mA? Is there any value in putting a capacitor in parallel with the battery?