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

TomWS

  • Hero Member
  • *****
  • Posts: 1930
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: 868
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: 868
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: 1930
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: 1930
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: 1930
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: 868
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: 868
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: 1930
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: 1930
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: 868
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: 1930
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: 868
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: 1930
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: 868
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.