Designs for Reliable (low V) Cell Monitoring electronics

[Tiberius]

Can I ask again, what resistor precision do you need in the potential dividers?

Nick

Good question.

If we need 0.1V accuracy with 30V full scale that would be 1 part in 300 or 0.3%. Precision resistors have gotten fairly cheap these days. Especially if surface mount is used.

But the real issue is stability. We probably want to calibrate the ADC anyway. So in that case we need stability in the resistors, and calibration will compensate the values for the actual resistances.

If we want to use the differential mode of the ADCs then the resistors will have to be significantly better.

I thought we were talking about much better accuracy than 0.1 V. Also there are two resistors in a potential divider.
And if you are monitoring the top cell, you are measuring the positive and the negative voltage separately, so the errors in each of those measurements add up.

Nick

 

[texaspyro]

Can I ask again, what resistor precision do you need in the potential dividers?

You could easily use 20% resistors... if they are stable. There is a micro behind them... one can easily calibrate out the divide ratio in software.

My welder uses 1% resistors throughout (only 10K and 2K). For the CBA mode, I accumulate readings over a 1 second interval and apply a software calibration/linearization. I get readings +/- 0.001V from 1 to 20V input (and am using the 5V regulator as the ADC reference).


If you put the isolation FET between input resistor of the divider, maybe with the filter cap at that node, and the pull down you get some pretty good transient protection. I don't think the FETs add much circuitry... just a JFET on each ADC input and a gate drive signal for all of them. Testing is easy... kill gate drive, see if ADC voltage goes low. Restore gate drive, see if you get reasonable cell voltages.

One issue with unisolated cell inputs to the ADC is if you want to power switch the micro. The micro will try to power itself through the inputs. That issue got me to use the isolation FETs.

 

[Alan B]

...

One issue with unisolated cell inputs to the ADC is if you want to power switch the micro. The micro will try to power itself through the inputs. That issue got me to use the isolation FETs.

Interesting. I have not had that problem because I don't remove VCC.

In this case the ADC inputs will be 1V fed by 475K, and the micro has 5V supplied when asleep (not powered down) so not a problem.

 

[Alan B]

...

If you put the isolation FET between input resistor of the divider, maybe with the filter cap at that node, and the pull down you get some pretty good transient protection. I don't think the FETs add much circuitry... just a JFET on each ADC input and a gate drive signal for all of them. Testing is easy... kill gate drive, see if ADC voltage goes low. Restore gate drive, see if you get reasonable cell voltages.

...

Reasonable technique. Still it adds something like 8*3 parts, and many of them are semiconductors (with attendant failure modes).

 

[Alan B]

Could run this micro on 3V, don't really think it needs 5V.

 

[CamLight]

I agree.
5V uses more power and it's getting harder and harder to use. Most of the lower power parts available now are rated 3.0V or so max.

Reasonable technique. Still it adds something like 8*3 parts, and many of them are semiconductors (with attendant failure modes).

Gonna' be hard to avoid widespread use of semiconductors in a BMS though.
In the thousands of devices I've built, or I've designed and others have built, there's never been a failure (knock wood!) of a semiconductor. Or any component for that matter. Semiconductors are incredibly reliable and will last decades when spec'd properly. No need to avoid them IMHO if they provide a desired capability. Having said that, I don't recommend blanket use of as many as we can. Just that the design should be feature-driven (not component-technology driven) and then the components spec'd to deliver reliable operation over the entire anticipated range of temperature, current, voltage, duty cycle, etc., for the BMS.

Could you list the possible failure modes you're concerned about for the various BMS components? This is very important for helping to narrow down the circuit topology, component families that can be used (e.g., no electrolytic caps, just MLCC because elect. caps can fail at lower temps), etc.

I don't know though if you want to stick with your original single-micro design and just make it as reliable as possible or keep the thread open to what can make a BMS more reliable and base the design on outcome of those discussions. It's your thread, I want to try to get myself back on the track you want to keep.

 

[CamLight]

Something to consider if only creating a BMS with over- and under-voltage protection (no gas gauging, SOC display, etc.)...
A lot of compromises often need to be made when using discrete components and ADCs or the ADCs in a general-purpose micro for a BMS. The dedicated single-cell and multi-cell protector chips out there have ADC front ends created specifically for reading and acting on too low or too high cell voltages (direct 0-5V inputs, hard-wired cutoffs, low current draw, direct protection-FET control, etc.).

They can save you a lot of time when creating a BMS and can also provide a very robust secondary-protection role. Their direct-to-FET connection can disconnect the pack without the intervention of a microcontroller in just microseconds. They can be used as the primary BMS protection or as secondary protection for a dedicated BMS chip or microcontroller. And, if stacking single-cell protectors, the design is modular for any number of cells.

