Author Topic: Efficient use of coin cells  (Read 17104 times)

joelucid

  • Hero Member
  • *****
  • Posts: 868
Efficient use of coin cells
« on: July 18, 2015, 08:16:34 AM »
I've been thinking about coin cell operated Moteinos for a bit and looked more into power consumption during sleep. As it turns out the most costly subsystem during sleep is the watchdog timer consuming a hefty 5 uA. If you build a sensor using energy efficient components (say the si7021) it's clear that the WDT is the main energy drain even if measurement and radio are figured in.

It occurred to me that I can shave off part of that by using listen mode to trigger measurements and switching the WDT off during sleep. The Moteino will be woken from sleep by the radio triggering an interrupt.

So I'll have one Moteinos broadcast 3s bursts every 10 minutes to wake up all thermometers and they will report back with the temperature. Sleep power should go down to about 3uA total with that approach. Add about 2uA for sending the update or an average total of 5uA which gives a couple of years on a cr2032.
« Last Edit: October 03, 2015, 05:43:30 AM by joelucid »

TomWS

  • Hero Member
  • *****
  • Posts: 1930
Efficient use of coin cells
« Reply #1 on: July 18, 2015, 09:06:08 AM »
I've been thinking about coin cell operated Moteinos for a bit and looked more into power consumption during sleep. As it turns out the most costly subsystem during sleep is the watchdog timer consuming a hefty 5 uA. If you build a sensor using energy efficient components (say the si7021) it's clear that the WDT is the main energy drain even if measurement and radio are figured in.

It occurred to me that I can shave off part of that by using listen mode to trigger measurements and switching the WDT off during sleep. The Moteino will be woken from sleep by the radio triggering an interrupt.

So I'll have one Moteinos broadcast 3s bursts every 10 minutes to wake up all thermometers and they will report back with the temperature. Sleep power should go down to about 3uA total with that approach. Add about 2uA for sending the update or an average total of 5uA which gives a couple of years on a cr2032.
Funny you should mention this.   I'm in the middle of testing a similar setup and here's what I've found:

