From: who where on
On Mon, 05 Oct 2009 09:09:13 -0700, Jeff Liebermann <jeffl(a)cruzio.com>
wrote:

>On Mon, 05 Oct 2009 16:45:09 +0800, who where <noone(a)home.net> wrote:
>
>>It was a jumper on pin headers, extending it to the front panel would
>>be a snap.
>
>I was thinking more of something with a built in ethernet or USB port.
>All the charge parameters can be setup on a web page. Once one has a
>suitable processor, adding features such as battery history, battery
>test, counterfeit detection, run time calculation, and fire detection
>are mostly software. I'm half way inspired to design and build one
>for myself but suspect that I can't make much money on it at consumer
>price levels.
>
>>The controller I used was the MAX1737.
><http://www.maxim-ic.com/quick_view2.cfm/qv_pk/2217>
>>You get a certain amount of
>>flexibility designing around it, and we (the client and I) preferred
>>their regime to the others we considered.
>
>Ok, but that's pure analog. Analog is not a problem but it does limit
>what weird things can be done with a Li-Ion charger.

The brief was "KISS". The end-users were real industrial users, and
quite disinclined to fiddle of even treat the pack and charger as
other than a black box.

>I was thinking
>more in the way of a digital (i.e. PIC controller) design, such as:
><http://www.microchip.com/stellent/idcplg?IdcService=SS_GET_PAGE&nodeId=1406&dDocName=en024090>
><http://ww1.microchip.com/downloads/en/DeviceDoc/51515a.pdf>
>and increasing the output current capabilities to run larger battery
>packs. For example, when the battery pack is in the charger and
>allegedly fully charged, it would be fairly easy to apply a load and
>discharge it for perhaps a minute or more. The asymptote of the
>terminal voltage curve can be extrapolated to produce an estimated
>runtime. Some of the remote battery management systems already do
>this quite accurately. One could also include some RAM and add a data
>logger and coulomb counter (amp-seconds). The area under the current
>curve is the charging and discharging energy. This would give a good
>clue as the battery packs comparative quality (something that I
>suspect the manufacturers would not be interested in supplying).
>
>>The selection was vendor-made based on the end user's stated role, and
>>was selected in_conjunction_with pack sizing. Any time the role
>>looked like prolonged high SOC and temperatures above 30C, he'd go
>>with 4v10 and the pack size would then be determined. He didn't want
>>premature failures, unlike laptop makers who don't give a rats.
>
>Good plan. However, there's always going to be the customer that
>plugs in a new battery pack, runs it as long as possible, and then
>proclaims that they're not getting the specified run time.

If they weren't getting the specified run time, it would be the result
of improper sizing (vendor fault or user-supplied misinformation), or
faulty pack or charger (vendor responsibility). Easily resolved.

Recall that the pack size was chosen AFTER the CV limit was
determined.

>>Maybe I missed your objective. I understood it to be determining when
>>to stop discharge (in the laptop) to achieve a chosen SOC. Any time
>>you are playing with discharge the laptop activity is fundamental, but
>>for a known target SOC it isn't hard to invoke a known task (eg screen
>>saver) and do the linear maths.
>
>It was to see how close to a full charge was being used and where the
>battery droop detection was set. That's measured in coulombs
>(watt-seconds) or run time (hours). I have a Kill-a-Watt meter that
>measures power consumption from the 117VAC line. I run the laptop
>only from the charger, with the battery removed, for about 30 minutes
>(the limit of my attention span), doing what I consider to a typical
>applications mix. The Kill-a-Watt meter records the watt-seconds
>(actually watt-hrs) used. It also compensates for power factor. I
>throw in the switcher efficiency of about 85-90%:
><http://www.energystar.gov/index.cfm?c=ext_power_supplies.power_supplies_consumers>
>and calculate the energy consumption per hour of use. I use that as
>the average load for run time calculations.