And some of them only draw 2uA each!

 

[Alan B]

I think post #1 has most of it. It has been updated several times to capture the essence of the thread.

We have inspected a lot of failure data and generated requirements, and then a design to meet them.

There are a lot of proposals that don't meet the requirements. There are some that dramatically exceed them.

There is a tendency to say "since it has a micro we need to add a bunch of extra features beyond the requirements".

I'm using the micro here to meet the requirements and make the monitor more reliable, not add unrequired features. Those is also fine, but are a different design.

I don't mind parts if it is necessary to meet requirements. Connections are generally less reliable than properly spec'd and protected quality parts.

Things like hooking up wrong, connecting in wrong order, transients on external lines from handling, connecting, etc. are a major cause of failures. And very disappointed users. Even if it is their mistake it is still unfortunate and quite avoidable with proper design.

How do you know the monitor is working? Most of them don't give you any clue. That would be useful to judge whether it is working. With a micro we can do a lot of self tests and provide a visual indication that all is OK. Verification is part of reliable operations.

I'm not sure how much farther this particular design can go without building it. Anyone interested in laying out a PC board? If that is done, should it be surface mount, or through hole? If a pcb was made, how many folks would want some??

Reviewing the custom battery chips is interesting. Though they are expensive and not very available. They have a lot of nice features that we decided were not desirable on-board. One goal was to place minimum electronics on-board. Things like balancing circuits have failure modes we don't want on-board.

So it seems we are coming to two points of view. One is that the TC54 is good enough, the other is that we need features far beyond these basic requirements.

 

[Alan B]

Here is an interesting voltage monitor chip from Maxim - MAX11080.

http://www.maxim-ic.com/datasheet/index.mvp/id/5524

Low voltage resolution 100mV.

High voltage resolution 25mV.

Sounds familiar. Not too different from my AVR design.

However it will handle 12 cells. It costs about $6 in 25 qty. 38 pin surface mount.

It provides a linear regulator to power other stuff.

Current consumption is low. 35uA. on 36V

The alarm output has a heartbeat.

It requires a resistor and capacitor per cell.

It can be programmed for different voltages with jumpers.

It comes close to meeting requirements stated in post #1. It requires almost as many external parts (but not quite) as the reference micro design in this thread.

 

[CamLight]

A verrrry nice chip.
One advantage is that is significantly reduces the amount of code that needs to be written, a major point of failure.

I can help with the PCB layout and Gerber file creation. I use Eagle though and the schematic (with the components selected for the desired PCB footprint) would have to be Eagle too.

[Edit] Actually, if you spec the PCB footprint you want for the components (e.g., "0.1 inch lead spacing" or "0805" for a cap, etc.), I can easily copy your schematic if you're not using Eagle (seemed like diff software it in that schematic you posted).

I recommend surface mount wherever possible to reduce size and leverage the availability of less expensive components. But, this brings up the physical side of your requirements, what type of environment you want the board to work in reliably, and who the DIY version of the board is being offered to.

Surface mount (SM)is smaller and often less expensive. A wider selection of components is often available too as thru-hole components become less and less available. But, SM parts hate board flex and the board will need to take that into account. Actually, thru-hole boards need to be protected from vibration too because part leads can fatigue and snap. "Gooping" the larger thru-hole components to the PCB can help with that though. The micro and/or voltage-protection chip might only be available in a SM-version too (well, the micro is probably available in thru-hole)?

The possible downside to SM? Soldering needs to be taken into account.
Should this board be easy to assemble by anyone with a basic soldering iron (making it larger and perhaps more expensive)? Or should it be optimized for size and cost and perhaps be a more advanced soldering project using a mix of SM and thru-hole, or even all SM?

 

[GGoodrum]

This chip has been around awhile now, and there has been a couple threads on it. Methods had issues with this part, so he went with a similar 12-channel chip from Linear Tech. He ended up building a bunch of 36-channel full BMS units for Steve/Jozzer's motorcycle project.

I have one question. Just how is this "monitor" going to protect a pack/cell from draining down to zero, if there's nobody around to hear your "chirper" alarm? In your 4th "requirement", you state that the unit should still operate if "one or two cells go to 0V", but what's the point of that? Shouldn't a goal be to keep all the cells from going to 0V? If the unit can't do anything about saving the cells from over-discharging, who cares if it can keep running? I don't know, but it sure sounds like you are creating requirements to fit the widget you want to build. :?

