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

joelucid

  • Hero Member
  • *****
  • Posts: 867
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: 1925
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: 867
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: 867
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: 1925
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: 1925
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: 867
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: 867
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: 1925
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: 1925
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: 1925
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: 867
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: 1925
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: 867
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: 1925
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 »

TomWS

  • Hero Member
  • *****
  • Posts: 1925
Re: Efficient use of coin cells
« Reply #15 on: August 10, 2015, 12:21:02 PM »
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.
Yes, exactly!  If you can fit a cap big enough to do this.  I couldn't, but a supercap would certainly keep the ESR low enough to keep pulsed operating voltage well above 2.0V even with a battery that is approaching EOL.

Tom


joelucid

  • Hero Member
  • *****
  • Posts: 867
Re: Efficient use of coin cells
« Reply #16 on: August 10, 2015, 05:30:47 PM »
Tom, if you eliminate the overhead in your circuit maybe you can fit 5 100uF caps on there. I think you don't need the pull up and cap on reset (the 328p has an internal pull-up on reset and the cap is not really needed). Also you can use the internal pull-ups of the 328p for SPI bus communication as long as you keep SPI  frequency pretty low.

With 500uF you should be able to operate your circuit down to around 2.5v idle voltage which is close to EOL. I think 200uF is very little unfortunately.

I have yet to try this but soldering wires to a 2032 might allow to eliminate the battery holder and save further space.

joelucid

  • Hero Member
  • *****
  • Posts: 867
Re: Efficient use of coin cells
« Reply #17 on: August 10, 2015, 05:37:56 PM »
See http://www.atmel.com/Images/Atmel-2521-AVR-Hardware-Design-Considerations_ApplicationNote_AVR042.pdf

for more details on the reset cap and resistor. For our application I suspect none is needed.

TomWS

  • Hero Member
  • *****
  • Posts: 1925
Re: Efficient use of coin cells
« Reply #18 on: August 10, 2015, 10:14:46 PM »
See http://www.atmel.com/Images/Atmel-2521-AVR-Hardware-Design-Considerations_ApplicationNote_AVR042.pdf

for more details on the reset cap and resistor. For our application I suspect none is needed.
On a number of my motes, and this prototype in particular, I have found that a capacitor to ground was required to reliably reset the AVR on power up.  On motes that use a standard Moteino R4 board, I've found a header on the FTDI connector that jumpers the DTR pin to the GND pin has provided more reliable startup when not using the FTDI cable.  I think it depends on the rise time of VDD

Tom

TomWS

  • Hero Member
  • *****
  • Posts: 1925
Re: Efficient use of coin cells
« Reply #19 on: August 10, 2015, 10:42:47 PM »
Tom, if you eliminate the overhead in your circuit maybe you can fit 5 100uF caps on there. I think you don't need the pull up and cap on reset (the 328p has an internal pull-up on reset and the cap is not really needed).
Maybe, but I've sent the PCB out to fab and I'm quite satisfied with the expected life span for my application.  If I wasn't so focused on minimizing size, I agree, I'd go with a cap that was at least 10 times the size of what I have now.
Quote
Also you can use the internal pull-ups of the 328p for SPI bus communication as long as you keep SPI  frequency pretty low.
I think you mean the I2C bus, but, frankly, the amount of time these are supplying current is so low, the resistance doesn't really contribute to battery life.
Quote
I have yet to try this but soldering wires to a 2032 might allow to eliminate the battery holder and save further space.
I don't think soldering to the battery case would be healthy for the battery.  In my case the battery holder only adds Z dimension (approximately 4-5mm), it takes no additional X/Y space as it straddles the radio module.

Tom


TomWS

  • Hero Member
  • *****
  • Posts: 1925
Re: Efficient use of coin cells
« Reply #20 on: August 11, 2015, 10:01:36 AM »
I have yet to try this but soldering wires to a 2032 might allow to eliminate the battery holder and save further space.
If you have the equipment, spot welding contacts on to the battery plates might work without damaging the battery chemistry.

Tom