The problem with those meters is that - being cheap/chinese - they
tend to poorly handle the line current "blips" into a rectifier. And
even if they returned true RMS, that doesn't itself reflect the actual
power drawn in those circuits.
From: who where on
On Mon, 05 Oct 2009 09:35:49 -0700, Jeff Liebermann <jeffl(a)cruzio.com>
wrote:

>On Mon, 05 Oct 2009 16:57:03 +0800, who where <noone(a)home.net> wrote:
>
>>>Well yes.... any storage device, with a low internal series resistance
>>>will exhibit a fairly flat discharge curve followed by an abrupt
>>>droop. See the first graph at:
>>><http://www.mpoweruk.com/performance.htm>
>>>The problem is that the sharp knee is somewhere between 5% and as
>>>little as 1% of capacity.
>>
>>It wasn't a sharp drop that we saw. More of a curve than a cliff.
>
>Sorry. I shouldn't have said "abrupt". It does tend to dribble off
>with a rather soft knee. Also, if you have several mixed cells in
>series, of different ages, the knee will appear at different points in
>the discharge curve for each cell. The knee will also be less
>defined. (A good reason not to mix different age cells).

All the more reason to use a pack protection module that monitors (and
responds to) cell voltage differences.

>>>To prevent running the battery into the
>>>ground (and possibly reverse polarizing some of the cells when
>>>connected in series), the dropout point is as close to the beginning
>>>of the droop as possible. That's fine for a new battery, but as the
>>>battery ages, the same threshold slowly moves up the charge curve as
>>>the terminal voltage decreases. I don't think any of the SOC chip
>>>vendors compensate for this.
>>
>>I'm not aware of any that do.
>
>AN AGING MODEL FOR LITHIUM-ION CELLS
><http://etd.ohiolink.edu/send-pdf.cgi/Hartmann%20Richard%20Lee%20II.pdf?acc_num=akron1226887071>
>Warning: 278 page of a grad student's dissertation.
>Skipping to Chapter VI - Conclusions, where it says:
> A direct correlation was found between the cell capacity and
> the open-circuit voltage of a fully discharged cell. Cell
> resistance increased at a linear rate throughout the life
> of the cells.

Without reading his/her dissertation, I'm not sure what (s)he's
measuring. What does (s)he define as a fully discharged cell, and how
does (s)he achieve that state?

>>But with the (IIRC) Mitsumi chips we
>>used, there was less need than with say nickel chemistries. The
>>module monitored cell voltage differences, and would prevent operation
>>if the differences exceeded a preset threshold value. With EOD set at
>>3v0 (average cell), there is no way any cell would get near to 2v5.
>
>The circuit doesn't monitor individual cells.

The modules we used certainly did. There was a connection to each
series connection node. (And in assembly the connections had to be
made in the correct order.)

> I would think that one
>cell with a bad case of premature aging might cause problems.

That is exactly what the module preempted.

>I'm
>beginning to think that I'm worrying over a non-problem. Never mind.

From: Jeff Liebermann on
On Tue, 06 Oct 2009 11:33:22 +0800, who where <noone(a)home.net> wrote:

>>AN AGING MODEL FOR LITHIUM-ION CELLS
>><http://etd.ohiolink.edu/send-pdf.cgi/Hartmann%20Richard%20Lee%20II.pdf?acc_num=akron1226887071>
>>Warning: 278 page of a grad student's dissertation.
>>Skipping to Chapter VI - Conclusions, where it says:
>> A direct correlation was found between the cell capacity and
>> the open-circuit voltage of a fully discharged cell. Cell
>> resistance increased at a linear rate throughout the life
>> of the cells.
>
>Without reading his/her dissertation, I'm not sure what (s)he's
>measuring. What does (s)he define as a fully discharged cell, and how
>does (s)he achieve that state?