The average current while sleeping and an SI7021 (and an idle BMP180 since I'm prototyping with a Weathershield) is 4.3uA with a coin cell.  The average calculated current with RFM69W transmitting every 10 minutes at about mid power is about 5.2uA.  All good and, as you say, the coin cell should last for years. 

The problem is startup.  Loading the sketch and initially charging the bulk caps takes a LOT out of the coin cell and, in fact, if you're not careful, the coin cell discharges so much in this initial startup it can never get to sleeping mode.   My plan of attack is to install the coin cell with a well established procedure that avoids the initial shock to the battery.

The procedure is to program the module with the sketch using separate power supply (no battery installed) and do all configuration (set node id, establish connection to gateway, etc) at that point.  Then, to install the battery, use a power source to operate the node (and precharge the bulk caps), let the node sleep, install the battery, and disconnect the external power source. 

This procedure SHOULD allow the device to operate for years on the coin cell.  Unfortunately, the node is totally intolerant of any 'problems'.  One hang, Gateway goes out and the node retries multiple sends, anything, and your dead, literally.  The coin cell just does not have the capacity to operate an actively listening or transmitting node for more than a few seconds before the voltage collapses to an unusable (and unrecoverable) voltage.

My latest code doesn't use retry because it's too dangerous to the node.  We'll see if that allows the node to live up to its expectations.

Tom

joelucid

  • Hero Member
  • *****
  • Posts: 868
Re: Efficient use of coin cells
« Reply #2 on: July 18, 2015, 04:31:52 PM »
Tom,

Thanks, very interesting!

My plan was to preprogram the 328p's with a modified wireless boot loader that better supports coin cell operation. I bought a socket that will allow me to flash the chips before assembly. The (to be developed) boot loader would bring down the app in chunks to avoid the battery drain.

Then the remaining challenge would be the cap. I had thought about adding some boost switching circuitry to slowly charge the cap via an inductor until it's ready to go wireless but had killed that idea as too complicated. I really want at least the hw to be super simple, running on internal 8mhz with no external parts other than the large cap and 2 decoupling caps.

Are you positive that charging the large cap would be an issue if the system came preprogrammed?

joelucid

  • Hero Member
  • *****
  • Posts: 868
Re: Efficient use of coin cells
« Reply #3 on: July 18, 2015, 05:18:48 PM »
Btw, how do you avoid WDT? Using listen mode or some other trick?

TomWS

  • Hero Member
  • *****
  • Posts: 1930
Re: Efficient use of coin cells
« Reply #4 on: July 18, 2015, 07:42:37 PM »
<snip>
Are you positive that charging the large cap would be an issue if the system came preprogrammed?
I don't have any hard data yet as I've only begun testing this last week and mainly focused on operating performance, choosing to mull over the startup problem.  It is clear there is a problem because a fresh cell had dropped to 2.6V in a matter of seconds before I had a chance to disconnect it.  How much of it is bulk cap surge, it's tough to say, but that could be a huge load given the ESR and that it starts at 0V as the battery is connected.

I think the ideal circuit would be one where there are two switches, which are open on startup, controlled by a voltage comparator.  The first switch is between the coin cell and the bulk cap, the second between the cap and the rest of the circuit.  There is a resistor in parallel with the first switch (say 1K ohm) which would charge the bulk cap up to the coin cell voltage.  Once the cap was within 0.1V of the coin cell, then both switches close and the rest of the circuit is powered up, with the bulk of the current coming from the bulk cap.   

I'm only using 200uF as the bulk cap as I wanted to keep this node tiny and anything bigger requires a significantly physically larger cap.  This cap should be fine IFF the transmissions and wake time is limited to a few mS.

As I said, the real problem is when there is that unanticipated problem - the one where everything stays running at full power for seconds.  This is disastrous for this battery.

This is certainly a worthwhile project to work on!

Tom

TomWS

  • Hero Member
  • *****
  • Posts: 1930
Re: Efficient use of coin cells
« Reply #5 on: July 18, 2015, 07:46:54 PM »
Btw, how do you avoid WDT? Using listen mode or some other trick?
Are you asking me?  I do use WDT, using the Sleep_n0m1.h library.  Mote sleeps for 10 minutes and then sends its measurement to the gateway without retry and then goes back to sleep.

Tom

joelucid

  • Hero Member
  • *****
  • Posts: 868
Re: Efficient use of coin cells
« Reply #6 on: July 19, 2015, 11:20:14 AM »
Quote
One hang, Gateway goes out and the node retries multiple sends, anything, and your dead, literally.  The coin cell just does not have the capacity to operate an actively listening or transmitting node for more than a few seconds before the voltage collapses to an unusable (and unrecoverable) voltage.

Yeah, that's where the polling mechanism via listen mode could really help, too. That way the nodes wouldn't do anything unless the gateway is alive and well and asks for an update.

Having the gateway control when nodes send their updates could also finally allow a feature I've been wanting to do for some time: allow nodes to send at different baud rates.  Most nodes I have run really well on 200kbit - but I have two that require Felix 55kbit rate (one of them isn't even happy at that rate during rain).

Now especially with coin cells I want to use as high a bit rate as possible to shorten transmit & receive times. If I control when the nodes transmit I can select one bit rate at the gateway and wake all clients that support that rate.

I'd likely support 3 bit rates (200kbit, 55kbit, 19.2kbit) and have the nodes in listen mode with a different frequency for each rate. A broadcast at a given frequency would wake all clients supporting the rate and have them send an update if required. If the coin cell nodes work at 200kbit I suspect that I can further reduce the duty cycle of listen mode and maybe get sleep power consumption down to ~2uA, about half of what's required for the WDT.

Joe

joelucid

  • Hero Member
  • *****
  • Posts: 868
