A PIC based Battery Management System

[dirty_d]

bquick, i wrote a similar program for an atmega168 for a RC lipo charger, i never actually built the charger though since i haven't really used the rc plane much and i have a cheap charger that works fro now. i did the balancing pretty much the same way as you except that the shunt is just always on for the highest voltage cell in the pack if the difference between cells was greater than 12mV. but it seems like this isn't the ideal way to do the balancing, GGoodrum posted part of his BMS on page 10 of this thread, once the cell voltage reaches 3.65V the shunt turns on and bypasses some of the charging current, then a signal is sent to the charger to lower the charge current to an amp or so, the shunt just bypasses enough current to keep the cell at exactly 3.65V until the current through it drops to 100mA through each cell, then the pack is done.

it certainty is cheap

 

[peterperkins]

Nice to see lot's of progress on this thread. I certainly don't claim to be a programmer but here's my latest updates. Great to have so many contributors. :wink:

I'm not ignoring the helpful replies directed at me, thanks I've been on hols and am trying to do the PCB's myself to learn!! If it all goes t*its up I'll come back to the group about that!

Yes I do need to include a series resistor in the load transistor base prob 220R or similar.

Looks like a number of us are working on very similar ideas. 8)

Did a fair bit on Master software last night. Not quite ready to run but not far off. Should have a workable version ready by the time I have my boards built and cells arrive. I currently have one prototype master and a single slave on the bench talking over an opto isolated 2400 baud link, I calculate approx one second to receive word data from my 50 cell pack.

http://www.solarvan.co.uk/MASTER010708.txt
http://www.solarvan.co.uk/master260608.jpg

http://www.solarvan.co.uk/SLAVE010708.txt
http://www.solarvan.co.uk/slave250608.jpg

 

[safe]

I still have to say that this is a great idea. I'm looking forward to seeing some data about how it's working in practice. Be sure to add photo's too.

 

[bquick]

I hope to have mine ready for testing this weekend. I finally got the motor for my bike, so I've been spending my time getting it on the road. I'm riding it to work now and everything is going well. I now need to get my board working so I can monitor my voltages.

I found out that the voltmeter I was using was off by .6 volts, so I have to re-calibrate all of my processors.

I finished soldering up my board last night and wiring in connectors. I have to figure out how to mount it on the bike.

I bought (3) 24V lead acid battery chargers from EBay and put them in series to charge my 64V pack. They are supposed to put out 5 amps, but when I hook them to my batteries, I draw 9 amps and the chargers get hot. I turned the output voltages of the chargers down to give a total of 73V output, but they still draw too much current. Do you suppose the internal resistance of my pack is too low? I expected the output of the chargers to be regulated, but maybe not.

- Brad

 

[Tiberius]

I bought (3) 24V lead acid battery chargers from EBay and put them in series to charge my 64V pack. They are supposed to put out 5 amps, but when I hook them to my batteries, I draw 9 amps and the chargers get hot. I turned the output voltages of the chargers down to give a total of 73V output, but they still draw too much current. Do you suppose the internal resistance of my pack is too low? I expected the output of the chargers to be regulated, but maybe not.

- Brad

The problem won't be the battery resistance, that will always be too low to regulate the current. Lead acid chargers vary in their sophistication. A a good charger will have some form of current control and voltage control. The really simple ones just give the battery the rectified AC waveform and let the combination of voltage and power supply internal resistance sort it out. You will need to turn the voltage down lower still, or add some series resistance.

Nick

 

[Tiberius]

Hi Guys,

We seem to have both Atmel and PIC solutions being debated and pursued here. Maybe a better title would be "One processor per cell BMS".

Anyway, it strikes me that one of the crucial things will be to get the hardware counnt per cell as low as possible. I think someone back many pages ago worked out that one out of the Atmel or the PIC worked much better than the other for accurate voltage measurement with a simple circuit - or did I dream that?

Nick

 

[Tiberius]

OK, re my above question, I just found this from Brad. Is there a simple PIC solution too?

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

Edit: Apologies for 3 posts in a row.
I'm not really talking to myself........

 

[fechter]

Right. One possible way around this would be to use a cruder communication method.

For example, you could use an AtTiny13 on each cell with an optocoupler to send cell voltage status. Maybe not exact cell voltages, but whether the voltage was within a specified range, more like what we're doing with the analog approaches.

Other than a 'cool factor', there may not be much value in knowing individual cell voltages. You would want to be able to identify a weak or bad cell and control the charging current and trip the low voltage cutoff.

Perhaps there's a way to program the code to emulate a UART without actually having any hardware.

 

[dirty_d]

