Battery lifetime and lifetime of other components?

[espruino-discuss]

Posted at 2016-12-13 by MobiTech

Hello, do you have some experience about the lifetime of a battery? How long could it be used just listening for a button click without using a led or sending advertisements? And how would it be affected by advertising?

What is the estimated lifetime of the tactile switch and LEDs?

[gfwilliams]

Posted at 2016-12-13 by @gfwilliams

It's tricky to give exact figures - the best thing to do is measure. I put a double-sided flexi PCB between the battery and the board, and measure the current draw.

• It's roughly 20uA when advertising, so a bit over a year
• It's roughly 3uA when not advertising, so potentially 5 years or so
• When watching a button and not advertising that raises to 12uA, so it's still around 2 years

Kingbright don't give lifetime info for their LEDs, but it's a lot. They're high quality and only run at 1-2mA so not stressed.

In terms of switch lifetime, it seems to be around 50,000 presses - so if you pressed it once a second for 24 hours a day then it might start to get a bit dodgy after 6 months.

[espruino-discuss]

Posted at 2016-12-13 by Bennr

@gfwilliams Ah I was just going to ask that. Is this code going to give me the 2 years-ish figure?

setWatch(function(e) {
  controls.playpause();
}, BTN1, { repeat: true, debounce : 50, edge: "rising" });

[gfwilliams]

Posted at 2016-12-13 by @gfwilliams

Yes and no... You get 2 years when there's no computer connected - but when your computer connects it starts shoving packets out at 50Hz and draws 200uA - so you're only looking at around 40 days.

Potentially you could try turning Bluetooth off for a while when it hasn't been used, and then turning it back on when the button is pressed.

It's something that could be changed in firmware (maybe an option?) - but a slower poll rate when connected means you can transfer less data per second, which means that using the REPL and uploading firmware gets painful.

[espruino-discuss]

Posted at 2016-12-13 by Bennr

@gfwilliams Ah right ok. If the Puck gets disconnected does the power consumption go back down again? i.e. If the computer it's connected to gets shut down, does it go back to broadcasting again?

Personally I think it's better to let the code decide when it should shut off BT. Although if there was a Puck.sleep(timeToWaitBeforeSleeping) sort of option that would be good?

[gfwilliams]

Posted at 2016-12-13 by @gfwilliams

Yes, if there's no connection it'll go back to its normal sleep mode.

You can do NRF.sleep to shut off Bluetooth completely - if you want to wait before doing it there's always setTimeout :)

[espruino-discuss]

Posted at 2016-12-13 by Stevie

I did some measurements of my own using a similar method. Basically I 3D printed a CR 2032 replacement and put a cable on top and below the replacement.
The numbers I measured are a bit higher than what you mention, about 270 uA when connected, 8 uA when not advertising and have the watch set. When advertising the current fluctuates so strongly that it's difficult to judge. But it seems in the same ballbark of the 20uA.
So all in all it's all the numbers are in the same ballpark and the differences in measurements could be measurement errors on my side. So battery lifetime seems to be excellent and I can now measure how much current different applications would draw.

[espruino-discuss]

Posted at 2016-12-14 by @allObjects

When advertising the current fluctuates so strongly that it's difficult to judge.

For that, check these places from Nordic's Developer Zone out:

• https://devzone.nordicsemi.com/power/ nRF52 Online Power Profiler
• https://devzone.nordicsemi.com/blogs/903/ Blog / Explanation

[gfwilliams]

Posted at 2016-12-14 by @gfwilliams

@stevie interesting... I tried to over-estimate the figures I gave though.

When measuring I tended to put a big capacitor across the meter - it helps to smooth out the fluctuations a bit and makes it a bit easier for me to get an average.

It's worth noting that there's some 'negotiation' during the connection where the Puck gives a range of polling frequencies it accepts, and the host then chooses one. It's entirely possible that my computer chooses a lower polling frequency, and yours chooses a higher one (and hence higher power draw).

[espruino-discuss]

Posted at 2016-12-14 by Stevie

@allObjects: I looked into the Online Profiler a while ago, but it does not help that much. It does not allow to specify watches on pins and timers and so on. Maybe they do not have much influence on the power consumption. For other microcontrollers, they do. But that's what I am trying to find out.

[espruino-discuss]

Posted at 2016-12-14 by Stevie

I will try the idea with the capacitor, great suggestion! I will post the new results when I have done that. But again this could also be related to measuring error.

[gfwilliams]

Posted at 2016-12-14 by @gfwilliams

Another option is to use a digital oscilloscope and to power the Puck via a resistor. You can then measure the voltage across the resistor and the oscillicope often has a 'measure' function that will allow you to get the average voltage over a period.

Unfortunately mine isn't accurate enough to do it, but I imagine most new ones would be

[espruino-discuss]

Posted at 2016-12-14 by @allObjects

@stevie, with a not running Espruino boils down to what BLE consumes. Even advertising is without Espruino running. Pins keep their state practically power less, and as long as they are not sourcing or a pull-up is going on, it should still be what BLE consumes.

Of course, this does not answer the questions where the pins are driving something...

[espruino-discuss]

Posted at 2016-12-14 by MobiTech

Is the power consumption 20uA in one hour? So that I can calculate it this way:
20uA * 24 (hours) * 365 (days) = 0,1752 A
The lifetime would be for a battery with 230mAh: 0,23 A / 0,1752 A = 1,3 years.
Is that right?

Still another question: How could I stop advertising? Should I listen for a response of a smartphone or stop advertising automatically after some minutes (max. 15-20 minutes)? What reduces the power consumption?

[gfwilliams]

Posted at 2016-12-14 by @gfwilliams

Amps are like Watts - they're an instantaneous power measurement. The watch battery in the Puck is rated at something like 220mAh, so it'll provide 0.22 Amps for an hour - and then it's flat.

So it's basically what you're doing. The value you get of 0,1752 is basically the size of battery (in Amp-hours) that you'd need to run it for a year.

Often what you care about is how long it'll run given a battery size you know - in which case 220mAh / (20 uA * 24 * 365) gives you the number of years.

You can stop advertising with NRF.sleep() but then the Puck is effectively dead, until you wake it up - maybe in response to a button press with NRF.wake().

What battery life are you trying to get? In most cases I'd suggest just leaving it advertising - maybe reducing the advertising interval to nearer once a second and lowering the transmit power.

[espruino-discuss]

Posted at 2016-12-14 by Stevie

Hi @gfwilliams,

So I did some more measurements with the suggested capacitor. I used a 1 uF capacitor which should be plenty for smoothing out things a bit (actually the Puck can run for a couple of seconds off the capacitor before losing the connection to the web UI).

The measurement for the connected state is basically the same (~270 uA). The measurement for the advertising / disconnected state is smoothed out but still looks pretty weird: It stays at 12 uA for a bit, then ramps up to 80 uA within 3.5 s and then goes back to 12 uA again witinh 3.5 s. So we basically have a 7 second loop where something is happening. Without the capacitor it is similar, just a bit more fluctuating. Note that this happens with an empty Puck (reset() + save()) as well as with one which is watching a pin. Basically the same behavior. So something is going on every 7 seconds which draws quite a bit of power when advertising.

I also tried to switch off the bluetooth sender/receiver using NRF.sleep(). That does something: I immediately lose the connection from the web UI. But apparently it still advertises bluetooth. It still has this power cycle described above. And I can connect to it later using the web UI. I checked if the NRF.sleep() somehow causes a reset by lighting the LED on reset for a second. So that does not happen. So apparently either the bluetooth is not switched off completely. Or it is switched on again.

This is with the latest firmware.

Any ideas?

UPDATE: It seems the disconnection from the IDE triggers a reset of the bluetooth stack (in jswrap_bluetooth.c, bleUpdateServices). So that explains why the NRF.sleep() does not switch off the bluetooth stack. It only works when there is no bluetooth connection. I called it from a timer and then the current goes down to ~12 uA. But still once in 7 s it goes up to 24 uA. This is independent from a setWatch on the button.

UPDATE2: When setting the advertisement interval to 750 ms, then the power fluctuation is much faster. When setting the advertisement interval to 2 s, then it fluctuates between 12 uA and 30 uA every 2 seconds. That's kind of what @gfwilliams also measures. So my conclusion is that the fluctuation is somehow connected to the Bluetooth advertising interval. Maybe there is something wrong with the initialization of the Bluetooth stacked which is fixed when calling NRF.setAdvertising(...)? Interestingly enough with that setting even in the NRF.sleep() state the power consumption seems to be still fluctuating between 12 uA and 24 uA every 7 seconds.

[espruino-discuss]

Posted at 2016-12-14 by Stevie

@gfwilliams, actually I did that first, but mine isn't accurate enough, either :-(

[gfwilliams]

Posted at 2016-12-15 by @gfwilliams

Do you know for sure that bleUpdateServices is called? When you disconnect, advertising gets started regardless. NRF.sleep was only intended to be called when you don't have an active BLE connection so doesn't really do anything very clever.