Re: Efficient use of coin cells
« Reply #7 on: July 28, 2015, 12:53:49 PM »
Quote
This procedure SHOULD allow the device to operate for years on the coin cell.  Unfortunately, the node is totally intolerant of any 'problems'.  One hang, Gateway goes out and the node retries multiple sends, anything, and your dead, literally.  The coin cell just does not have the capacity to operate an actively listening or transmitting node for more than a few seconds before the voltage collapses to an unusable (and unrecoverable) voltage.

Tom, you should check out some supercaps. I just got delivery of my test caps yesterday and there's no way I'm going back to regular caps for this project. I'm currently testing a 0.1F cap which has a diameter of about 10mm and is maybe 3mm think. I can disconnect a 2.6V power supply and a moteino running my old (not cap optimized, 55kbaud, still with acks etc) code will send more than 50 updates before it collapses. The end product feels much more like a real Moteino than with a 400uF cap. Amazingly there is no leakage current to speak of at the cap after some charging time.

I have a 1kOhm resistor between the cap and the coin cell which will limit cr2032 drain to around 3mA during startup and much closer to the optimal 0.5 - 1mA during normal operation. This should really maximize coin cell lifetime.

Unfortunately the RFM69HW draws A LOT of power early during startup, so I still pre-charge. Not clear yet if I'll just eat that cost and go to 500Ohm to enable simultaneous cap charging and RFM69 wasting, or if I'll add a MOSFET to allow the 328p to power up the radio when the cap is full. I'm booting the 328p at 1Mhz so reset current should be minimal until it starts up and goes to sleep waiting for the cap to fill.

TomWS

  • Hero Member
  • *****
  • Posts: 1930
Re: Efficient use of coin cells
« Reply #8 on: July 28, 2015, 03:27:32 PM »
Tom, you should check out some supercaps. I just got delivery of my test caps yesterday and there's no way I'm going back to regular caps for this project. I'm currently testing a 0.1F cap which has a diameter of about 10mm and is maybe 3mm think. I can disconnect a 2.6V power supply and a moteino running my old (not cap optimized, 55kbaud, still with acks etc) code will send more than 50 updates before it collapses. The end product feels much more like a real Moteino than with a 400uF cap. Amazingly there is no leakage current to speak of at the cap after some charging time.

I have a 1kOhm resistor between the cap and the coin cell which will limit cr2032 drain to around 3mA during startup and much closer to the optimal 0.5 - 1mA during normal operation. This should really maximize coin cell lifetime.

Unfortunately the RFM69HW draws A LOT of power early during startup, so I still pre-charge. Not clear yet if I'll just eat that cost and go to 500Ohm to enable simultaneous cap charging and RFM69 wasting, or if I'll add a MOSFET to allow the 328p to power up the radio when the cap is full. I'm booting the 328p at 1Mhz so reset current should be minimal until it starts up and goes to sleep waiting for the cap to fill.
I haven't checked out super caps in a while but, in the past, leakage was an issue, especially if I go to SMD versions. 

Like you, I'm thinking of a resistor precharge circuit (attached is my latest iteration), but, in this case, to be safe, I added the RFM69 reset line because I'm not confident it will reliably reset with such a slow rise time.  I can monitor the cap voltage by way of the SDA pullup resistor. 

Note that the outer dimension of the PCB is 26 mm diameter circle.

Tom

TomWS

  • Hero Member
  • *****
  • Posts: 1930
Re: Efficient use of coin cells
« Reply #9 on: July 28, 2015, 03:40:15 PM »
Tom, you should check out some supercaps. I just got delivery of my test caps yesterday and there's no way I'm going back to regular caps for this project. I'm currently testing a 0.1F cap which has a diameter of about 10mm and is maybe 3mm think. I can disconnect a 2.6V power supply and a moteino running my old (not cap optimized, 55kbaud, still with acks etc) code will send more than 50 updates before it collapses. The end product feels much more like a real Moteino than with a 400uF cap. Amazingly there is no leakage current to speak of at the cap after some charging time.

I have a 1kOhm resistor between the cap and the coin cell which will limit cr2032 drain to around 3mA during startup and much closer to the optimal 0.5 - 1mA during normal operation. This should really maximize coin cell lifetime.

