A PIC based Battery Management System

[bquick]

I've made some progress.

I breadboarded a two cell circuit where one cell is the master. The master regularly sends a message to the slave to have it send it's battery voltage. The cascading programming is in place so that the slave will send it's voltage to the next slave and so on, but I only have one slave set up currently. When the data gets back to the master, it adds it's own cell's data and displays the lowest cell's data. I had the display working, but I burned it up, so now I'm just turning on and off a LED until I get a new display.

Currently, both processors are running on the same voltage, but they are doing all communication through optocouplers, so I don't see any reason why they wouldn't work at normal cell voltage.

The internal voltage references aren't very accurate, so i have a calibration routine where I calibrate each processor at 3 volts and save the calibration data in EEPROM.

So, it looks like the concept works. It requires for each cell:

(1) ATmega 48 $1.69
(1) Opto $0.16
(2) Resistors

I'm pretty close to wiring up 20 processors.

- Brad

 

[Tiberius]

So, it looks like the concept works. It requires for each cell:

(1) ATmega 48 $1.69
(1) Opto $0.16
(2) Resistors

I'm pretty close to wiring up 20 processors.

- Brad

Hi Brad,

Pretty good, well done. I looked again at the AtMega8 spec. There are protection diodes in place, so I think that if you activate the pullups, you could just AC couple one USART output to the USART input on the other device and get direct serial comms between them.

On the other hand, if an optocoupler is only 16cents....

I'm still worried about sending the info round in a loop through the processors. What if one cell fails and thereby disables the processor?

Nick

 

[fechter]

The internal voltage references aren't very accurate, so i have a calibration routine where I calibrate each processor at 3 volts and save the calibration data in EEPROM.

Yes, that was an issue with the PICs I was looking at. The accuracy specs for the AtTiny 13 were much better, possibly eliminating the need for calibration later.

Couldn't the cell processors share a parallel data bus (via optocouplers)? The master MCU queries each of the cell processors sequentially to get a voltage report. It might make stacking cells easier. I'd still like to know how you wake them up if they are asleep.

Look at driving a shunt transistor/resistor too. You could do a complete BMS. When charging, the cell processors activate their shunt whenever the voltage gets up to 3.65v or whatever the set point is. This could be programmable for different chemistries. If the shunt is activated and the cell voltage continues to climb, then send a signal to reduce charging current. Master MCU can keep track of which cells hit the limit first. When all cells have been at the set point long enough to balance, MCU terminates charging current and signals end of charge.

 

[Randomly]

You are worried that putting all the cell processors in a loop will make it vulnerable to a single failure anywhere along the way. Yet if you have a single failure with a star system you still don't want to run the battery since you no longer have a fully working LVC even though you can still 'see' the other cells. I don't see that it changes the overall reliability of the system no matter how you connect it. You still have to have a processor per cell and data in and out for each cpu and if any of that has a fault the system should disable the pack.

For diagnostic purposes to find a bad CPU or connection in the loop you can implement a long duration watchdog timeout on the cpus. If they do not receive a query from the master processor before that timeout occurs, they wake up and send an error packet. Each succeeding processor passes it along and increments a byte in the packet so the master processor can tell how 'deep' the fault is and which CPU originated the fault. If you know how deep in the loop the fault occurred, you can find where the discontinuity is in the loop.

The only potential liability I can see to a loop configuration is the possible problem of latency, but that is highly dependent on data rate and the number of stages in the loop, and how much latency you can tolerate. If you can poll all the cells once a second that's probably more than sufficient for undervoltage, overvoltage, and temperature monitoring.

 

[bquick]

Yes, you could use a parallel bus or a RS-485 type serial bus, but it would require more optocouplers. Also, I think my method will actually be faster than polling each processor independently.

I had thought about the problem of one processor failing and came up with the same solution as Randomly.

I don't think latency will be a problem. I'm currently operating at 9600 baud, but I may switch to 2400 for reliability. It will probably depend on the reliability of the communication with the display. The first display I got came as a kit that I had to put together. It worked well until I toasted it by applying 12V to the wrong place. The second one came preassembled and I got a lot of data errors using it, so I also burned that one up (not really the reason, but it's better than admitting my stupidity of once again putting 12V where it didn't belong.) I ordered another display with a PIC that runs at 2400 baud, but I can still use my 9600 baud interface board on it as well.

The way my communication works, when a processor starts receiving a battery voltage message from the previous processor, it begins forwarding that message to the next processor, even before it's received all of the data, so the messages are actually overlapping. Using this method, it don't expect to have any problem getting more than 1 reading per second.

- Brad

 

[Randomly]

You may want a CPU receiving a message to buffer it fully before passing it on. When it's done transmitting it's data, put it to sleep. That way only 2 CPU's are awake drawing current at any one time, one sending data, one receiving data. This is assuming it does not increase the latency too much for your design goals. If you are using the transistor level translator circuit for communication your data rate will really only be bottlenecked by Instruction cycle time.

