On the side comment I haven’t seen a “gas” car battery with such protection and one such car battery did explode on me some twenty years ago. Fortunately, without causing permanent damage to me at that time. /* I know, car as a whole is not an embedded system. */

From the cost perspective, embedding more intelligence in the battery pack moves a cost factor out of the BOM control of the embedded system developer, so that all systems would need to pay, or there would be an explosion of battery types, each with there own level of battery control/protection… As I stated previously, it makes a lot of sense to have protection included in the battery/cell against catastrophic failure modes, but I believe that it makes more sense to have ‘gas gauges’ and lifetime estimates done in higher-level software and hardware… The world is open to many opinions

It was your name attached to this topic that triggered my attention. And I couldn’t resist. I have so many stories related to batteries. My interest grew significantly after I purchased a hybrid car in 2007. And, yes, there is a story attached to this car and… some frustrations. As I said, I will return with details because my story has something to do (indirectly) with our own jobs. But I need more time to order the facts and put it in the context.

I agree that batteries are “smarter” every day. There is a danger here as well: being smart means being more complex and being complex means being more exposed to “soft”(ware) failures. Are we relying too much on the intelligence we embed into all these devices? Is this slowing the penetration of other technologies that may not require sophistication to solve the same problem?

When I asked this question I had in mind MRAM vs flash memory: despite of all its qualities, MRAM has not been widely adopted by the market but companies rather spend a lot of resources and effort on error correction and wear leveling algorithms (see the latest news regarding Anobit that developed very complex algorithms that would allow unreliable MLC NAND to be used, well… more reliably!!!). Aren’t we in the same situation with Lion batteries? Maybe we just lost the ability to see (and to search for) more fundamentally simpler solutions…

At 3 am in the morning I’m becoming too emotional

It’s a nice point about a system being so tightly-designed around a particular energy cureve that it can’t handle an ‘unforeseen’ battery chemistry (or quality) being used, especially if the batteries are replaceable, standard-sized cells like AA/AAA, et al … I would have hoped that under-voltage detect would be used, but seems that someone forgot that aspect in your radio; maybe saved 3 cents

In cell phones, the volumes are so high, the cells are built-to-fit, and every milli-Joule needs to be dragged out, plus safety concerns, plus user expectation, that we really design a lot of the circuitry to maximise energy use in just that narrow band of specifications… and, now, with digital interfacing being built into the cells, it’s possible to get quite intimate knowledge of a cell that is plugged in. That, again, goes to the earlier comments on putting protection and monitoring at the ‘right’ layer of the hardware/software stack.

http://batteryuniversity.com/

The guy who keeps this site started his own company – Cadex- years ago. The company produces battery analyzers, chargers and testers.

I would also recommend “Linden’s Handbook of Batteries” – the 4th edition was released in 2010 (see http://www.amazon.com/Lindens-Handbook-Batteries-Thomas-Reddy/dp/007162421X ).

I hope it may help someone.

The rapid discharge phenomenon is rather visible in the case of NiMH or NiCad chemistry. The following story is just an example — this is when I became aware of it.

I have a relatively old and cheap digital radio (~15 years old design) that was probably designed for alkaline batteries; to change the batteries you have to turn off the radio (digital on/off that put the electronics in standby) and rely on an internal capacitor capable to maintain the settings for about 1…2 minutes (depending on the battery voltage at the replacement time).

Because alkaline batteries have lower capacity than modern NiMH rechargeables, I switched to NiMH but with a “side effect”. When the battery is discharged enough to make the radio barely usable on AM and unusable on FM, I cannot turn it off (put it in standby) anymore and I cannot change the batteries without losing all the settings because the internal capacitor gets drained quickly by the still active electronics.

It is obvious that the designer never had in mind such a sudden voltage drop (usually from 1.2V to 0.9V in 10…15 seconds) and the controller that handles the user keys (including the on/off button) does not respond to any user actions anymore. So, I end up reprogramming the settings after changing the batteries (i.e. setting the clock/alarm and 15 stations).

So, as designers we need to anticipate far more than our educated minds tell us in the first place. Users are always unpredictable and very inventive. Conditions may vary a lot as well in patterns that may never be anticipated enough (see the Chevy Volt case).

Like most of the current software that we have to deal with every day (see patches, updates, upgrades, etc) – perfection is an almost unachievable goal. Designing embedded systems, especially those used in safety critical applications, becomes a daunting task that very few are willing to appreciate. It is probably one of the most difficult jobs in the high-tech industry – and I’m not saying this because I am an Embedded Engineer.

The battery management problem is just another issue that we have to deal with. A really challenging one…

Many loads that are in use today are likely to be constant-power; even LED flashlights, typically, have a DC/DC converter to deliver constant power to the LED over the discharge voltage of the cell/battery pack.

In my experience the big problem is that even f you provide a good quality battery holder and electronics that works correctly down to 0.8V per cell the end user then defeats all your efforts by using rubbish batteries from some no-name source. These are not backed up by any specification and may very well fail as Franz describes.