See Pg 24 (section 2.2.2). He lists 3 methods along with their
limitations. I think (not sure) he's using coulomb counting
(amp-hrs). Section 2.2.3 follows with capacity measurement, which is
necessary to calculate the SOC. There's too much to quote. However,
you wanted the discharge point, and that's not covered directly. He
hints at:
For lead acid and lithium-ion batteries, the relationship
between the stabilized open circuit voltage, Eocs, and the
SOC is approximately linear (Wang & Stuart, 2002).
which implies that he uses 100% SOC as one point and extrapolates a
linear plot to zero SOC somewhere on the knee of the curve. However,
he also notes that it's temperature dependent, has hysteresis, and
requires substantial time to stabilize the terminal voltage. Unless I
missed something, he doesn't really specify how to measure the knee.

I won't pretend to understand all of it, especially since I'm buried
in work tonight and am having problems with (paying) distractions.
Maybe tomorrow.

>>The circuit doesn't monitor individual cells.
>
>The modules we used certainly did. There was a connection to each
>series connection node. (And in assembly the connections had to be
>made in the correct order.)

OK, I'm impressed(1). That's the way battery packs should be built
and monitored. However, why stop at monitoring individual cells? I
prototyped NiCad and NiMH battery packs where each cell was also
charged individually. It's (fairly) well known that you can charge
these cells at almost any rate, as long as they're under 100% SOC. Go
over even slightly, and the cell gets very hot, very quickly. I've
built simulated chargers to do this and was able to charge NiCads
successfully at up to 20C (20 times rated capacity) to about 95% SOC.
Incidentally, the failures were rather impressive, including 2 small
fires, which might explain why such fast charging is not commercially
acceptable. I'm tempted to try the same tests with Li-Ion, but have
not been sufficiently inspired or bribed to do so.

(1) Note: I'm not easily impressed.

--
# Jeff Liebermann 150 Felker St #D Santa Cruz CA 95060
# 831-336-2558
# http://802.11junk.com jeffl(a)cruzio.com
# http://www.LearnByDestroying.com AE6KS
From: who where on
On Mon, 05 Oct 2009 22:53:17 -0700, Jeff Liebermann <jeffl(a)cruzio.com>
wrote:

