Designs for Reliable (low V) Cell Monitoring electronics

[CamLight]

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.

I completely agree,

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

SM boards are typically a lot smaller than their thru-hole counterparts and this makes it easier to protect them. Either with a less-expensive case, glue-lined shrink tubing, or a conformal coating. Because SM components are smaller and can't shift around, the shrink-wrap is easier to source or the coating is easier to apply (and doesn't crack). With the SM boards/components being lighter, the forces on the board are smaller too when subjected to shock. Gotta' keep the board from flexing though but that's easy with a small board or one that's just cased via goop-lined shrink tubing and left "floating" in a pack's bag or even duct taped to the pack.

But, this is a low-power board and the thru-hole components won't be very large/heavy. The advantages of SM might not be worth it compared to the difficulty for some in soldering a SM board. Particularly if you just get some regular shrink tubing, squirt in some neutral-cure RTV or hot glue, and shrink the tubing down until it squeezes out whatever goop is in there. The components are then shock mounted and watertight.

[Edit] Another advantage...
If you use a short length of flexible heat shrink tubing wherever the wires exit whatever goop that is used, then the wires are very nicely protected from fatiguing and breaking copper strands due to vibration. Using RTV as the goop may be flexible enough to keep the copper from eventually breaking where the wires exit the RTV but a few more pennies in heat shrink can help a lot.

But, this requires the connectors to be cable-mounted. This allows for easy connector replacement if they get damaged but you do have flying leads coming off the board. Once the connections are made though, there's not much of a difference. Not sure which method is better, just tossing out possibilities.

 

[CamLight]

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!

Agreed.
And I do want to apologize for distracting the thread with my earlier full-BMS chip recommendations and not noticing you had focused on just having monitoring-only functionality. I swear I saw the original thread title include "BMS" and that, for me, meant additional protection, etc.

I'll check my data sheet hoard and see what's out there and widely available now for simple over- and under-voltage protection (with alarm output) that draws little current, can meet your requirements, and handle packs up to 8S packs.

 

[CamLight]

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.

PCB123?
I'm still willing to help but would need you to select the PCB footprint (i.e., size) for the components. This might be as simple as printing out a BOM from your software? I can then do the schematic/layout in Eagle and generate Gerbers that can be used at any board house (mentioned this so others know what the situation is).

Perhaps someone else willing to help uses the same software as you? This would still tie the board's manufacture to that one vendor but it make things verrrry easy.

 

[Alan B]

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.

PCB123?
I'm still willing to help but would need you to select the PCB footprint (i.e., size) for the components. This might be as simple as printing out a BOM from your software? I can then do the schematic/layout in Eagle and generate Gerbers that can be used at any board house (mentioned this so others know what the situation is).

Perhaps someone else willing to help uses the same software as you? This would still tie the board's manufacture to that one vendor but it make things verrrry easy.

ExpressPCB. I was attracted to them many years ago with their 3 boards in 3 days for $55 deal.

 

[Alan B]

...

And I do want to apologize for distracting the thread with my earlier full-BMS chip recommendations and not noticing you had focused on just having monitoring-only functionality. I swear I saw the original thread title include "BMS" and that, for me, meant additional protection, etc.

I'll check my data sheet hoard and see what's out there and widely available now for simple over- and under-voltage protection (with alarm output) that draws little current, can meet your requirements, and handle packs up to 8S packs.

No need to apologize. Those suggestions you made were in my other quad cell BMS thread, not this monitoring thread.

Edit - just was reviewing this thread and see the suggestion was in both threads. No problem, anyway.

 

[CamLight]

I checked TI and they don't have anything widely available now in their battery-management/monitoring portfolio that fits your requirements. Your design falls in between their bare-bones OVP-only (over-voltage protection) chips and their fuller-featured ones.