the only problem with using the internal 1.1V internal reference is that it can vary from 1.0-1.2V so its not very accurate at all, it even changes a little depending on the voltage VCC is at. they're should be some voltage reference ICs that are cheap.

$0.75, 1.0V, 0.35% tolerance
http://www.analog.com/UploadedFiles/Data_Sheets/ADR510.pdf

 

[bquick]

I figured if I could get a processor with USART for $1.69, why struggle with a primitive communication method.

I have found that using the 1.1V reference isn't all that reliable by itself, but I'm using a calibration routine where I set the voltage to 3.00 volts, trigger an input on the processor and the processor averages 3000 readings and remembers it's calibration in eeprom.

Using this method, I think I can get reasonable results between 2.4 and 3.6 volts, which is the area I'm interested in.

- Brad

 

[peterperkins]

More updates

http://www.solarvan.co.uk/Master030708.txt
http://www.solarvan.co.uk/Master030708.bmp (One circuit per system)

http://www.solarvan.co.uk/Slave030708.txt
http://www.solarvan.co.uk/Slave030708.bmp (One circuit per Lifepo4 cell)

Ref the PIC (Picaxe in my case) measuring it's own Vcc (supply V or cell), you do need an accurate V-Ref to compare it to, I am using a 1.25v lm385.

The result of the V Ref adc conversion changes as the Pic supply varies. But I use the following integer maths correction code to give me the right result. It is accurate to about +/- 25-50mv which is fine IMO. Lithium cells are a lot more rugged than most realise. Accuray to the nth dgree is not reqd IMO.

symbol CellVoltage = w0	    ;w0=Corrected Cell Voltage 
symbol RefADC = w1		    ;w1=Raw Adc input data variable 0-1024 10bit
symbol RefVADC = 1279 		;RefVADC = Fixed Reference voltage * 1023 (1.25 * 1279)

`Measure lm385 1.25v voltage reference
	readadc10 2, RefADC


`*25/25 to improve integer math accuracy +- 0.02 RESULT is * 1000

	CellVoltage = RefVADC *25 /RefADC * 100 /25