The really clever part of Randomly's active cutoff circuit is that the circuit will keep the load removed, all the way down to 0V. The TC54 outputs all have to be high, meaning above the cutoff, for the FET(s) to be on. As soon as any one goes below the threshold, its output goes low, which causes the FETs to be slammed off, very quickly. The only current flowing at that point is the 1uA quiescent current of the TC54. If the pack capacity was down to, say, 1Ah, at a 1uA discharge rate it will take one million hours, or 114 years, to drain 1Ah. Even with the FETs on, the max the circuit will draw is 120uA, so again, if the pack was down to 1Ah of capacity, it would still take 347 days, or about 11-1/2 months to drain it down to zero. Even then, it won't go all the way to zero, it will go down to where at least one cell hits the cutoff, and then the drain rate drops to 1uA.

-- Gary

 

[Jeremy Harris]

I don't want to pre-empt the outcome of the analysis of reliability data that Bigmoose is gathering, but would suggest that electronic component failure is a pretty rare occurrence and that the most common forms of failure will be related to mechanical factors (wires breaking, connectors not crimped correctly, shock and vibration damage etc), poor installation and LVC circuits that can drain a cell/pack if left unattended.

I know I'll probably irritate Alan by suggesting this, as he may see it as trying to deflect his thread away from his pre-ordained ucontroller solution, but a really good cell low voltage protection unit should be as simple as possible, be easy to install reliably (by someone with maybe limited knowledge of high reliability electronic systems) and be as foolproof in use as we can make it. It should tolerate being miswired, installed in a poor location etc. It should be as easy as possible to connect and use and not have the installer scratching his or her head when trying to fit it. Once fitted, it should just do the job of warning when a cell goes lower than a defined threshold, preferably with some form of cut-off option (using the ebrake signal is the obvious way to do this, it avoids any power switching).

There are already designs available that almost meet these criteria, with the exception of the major problems of installation reliability and interconnect problems and some question marks over low current draw under all conditions. In my view, users shouldn't have to deal with fragile exposed circuit boards, unreliable soldered flexible wires and dodgy connectors. If a unit was virtually sealed, with only (very well-protected) connections to the cells to be made by the user, then I believe that the vast majority of failures we see at the moment would be removed at a stroke.

The actual circuitry in the box isn't that critical, in my view. The low current draw, non-opto, circuit that Randomly came up with would do the job, although I'm sure that with some ingenuity a ucontroller solution could probably be made to do something similar. I doubt that the actual circuitry chosen would make a jot of difference to real-world reliability though (with the exception of some concerns about unqualified home-brew code having unforeseen failure modes) as that is probably dominated by the factors I mentioned above.

A variation on Vilfredo Pareto's Principle would seem to apply here; maybe 80% of the reliability problems are associated with wiring, robustness, connectors and perhaps high current draw under fault conditions. Putting effort into trying to refine the area that has the least failure modes doesn't seem to be anything other than an interesting intellectual exercise in electronic design, as it's not going to have a major impact on system reliability on its own.

As a final comment, it might be worth looking at the link that Lowracer has provided to a German website that sells LiPo protection units, just to get some ideas. This one: http://uk.babelfish.yahoo.com/translate_url?doit=done&tt=url&intl=1&fr=bf-home&trurl=http%3A%2F%2Fwww.elv.de%2FLithium-Polymer-%2528LiPo%2529-Schutzschaltung%2C-Fertiggerauml%3Bt%2Fx.aspx%2Fcid_74%2Fdetail_10%2Fdetail2_14229%2Fflv_%2Fbereich_%2Fmarke_&lp=de_en&btnTrUrl=Translate looks to be readily incorporated into a tough little system, as do some of the other units on the main page of that website, here: http://www.elv.de/Ladeger%C3%A4te/x.aspx/cid_74/detail_1/detail2_58. This isn't a recommendation by me, these units may be as flawed as any other - I'd just not seen them before.

Jeremy

 

[Alan B]

...

I have one question. Just how is this "monitor" going to protect a pack/cell from draining down to zero, if there's nobody around to hear your "chirper" alarm? In your 4th "requirement", you state that the unit should still operate if "one or two cells go to 0V", but what's the point of that? Shouldn't a goal be to keep all the cells from going to 0V? If the unit can't do anything about saving the cells from over-discharging, who cares if it can keep running? I don't know, but it sure sounds like you are creating requirements to fit the widget you want to build. :?

The really clever part of Randomly's active cutoff circuit is that the circuit will keep the load removed, all the way down to 0V. The TC54 outputs all have to be high, meaning above the cutoff, for the FET(s) to be on. As soon as any one goes below the threshold, its output goes low, which causes the FETs to be slammed off, very quickly. The only current flowing at that point is the 1uA quiescent current of the TC54. If the pack capacity was down to, say, 1Ah, at a 1uA discharge rate it will take one million hours, or 114 years, to drain 1Ah. Even with the FETs on, the max the circuit will draw is 120uA, so again, if the pack was down to 1Ah of capacity, it would still take 347 days, or about 11-1/2 months to drain it down to zero. Even then, it won't go all the way to zero, it will go down to where at least one cell hits the cutoff, and then the drain rate drops to 1uA.

-- Gary

Good observations and fair question.

I'm trying to come up with a reasonable set of requirements and a design that meets them. Questioning the requirements is fair game.

First of all, I'm wondering if folks have read the spec sheet of the TC54 and understand them. I just went and rechecked it. Years ago I used one of that type of chip on a solar charge controller, and it exploded the FET it was driving under circumstances of charging a really dead battery. According to the spec sheets, below 0.7V they are essentially unspecified. They don't work. I believe it actually oscillated on the back side of its operating curve where it is not specified which blew my FET.

So the TC54 designs with an opto fail below the LED minimum voltage, and the ones with no opto fail to work below 0.7V. They will NOT protect down to 0V. I don't see a way to fix that.

The low drain of the TC54 is really nice. But if it doesn't meet requirements, we can't use it. There is at least one other requirement that the TC54 fails to meet, that of incorrect wiring survival.

I picked a couple of cells going to 0V, but we can change that if folks think it is inadequate. My observation has been that generally one or two cells go to 0V on a pack going bad. I chose that requirement because it appeared adequate, not to drive the design. By moving one wire the micro design can accomodate the total pack voltage going down to about 4V and still have it chirp. The micro could also shut off the opto after it notices that there is no load on the pack.

One question is how long between the time the first cell falls below the low threshold and it becomes damaged? This is the "golden window". Perhaps the micro should notice the pack is not being discharged and change the threshold to a higher value like 3.0V (for LiFePO4). Go into "stored pack protection mode" instead of "on road mode". This would give a better warning window.

If chirping isn't enough then I'm not sure what we can do. Send a text message?

 

[Alan B]

A verrrry nice chip.
One advantage is that is significantly reduces the amount of code that needs to be written, a major point of failure.

I can help with the PCB layout and Gerber file creation. I use Eagle though and the schematic (with the components selected for the desired PCB footprint) would have to be Eagle too.

[Edit] Actually, if you spec the PCB footprint you want for the components (e.g., "0.1 inch lead spacing" or "0805" for a cap, etc.), I can easily copy your schematic if you're not using Eagle (seemed like diff software it in that schematic you posted).

I recommend surface mount wherever possible to reduce size and leverage the availability of less expensive components. But, this brings up the physical side of your requirements, what type of environment you want the board to work in reliably, and who the DIY version of the board is being offered to.

Surface mount (SM)is smaller and often less expensive. A wider selection of components is often available too as thru-hole components become less and less available. But, SM parts hate board flex and the board will need to take that into account. Actually, thru-hole boards need to be protected from vibration too because part leads can fatigue and snap. "Gooping" the larger thru-hole components to the PCB can help with that though. The micro and/or voltage-protection chip might only be available in a SM-version too (well, the micro is probably available in thru-hole)?

The possible downside to SM? Soldering needs to be taken into account.
Should this board be easy to assemble by anyone with a basic soldering iron (making it larger and perhaps more expensive)? Or should it be optimized for size and cost and perhaps be a more advanced soldering project using a mix of SM and thru-hole, or even all SM?

Shucks now my code is bad, before it is even written?

Heck, if we can meet requirements without writing code, great.

I have not learned Eagle due to two issues. One is the licensing not fitting my needs, the other is the time it takes. I'm using a free program but it is fixed to one pcb vendor which is not great either, but it is easy to use so I've used it. I should do something else at some point. Time.

I'm torn between through-hole and surface mount. I have a microscope and hot air rework system but not everyone does.

This particular micro is available in through hole. Most of the AVR parts are. So that is an option for this design. But it would be good in surface mount as well. If folks wanted a through hole kit then most of these fancy BMS chips would be right out. They are generally high pin count surface mount only.

It really depends on who wants to build these things. I don't have time to build more than a few. So it either needs to be a kit, or someone needs to build them for everyone.

 

[Alan B]