joelucid

  • Hero Member
  • *****
  • Posts: 867
Re: Efficient use of coin cells
« Reply #21 on: August 13, 2015, 12:56:38 AM »
Quote
I think you mean the I2C bus, but, frankly, the amount of time these are supplying current is so low, the resistance doesn't really contribute to battery life.

Of course you're right, I meant I2C. My concern wasn't battery life but space since you had said you couldn't add as much capacitance as you wanted to your circuit. Anyway since it's out to fab it is what it is I guess.

Along these same lines (minimizing components) I did a test yesterday flashing my test app without any boot-loader. And wouldn't you know it the prototype came up without problems or damage to the coin cell even without any resistor on power-up and with the RFM69 and a 470uF cap fully attached. I did measure a 150mA spike which is certainly a lot.

Given the resilience of these cells and that power-up only happens once I'm going to experiment a bit more with this setup, going with at least a 500uF cap and nothing else. The improvement in end of life performance might well be worth the initial hit. 
« Last Edit: August 13, 2015, 12:58:31 AM by joelucid »

joelucid

  • Hero Member
  • *****
  • Posts: 867
Re: Efficient use of coin cells
« Reply #22 on: August 13, 2015, 01:05:13 AM »
On a number of my motes, and this prototype in particular, I have found that a capacitor to ground was required to reliably reset the AVR on power up.  On motes that use a standard Moteino R4 board, I've found a header on the FTDI connector that jumpers the DTR pin to the GND pin has provided more reliable startup when not using the FTDI cable.  I think it depends on the rise time of VDD

Interesting - I've never had any problems in that area. Do you have the BOD active? In scenarios where VDD rises slowly that should help. Additionally you could add a startup delay via the low fuse if you haven't already tried that.

TomWS

  • Hero Member
  • *****
  • Posts: 1925
Re: Efficient use of coin cells
« Reply #23 on: August 13, 2015, 08:28:18 AM »
Given the resilience of these cells and that power-up only happens once I'm going to experiment a bit more with this setup, going with at least a 500uF cap and nothing else. The improvement in end of life performance might well be worth the initial hit.
I think you and I are on the same wavelength!  Because of the apparent resilience of the batteries, I'm also thinking that my V1 boards might be useable.  I'll just have to program them while it's powered with an external power source, something I plan to jig for the V2 boards anyway.  The only thing that is NOT resilient is the ability to power up if the radio is drawing a lot of power on power up.  In this case you can never get enough voltage to get past boot and you're stuck simply bleeding the life out of the battery. :(

Re the power on reset, I've had the startup issue on motes where BOD was set to 2.7V so you would think that would have taken care of the problem.  I can not say that I've studied this exhaustively, however, as the jumper from DTR to Ground seems to address the issue on problem Motes and I have more fun things to work on  ;)

Tom

TomWS

  • Hero Member
  • *****
  • Posts: 1925
Re: Efficient use of coin cells
« Reply #24 on: August 13, 2015, 08:58:31 AM »
Quote
I think you mean the I2C bus, but, frankly, the amount of time these are supplying current is so low, the resistance doesn't really contribute to battery life.

Of course you're right, I meant I2C. My concern wasn't battery life but space since you had said you couldn't add as much capacitance as you wanted to your circuit. Anyway since it's out to fab it is what it is I guess.
You're right, I could have eliminated R2 (on SCL) line since it's not multi-master so driving with a push-pull output would actually be better.   However, having chased enough I2C (AKA SMBUS) issues in my life, I wouldn't use anything larger than 10K for an SDA pullup.  Getting rid of R2 would have given me enough room for another 100uF.  I'd have to do a trial layout to see if I could fit something as large as a 470. 

When I do R3  :D

Tom

joelucid

  • Hero Member
  • *****
  • Posts: 867
Re: Efficient use of coin cells
« Reply #25 on: August 13, 2015, 04:41:20 PM »
Quote
I'll just have to program them while it's powered with an external power source, something I plan to jig for the V2 boards anyway.  The only thing that is NOT resilient is the ability to power up if the radio is drawing a lot of power on power up.