>On Tue, 06 Oct 2009 11:26:50 +0800, who where <noone(a)home.net> wrote:
>
>>The brief was "KISS".
>
>KISS is often a euphemism for "cheap".
>
>>The end-users were real industrial users, and
>>quite disinclined to fiddle of even treat the pack and charger as
>>other than a black box.
>
>True. There are probably some safety issues involved. It would not
>do to have the customer twiddle the charging characteristics and
>potentially turn the battery pack into a incendiary or explosive
>device.
>
>>If they weren't getting the specified run time, it would be the result
>>of improper sizing (vendor fault or user-supplied misinformation), or
>>faulty pack or charger (vendor responsibility). Easily resolved.
>
>Nope. There's also the possibility of creative testing. The
>applications mix used for testing battery life by MobileMark 2007:
><http://www.bapco.com/products/mobilemark2007/index.php>
>has a huge effect on measured battery life. However, there's nothing
>standard about the selection of test apps, which could easily be
>tweaked by the equipment vendor. I'm starting to see this with
>Netbooks, where fairly long battery run times are predicted, but
>rarely demonstrated. I had an Acer Aspire One (9" screen) and
>currently an Asus 700. Neither has come close to the rated run time
>when I use them normally at a local coffee shop.

Remember these are industrial applications, NOT pooters.

>>Recall that the pack size was chosen AFTER the CV limit was
>>determined.
>
>Good. That covers the vendor in case anyone actually tests for the
>claimed capacity or run time.
>
>Just thinking about it, there's enough info here to build a table or
>graph of the calculated battery life versus run time terminating at
>different EOC's. As you note, the closer to depletion I run the
>battery pack, the shorter the battery life (measured in charge
>cycles).

Whoa, where did I say that? IMOE there is no discharge end impact on
cycle life.

(snip rest)
From: who where on
On Mon, 05 Oct 2009 22:31:54 -0700, Jeff Liebermann <jeffl(a)cruzio.com>
wrote:

>On Tue, 06 Oct 2009 11:33:22 +0800, who where <noone(a)home.net> wrote:
>
>>>AN AGING MODEL FOR LITHIUM-ION CELLS
>>><http://etd.ohiolink.edu/send-pdf.cgi/Hartmann%20Richard%20Lee%20II.pdf?acc_num=akron1226887071>
>>>Warning: 278 page of a grad student's dissertation.
>>>Skipping to Chapter VI - Conclusions, where it says:
>>> A direct correlation was found between the cell capacity and
>>> the open-circuit voltage of a fully discharged cell. Cell
>>> resistance increased at a linear rate throughout the life
>>> of the cells.
>>
>>Without reading his/her dissertation, I'm not sure what (s)he's
>>measuring. What does (s)he define as a fully discharged cell, and how
>>does (s)he achieve that state?
>
>See Pg 24 (section 2.2.2). He lists 3 methods along with their
>limitations. I think (not sure) he's using coulomb counting
>(amp-hrs). Section 2.2.3 follows with capacity measurement, which is
>necessary to calculate the SOC. There's too much to quote. However,
>you wanted the discharge point, and that's not covered directly. He
>hints at:
> For lead acid and lithium-ion batteries, the relationship
> between the stabilized open circuit voltage, Eocs, and the
> SOC is approximately linear (Wang & Stuart, 2002).
>which implies that he uses 100% SOC as one point and extrapolates a
>linear plot to zero SOC somewhere on the knee of the curve. However,
>he also notes that it's temperature dependent, has hysteresis, and
>requires substantial time to stabilize the terminal voltage. Unless I
>missed something, he doesn't really specify how to measure the knee.
>
>I won't pretend to understand all of it, especially since I'm buried
>in work tonight and am having problems with (paying) distractions.
>Maybe tomorrow.

I haven't really got the time to dig into the diss, but the expression
"A direct correlation was found between the cell capacity and
the open-circuit voltage of a fully discharged cell." doesn't make any
sense. If you define a fully discharged cell as one which has been
discharged to a pre-defined end-point (voltage), then all cells would
have the same EOD voltage except for rebound. Or is THAT what he is
getting at?

>>>The circuit doesn't monitor individual cells.
>>
>>The modules we used certainly did. There was a connection to each
>>series connection node. (And in assembly the connections had to be
>>made in the correct order.)
>
>OK, I'm impressed(1). That's the way battery packs should be built
>and monitored. However, why stop at monitoring individual cells?

It is more about safety than extracting maximum life/performance from
the packs. That's why these were termed "pack protection modules".
They provided:

(a) over-voltage cutoff
(b) excess charge current cutoff
(c) excess discharge current cutoff
(d) cell voltage imbalance cutoff
(e) undervoltage cutoff

clearly aimed at protecting the pack (and manufacturer) from hazardous
situations.

>I prototyped NiCad and NiMH battery packs where each cell was also
>charged individually. It's (fairly) well known that you can charge
>these cells at almost any rate, as long as they're under 100% SOC. Go
>over even slightly, and the cell gets very hot, very quickly. I've
>built simulated chargers to do this and was able to charge NiCads
>successfully at up to 20C (20 times rated capacity) to about 95% SOC.
>Incidentally, the failures were rather impressive, including 2 small
>fires, which might explain why such fast charging is not commercially
>acceptable.

Because Ni-XX chemistries are current-mode charged, and actually
over-charged, that of itself provides a measure of SOC equalisation
which really makes it unnecessary to get involved in individual cell
charging in series strings. This was disucssed in a recent thread on
equalising SOC. Current-mode charging -> series cell equalisation if
overcharged. Voltage mode (i.e. Li-XX) charging -> parallel cell
equalisation.

> I'm tempted to try the same tests with Li-Ion, but have
>not been sufficiently inspired or bribed to do so.

Probably not worth the effort *if* the replication of charging
circuits adds much complexity.

>(1) Note: I'm not easily impressed.