My guess is that the pulse in power usage is due to calibration of the internal RC oscillator. The nRF52 uses the RC oscillator most of the time, but occasionally it checks the temperature and compares to the high speed oscillator to make sure it's still keeping good time.

[espruino-discuss]

Posted at 2016-12-15 by Stevie

No, that was just a guess. What I see is that the connection breaks down. From the source code it is clear, that the BLE stack goes into sleep mode. Then later it wakes up again. The mentioned function looked like a candidate. But if you say that the NRF.sleep() is not supposed to be called with an active connection that's fine with me. I was just not expecting that and thus thought initially it might not work. Personally I think a hint in the documentation might be helpful there.

The RC oscillator sounds like a possible reason. Since it is short and only occurs every 7 seconds or so that's no issue for me.

The remaining issue is the behavior before calling "NRF.setAdvertising(...)" for the first time. There the power really goes up for 3.5 s and ramps down for 3.5 s. In think there is some serious current flowing during that time (if one accepts 80 uA as serious :-) - well, if the expected current is 20 uA, then 80 uA is serious). This goes away after calling NRF.setAdvertising(...) for the first time. Since I now have a workaround there is no big problem for me, but I think it is something to be looked into - if anyone else can reproduce it...

[gfwilliams]

Posted at 2016-12-15 by @gfwilliams

I just checked with a scope, and this is what I see on a standard unprogrammed Puck with 1v89 firmware and no code on it.

It's exactly what you'd expect - so if you're seeing something strange on your meter I'd probably put any problems down to that. I wouldn't waste too much time trying to narrow down uA consumption until you can stick it on something where you can really reliably view the power consumption over time, or you might just end up chasing artefacts of your meter :)

It's likely that the sample window of your meter is such that occasionally the pulse of power draw gets inside it, and occasionally it doesn't - you're basically seeing an interference pattern :)

Attachments:

• IMG_20161215_103840.jpg

[gfwilliams]

Posted at 2016-12-15 by @gfwilliams

Also, if you think the documentation could do with clearing up in places, there's a little arrow (⇒) to the right of the function name, and it brings you to where the function (and documentation is defined).

I'm insanely busy at the moment, so if anyone does have time to issue pull requests to clear things up or add examples, it'd really be appreciated. I'm working on the code now, so I'll add NRF.sleep though

[espruino-discuss]

Posted at 2016-12-15 by Stevie

Thanks for double checking! I will try the same with my scope. And I agree, let's not chase ghosts.

[espruino-discuss]

Posted at 2016-12-15 by Stevie

Okay, the little arrow I overlooked so far. That's really useful. I can certainly add something there in the future.

[espruino-discuss]

Posted at 2016-12-16 by stevie4711

Hi @gfwilliams, thanks for putting the enhancement to the NRF.sleep() in so fast. I tested the new version and it works great, now! I also did the measurement with the scope. But as expected the accuracy is not really good enough to say anything conclusive. But at least I did not see this weird fluctuation anymore. So all seems to be good.

Oops, apparently I have 2 accounts :-)

[espruino-discuss]

Posted at 2016-12-16 by AntiCat

I've made some measurements:

• The Pattern below is repeated every 182ms. (It should be 175 ms)?
• Each advertisement is >4uA. Note: the current drawn exhausted my scale.

---

Attachments:

• Advertisement.png

[espruino-discuss]

Posted at 2016-12-17 by AntiCat

Below my second try, peaks are significantly higher as I anticipated.
(I've inserted a reference to the previews scale)

Each advertisement is ~12uA.

Attachments:

• peak.png

[gfwilliams]

Posted at 2016-12-19 by @gfwilliams

Wow, nice captures. I think with the see-saw you're probably seeing the switch-mode power supply kicking in?

What do you mean by 12uA? 12uA average over that time period?

[espruino-discuss]

Posted at 2016-12-19 by DeleteMe

ups

[espruino-discuss]

Posted at 2016-12-19 by AntiCat

Sorry for not explaining my measurements in more detail in the first place.

I've used a CR2032 coin cell as energy source and measured the voltage drop on a 10R high precision resistor (uCurrent). Therefore the see-saw supposedly shows the different phases of the uC cycle:

1. power up
2. pre-processing
3. transmit (I assume 3 consecutive re-transmits)
4. power down

I'm using the DSO's math functions to calculate the integral (shown in purple) on channel 1 (yellow). The integral of this particular measurement is 11.44uU = 11.44uA/advertisement. However measurements are never exact. Hence I decided to state the value at ~12uA/advertisement, in my post above.