Tom, just got the first signs of life of my bootloader with coin cell support today.

With a fresh battery I can update an application very quickly, no external power source required. In high throughput mode I transfer data in chunks of 1kb which at 200kbit take around 50ms. With a fresh battery I can easily install an app this way, only waiting for the battery to recover between chunks (maybe 1s between chunks). Probably under 20s for a full application, but the battery does suffer.

With an older battery I switch to simple mode which is strictly request / response with 3 requests required per 128 byte page. I recover battery after each response which results in several minutes for a full app.

I think the radio might not be a problem if the battery isn't nearly dead. I successfully booted (and installed) from a 2.98V coin cell today (don't have anything worse but not yet dead lying around).

TomWS

  • Hero Member
  • *****
  • Posts: 1925
Re: Efficient use of coin cells
« Reply #26 on: August 13, 2015, 06:34:42 PM »
Quote
I'll just have to program them while it's powered with an external power source, something I plan to jig for the V2 boards anyway.  The only thing that is NOT resilient is the ability to power up if the radio is drawing a lot of power on power up.

Tom, just got the first signs of life of my bootloader with coin cell support today.

With a fresh battery I can update an application very quickly, no external power source required. In high throughput mode I transfer data in chunks of 1kb which at 200kbit take around 50ms. With a fresh battery I can easily install an app this way, only waiting for the battery to recover between chunks (maybe 1s between chunks). Probably under 20s for a full application, but the battery does suffer.
This is excellent, but it would be nice to quantify how much the battery does suffer.  Is the node RX only (during programming) or is there a TX part of the protocol?  If the default startup simply quiesces everything almost immediately, ie, gets the node in low power listen mode ASAP (as part of boot process), then this could be useable, without any elaborate sequencing scheme.
Quote
With an older battery I switch to simple mode which is strictly request / response with 3 requests required per 128 byte page. I recover battery after each response which results in several minutes for a full app.
Still, this is usable and on par with a request/response cycle using a conservative scheme, 'standard' data rates, and flash.  That this can be done without flash is excellent!
Quote

I think the radio might not be a problem if the battery isn't nearly dead. I successfully booted (and installed) from a 2.98V coin cell today (don't have anything worse but not yet dead lying around).
Stick around, you'll soon have batteries running between 2.800-2.700...

You're still using the 470uF you mentioned earlier?

Great work!

Tom

joelucid

  • Hero Member
  • *****
  • Posts: 867
Re: Efficient use of coin cells
« Reply #27 on: August 14, 2015, 03:01:00 AM »
This is excellent, but it would be nice to quantify how much the battery does suffer.  Is the node RX only (during programming) or is there a TX part of the protocol?  If the default startup simply quiesces everything almost immediately, ie, gets the node in low power listen mode ASAP (as part of boot process), then this could be useable, without any elaborate sequencing scheme.

For the burst protocol it's request / response with every request selecting up to 1024 bytes of data to be sent back from the server. The response is sent in a continuous burst similar to the Listen code. The key to the efficiency of the protocol is that only bust packages that weren't received are requested again, eliminating retransmit latency.

I set the fuses for the 8mhz internal clock with the 8x clock divider set, so I start up at 1Mhz. First thing I do is to put the radio to sleep. Then I wait for the battery to recover. Then I select 1Mhz and send a boot request to the server asking if a new version is available. Based on the voltage drop during that send I select the simple or the burst scheme for the install.

If a new version is available I pull it from the server request by request, pausing after each request until the battery recharges the cap and recovers (effectively I measure vcc, go to sleep for 250ms, measure vcc again and continue this loop until vcc no longer improves). I flash pages as they arrive.

I don't yet have detailed data on the battery impact. Remember this just started to work yesterday - still lots to sort out.
« Last Edit: August 14, 2015, 03:08:33 AM by joelucid »

TomWS

  • Hero Member
  • *****
  • Posts: 1925
