A PIC based Battery Management System

OneEye said:
OK, how do you feed this beast when charging? Lets say you want the end of charge to be 3.65V per cell; do you simply feed it with n*3.65V in a CC/CV scheme?

Also, where do pins 5 & 6 from the lowest cell go?

For a string of cells, do you need the same number of chips, or one less?

Yes, you can simply use a bulk CC/CV charer that has a crossover/cutoff point of at least 3.65V per cell. For a 36V/12-cell pack, that is 48.8V and for a 48V/16-cell pack, the cutoff voltage needs to be at least 58.4V.

-- Gary
 
OneEye said:
Also, where do pins 5 & 6 from the lowest cell go?

For a string of cells, do you need the same number of chips, or one less?

Sorry, bad drawing. The whole bottom charge pump would not be used for the string of batteries shown. You need n-1 charge pumps (n= number of cells).
 
How might this charge-pumping magic compare to separate chargers per cell?
 
The LM2662 has a 3 ohm output impedance. That means if the voltage difference between adjacent cells is 50mv, the current flow will only be 17ma. or 33ma for 0.1v difference.
 
The average current would be even less. As capacitor would charge voltage differential would decrease. It would still equalize voltage eventually. So would 10ma dissipative balancing. For me more interesting question is if this technique can transfer significant energy at end-of-discharge. If you look at LiFePO4 discharge chart, almost full and almost empty cells have basically the same voltage. But when the weakest cell drops to 3.0V and the rest stay at 3.6 that's when it becomes interesting. Dissipative or current shunt balancers can't help. Charge pump would transfer at max 200mA. Just to roughly guess, let's say average current would be 100mA. Or balancing rate of 0.1Ah per hour with resistive losses of approx 10%.

This is between adjacent cells. I'll just guess it would be 1/2^N (or 1000 less for cells separate by 10 other cells). It would be way better if there was a way to switch between weakest and strongest cells somehow. Doing that logic in MCU is easy, but need high-voltage switches again...

How about a custom FET switcher with two FETs with 3mOhm and capacitor with 3 mOhm ESR, cells with say 5 mOhm. Max current of 42Amps. Not this would be a nice balancer :twisted:
 
You mentioned the MAX889 as a possible alternative. It claims 0.05 ohm output impedence when run in a regulated mode (requires a voltage divider set up between Vin, Feedback, and Vout). Does that mean a .01V difference could yield the full 200mA of current? When it is in free-run (unregulated) mode its impedence is 2ohm. Does the regulation on the output prevent the inverter from being reversed to act as a doubler? If so that would make it one-way balancing only. I'm not sure what that would do to a string if the first cell (or is it the last one) was too high or too low.
 
The charge pump as a component was being considered on the "Smart Battery Data Specification" thread as part of it's resolution... I feel like now I've been hijacked. :shock:

Oh well, if people are stealing ideas that's good for everyone... :)
 
tomv said:
How about a custom FET switcher with two FETs with 3mOhm and capacitor with 3 mOhm ESR, cells with say 5 mOhm. Max current of 42Amps. Not this would be a nice balancer :twisted:

That's what I was thinking. Since the FETs are only seeing 2 cells worth of voltage, it should be possible to get some with very low on resistance. I'm not sure about the capacitor though. Pumping 42 amps through a little capacitor probably isn't going to happen. It would need to be a pretty big capacitor with very low ESR. The multilayer ceramics seem to be the best suited for this application. In a surface mount variety, you could easily parallel a bunch of them.

I've never seen a high current (>1 amp) switched capacitor charge pump for some reason. They say you can parallel the existing ones for greater current. My guess is it becomes cheaper to use inductors above this level.

There would be a bit of challenge in driving the gates. A high side gate driver chip for each FET would work if you could figure out how to bootstrap them. You might need a little charge pump for the gate driver on the highest cell. A bunch of discrete FETs and driver chips might be not that expensive.
 