I don't want to pre-empt the outcome of the analysis of reliability data that Bigmoose is gathering, but would suggest that electronic component failure is a pretty rare occurrence and that the most common forms of failure will be related to mechanical factors (wires breaking, connectors not crimped correctly, shock and vibration damage etc), poor installation and LVC circuits that can drain a cell/pack if left unattended.

I know I'll probably irritate Alan by suggesting this, as he may see it as trying to deflect his thread away from his pre-ordained ucontroller solution, but a really good cell low voltage protection unit should be as simple as possible, be easy to install reliably (by someone with maybe limited knowledge of high reliability electronic systems) and be as foolproof in use as we can make it. It should tolerate being miswired, installed in a poor location etc. It should be as easy as possible to connect and use and not have the installer scratching his or her head when trying to fit it. Once fitted, it should just do the job of warning when a cell goes lower than a defined threshold, preferably with some form of cut-off option (using the ebrake signal is the obvious way to do this, it avoids any power switching).

There are already designs available that almost meet these criteria, with the exception of the major problems of installation reliability and interconnect problems and some question marks over low current draw under all conditions. In my view, users shouldn't have to deal with fragile exposed circuit boards, unreliable soldered flexible wires and dodgy connectors. If a unit was virtually sealed, with only (very well-protected) connections to the cells to be made by the user, then I believe that the vast majority of failures we see at the moment would be removed at a stroke.

The actual circuitry in the box isn't that critical, in my view. The low current draw, non-opto, circuit that Randomly came up with would do the job, although I'm sure that with some ingenuity a ucontroller solution could probably be made to do something similar. I doubt that the actual circuitry chosen would make a jot of difference to real-world reliability though (with the exception of some concerns about unqualified home-brew code having unforeseen failure modes) as that is probably dominated by the factors I mentioned above.

A variation on Vilfredo Pareto's Principle would seem to apply here; maybe 80% of the reliability problems are associated with wiring, robustness, connectors and perhaps high current draw under fault conditions. Putting effort into trying to refine the area that has the least failure modes doesn't seem to be anything other than an interesting intellectual exercise in electronic design, as it's not going to have a major impact on system reliability on its own.

...

Jeremy

It is interesting how much we agree, Jeremy.

But Randomly's circuit does not protect at all below 0.7V.

And the TC54's fail over 12V so incorrect wiring destroys them.

So we need a design that meets requirements. Micro or not. Suggest one. Disagree with requirements. Ignore the micro. It is just a chip.

I've shown how we can meet the requirements with a micro in three chips for perhaps $10 in parts, maybe less. I added a number of features like chirping to handle a number of documented cases of failures that present designs do not. The current consumption is not the best, but it would drain less than half of a 5AH pack in a year. How low does it need to be?? It would run six years on my pack.

One thing I find interesting is that some folks think purpose designed chips are better than micros in some magical way. In detail, the purpose designed chips are often very similar internally to a micro and they often contain micros. They are pre-programmed to do a specific job. They have advantages and disadvantages, but they are just another component, as are general purpose micros. You are stuck with their flexibility, and their lack of it. The general purpose micros tend to be more available for a longer period of time and more flexible. These special chips come and go quickly which is hard on a small project that has no funding to buy lots of chips. I'm not against using them, just be aware of the issues. We generally support systems for 20 years and getting parts becomes a problem at some point, generally sooner for special parts.

The Maxim chip can probably be made to meet requirements, probably works out a couple bucks more costly, requires surface mount, handles 12S and will have much lower power drain. Might be a good choice though. Wonder what Methods found to be a problem with it. I read most of his thread and don't recall the issue, but he was building to different requirements. Would have to add something to it to get chirping and process the output signal. I have mixed feelings about it. How long will it be available? Is a 38 pin part reliable in a high vibration ebike environment?

How can we have a low pack warn us when not in use? Chirping is one way. Other ideas??

Let's see alternative designs that meet requirements?

 

[fechter]

There's a nice alternative to the TC54. Seiko makes a number of them. They are available with all the functionality needed for a full system: under voltage, overvoltage and shunt activation. There's a description of one here: http://endless-sphere.com/forums/viewtopic.php?f=14&t=18803&hilit=seiko

Datasheet here:
http://datasheet.sii-ic.com/en/battery_protection/S8209A_E.pdf

These have extremely low standby current drain and have an integral transistor chain output that eliminates the need for optocouplers.

Unfortunately, they are hard to buy unless you want like 1,000 of them.

 

[Jeremy Harris]

Do we need to protect below 0.7V? Cells are, to all intents and purposes (and not withstanding a few apparent resurrections) dead long before they get that low. Miswiring could result in this condition, but would the device fail? I suspect not, which means that, as long as the rest of the circuit is robust enough to not be bothered by odd behaviour, this shouldn't matter.

I'm pretty sure the inputs of any sensing circuit can be protected via something simple, like a resistor/zener clamp, with the resistor value enough to limit the current through the zener to a safe value but not so large as to overly affect the switching threshold. A 10k series resistor would only affect the threshold of a TC54, for example, by ~10mv, yet would, in conjunction with a zener of maybe 5v1, provide pretty good protection for a hundred volts or more being accidentally applied, of either polarity. Something similar would be needed on the front end of any circuit, I suspect, to deal with the inevitable connection errors that will occur.

I think a warning when in storage is a nice to have, but probably not that big a deal. If someone has stored a discharged pack, or left one for a very long time such that it has self-discharged, then the probability is they're not around to be warned of impending failure. I don't know about other folk, but I keep battery packs outside, in an open metal shed some way from the house (my famous NiMH battery fire photos from a few years ago are on here somewhere and explain why I do this!). Although I'm sure that LiFePO4 cells are fine if kept and charged indoors, I much prefer keeping them away from the house, so probably wouldn't hear/see any warning unless I went out to check. If I'm going out to check then I could as easily do what I do now, plug a Cellog in to see how they're keeping.

If a low voltage detection system only really works when the battery pack is in use then that would meet the vast majority of user needs, I think. Although active power switching is nice, I personally think that just activating the ebrake line, or switching off the low current controller supply, is enough.

As I've said before, I'm not in any way anti micro controller use. I'm just wary, from experience of more flight safety issues related to code than I can wave a big stick at, including the well-publicised grounding (for several years) of a new Chinook fleet we bought, due to unqualified code in the FCS and cockpit displays. One rather popular (but old) fast jet here has around 4000 lines of SOUP running in the on-board weapons system computer, no-one knows where this code came from, who wrote it, what the compilers were and the source code long ago disappeared. Every time it any work is done on the system the guys just pray that the SOUP doesn't cause a critical glitch. Not a nice situation. What's worse was a new FADEC that I was looking to buy only six or seven years ago for a helicopter procurement programme I was managing. The code was written in C++, by an industry leading engine manufacturing partnership (who I won't name). When we looked at it, we discovered that the teams had used three different compilers (ostensibly to increase reliability) and each set of code had the potential to fail in different ways depending wholly on the compiled code, not the source code. As this unit was directly linked to the FCS, it caused a fair bit of angst to get sorted (the only way to fix it was to do a static code walk through on about 28,000 lines of compiled code, by hand, on bits of paper, correcting the potential glitches one by one...........).

I know we're not in that sort of territory, or after the same sort of reliability, but one can't help but have one's views coloured by personal experience.

Jeremy

 

[texaspyro]

How can we have a low pack warn us when not in use? Chirping is one way. Other ideas??

Flares!

 

[GGoodrum]

I totally agree with Jeremy. I too came from a military-based aerospace background. I started out life as a software wienie, working on 16-bit computers used as fire control computers in attack helicopters, and in anti-submarine warfare systems on helicopters. I've seen numerous cases where errant code can cause all sorts of headaches. The code, back then at least, was the least reliable part of the system, initially at least. It wasn't until we got heavy into "stress testing" the code, for every possible failure path, that things got a lot better. In any case, it definitely gives me pause to try designs with a uP in the loop, as it just adds another level of complexity to the mix. I also agree that many purpose-built chips contain micros that are "pre-programmed", but to me that is better because the thought is that somebody has already thoroughly tested the code.

I also don't buy the TC54 chip failing under 0.7V. First of all, if the cells are draining because a controller was left on for an extended period of time, for example, the cells will drain down to where at least one trips. That will cutoff the FETs, which stops the drain on the pack. What is left is the 1uA quiescent current drain of the TC54. That cell will never get too much below the cutoff voltage. Even if the cell is down to 100mAh of capacity when the trip point is first hit (it is probably higher...), at a 1uA drain rate it will take 100,000 hours, or about 11 years, to kill the cell.

The TC54 doesn't magically kill itself when it hits 0.7V either. All that happens is that the output is undefined. In Randomly's circuit this is perfectly fine because the only way for the FETs to be on is when all of the TC54s are actively above the cutoff, and their outputs are high. If any one output is anything but high, the "chain" will be broken and the FETs will be turned off.

A cell dying on its own can't be stopped, no matter what circuit is used, but clearly, there are extremely reliable ways to protect cells from being overdischarged, due to leaving something on. Even the dedicated detector chip (i.e. -- TC54...) approach can be made to handle the case where a cell connection is broken. A simple 5V zener will take care of this problem. Voltage spikes? I've never seen this to be an issue on any pack I've owned. To get around the mis-wiring problem, you simply avoid using direct connections to the pack. Using connectors allow each side to be tested for being correctly wired, prior to connecting them together. Once I started doing this, I never had another mis-wire, killing a TC54 problem.

-- Gary

 

[texaspyro]

The idea that the code aspect will be an unimaginable, unmanageable cesspool of errors is, well, crap. The basic BMS code would be a couple hundred lines of C. Geez, it's read an adc, compare to LVC, compare to HVC, lather, rinse, repeat. My poor, dead, mother could handle that... and turning on a light bulb was the limit of her techno powers (but she could field strip and reassemble a Singer sewing machine in pitch darkness).

We are not talking 50,000 lines of battle management written by an army of lowest bidder gooberment workers that get promoted if they can crank out 6 lines of ADA in a day. Anybody with more than a passing familiarity with embedded design can handle it. Once the basic BMS code is up and running, you can add the link to a remote display, etc. Personally, I want a graphic LCD display that shows each cell, etc.

 

[Jeremy Harris]

The idea that the code aspect will be an unimaginable, unmanageable cesspool of errors is, well, crap. The basic BMS code would be a couple hundred lines of C. Geez, it's read an adc, compare to LVC, compare to HVC, lather, rinse, repeat. My poor, dead, mother could handle that... and turning on a light bulb was the limit of her techno powers (but she could field strip and reassemble a Singer sewing machine in pitch darkness).

We are not talking 50,000 lines of battle management written by an army of lowest bidder gooberment workers that get promoted if they can crank out 6 lines of ADA in a day. Anybody with more than a passing familiarity with embedded design can handle it. Once the basic BMS code is up and running, you can add the link to a remote display, etc. Personally, I want a graphic LCD display that shows each cell, etc.

Well, with the greatest respect, that's not what either Gary or I said, but hey, it's good to rant once in a while...........

BTW, in my experience, it's rarely the source code that's at fault, most unforeseen and virtually un-testable software failure modes I've seen have come from unqualified compilers, of which there are a lot around, producing object code with deeply buried flaws. You can write the very best, flawless bit of code a couple of dozen lines long and yet not be certain that the compiler hasn't screwed up, with some weird and wonderful error that happens when some peculiar set of conditions occurs.

Anyway, getting back on track, I thought that Alan started this thread with an (or maybe the) objective of producing a high reliability low voltage monitor, not an all singing, all dancing, BMS with fancy displays. I can see benefits in both - geeks will want heaps of nice looking data to drool over, some will just want to know that something reliable is looking after their cells and some frankly won't care.

The bottom line seems to be that there is a need to not just design a reliable circuit, but to make sure that every aspect of it's installation and use are as carefully thought through, with potential failure modes eliminated by design and manufacturing method. I am near-certain that the mechanical aspects of a unit like this are more important than the electrical aspects when it comes to reliability, so some creative thought as to how to build and package the device will likely be more constructive than pretty much any other aspect.

For example, we know that soldered wires come off battery connections, that some of the connectors we're using have an unacceptably high failure rate, that circuit boards suffer damage from mechanical stresses, heat, cold and damp. Something simple, like coming up with an affordable, easy to use, high reliability connector system (i.e. doesn't need expensive, calibrated crimp tools) would be a good start. Some ways to make robust and cost effective housings would also be good. Proven ways of protecting components, wires etc from stresses, temperature and humidity related problems, that are within the scope of the sort of stuff a home brew constructor could use would also be good. I suspect that SM boards maybe be easier to protect from environmental/accidental damage than through hole boards, but some evidence to show one way or the other would be good.

Jeremy

 

[texaspyro]

I've written several hundred thousand lines of code for AVR chips using the win-avr GCC compiler. Compiler problems are so far down in the list of worries, it takes an SEM to see them (and you can use the one I wrote the AVR code for to try). And all my code is perfect, rock solid, and flake free! Nothig evar goze wong.

Regardless of the technology behind the BMS... connector, wiring, PCB, interconnect, component problems are all pretty much the same. Having a micro in the loop gives you a MUCH greater chance of detecting the problem and minimizing the consequences. And no matter what the technology, a half-way decent BMS is an order of magnitude more reliable than running your pack bareback. Humans are about the worst BMS out there (but slightly better than Chinocrap).

 

[CamLight]

Shucks now my code is bad, before it is even written?

Wasn't even trying to imply that.
Just that the code, same as lots of other aspects of a product's design, has to be included as a possible point of failure.

 

[CamLight]

One thing I find interesting is that some folks think purpose designed chips are better than micros in some magical way. In detail, the purpose designed chips are often very similar internally to a micro and they often contain micros. They are pre-programmed to do a specific job. They have advantages and disadvantages, but they are just another component, as are general purpose micros. You are stuck with their flexibility, and their lack of it. The general purpose micros tend to be more available for a longer period of time and more flexible. These special chips come and go quickly which is hard on a small project that has no funding to buy lots of chips. I'm not against using them, just be aware of the issues. We generally support systems for 20 years and getting parts becomes a problem at some point, generally sooner for special parts.

I haven't seen that bias towards purpose-designed chips here though. Certainly not from me.
The majority of my designs use standard micros but a few do use dedicated-function chips (or chipsets) and those designs really benefit from that. You've got a design that uses a micro, is simple, easy to build and completely meets almost all of your requirements. Doesn't get any better than that!

The thread was opened to solicit suggestions and some have been made that don't include micros. IMHO, that's a good thing as it can not only confirm your design approach as being the way to go but can also inspire other design ideas, features, etc., even for a simpler-is-best design. Comparing current draw and other specs for dedicated-function chips against a micro can also be useful in firming up some specs for a design that uses a micro. And, datasheets for the dedicated-function chips often contain great PCB layout examples and tips, schematics and equations for effective low-pass filter design and component selection, have simple low quiescent-current regulator designs that can be stolen for a micro-based monitor, etc.

But, the design is pretty firm and now proceeding towards the more physical side of implementation...a great step forward!

 

[Alan B]

I'm glad we're having a good discussion here. It would be boring if we all agreed on everything. Let's make sure to keep it friendly.

On the TC54 chips. If the spec sheet says they go "undefined" below 0.7V, that means (to me) the voltage is too low to operate the device, and the output will probably go tri-state. So if the design had resistors biasing the output to "bad cell" then it would go that way, if the bias was to "good cell" it would then revert to incorrectly reporting cell ok. I didn't see that part of the design in the non-opto case. In the opto case it was biased to "good cell", so it indicates incorrectly below 1.5V. If it is biased to the high side of the falling cell then there is not much voltage (less than 0.7) to indicate high or operate a gate or base so it may indicate incorrectly there also.

More fundamentally we need to understand if the requirement for the monitor to work below 0.7V cell voltage is necessary or not. Do we want the monitor to reliably report cells below 0.7V, or do we want to write in the specifications "this unit does not correctly protect the pack if any cell drops below 0.7V". If we climb on the bike, and a cell has gone bad, do we want it to protect or pretend??

We have seen evidence that at least the Headway cells recover quite nicely from 0V if they were not subject to "reverse current". So giving up on them at 1.5V or 0.7V is not prudent.

I think the requirement should be that the monitor work down to zero cell volts on at least a couple of cells. Beyond that point the overall pack voltage will be so low that it won't appear to be a good pack from the total voltage point of view. So the controller will catch it. We can detect (with at least one design) this condition, so it seems a valid and reasonable requirement to me. But if we want the monitor to keep working all the way down to a pack voltage of 4V we can meet that (and change the requirement).

Placing zeners across the TC54's is a nice improvement. It protects against wrong order of connection. But it does not protect against incorrect connection (connecting to a cell junction above 12 volts will destroy the zener and the TC54). Adding series impedance to allow the zener to protect against 30V might be workable, but it would require some analysis and perhaps testing to determine if this would cause new problems. It would change the hysteresis characteristics and possibly cause latch up, depending on the load of the TC54. Someone should work through the numbers and see if there is a combination that would work.

At this point it looks to me like the TC54/opto design is a great solution if:

1) you never connect it to the wrong cells, and
2) if you are okay with no protection below 1.5V (or possibly 0.7V depending on the particular design)

The TC54/opto solution has very low current drain, though the current jumps up a bit when the opto comes on.

It has been suggested that JFETs be added to the micro design to lower the sampling divider power consumption (in which case it would go WAY down as MOST of the power is being drawn by the voltage sampling dividers). Perhaps an example circuit should be presented here to review that. It has been a long time since I worked with JFETs. This, or some similar improvement would reduce the current consumption of the micro by 90%.

It would also be good to get some other suggestions on simple battery pack monitor chips such as the Maxim I mentioned before that might be candidates for this application. We are looking for simple monitoring solutions, not full BMS chips, at least in this particular discussion.

I did add a requirement that the parts be readily available to post #1. This was implied earlier but needed to be stated. New parts that are not available, or parts only available in high quantity, etc are probably not of (much) interest to this discussion. We want something available and real.

Thanks for your input!