EIA-485 is based around differential drivers which you don't have here so almost none of it actually applies to this application. You also don't need it's tristate drivers because you can wire-or single ended systems. EIA-485 doesn't specify any protocol at all, it's just a physical layer spec.

A simple asynchronous or manchester encoded serial interface seems the best option here. Minimizing the connections seems prudent.

I think you are very much on the right track.

 

[bquick]

I don't see the advantage to having only two CPU's drawing current at a time since each cpu has it's own very large battery. The way I'm doing it, if the data a processor is receiving is corrupted (I'm CRC'ing messages) then the processor simply stops sending the message to the next cell. All receiving processors will time out one right after another with the master being the last to time out and it can record the error if desired. I could alternatively send an error code down the line, but I don't see a strong reason to add the complexity.

On the ATmega48 input pins, you can turn on an internal pull-up resistor. Unfortunately, I don't think I can do this while using the input as the usart receive pin, otherwise, I could save a resistor per cell.

- Brad

 

[Randomly]

yes under most circumstances you have a big battery. I'm thinking of the state when the battery is depleted, you don't want to be draining too much current on a depleted cell since the cell voltage falls so rapidly at the end of the discharge curve. However this may only be a concern in a commercial system where it's possible that somebody would leave a discharged pack without recharging right away, or an almost depleted pack is left unattended for extended periods of time.

It may also be worth putting some attention into getting reasonably even current consumption between cells since you will have to make up any imbalances generated by the CPU system when you balance the cells during charging. That may extend the charging time. At least keep the issue in mind.

The error code idea was just a debugging aid.

 

[safe]

My two cents worth...

If you are using the configuration like bquick is talking about where there is one master and a loop of slave processors attached to the cells then if any one of the slaves fails you have a problem:

What do you do?

One approach is some sort of "intelligent corrective recovery" where you figure out ways to fix problems that might crop up. (like a low battery / failed cell)

But the other option is to simply have a generic "It's Not Working" warning that makes it very clear that something is going wrong.

I'd tend to favor the second more blunt panic signal because it's easier to do in the beginning. You could then in later development projects start to add the "brains" back in so that you could correct most of the problems that come up.

It's always easier to get a limited feature list completed rather than allow "feature creep".

I like the basic idea... one processor per cell... communication in a "token ring" pattern... one master processor. Seems to me you should stick to a "first version" that just does that.

Just get a "Version 1.0" shipped and then start looking past it...

 

[bquick]

A simple debugging trick that I'm using already is to put an LED on each processor. When it receives a message, it flashes the LED. This allows you to visually see the data traveling down the chain.

The sockets I ordered were the wrong width. I tried cutting them down, but it would work better with the proper sockets. I ordered new sockets yesterday. I got them extra long so there's room in each socket for a processor, an optocoupler (or two) and a couple of resistors.

My Perm 132 motor won't be here for another week, so I'll have some time to wire wrap up the board.

- Brad

 

[safe]

bquick

If you have a digital camera you should take pictures as you go and upload them either here or on a build thread in the photo's section. If you start a build thread be sure to post a message about it here so we can find it.

 

[fefifofob]

Howdy ya'll... Been watching this thread to see how things turn out.

I found this app note about measuring individual voltages in battery stacks. I thought some might be interested.

http://www.linear.com/pc/downloadDocument.do?id=25643

 

[Randomly]

Mostly a lot of cut off ears and no Van Goghs. Jim William's (an absolutely legendary analog designer) solution with the transformer isolation sampling is neat since common mode voltage has absolutely no effect on the readings and the current drain is basically none. Resolution also remains high with little thermal drift. But a custom transformer per cell? Not exactly a low volume do-it-yourself type solution.
All the other solutions mentioned try to use some level shifting scheme or complex isolation. The CPU per cell approach I think is better than every other approach listed. The cost is quite low, especially for a low volume production design. It's also extremely flexible and capable of incorporating pretty much any feature you could want in a BMS. By level shifting the communications, you eliminate the need to level shift the cell voltage for reading, or to level shift the drive to the balancing load. Makes for a pretty simple and minimal system. Cheap microcontrollers are a powerful tool.

I remember coming across this app note about 6 months ago, but I tend to be allergic to transformers. However I'm glad you brought it up as it does cover a good number of approaches and their strengths and weaknesses.

For anybody interested in the subject it's definitely a must read.

 

[bquick]

OK, I've decided to scrap my project and start over using separately excited transformers for each cell.

On second thought, maybe I'll continue one. Interesting approach, though.

Here's a photo of my breadboard:



The extra components on the left are for running the display. They include a 5V voltage regulator so that I can run the display off the 12V system voltage. It gets pretty warm. The master controller is on the right and the slave is on the left. They both run identical programs, but the master controller has an input pin connected to ground. To calibrate the ADC, I set the power supply voltage to 3.00 volts and then connect a different pin to ground. Each chip remembers it's calibration in EEPROM. The station on the right is hooked up to the programmer.

- Brad

 

[lawsonuw]

Howdy ya'll... Been watching this thread to see how things turn out.

I found this app note about measuring individual voltages in battery stacks. I thought some might be interested.