Unfortunately the RFM69HW draws A LOT of power early during startup, so I still pre-charge. Not clear yet if I'll just eat that cost and go to 500Ohm to enable simultaneous cap charging and RFM69 wasting, or if I'll add a MOSFET to allow the 328p to power up the radio when the cap is full. I'm booting the 328p at 1Mhz so reset current should be minimal until it starts up and goes to sleep waiting for the cap to fill.
I haven't checked out super caps in a while but, in the past, leakage was an issue, especially if I go to SMD versions. 

Like you, I'm thinking of a resistor precharge circuit (attached is my latest iteration), but, in this case, to be safe, I added the RFM69 reset line because I'm not confident it will reliably reset with such a slow rise time.  I can monitor the cap voltage by way of the SDA pullup resistor. 

Note that the outer dimension of the PCB is 26 mm diameter circle.

Tom
Actually, re-reading your note, maybe your idea to put the switch only on the radio is a better idea (I wouldn't need the reset pin), but I was going after using a resistor to precharge and then the switch jumpers the resistor taking it out of the circuit.  I don't think 200uF is enough to sustain the radio during transmissions.  Sigh, I may have to prototype this approach.  I was hoping to go right to PCB...

My current prototype is holding its own, currently running at 2.778V with a severely abused coin cell.  The voltage seems to have plateaued at this level for about a week after a number of mess-ups quickly bled off the 3.0 down to about 2.85V (it had gotten to 1.6V at one point!).

Tom

TomWS

  • Hero Member
  • *****
  • Posts: 1930
Re: Efficient use of coin cells
« Reply #10 on: July 28, 2015, 04:35:07 PM »
Working on the general principle that you can always fit one more component, I fitted a second transistor on the PCB.  I can now independently switch the pre-charge resistor (I was able to increase its value to 1K and can probably go higher although that could be approaching the point of diminishing returns) and an independent switch for the radio.  I kept the reset pin because it was already wired but I shouldn't need it.

A supercap would now work great if I could fit it.  I couldn't even fit a single 470uF (because of the curvature of the PCB) and had to go with two 100uF caps just to get 200uF.

Tom

joelucid

  • Hero Member
  • *****
  • Posts: 868
Re: Efficient use of coin cells
« Reply #11 on: July 28, 2015, 06:36:39 PM »
Yeah if you go with 200uf you'll need to be able to switch the charging resistor off. However that will likely impact lifetime of the cr2032 because it doesn't like pulsed loads much. You definitely need the rfm69 switch. My prototype didn't boot without precharging with a 2.6v source since the rfm69 would just draw voltage down to around 1.4v. It did boot with 300 Ohm - but I'm uncomfortable with that esp with a supercap.

Btw the si7021 data sheet says it draws several mA during boot - so I'm planning to power it from a gpio port (the current prototype does not yet include the si7022).

Wrt leakage current: I set the update frequency of the moteino to several hours and then measured current into the circuit. Active was the WDT, listen mode and the cap. After maybe 20 minutes the current was down to around 6uA which is excellent (4uA WDT,  so 2uA or so for listen mode, 328p sleep and cap leakage). But yeah it'll cost a bit of space.

TomWS

  • Hero Member
  • *****
  • Posts: 1930
Re: Efficient use of coin cells
« Reply #12 on: July 28, 2015, 07:38:08 PM »
Yeah if you go with 200uf you'll need to be able to switch the charging resistor off. However that will likely impact lifetime of the cr2032 because it doesn't like pulsed loads much. You definitely need the rfm69 switch. My prototype didn't boot without precharging with a 2.6v source since the rfm69 would just draw voltage down to around 1.4v. It did boot with 300 Ohm - but I'm uncomfortable with that esp with a supercap.
I agree with that assessment.  Best to charge up the cap (whatever it is) and then power up the RFM69 when you know you have enough coulombs to power it through its initialization.  BTW, my target is to safely get 9+ months from the battery.
Quote
Btw the si7021 data sheet says it draws several mA during boot - so I'm planning to power it from a gpio port (the current prototype does not yet include the si7022).
This caught me a bit off-guard. I incorrectly assumed the device powered up in standby state.  Fortunately the duration is only 5mS so not a problem on the surface.  However, the real question is what is the current draw during a very slow rise time VDD?  If it's 5mA @ 3.3V (ie 660ohm) then my latest setup with 1K resistor isn't going to work because the voltage will never get to a level sufficient to 'boot' the sensor.  Sigh, GPIO for the power might be the right answer, but then I can't use the SDA line as a VSense.  I can probably wire in VSense on another pin (no new components, thank goodness) and driving power to the SI7021 will probably take a bit of trace jiggling...
Quote
Wrt leakage current: I set the update frequency of the moteino to several hours and then measured current into the circuit. Active was the WDT, listen mode and the cap. After maybe 20 minutes the current was down to around 6uA which is excellent (4uA WDT,  so 2uA or so for listen mode, 328p sleep and cap leakage). But yeah it'll cost a bit of space.
Supercap's not for me, but, once I resolve the SI7021 power up sequence, I'm comfortable that I should get reasonable life from the coin cell.  It's those hangups that worry me - no spare capacity to recover. 

Tom

joelucid

  • Hero Member
  • *****
  • Posts: 868
Re: Efficient use of coin cells
« Reply #13 on: August 10, 2015, 02:27:07 AM »
Quote
So, the target is to make the current consumption as smooth as possible with a well defined cap, which buffers the transmissions and listening mode current peaks?

I've always thought that would be the optimum as well. But there is some conflicting evidence (see https://www.dmcinfo.com/Portals/0/Blog%20Files/High%20pulse%20drain%20impact%20on%20CR2032%20coin%20cell%20battery%20capacity.pdf for example).

In the end the primary purpose of the cap might be to provide enough juice to avoid a voltage drop below the operating limits of the rfm69.

This is an interesting question since if the pulsed load hurts it would make sense to put a resistor in front of the load. This might make sense anyway since it would cause the system to restart if it gets stuck in receive etc instead of damaging the battery. I'm currently running a test to verify this.


TomWS

  • Hero Member
  • *****
  • Posts: 1930
Re: Efficient use of coin cells
« Reply #14 on: August 10, 2015, 12:07:07 PM »
Quote
So, the target is to make the current consumption as smooth as possible with a well defined cap, which buffers the transmissions and listening mode current peaks?

I've always thought that would be the optimum as well. But there is some conflicting evidence (see https://www.dmcinfo.com/Portals/0/Blog%20Files/High%20pulse%20drain%20impact%20on%20CR2032%20coin%20cell%20battery%20capacity.pdf for example).

In the end the primary purpose of the cap might be to provide enough juice to avoid a voltage drop below the operating limits of the rfm69.

This is an interesting question since if the pulsed load hurts it would make sense to put a resistor in front of the load. This might make sense anyway since it would cause the system to restart if it gets stuck in receive etc instead of damaging the battery. I'm currently running a test to verify this.
Excellent article, Joe!  Thanks for finding and posting it!  The takeaway for me, and consistent with my findings is that, in our case, FEP is the key factor.  We already have very low average current and, from the data in the article, it seems that even with very high current pulsed loads the battery can deliver at least 150mAH, which, in my case would keep me happily running for 5+ years.  What would prevent this longevity is the IR drop allowing the voltage below FEP and, I think, as Felix pointed out and, again, consistent with my findings, FEP is probably around 2.0V for this circuit (assuming very low Vgsth for the FETs). 

Net is that an additional series resistor is actually a mistake.  I've designed my circuit with a series resistor but, in my testing have tried several values and have concluded that no resistor is best (for FEP reasons).  However, I didn't have enough data to know how the high currents would affect overall life of the battery.  Now I do!  Thanks again!

Tom
« Last Edit: August 10, 2015, 12:09:12 PM by TomWS »