I'm new to this board, but I've read this discussion and found it very interesting. I'm looking mainly for LVC for a 20 cell pack. I'd like to drive a display that tells me mainly what the lowest cell voltage is, with options to display other cell info.

After reading this discussion, I think the method that makes most sense to me is to use a processor for each cell. The processor would run off the cell's voltage and monitor it as well. I would then daisy chain the processors together, one processor's serial output connected to the next processor's serial input (through an opto). Each processor would monitor it's cell voltage, then transmit that cell's voltage, along with all of the upstream voltages to the next processor. The last processor would output to the display. I imagine they could all run the same program. The last processor could be told to output to the display by an input or by counting the cell data that it receives.

One processor and one opto per cell.

Anyone see any problems with this?

- Brad
 
We thrashed through and argued about 21 pages worth of ideas and unless my memory has failed me I don't think anyone suggested that exact setup.

Most of the systems wanted to do some kind of balancing along with the low voltage detection. You do know that there are simple but relatively expensive chips that could give you the cell voltage with enough "common mode voltage" isolation to do the job?

:arrow: That's a good contribution... use the PIC just to measure the voltage and then use the opto to pass the information along. There is a "standard" for communication that is the "Smart Battery Data Specification" that also owns it's own thread, but it's bloated and probably not something you would want to use. (you might look at it for ideas however)

Your information passing will involve creating a language between the PIC's and that's where the Smart Battery fit in with the overall scheme of things.

I think where you have introduced a new idea is the idea of daisy chaining the PIC's rather than using a bus design. The bus design takes it's cue from the computer world... what you are suggesting is more like the old series port rather than the bus.

Your idea would simplify the communication code.

...so I guess your software would look for a serial packet of data of undetermined size and then uncode it, then repackage the data with the extra voltage value and pass it along. The data would then finally be processed with the same unpacking routine, but for the display it would then call other routines to populate the display.

You could go directly to an LED... nice... :)

Maybe have an option to only display the lowest voltage value while you ride so that you could focus on it. Then when you stop and hit some button you could scroll through all the values one at a time.
 
Safe,

Thanks for the reply.

With a processor on each cell, it wouldn't be too hard to add circuitry for balancing, etc.

I'm thinking of a very simple messaging system.
- Each message would contain a string of battery voltages.
- Each processor would wait for a message, append it's cell's voltage and send the message.
- The last processor (I'll call it the main processor) outputs to the display.
- The main processor then sends a signal to the first processor (one bit, via opto) to tell it to start over.
- The main processor would also start the process if it doesn't receive any messages for a predetermined period of time.

The main processor would be at the negative end of the chain. It would also monitor the voltage across a shunt at the negative end of the chain. This way, it could monitor current and calculate watt-hours used.

The main display would show lowest cell voltage, current draw, and what hours used.
An alternate display mode would show voltage of all cells.

- Brad
 
Hi Brad,

Yes, after thrashing around 22 pages worth of stuff, I think the one processor per cell approach is the nicest. No problem with the processor activating the shunt. The small processors run nicely on 2.5 to 5v and are around $1 ea.

This approach would be inherently modular, and you would need a 'master unit' that would listen to all the cells and perform the cutoff funcitons as well as display cell information. If there is one weak cell in a long string, it would be nice to know which one it was. Smart software could do this automatically. The master unit could also be the interface to calibrate or change the set points for the cell units. You might want a display like a CA with some buttons, but this would add to the cost. If you had a display, it could have a bar graph 'fuel gauge' that automatically self calibrates, as well as individual cell measurements. Alternatively, you could have a USB interface and plug it into a computer to display cell information and reprogram set points.

The part I hadn't decided on was what the best way to have them communicate. They are all sitting at different voltages, so either you need optocouplers on each one or use a communication that happens at a high enough frequency that you can capacitively couple them. I don't know what the maximum number of devices (cells) is that you can run on a single bus. Seems like data collisions would happen or something if there were too many. I suppose the master unit could poll each cell in sequence to keep things straight.

Cell units could be built for any number of cells and daisy chained with just the data bus lines.
You could build them stackable with connectors so you just snap them together to make any size BMS. When the battery was not charging or discharging, the cell units would go to sleep to conserve power.

The design would be scaleable by using larger, more powerful dissipators. Everything else would be the same.

The hardware layout is pretty straightforward. The problem is software. I know what I want it to do (sort of), but don't have a clue how to program a PIC. Overall, this approach will likely be more expensive than an analog design in terms of parts, but may be easier to produce.
 
"Easier to produce..." is the key, in my opinion. You need to have as few parts as possible. Adding a way to do balancing would make this a real BMS possibility. The LVC portion is easy, even the indication of relative voltage levels. You could have each PIC drive a two-color LED. If the voltage is below a certain minimum, the LED would be red. If it is full it would be green, and would vary from green to yellowish, to red, as the cell was discharged.

-- Gary
 
bquick said:
- Each message would contain a string of battery voltages.
- Each processor would wait for a message, append it's cell's voltage and send the message.
- The last processor (I'll call it the main processor) outputs to the display.
- The main processor then sends a signal to the first processor (one bit, via opto) to tell it to start over.
- The main processor would also start the process if it doesn't receive any messages for a predetermined period of time.
The daisy chain idea combined with a main processor to drive it is a good design. Skip the bus altogether. Also, this allows the system to be essentially turned off when you don't need it. Some sort of "sleep mode" could be triggered by the main processor to conserve energy... or possibly "sleep mode" is the default state and action is only taken as a response to the main processor initiating action.

More like "token ring" than "tcp/ip"...


http://en.wikipedia.org/wiki/Token_ring
 
One processor per cell sounds good, but it doesn't solve everything.

There are both cell level and pack level processes and functions to consider. A cell level processor does not know what the pack is doing - charging, discharging, LV cut off, off, etc - unless it is told. OK, it can work some of it out from current and voltage measurements, but not everything.

So either you need a pack level master controller, or to distribute the pack level functions among the cell level processors. Either way you need a fair level of communications both in and out of the cell level circuits.

Nick
 
Again, I'm more interested in monitoring (LVC) than balancing at the moment, although I understand the desire for a complete package.

I was thinking that if the communication were a complete ring, the master processor could send commands to any of the other processors (or all of them). It would require that the master processor have two serial outputs if we want to drive a display.

For simplicity's sake, I figured that all of the processors would run the same program. The master would have an input set to tell it that it's the master. [EDIT] After looking at prices, it may make sense to use an inexpensive processor on each cell and splurge ($3) on the master processor.

GGoodrum, my first idea was to have each processor completely independent and have it flash LED's at different rates depending on how low the voltage was, but I don't want to have to look at 20 flashing LED's. I want a nice digital display that shows exactly how low my lowest cell is. The self adjusting bar graph is an interesting idea too.

Sleep mode sounds good. I'll have to see what it takes to wake these chips up.

I'm not an electronics guy myself, so it has to stay electrically simple for me to keep up. I've never programmed one of these chips before, but from what I've gathered, it shouldn't be too hard. I already downloaded the tools for the Amtel chips and I can compile the C sample code in Xcode on my Mac. I've done lots of programming, so that's the easy part for me.

- Brad
 
bquick said:
I've done lots of programming, so that's the easy part for me.
Me too. I've got a BS in CS and did the whole dot.com thing and real estate afterwards. Your idea seems good and "keeping it simple" is probably a better way to go.

What would be ideal is to get the price waaaaaay down so that it really competes with the analog approaches. Think "dirt cheap" because that's what you are up against. You can solve the LVC problem for something like $5 per cell using specialized analog chips, so that's your goal to beat... it's not easy...
 
safe said:
bquick said:
I've done lots of programming, so that's the easy part for me.
Me too. I've got a BS in CS and did the whole dot.com thing and real estate afterwards. Your idea seems good and "keeping it simple" is probably a better way to go.

What would be ideal is to get the price waaaaaay down so that it really competes with the analog approaches. Think "dirt cheap" because that's what you are up against. You can solve the LVC problem for something like $5 per cell using specialized analog chips, so that's your goal to beat... it's not easy...
Hey, Safe, you have a BS in BS too, right? :)

One trick to making a microcontroller-based system appear cheap is to give it plenty of programmed features.

Making it field-configurable with a push-button and an LED is often a big win and very inexpensive.


Richard
 
I"m most likely only going to build one of these and use it for myself, so I don't need to squeeze every penny out of it. But I understand that others will feel otherwise.

After doing some research, I've found that we will need a reference voltage that's higher than the cell voltage. The amtel chips have a 1.1V internal reference. So, it looks like a resistor divider system will have to be used. If we have to use the resistors, then we might as well measure multiple cells with each processor. This will cut the cost a bit. It makes shunting more difficult, but like I said, I'm mainly interested in LVC.

- Brad
 
I thought the AtTiny chips could measure via the A/D input directly without any divider. I'll have to check on that.
 
I did some research, and it IS possible to read the Vcc voltage on the Amtel chips. You use Vcc as the reference and the 1.1V reference as the input. From the result, you can determine what Vcc is.

So, one processor per cell WILL work.

I want to use USARTs to communicated between chips to make it simple. The cheapest processor I can find that has A-D and USART is $1.69 (25 pcs). It comes in a 28 pin package. I'd like something smaller, but I can't find a smaller Amtel with USART and A-D.

- Brad
 
bquick said:
I did some research, and it IS possible to read the Vcc voltage on the Amtel chips. You use Vcc as the reference and the 1.1V reference as the input. From the result, you can determine what Vcc is.

So, one processor per cell WILL work.

I want to use USARTs to communicated between chips to make it simple. The cheapest processor I can find that has A-D and USART is $1.69 (25 pcs). It comes in a 28 pin package. I'd like something smaller, but I can't find a smaller Amtel with USART and A-D.

- Brad
With a few ten-cent diodes a UART can be shared among multiple connections. I've seen this done with an inexpensive multi-user computer back when serial terminals were de rigueur.

Richard
 
One important hassle will be resetting and monitoring that each channel is alive and well...
Jeff K. "Deep Cycle" project
 
jeffkay said:
One important hassle will be resetting and monitoring that each channel is alive and well...
Jeff K. "Deep Cycle" project
Nah, just add that to the protocol. Since channels can talk to each other they just need to count how many of their brothers respond. Channels can number themselves. End channels would need to have a jumper or other indicator so they know not to expect input from one end. Easy and cheap.

Richard
 
Hi Guys,

If we are getting away from the original thread title and thinking of Atmel devices, let me add something...

My son and I have developed several systems using multiple small Atmel processors - I do the hardware design and he writes the code. We have variously used three different methods for inter chip comms - custom bit bashing serial interface, SPI and the Atmel TWI (two wire interface), as well as the USARTs for chip to rest of world comms.

All these have of course been with the processors running off the same voltage, or at least a common ground. The TWI works by paralleling up the chip connections and giving each one an address. I'm told it a pain to program. With SPI the devices can in theory be daisy chained in a ring. We've never tried it with a chain of more than 2.

The big problem in the current discussion is that the processors are on different supply rails. I think in this case it may be better to accept that it will end up with custom bit bashing and the first thing to do is to sort out the hardware link.

EG.,
Is it better to do a parallel type connections, or a serial daisy chain?
There are ways of doing a Wire-OR or Wire-AND across different power rails? Is this usable for cell to master signalling?
There has to be better ways than opto couplers.

HTH

Nick
 
Back
Top