http://www.linear.com/pc/downloadDocument.do?id=25643

here's an awful small 1:1 transformer a surface mount transformer No specifications on how much common mode voltage it'll take though. Lots of others in the catalog too.

Still, one microprocessor per cell would have less parts, AND a good chance of having a lower total power consumption. All the transformers and multiplexing chips have to get power from somewhere. With a battery powered system power has to come from the battery period, no trick the BMS circuit pulls will change this. (short of adding another power source. Solar powered BMS anyone?)

Marty

 

[Randomly]

The transformer approach I'm sure was driven by the design constraint of dealing with Battery pack voltages in the many hundreds of volts, Electric car stuff. It also seems to be tilted toward high volume production where tooling costs can be amortized. A key sentence in that App note
"Accuracy is critically dependent on transformer clamping fidelity over temperature and clamp voltage range. The carefully designed transformer specified...."
So not just any transformer will do, it not only has to have the voltage standoff rating but the magnetics needs to be carefully tailored to the specific task.

For pack voltages under 100V there are clearly better solutions.

 

[Tiberius]

Interesting idea, though.

Each measurement puts charge into the cell, rather than taking it out. So why not beef up the pulse and the transformer and then you have a way of charging the battery while monitoring each cell?

Nick

 

[Randomly]

Yes it's certainly a possible way of balancing the cells, but trying to supply significant charging current would require bigger cores, take up more space, and may get unwieldy with large cell stacks. It does seem like a completely viable way of cell balancing, but doesn't make sense for bulk charging.

good observation.

 

[bquick]

I have a charging question for those of you with battery knowledge:

I have a 64 volt nominal LiFePO4 pack. I'll need at least 72 volts to get 20 cells to 3.6 volts. If I have some sort of smart balancing resistor on each cell and I can turn off the power supply when charging is done, can I use an 80V unregulated supply?

I'm thinking of something like this:

http://cgi.ebay.com/80V-10A-24V-1A-Power-Supply-Rutex-CNC-Motor-Driver_W0QQitemZ270186852138QQihZ017QQcategoryZ11772QQrdZ1QQssPageNameZWD1VQQcmdZViewItemQQ_trksidZp1638Q2em118Q2el1247

I obviously don't want to leave the power supply connect after the pack is charged, but If I cut the power supply off, is there a problem with this? I'm thinking that I might not get as full a charge as if the power supply hovered near 72 volts and trickled the current in slowly.

- Brad

 

[Randomly]

You need a supply that has current limiting or you'll overheat it. I don't think that supply is current limited. The idea should work , although you won't get a full charge without a CV charging stage, but you may get pretty close.

 

[fechter]

Depending on the current rating of the supply, you may need to put a big resistor in series with the supply to limit the current. Somewhere around 1 ohm.

 

[tomv]

My own project to build BMS ended at the security checkpoint in the airport. The comment was "now this looks like a bomb!". I got dragged through every imaginable search and check and lost my two precious Arduino boards + all circuits I've built. Apparently I'm lucky to not have been charged with carrying "Hoax device" which has up to 5 years of federal prison term. Note to self: don't carry your own circuit boards in carry on luggage no matter how valuable they are.

More on topic, as some of you are close to buying parts/building, take a look at Atmega406 - it's specifically designed to handle 4S lithium packs and Atmel provides reference design/software code that saves tons of time. Their balancing uses MCU itself, so that might need to be beefed up, other than that it's instant solution. I'm thinking to give it a try next time I get around building BMS. Tiny packaging is both advantage and protyping problem.

 

[Tiberius]

Hi tomv,

The way airport security works is weird. I posted somewhere else on the forum about the fun I had taking a headset and lifejacket through one day. But that was many years ago, before the current paranoia.

Recently, though, I got stopped with some prototype boards in my carry on luggage at a European airport. They insisted on taking them out and running them through the x ray machine individually. Then I was allowed to go. I've always found that a business card that says something about electronics helps.

Nick

 

[bquick]

I hooked up a darlington transistor and some ceramic resistors to my circuit last night and was able to trigger it with the processor to draw an amp. I was a little concerned about putting these in the circuit because I was afraid of a processor malfunction turning it on and draining a cell to zero, but it looks like it turns itself off when the voltage gets down to around 2.5.

I'm thinking the logic would go something like this: When in charging mode, once the cell voltage gets higher than 3.2 volts, turn on the shunt with a duty cycle proportional to the difference between the cell's voltage and the lowest cell's voltage, with 100% duty cycle at a .2 volt difference.

How might you change these numbers?

- Brad

 

[Randomly]

I think it will depend a lot on your ability to get rid of the heat from the balancing. 1 amp means up to 3.2W for that particular cell, with a lot of cells you may have some difficulty dissipating the heat depending on how it's all heatsinked/ventilated. The actual algorithm you mention sounds workable, I think you should try it out and see how it behaves in a real system.

Remember heat is the bane of lithium cells. Charging them at temperatures above 40C and the cycle life starts to drop. Over 60C and the cycle life just plummets.