'To display on Picaxe Lcd display AXE033 
	b10= w0 / 100 'Integer Math drops all values in the decimal portion of the result.
	b11= w0 // 100 'Note:- Modulus command does not display leading zeros.
	If b11 < 10 Then: let b11 = "0" :EndIf
	serout Lcd,N2400,(254,128,"Supply V ",#b10,".",#b11,"  ")
	serout Lcd,N2400,(254,192,"Raw ",#w0,"  ")

 

[Tiberius]

Brad,

Which Atmel device are you using? Some of the ones with USARTs don't like low voltages.

Peter,

The PICAXE looks interesting, what's the serial comms facilities on it? I can't find a proper datasheet describing the hardware - do you have a link to one?

Nick

 

[bquick]

I'm using the ATMega48. The one I'm using works down to 1.8 volts. I'm able to keep everything running (including communication) down to 2 volts. My display runs off the vehicle's main 12V supply.

- Brad

 

[peterperkins]

Peter,

The PICAXE looks interesting, what's the serial comms facilities on it? I can't find a proper datasheet describing the hardware - do you have a link to one?

Nick

http://ww1.microchip.com/downloads/en/DeviceDoc/41211D_.pdf

I am using 2400 baud serial comms for my system, it can scan 50 cells per second approx.

 

[Tiberius]

Thanks Brad and Peter,

I will inwardly digest those. Searching for PICAXE on the microchip website drew a blank.

Nick

 

[bquick]

I went for my first couple of test runs with my board on my bike.

Unfortunately, it seems that there's enough noise in the system to cause problems with my processors. It seems like the processors are starting execution at random spots. The display will go into self test mode, which is usually activated by a jumper. When I'm done, some of my processors will have re-calibrated themselves. The only way I can figure this would happen is by random code execution.

Interestingly enough, the ones that re-calibrate themselves are in the center of the chain, which would be the ones at the bottom of the stacks (I have two stacks of cells.) These are also the cells physically closest to the motor (one inch away). So, they may be getting bombarded with noise from the motor. Maybe I should try wrapping the pack with aluminum foil?

Is there a simple way to filter the wires feeding the processors?

Anybody have any ideas?

- Brad

 

[Randomly]

Tracking down and dealing with noise can set you adrift in a sea of engineering weirdness. Could you possible repost your schematic and I'll try and make some suggestions as to where to look and possible fixes.

Off the top of my head if you are getting weird code execution then the supply to the CPU isn't stable enough. You need to decouple it from the battery. If the current drain is low a simple RC may suffice, if not you may need to put a voltage regulator or filtered buffer in there. Fast rising edges on the supply rail can cause all kinds of havoc with CPUs, resetting them etc.

Another potential problem are I/O lines getting spiked outside the positive or negative rails. This can inject current into the substrate and cause untold weirdness. Series resistors to limit current into the I/O pins and/or clamp diodes to the supply (preferably schottky) can protect against that.

There are a number of other places for gremlins to inhabit, repost your schematic and I'll take a look at it.

 

[Tiberius]

Hi Brad,

What's your construction technique for the on bike trial? I think I saw a picture of a breadboard with push in wires.
If you have the BMS and the battery pack separated, with long wires from each cell, then its possible that the wires may be picking up electrical noise.

Nick

 

[Jeremy Harris]

Nick,

I've used the Picaxe quite a bit. It's dead easy to use, the only real shortcoming is that it's a bit slow. Underneath the Picaxe code, the chips are just ordinary PICs, custom coded with the operating system by Revolution Education. The full description is on their website, with downloadable manuals, here: http://www.rev-ed.co.uk/picaxe/. What they are really good at is interfacing to the outside world with simple code.

I built an air speed indicator unit using a Picaxe 08M, one of the really cheap 8 pin ones, and managed to implement the interface to a pressure transducer, the code to square the input, an analogue voltage output proportional to airspeed (using pwm), plus a serial data output to go to a logger. All told it was a couple of dozen lines of code.

Jeremy

 

[bquick]

Yes, I do have long lines going to each cell.

I'll have everything working fine, but when I twist the throttle, I get an initial "bump" before I get smooth acceleration. When the bump happens, the processors go wild.

I did some testing yesterday and I may not be executing random code (although I still may be). It's looking like all of the variables, including the inputs are getting set to 0xFF. This triggers my code to re-calibrate the ADC. I'm going to re-structure my code today to see if I can't get it to fail in a desirable manner.

- Brad

 

[lawsonuw]

I'll have everything working fine, but when I twist the throttle, I get an initial "bump" before I get smooth acceleration. When the bump happens, the processors go wild.

That sure sounds like the power supplies to the PICs are browning out or otherwise going crazy during that initial hit from the controller. I've used a diode-capacitor combo on the power supply to ride through drop outs like that on a previous project.

Marty

 

[hardym]

Only a little related to this thread, but I've opened up a EM-929L battery pack that is being sold on the surplus market. http://www.73.com/a/0696.shtml
It is supposed to have 4Px4S 16 ICR18650, but has some korean make instead.

Most interesting are the chips inside:

It has a PIC16C72A processor (it was built in 2002, this processor is not current).
MAX 1414C instrumentation A/d with a real-time-clock.
Ti bq2060A Power Management IC
And a lot of TPC8103 FETs, usually in pairs.

After scanning the TI bq2060A manual, most of the heavy battery management work is done in this chip.

Pictures are here:
http://www.batteryvehiclesociety.org.uk/forums/viewtopic.php?p=9537#9537

Mark.

 

[bquick]

I did a bunch more testing today, but I'm still not getting favorable results.

I first removed the board from the bike to make sure the processors weren't getting directly affected by radiation. With only the battery and control wires connected, it went haywire when the throttle was bumped.

I then discovered that the "fuses" for the processors can be set to offer brown out protection. I set these fuses as well as one that keeps the eeprom memory from being reset when the chip is programmed. Unfortunately, these had no effect. Some of the processors still lost their calibration (which is stored in eeprom). It's interesting that the program doesn't get trashed, which is also in eeprom. It still may be that I'm executing code randomly.

Now that I have them set to now clear the eeprom memory when they are programmed, maybe I can remove the calibration code from the program to see if they recalibrate themselves without the code in the program to do that.

It's OK with me if they temporarily stop working as long as they recover gracefully.

- Brad

 

[Tiberius]

Hi Brad,

Brownout, or similar problems from power supply variations can be a big problem unless the processor actively protects against them.
I'm not a software guy; I do sparkware rather than hackware or wetware, but I often end up in the project manager role and therefore having to sort out which department owns the problem. One of the biggest project failures I had to sort out was down to brownouts. One of the bought in circuits had been extensively tested and guaranteed but failed when we used it in anger. It turned out all the supplier testing had been done with it constantly powered up, but we were powering it down between operations. About once every fifty cycles it erased part of its memory.

Nick

 

[Tiberius]

Have you seen this one?

ATmega8HVA - processor designed to monitor 1 or 2 cell Li-Ion
http://www.atmel.com/dyn/products/product_card.asp?part_id=4325

Nick