Re: Efficient use of coin cells
« Reply #28 on: August 14, 2015, 07:35:00 AM »
I don't yet have detailed data on the battery impact. Remember this just started to work yesterday - still lots to sort out.
I certainly wasn't complaining about the lack of battery impact data, especially at this stage!  My main point was to try to figure out HOW or WHAT we even gather data pertinent to determine impact!   I'm not sure what would be important or what to instrument...

Thanks for the info, it sounds like you've got a lot covered already. 

Tom

joelucid

  • Hero Member
  • *****
  • Posts: 867
Re: Efficient use of coin cells
« Reply #29 on: August 14, 2015, 01:38:34 PM »
I certainly wasn't complaining about the lack of battery impact data, especially at this stage!  My main point was to try to figure out HOW or WHAT we even gather data pertinent to determine impact!   I'm not sure what would be important or what to instrument...

That's an excellent point. I don't even know where to start either. How do we measure without starting from a fresh cell for each trial? It would help if the state of a coin cell were completely defined by its current voltage under a given load but I doubt even that is true. If it were we could measure the discharge curve of one brand and then test how far different load structures bring us down the curve.

This feels strangely attractive - probably first order of business is NOT to get drawn into extended battery studies. I think my criterion will be that I expect no load voltage to return to its level before install some time after install. An install should not cost more that 1/100th volt. That probably won't work for a completely fresh battery - but it should for one in the 3v area.

TomWS

  • Hero Member
  • *****
  • Posts: 1925
Re: Efficient use of coin cells
« Reply #30 on: August 14, 2015, 03:17:42 PM »
I certainly wasn't complaining about the lack of battery impact data, especially at this stage!  My main point was to try to figure out HOW or WHAT we even gather data pertinent to determine impact!   I'm not sure what would be important or what to instrument...

That's an excellent point. I don't even know where to start either. How do we measure without starting from a fresh cell for each trial? It would help if the state of a coin cell were completely defined by its current voltage under a given load but I doubt even that is true. If it were we could measure the discharge curve of one brand and then test how far different load structures bring us down the curve.

This feels strangely attractive - probably first order of business is NOT to get drawn into extended battery studies. I think my criterion will be that I expect no load voltage to return to its level before install some time after install. An install should not cost more that 1/100th volt. That probably won't work for a completely fresh battery - but it should for one in the 3v area.
From what I've seen in practice and from the data in the article you referenced, under no load even a practically dead battery will approach 3.0V.  I think the battery needs to be measured under a consistent load to monitor its health.  The load also needs to be present long enough to get the internal chemistry 'flowing' (might not be accurate description, but, I think, 'useful'). 

I'd entertain running a series of batteries, maybe from a few mfrs, with pulsed loads and measuring the voltage under load.  If done correctly, (at least two different pulse models), we should have enough data to extrapolate a useable model.  It would have to be aggressive enough to get data before WE are on Version 127 of our code  ;) but not so aggressive that we overstress the battery.  I'm thinking of maybe a Mega with 8 batteries tied to analog inputs and two different loads controlled by the SW.  One load to represent a 0.xxx mS x 16mA load every 3 seconds to represent listen mode and then a 45mA load for XmS every N minutes to represent a data transmission.

Ideas here would be useful...

Tom

joelucid

  • Hero Member
  • *****
  • Posts: 867
Re: Efficient use of coin cells
« Reply #31 on: August 15, 2015, 09:47:24 AM »
Quote
I'd entertain running a series of batteries, maybe from a few mfrs, with pulsed loads and measuring the voltage under load

Ha! Luckily someone has already done this - check this out. A fascinating read:

https://www.sics.se/~lmfeeney/publications/Files/wons14feeney.pdf

joelucid

  • Hero Member
  • *****
  • Posts: 867
Re: Efficient use of coin cells
« Reply #32 on: August 15, 2015, 10:37:58 AM »
One of the biggest still unanswered practical questions I have after reading these two papers is how load profile switching affects capacity. There is a paragraph in the first paper that suggests that as I switch from discharge curve a to b after using capacity c I should simply expect to move down curve b from the voltage implied by c. Meaning if I go to 0.3mA I will still reap specified capacity even after initially abusing the cell. That would be great since I could switch from burst downloads to simple downloads if the battery is old without any downside.

That could be easily tested and if true would drastically change the concept I had of a coin cell.

TomWS

  • Hero Member
  • *****
  • Posts: 1925
Re: Efficient use of coin cells
« Reply #33 on: August 15, 2015, 04:06:02 PM »
Joe, VERY interesting article! Thanks!

One of the key observations that I got from this last paper is that, for a given average current (ie, pulse current x duty cycle), you're able to draw MORE capacity from the coin cell with the higher pulse current (lower duty cycle).  This is very good news from an operating perspective.  The problem, as you say, is how to correlate this to your OTA programming model.  Clearly the battery can handle the high current for SOME duration as long as you have a sufficiently long recovery time. 

As you've pointed out, how long the battery can sustain the high current can be first order observed by measuring the VBat after each high current pulse (AKA downloaded packet) and deciding how close to the cutoff voltage you dare go before resting.  Since presumably you need a response to stop the flow, you need enough remaining voltage to make that transmission (unless you need a response to send the next block - but I suspect that uses more current in burst download mode). 

The next important metric would be how long does it take to recover enough to do another burst.  This might be the tricky part as you would need to wake up and do a VBat sample to see how much it has recovered.  The good news is that you'll never 'accidentally' measure the no load voltage - by virtue of the fact that you'll draw a few mA just to take the reading, so this should show you how much the battery has recovered and, with some amount of experimentation, allow you to project how long before you can check again... a simple heuristic should be able to converge on an adequate recovery time with just a few samples.

Unfortunately, it doesn't take long for the battery voltage to sink down to the low 2.xxx volts so it would be interesting to see if you could do more than 4 1024 byte blocks without resting.  However, I wouldn't think you'd need to go to any extremes WRT resting.  As long as you can recover enough to get the next 4K block to the device, once it's fully loaded, the device will be able to rest and recover most of its lost voltage, apparently without losing very much capacity.

Even if OTA did adversely affect your overall battery life, being able to do four OTA updates, for example, and still get several months of life it would be a great solution.

Tom

joelucid

  • Hero Member
  • *****
  • Posts: 867
Re: Efficient use of coin cells
« Reply #34 on: August 16, 2015, 12:57:43 PM »
Ironically the practical implication of the paper is that you don't need a cap at all to pull down (more than) specified capacity under a pulsed load with low duty cycle. Which is great - simpler circuit. Also I'm going to take the opposite position of my earlier assumption: the over-proportional voltage decrease under larger load is fully reversible and so as you imply in your message all you need to do in software is prevent voltage temporarily breaking below minimum operating voltage.

In other words we can have all the luxuries of better batteries (like burst downloads etc) until we hit the bottom. Then we just wait until voltage recovers. Happiness!
« Last Edit: August 16, 2015, 03:00:16 PM by joelucid »

TomWS

  • Hero Member
  • *****
  • Posts: 1925
Re: Efficient use of coin cells
« Reply #35 on: August 16, 2015, 02:26:12 PM »
In other words we can have all the luxuries of better batteries (like burst downloads etc) until we hit the bottom. Then we just wait until voltage recovers. Happiness!
Unless you go too far and you can't programmatically rest.  Then you're toast.  I do agree that it seems as if the battery will support this usage model and we're on the right track to something very useful (and tiny!).

On a somewhat related note, I have had my TTH Mote stop responding to wake up bursts on two occasions in the last week.  I normally generate the wake up burst every ten minutes from my gateway but I can also generate a wake up burst from my Snooper.  I tried this as well, but this also did not wake up the mote.  I'll have to put a scope on it to see if its still going through listening cycles when it's not responding, but wondering if you've seen this at all.

This is potentially the downside of ONLY listen mode - no way to wake up a Mote refusing to listen.

Tom

joelucid

  • Hero Member
  • *****
  • Posts: 867
Re: Efficient use of coin cells
« Reply #36 on: August 17, 2015, 09:47:42 AM »
Quote
So if a wake up burst hasn't happened within the counting window, you treat it as a 'wake up' anyway, yes?

Yes, this is because I'm not using the burst wake-ups instead of the WDT to save power yet in production. I've only used them to interact with my nodes more quickly so far. Of course I do hope to do this when my coin cell motes are ready. Did you find out if the listen spikes were still occurring?

Quote
also change my BOD bits to 1.8V BOD, rather than disabled

I would definitely use this to prevent the mote from hanging if voltage goes too low. You need a clean reset instead of a rogue mote!

Quote
With my version 2 circuit I can keep the radio completely powered off if I find that the voltage is too low on startup to risk a transmission.  I can then go into an extended recovery period until there seems to be enough power to, at least, report the low battery condition...

You could do this without the switch for transmissions of course. They key benefit of your circuit is that you can start the system if the coin cell is too weak to get over the 2.5mA or so bump the rfm69hw requires to start. Of course since we're moving towards no bulk caps on board it's questionable whether any hope of transmission with such a cell is reasonable - but maybe it is with a temporarily impaired battery that just needs some time out.

BTW, I read a couple of other papers on coin cells and I haven't found a single one by other authors that found high current, low duty cycle discharge capacity to be superior to continuous discharge using the same average current. I have found others that confirm that higher current gives better results than lower (e.g. http://scholarsarchive.byu.edu/cgi/viewcontent.cgi?article=4587&context=etd) - but at best approaching continuous discharge capacity.

So I think it's likely that this result is bogus. I'm particularly skeptical after finding the following comment in an earlier paper by the same authors (https://www.sics.se/~lmfeeney/publications/Files/wwic13_rohner.pdf):

Quote
Experimental data from our battery testbed. The mA-h that can be taken from
the battery (at a given voltage) depends on the load pattern. CI9 has a slightly shorter
load duration (mean current 262ľA) due to a limitation in the testbed
.

For the other loads they use 300uA - so this is more than 10% less! And it's the only load that managed to be better than continuous discharge in the other paper.

There is another caveat: they don't use constant current, but just several different resistors which at 3V result in the stated nominal currents. This means that as the battery gets old and voltage breaks down they are really kind to it by drawing lower currents. That's clearly different from what the rfm69w will do.

Still I think the conclusion that with super low duty cycles a large bulk cap makes little sense likely holds true.

TomWS

  • Hero Member
  • *****
  • Posts: 1925
Re: Efficient use of coin cells
« Reply #37 on: August 17, 2015, 10:20:11 AM »
Did you find out if the listen spikes were still occurring?
No, I haven't had time to set this up.  I may  have to scurry to try to measure this if the mote hangs again, however.

I've modified my code (but haven't loaded yet) to do the counting listen cycles and added a battery check on start up with the processor still at 1MHz clock.  I stay in this sleep/check loop until the battery level gets above the threshold hopefully giving me enough 'juice' to report the low battery condition.  I'm starting with a low battery threshold of 2.700V since this seems to be a reasonable 'knee' for a lightly loaded weak battery and will refine it as time goes on.

Quote
There is another caveat: they don't use constant current, but just several different resistors which at 3V result in the stated nominal currents. This means that as the battery gets old and voltage breaks down they are really kind to it by drawing lower currents. That's clearly different from what the rfm69w will do.
They do state that they use the Vmin as the 'voltage' in their plots.  However, they do treat their load as a constant current, rather than resistance so their results will be affected by this. Even so, I do suspect that very short duty cycles or, more precisely, very long recovery times, do allow the battery chemistry to recover capacity that would not be available with a constant drain so I'm not prepared to dismiss these findings yet.
Quote
Still I think the conclusion that with super low duty cycles a large bulk cap makes little sense likely holds true.
Totally agree with this!  So I'm not tossing my V1 PCBs yet!   :D

Tom

joelucid

  • Hero Member
  • *****
  • Posts: 867
Re: Efficient use of coin cells
« Reply #38 on: August 18, 2015, 02:40:09 AM »
I don't think soldering to the battery case would be healthy for the battery.  In my case the battery holder only adds Z dimension (approximately 4-5mm), it takes no additional X/Y space as it straddles the radio module.

I've got to say I'm starting to like this cr2450 package: http://www.digikey.com/product-detail/en/CR-2450%2FH1AN/P662-ND/2404067

It effectively takes as much space and costs hardly more than the cr2032 with a battery holder but you can solder them directly to the board. And with 620mAh you probably don't need to change them in this life either. Lastly the larger diameter should allow higher pulse currents.

Somehow I really don't like the idea of putting a battery holder that will only be used once on a space constrained board.

TomWS

  • Hero Member
  • *****
  • Posts: 1925
Re: Efficient use of coin cells
« Reply #39 on: August 18, 2015, 09:13:23 AM »
I don't think soldering to the battery case would be healthy for the battery.  In my case the battery holder only adds Z dimension (approximately 4-5mm), it takes no additional X/Y space as it straddles the radio module.

I've got to say I'm starting to like this cr2450 package: http://www.digikey.com/product-detail/en/CR-2450%2FH1AN/P662-ND/2404067

It effectively takes as much space and costs hardly more than the cr2032 with a battery holder but you can solder them directly to the board. And with 620mAh you probably don't need to change them in this life either. Lastly the larger diameter should allow higher pulse currents.

Somehow I really don't like the idea of putting a battery holder that will only be used once on a space constrained board.
Yeah, after I posted that message I remembered seeing CR batteries with tabs and found that the Renata 2450 (CR2450NFH-LF) would actually fit into my battery holder footprint because it has pins instead of the wider tabs that Panasonic has with the same 20mm spacing of the holder.  Renata also has a CR-2477 (960mAH) if you really want your mote to outlive you  ;)
Renata is also closer to your home  :)

The only struggle I have using the holder is the added Z dimension.  In my case, since it's straddling other parts, the holder also serves as a mechanical support and insulator.  It doesn't consume any X or Y space other than its pads, which I would need for these tabbed versions anyway.

Tom

WhiteHare

  • Hero Member
  • *****
  • Posts: 1296
  • Country: us
Re: Efficient use of coin cells
« Reply #40 on: August 27, 2015, 10:05:32 AM »
Amazingly there is no leakage current to speak of at the cap after some charging time.


By leakage current are you referring to self discharge? 

I recently purchased a 310 Farad Maxwell capacitor, the size of a D-Cell and obviously too big for your current project,  just to get a feel for it for some possible moteino supervised solar applications.  I did some quick measurements a few months ago, and although it obviously can hold a good charge, it also loses a lot of it through a very noticeable self discharge rate.  So, if you've found a class of capacitors which don't suffer from that, I'd be very interested to know what type they are.
« Last Edit: August 27, 2015, 10:07:04 AM by WhiteHare »

joelucid

  • Hero Member
  • *****
  • Posts: 867
Re: Efficient use of coin cells
« Reply #41 on: August 27, 2015, 10:58:14 AM »
I think http://www.reichelt.de/SPK-100-000-10/3/index.html?&ACTION=3&LA=446&ARTICLE=43281&artnr=SPK+100.000%C2%B5-10&SEARCH=superkondensator was the one I tested most. It's 0.1F.

I pre-charged it and then hooked it up with a Moteino (without voltage regulator) and a CR2032. I measured the current from the coin cell to the circuit. Initially the current was pretty high - maybe 20-30uA. But after maybe half an hour it was down to about what the Moteino needs without the supercap.

Supercaps are tricky. There are large charge rebalancing effects that look like leakage current. So you want to be sure to wait pretty long if you measure. That also goes for voltage measurements after load. Voltage will drop fairly quickly but recover with if the load is taken off as charges within the cap rebalance.

All that said the current theory is that caps are not needed for coin cell motes: You only need to write your code such that a weak coin cell has time to recover between load pulses. The ~10ms pulses that we typically need from a battery should be possible without caps until very close to EOL of the battery.