They do have some widely available, fairly inexpensive, 2-to-4 cell over-voltage protection chips preset for 4.30V-4.60V (http://focus.ti.com/lit/ds/symlink/bq29410.pdf) that are, IIRC, immune to cell connection sequence, only draw a couple of uA, and only need a cap to operate.

Still need two diodes for OR-ing their outputs though and perhaps optoisolation too. And, you'd still need some sort of UVP monitor to complete your design so not an elegant solution unless the parts count for OVP is significantly reduced using these chips (and you have OVP = 4.30V or higher, ruling out LiFePO4). Or the pack is allowed to drop to whatever voltage it wants to (negating the need for UVP)....definitely not meeting your requirements.

I haven't checked TI's (or anyone else's) generic voltage monitors though, i.e., chips similar to the TC54. I don't know if there's something else out now there that might fit your requirements and also address the less-than-desirable issues with using TC54's.

 

[Alan B]

Thanks for checking the TI chips.

The Max11068 looks interesting. It is a measuring and control chip very similar to the earlier mentioned max11080. It differentially measures cell voltages for a micro with a serial interface. It also has FET switches that can be used for balancing.

So this would be the next step up, a more accurate measurement of cell voltages plus low current balancing. Plus very low currents in standby.

This is more like the chips Methods has been working with.

This chip is in production but Newark doesn't seem to have it. It may be quite new.

It is a bit more than we need for these requirements.

It might be worth going through a design with the Max11080. It should come out lower in chip count and power than the micro. It is a 38 pin SOIC. Seems like more pins than it should require...

 

[CamLight]

We're thinking alike regarding these chips.
Yea, the MAX11080 is pin-count heavy. Between using 8 pins for setting the UV and OV voltages and 5 or 6 pins dedicated to alarms and shutdown and the pin count adds up quick!

I was able to sample the MAX11068 for evaluation but, that's it. None available for purchase from anywhere I have access to. My guess is end of the year at the earliest for purchase by individuals (end of the 1st quarter as the guess from my pessimistic side). The MAX11080 isn't widely available but there are a couple thousand around and that number should go up soon.

The MAX11080 won me over for a no-balancing-required BMS design I started working on. I couldn't find anything I really didn't like about it for my automotive application. But, the design was switched over to a full-featured TI BMS chip when the client soon decided they needed balancing. Don't know if using the MAX11080 would beat out your micro-based design though.

The MAX11068 evaluation kit uses a MAX11080 as a secondary protector and has schematics and example PCB layouts. Might be worth checking to see what components are absolutely necessary and which might be optional for your requirements?: http://datasheets.maxim-ic.com/en/ds/MAX11068EVMINIQU.pdf

 

[commanda]

The mob formerly known as Farnell have significant stocks of the 11080 in the UK.

http://au.element14.com/maxim-integrated-products/max11080guu-v/li-battery-management-38tssop/dp/1813076?Ntt=max11080

Amanda

 

[Tiberius]

The mob formerly known as Farnell have significant stocks of the 11080 in the UK.

http://au.element14.com/maxim-integrated-products/max11080guu-v/li-battery-management-38tssop/dp/1813076?Ntt=max11080

Amanda

Interesting, I have an account with this mob, and they still use the Farnell name.
Here's what they say about the MAX1108
http://uk.farnell.com/maxim-integra...ry-management-38tssop/dp/1813076?Ntt=MAX11080

I think its the same company as Newark in the USA.

Nick

 

[Alan B]

Interesting, Newark charges 8 bucks but doesn't have any, Farnell wants 8 pounds in the UK and 8 dollars in the US for the same Max11080. Farnell will ship to the US but their shipping charges are really high for something that is really not large or heavy.

The Max11068 and a small micro would exceed the battery monitor requirements by a small amount, adding balancing capability (which could be left turned off). It would meet Jeremy's requirements for data acquisition precision. And it would have very low current requirements. Pin count is really high. Surface mount only, not a small part either. Would be nice to combine with a small AVR that has a UART and a I2C to handle serial comms. Too bad it is made from unobtanium.

Using the Max11080 (which is obtainable but not cheap) would be simple but would not meet the same level of self checking that the micro design meets. Even adding a micro to it would not since internally it is comparators and we cannot really test them. It does give a heartbeat so perhaps it is internally self checking. There is a lot of external hardware on their sample designs but hopefully a lot of that can be left out if not stacking the chips for more than 12S sub packs.

Need to look at Linear's offerings to see if they have anything interesting and available.

 

[fechter]

I haven't checked TI's (or anyone else's) generic voltage monitors though, i.e., chips similar to the TC54. I don't know if there's something else out now there that might fit your requirements and also address the less-than-desirable issues with using TC54's.

I've spent quite a bit of time looking at the various voltage monitors similar to the TC54. Nothing came out looking significantly better, other than those Seiko chips, which can do both under and over voltage detection.

On the TC54 (or similar) adding a resistor ahead of it with a zener will make it pretty bulletproof. The effect of the resistor would be small and can be calculated/tested.

This would still lack fault detection.

Another topology I've pushed in the past is to use a near-brain-dead little processor like a $1 ATTiny13 on each cell. The MCU could run off the cell and signal through an optocoupler or transistor ladder like an analog system. Basically use the MCU to emulate an analog system, with unidirectional communication. Compared to the analog counterpart, this would offer lower parts count and programmability. Using a calibration routine, each one could be calibrated to a very high degeree of accuracy, at least better than what you get with an analog setup. It would also offer more sophisticated signalling options. While it could be protected against miswiring, it would still lack fault detection for some faults.

Cell level processors with bidirectional communication would offer much more detection and reporting capability as you could poll each cell to read voltage and if any one didn't respond you could detect that.

Somewhere between this approach and a centralized approach would be to use an off the shelf chip that works with something like 4 cells. TI and others have quite a few that are good up to 4 cells. Many of these have some kind of serial interface built in, and they are cheap.

 

[number1cruncher]

How hard would it be to setup a LVC per individual cell? In other words, for a 12s2p, monitor each of the 24 cells. I'm an electronics simpleton, so I envision Gary's LVC board with only one JST connector per set of monitoring components. Yes this would be complicated to set up with twice the parts, but would most likely detect a bad cell in a parallel string, I think. There's probably a better way to do it and may be in your technical discussion that I don't comprehend at this time. However, in the last year, most of my lipo pack failures were due to a bad cell trying to kill its paralleled neighbor.

 

[Alan B]

In the Linear stable the LTC6802 seems to be in Digikey but not stocked. At Newark the LTC6802 is $22. Robbery.

The LTC6801 is available but $11 each but drops to $7 in 25 qty.

The 02 requires a micro, the 01 does not.

I do like the cpu per cell designs. But I have not found one that meets all these requirements yet, and the parts count gets pretty high.

They ATTiny13 doesn't have a big enough stack for GCC (the C compiler) so I have moved on to other parts. I have a few of them here but don't like taking the time to do assembler.

However there are other 8 pin AVRs that work fine with GCC and are good for this and I have done a lot of work with them. I did look at some designs but the chip count was higher. It would meet some of the requirements, though if a cell goes below 1.8V there will be no data. That micro would not work, so it would be missing from the scanning rollcall. Probably would have to add one more micro as a master to have a reliable setup. The master would poll the rest, run from the pack V and do the signalling. With all the communications and two separate codes the software would be a bit more difficult than a single cpu design.

If the communication is unidirectional then the individual chips would be hard to poll. Then if one failed or the cell voltage went too low for the micro to operate it would be hard to tell that it was missing. Bidirectional communication takes more parts, unfortunately, like two optos per micro. Could program the micros to randomly spew out data and rely on luck they didn't collide on a unidirectional bus, but that seems not to be a great solution.

I suspect this approach would be difficult to harden against miswiring. Protecting the micro VCC against 30V without a regulator would be difficult. So either a regulator per micro would be required or miswiring would not be tolerable.

 

[Alan B]

How hard would it be to setup a LVC per individual cell? In other words, for a 12s2p, monitor each of the 24 cells. I'm an electronics simpleton, so I envision Gary's LVC board with only one JST connector per set of monitoring components. Yes this would be complicated to set up with twice the parts, but would most likely detect a bad cell in a parallel string, I think. There's probably a better way to do it and may be in your technical discussion that I don't comprehend at this time. However, in the last year, most of my lipo pack failures were due to a bad cell trying to kill its paralleled neighbor.

If the 2 cells are paralleled their voltage will the the same, so no value in a separate detector.

If two packs of series cells are paralleled then the individual cells in each pack are still separated (unless the balancing leads are also paralleled). So in that case monitoring each cell would be valid. But it does take a lot more hardware to do so.

 

[Jeremy Harris]

On the TC54 (or similar) adding a resistor ahead of it with a zener will make it pretty bulletproof. The effect of the resistor would be small and can be calculated/tested.

This would still lack fault detection.

Very true, but the the probability of component failure is almost certainly pretty low compared to other failure modes - it might well be good enough.

Another topology I've pushed in the past is to use a near-brain-dead little processor like a $1 ATTiny13 on each cell. The MCU could run off the cell and signal through an optocoupler or transistor ladder like an analog system. Basically use the MCU to emulate an analog system, with unidirectional communication. Compared to the analog counterpart, this would offer lower parts count and programmability. Using a calibration routine, each one could be calibrated to a very high degeree of accuracy, at least better than what you get with an analog setup. It would also offer more sophisticated signalling options. While it could be protected against miswiring, it would still lack fault detection for some faults.

Cell level processors with bidirectional communication would offer much more detection and reporting capability as you could poll each cell to read voltage and if any one didn't respond you could detect that.

Peter Perkins is the master of this approach with his system, although that grew into an all-singing-and-dancing BMS, rather than sticking with the idea of something simple. It does work well though and is more fault tolerant, in as much as it can self-check, than some other designs. The code is probably simple enough to not worry overly about firmware reliability, either. Having over and under protection combined would be a nice-to-have, although it'd necessitate putting some power stuff on the board to do balancing.

Jeremy

 

[texaspyro]

They ATTiny13 doesn't have a big enough stack for GCC (the C compiler) so I have moved on to other parts. I have a few of them here but don't like taking the time to do assembler.

I program Tiny13's with GCC all the time... but the TINY85 is just about the same price and has lots more memory.

My micro-per-cell design has a bidirectional synchonous daisy chained bus between the chips. It is capacitively coupled. The micros are powered by a capacitively coupled clock driven from the master controller. A similar design uses the AD7740 V/F converter in place of the micros.

 

[GGoodrum]

One nice thing about the PicAxe chip Peter used is it has a BASIC-like interpreter built-in, which makes coding even easier. The ATTiny 25/45/85 series does look interesting, though. Lots more memory, plus some other new features, and only $1.29 in quantities.

One point about the TC54, though. In the ladder-type output implementation, like Randomly did, the complementary version of the chip is used, which has its output high, instead of floating, when the voltage is above the cutoff. For the output FETs to be on, all of the transistors in the ladder have to be on, and the only way for that to happen is for each TC54 output to be high. So, once a cell drops below the cutoff, its TC54 output goes low, which breaks the chain. Even if the voltage drops below 0.7V, it doesn't matter what the TC54 output does at that point because it won't be able to be high enough to turn on the ladder transistor, so the output FETs stay off. The reality is, though, that if the reason the cell voltage is dropping is because of a load left connected to the pack, the cell that gets low enough to trip the TC54 is only going to drain a 1uA rate, from that point forward. It will literally take years to get it down to 0.7V.

If a cell is dying on its own then no BMS or LVC circuit is going to be able to do anything about it. In this case, having separate serial strings only paralleled at the pack level would at least limit the "killing" to one cell, but I'm not sure it's worth it. It has been my experience that cells are always going to end up with slight variances in capacities, IR and thermal characteristics, so paralleling them at the cell level helps average these differences out and makes it easier to keep them balanced. In the numerous a123 and LiPo-based packs I've built, I've not had a case where a cell died on its own, and then kill its paralleled mates. I have seen where overdischarging will do this, with unprotected packs, but not just a cell dying on its own. I also have not had a case where a failed circuit has killed cells. I have miswired circuits, which did kill the circuit, but I never left it connected this way so it didn't kill cells. The parts just don't fail on their own, so if you get the connections right, you are done, in my opinion. They best way to get the connections right, the first time, is to use a pair of interlocking connectors. This is what stopped all my early miswire problems. You can then test each connection in each half before connecting them together. No magic smoke.

My favorite connector type is still the AMP/Tyco VAL-U-LOK 4.2mm PE Series. I bought the crimper for these, which was not cheap, but it is a snap to use, and it does a perfect crimp on the pins and sockets, on 18-gauge wires. I've also found this same crimper can be used on the slightly smaller Molex MicroFit 3.0mm connectors, again with 18-gauge wires. I've just ordered, however, some MTA 156 connectors, mainly as a labor saving device, because with these, the wires don't have to be stripped first, so we'll see.

-- Gary

 

[Jeremy Harris]

I've used IDC connectors a fair bit (not professionally, only with hobby stuff) and been pretty impressed - they have the potential to get around some of the reliability issues with poorly made crimps or soldered flexible wires.

Jeremy

 

[texaspyro]

One nice thing about the PicAxe chip Peter used is it has a BASIC-like interpreter built-in, which makes coding even easier.

The biggest problem with Basic Stamps and PixAxe type devices is that they are hideously slow compared to native execution. Pic based designs being quadruply hideously slow since they divide the clock by 4 before you even get started. Plus you are locked in to their (usually rather limited) language. It really pays to learn how to program the chip directly in C. I have never had to write a single line of AVR assembler...

The GCC compiler for AVR chips is VERY efficient. My welder has over 12,000 lines of code and generates 150K of AVR object code (probably a third of which is text strings and tables). And I am not shy of using long variables and floating point code. The code is also highly efficient execution wise. The heart of my welder is a routine called from a 10KHz timer. Besides handling the ADC and speaker, that timer tick does a couple of 32 bit multiplies and several additions, compares, etc. A lot going on every 100 microseconds... with time to spare.

 

[Alan B]

They ATTiny13 doesn't have a big enough stack for GCC (the C compiler) so I have moved on to other parts. I have a few of them here but don't like taking the time to do assembler.

I program Tiny13's with GCC all the time... but the TINY85 is just about the same price and has lots more memory.

My micro-per-cell design has a bidirectional synchonous daisy chained bus between the chips. It is capacitively coupled. The micros are powered by a capacitively coupled clock driven from the master controller. A similar design uses the AD7740 V/F converter in place of the micros.

While it is possible to program the Tiny13 with GCC it is not directly supported and requires some special tricks and significant limitations on what source code constructs can be used, unless they made improvements that I have not seen. The Tiny13 is missing the stack support for functional argument passing and local variables, and doesn't support quite the same instruction set as the Tiny25 et al. When the Tiny25 came along I popped them into the existing hardware and it really increased productivity in software development.

The Tiny25/45/85 is a super little chip family (differing primarily in memory size). I have purchased over 100 of those for my projects. I packed a lot of code into the 4K model, and still have a lot of growth space. Very impressive.

It would be interesting to see your micro per cell design, either here or on its own thread!

It does sound like the TC54 design that Randomly made was a real improvement over the more common opto isolated types. It meets most of the monitoring requirements of this thread and does so at very low current. The parts cost is low. The parts count is a bit high compared to some other designs. It is a bit difficult to verify that it is working for all cells unless a test pushbutton is set up for each cell. Self testing is not available.

We use a lot of IDC connectors. They are convenient and have mixed reliability. It can be important to use the right tools and get them properly latched. The correct cable is also quite important. They can be reliable.

It is interesting that those with reliability testing experience here don't mention periodic testing and verification. On our systems that have actual reliability requirements we must periodically and/or continuously test them. Verification is required for any kind of insurance that things are still working properly. Some of the designs presented here are decidedly inconvenient to test. Others are inherently self testing, to varying degrees. There may be some value in that.

Any comments on using DB9 connectors for this application? They are available in pc board mount, good for many cycles, and commercially made pre-molded cables are readily available to cut up for the battery side, so all that need be done is sort out the wires and crimp ring lugs on (for Headways at least). No special crimper is needed.

 

[texaspyro]

I know the latest compiler supports the Tiny13. I had to switch to it when my welder code crossed the 128K boundary on the ATMEGA2561.There is a processor switch for the tiny13. It also generates faster code. The mega-donkey lcd routines use NOPs to generate the strobes to the LCD and I started getting screen glitches until I put in more NOPs. I don't know what they changed... the old code looked pretty darn good (but was tweaked to be right on the edge, for maximum performance)

I have not used TINY13's for much complicated stuff, but one app uses an interrupt to read the ADC and has a couple levels of subroutine calls with parameter passing. A friend of mine created the Tiny Cylon and wrote this code for it, so it is pretty capable... http://www.sparkfun.com/datasheets/Kits/tinyCylon2.c

I never built up a full micro-per-cell BMS. I did test all the parts and found no show-stoppers. I am now looking at 4/6/8 cells per micro designs. I wish there was a $1 AVR with A/D and uart. The lack of the uart led to the synchronous data link. The link clock also clocks the switched capacitor balancer and A/D sampler. The AD7740 also design keeps popping up its head...

 

[Alan B]

Amazing about the Tiny13 support for GCC. That compiler can do so much for so many different architectures, and generate very compact code. I guess I won't have to give away those Tiny13's after all. I think I have some Tiny22's also that were in a similar situation.

But the Tiny 45's are so much better, and I think I paid about $1.19 each for them. Not worth going to cheaper chips at that cost. I should probably get rid of the 13's and 22's anyway...

This Tiny261 is significantly more capable. 20 pins, all with many capabilities. It has about 11 ADCs, and will do differential voltage measurements on up to 7 cells! For 4/6 cell setups it is hard to beat. It has the USI serial I/O device (not UART), but it is not hard to do a UART with that hardware. I will probably update my quad BMS design to use it. The Tiny261 also has six PWM outputs for motor controls with programmable dead time, etc, so it could do the motor controller function. A few of them could easily do everything needed on an e-bike with the same part. Convenient. $1.57 in 100 quantity. Available in DIP, SOIC, VQN and TSSOP packages. The DIP package makes it easy to breadboard with. 20 MIP performance.

 

[CamLight]

For reference and possible discussion, here's a micro-per-cell design that worked beautifully for me. I easily achieved +/-10mV cutoff accuracy without calibration from 0C to 40C. It's easily scaled down as most of the components can be removed to tailor the feature set.

If an ADC is available in a tiny micro (6-8pin) you'd like to use, then you can remove the op-amp and supporting circuitry. If the micro has an accurate enough internal voltage reference to meet the requirements, you can remove the LM4050 too.

Just tossing this into the mix for comparison and possible ideas to borrow. Scroll down to the third article in attached PDF.

 

[texaspyro]

I guess I won't have to give away those Tiny13's after all. I think I have some Tiny22's also that were in a similar situation.

I run a Tiny AVR rescue center... can find them a good home :wink: