Battery Management System

Not as serious as a reprap tantrum, my RS485 bus is not behaving very well. If I terminate it properly, it doesn't work at all, and if I don't terminate it at all, then it works, but charging at more than 10A causes a lot of extra characters to appear. Termination has two functions, first, it absorbs the energy in each character as it hits the end of the bus. Without terminators the pulses bounce off the end of the bus and travel back the way they came, causing interference. The second function of the terminators is to hold the bus in a relatively low impedance state, so any stray energy (say that created by the electric and magnetic fields generated by the charger) that gets onto the bus is absorbed without causing spurious characters.

Without terminators, I'm seeing extra characters, but with a 2 metre bus, I don't have problems with reflections.

So why doesn't it work with terminators? It turns out the transmit enable circuit cannot predict the future. With no cells transmitting, the bus floats, and both wires sit at 0 volts. When a cell enables it's transmitter, one wire rises to about 4V and the other to about 1V. This is how the bus should look when we send 0xFF:

And here is how it looks when the EVD5 sends 0x55:

Note the difference in the first transition, the the inverting line should go from high to low, but it goes from 0 to low. This is because the transmitter is enabled during the start bit, rather than a sensible time before the start bit.

I tried enabling the bus with a very short pulse (arrowed) before sending a character (note inverting is on the bottom trace instead of the top like above):

This almost worked, but I couldn't avoid framing errors -- the receiver sees the pulse and gets confused. I need to wait long enough for the receiver to assume the start pulse was not the start bit of some random character, but the transmit enable circuit times out and disables the bus before this happens.

There are two possible solutions, capacitive termination, and increasing the baud rate. More on this later.

I've been messing around with the BMS master hardware instead of welding stuff together. I'm trying to send a CAN message and, rather than write my own library from the datasheet, I tried to use Microchip application note AN878. It was easy to adjust so it would compile with SDCC but I seem to have found a bug in the compiler.

Because the PIC is a Harvard Architecture CPU, pointers to code and pointers to data are handled differently, which SDCC implements by adding some extra bits to the pointer. Unfortunately it's possible to loose those bits while casting the address of an SFR to a pointer and assigning that to a pointer array element by index.

With the the bits cleared, the write-to-pointer-target helper will do nothing, leaving the pointer on the stack. When it returns, the rest of the code freaks out because it expects the pointer to have been popped off the stack.

The solution (apart from fixing the compiler bug) is to leave out the cast. It seems that assigning an SFR to a pointer array element doesn't actually need a cast.

BAD	pb[1] = (unsigned char *) &TXB0CON;
GOOD	pb[1] = &TXB0CON;

Kevin at Lynx Innovation kindly organised to have my EVD5 Backplane design made. I've stuffed half the components and tested out a few channels and it looks like I didn't stuff anything up too badly. The biggest mistake I made was to specify the wrong hole size for the main header where the EVD5 board plugs in (the rows of white sockets). This is somewhat inconveniently fixed by drilling the holes bigger and then soldering the top and bottom. Drilling the holes bigger destroys the plating on the inside and disconnects the two layers, so you have to solder the top and the bottom separately.

There are a couple of places where I could move traces to increase separation (and reduce the chance of shorts) but otherwise, I'm very pleased. Now all I need to do is order the enclosures and find some elves to assemble everything.

This is my third BMS backplane layout.

• It's too short (I forgot the bms overhangs it's edge connector)
• I'm going to try replacing J101 and J201 with double row headers and put them both on the same end
• At the expense of having all the heat at one end, I clustered all the MOSFETs near their connectors so the tracks don't get tangled
• I haven't attempted to bring the heat through to the back side while still preserving all those tracks running under the MOSTFETs, putting J101 at the other end ought to help
• This would do 10 cells, I'll actually print it 2 or 3 or more up to get management of 20 or 30 or more cells on one backplane

I used kicad to draw the schematic and then do the layout. The last time I did something like this was 10 years ago and the free tools were fairly primitive (and crippled) and I'm very impressed with kicad, it even has an autorouter!. The autorouter only deals with two layers at a time and needed a little help to finish this board, but I can tell you it's really satisfying to see most of the tracks appear automatically. There's even a version for windows!

Bob Simpson designed the EVD5 hardware to sit in the top of a box of A123 cells. You can see this design in action in the background of the photo above, the blocks of cells drop into boxes and the BMS circuit plugs into the green PCB down the side. Each layer of cells is connected together with a thin plate, and a tab on each of these plates sticks out and is simply soldered to the side PCB. The temperature sensors are also connected via the side PCB. The foreground shows what happens when this elegant layout doesn't quite fit -- you end up with a lot of wires. Bob has more electric trail bike construction photos and riding videos on his website.

To reduce the many wires and many fuses problem in my Thunder Sky battery, I am planning on (almost) only one wire to each cell. The BMS is set up for a kelvin connection which makes measuring the voltage easy. Without a kevlin connection, when I turn on the bypass current, the measured voltage will drop (because current is now flowing through relatively thin wires). This can be corrected in software as the voltage drop is purely resistive and won't change very quickly, if at all. We can see in the graph below that without a correction, the measured cell voltage drops 60mV when we bypass 500mA. With correction, this error is only 20mV. I used gnuplot to fit the line to the uncorrected data, and it appears to have given more weight to the low current end (where there are more points) as we have a larger error at higher currents. (I still need to investigate why I'm getting such quantised data)

Unfortunately, with one wire for each cell, adjacent cells share a wire and current bypassed in one cell will effect it's neighbours. Since the slaves do not talk to each other, the master will have to take care of this effect. Internally each cell's slave only uses the voltage reading to implement an antonymous "dumb" balancing. The master will coordinate normal BMS operation, so this won't be a great problem.

I managed to blow up both of my LJTick-RelayDriver boards. These are little boards that plug into a LabJack and allow it to drive relays. Since I wanted to drive a relay to turn the battery charger on and off, I had to investigate. The circuit is quite simple, a ULN2003AI Darlington Transistor array and 3 resistors. R1 provides a return path for the base current by and also connects the relay power supply ground to the LabJack's ground. LabJack's datasheet suggests it should be 10Ω, but on both my units it was open circuit. I guess what happened was I put the relay power across this resistor (perhaps by using the a supply sharing a ground with the computer and connecting it backwards) which would cause a great deal of current to flow. If it was 12V, you would expect about 14W to be dissipated in a tiny surface mount component. No wonder it went open circuit.

I replaced this resistor with a 120Ω 1/2W unit which will still be overloaded by a 12V fault, but will last a lot longer.

Normally I'd use my EVision to measure the charge current, but it needs more voltage than a few cells provide. Last year Vik gave me a few Alegro ACS754LCB-100 hall effect current sensors, so I dug them up and now I'm measuring the charge current. A hall effect sensor uses physics to measure the magnetic field created by a current passing along a wire -- this one is calibrated to produce 20mV on it's output per amp flowing in it's sense wire. I tried 3 sensors and only one of them matched the datasheet. After I'd soldered that one with my too-small soldering iron (which means the part was kept very hot for a long time) it wasn't all that close to specification either. It's response is still linear so I've just adjusted the mV/A value in my code. I'm measuring the signal with my LabJack U3. The code will be in svn soon.

A hall effect sensor is good because it isolates the sensed current from the signal wires. This way I can tolerate one isolation fault between my computer and the battery. If I used a regular resistive shunt, the battery would be connected to the computer and an unexpected second isolation fault could cause potentially damaging current to flow. The low insertion losses of the hall sensor also make the charger's voltage regulator more accurate. The disadvantage of hall sensors is they produce more noise in the output signal than a typical resistive shunt.

Below we see 3 cells being charged. The charge current starts out high, I adjust the voltage control down and we see the current drop as the cell voltage rises. Then I adjust it up a little. It becomes obvious that the green and blue cells are nearly full while the purple cell is not, so I connect a separate 3A supply to that cell only. This increases the total voltage and the charge current drops. The PFC30 voltage regulator seems to cut the charger off completely below about 300mA.

If you have to use compressed air, blow from the solder side through to the component side, not the other way around. Blowing spreads solder everywhere, and doing it from the component side spreads it all over the components. The solder sticks to the tip of a hot fluxed soldering iron, so it's easy to clean the splatter, if you can get to it with the iron. It took about an hour and half to clean the solder off the components shown above. It took about 2 minutes to do the same job on the other board where I blew from the solder side and and the splatter wasn't hidden in all the component nooks and crannies.

My previous attempt at averaging out the charging noise involved taking 10 ADC readings, but at the weekend I learnt that this is unlikely to work -- 10 ADC readings is very quick and my noise is at 50Hz. I'm now averaging for 160ms or thereabouts. Averaging 8 cycles of the noise is probably much more than I need, but it solves my problem nicely. It is causing problems with the scan time.

The firmware is continuously monitoring the cell voltage, and when a request comes in it will have to wait for any ADC averaging that is already going on before waiting another 160ms for a new reading to respond to the request. Since we take two ADC readings to measure the voltage, and we also ask for the shunt current, it takes about 10 seconds to scan 10 cells (I now have two BMS boards up on the bus). I will improve this in two ways, the first is to cache the most recnet values so that they do not need to be regenerated when a request to send them is received. The second will be to interrupt the currently executing ADC reading to return a cached value. It may be possible to do this latter change purely in the receive interrupt handler, if it isn't it will likely involve a significant design change to the firmware's main loop.

The above graph shows quantisation of about 9mV. This is unexpected with so many values averaged. I will confirm the average calculations by streaming the raw data back across the bus. I'm currently running at 9600bps, I may increase to see more of the data. Charging current was between 5 and 10A.

I hooked up my oscilloscope and had a look at the charging noise. My scope is rather geriatric, and the calibration is poor, but for what it's worth, it was set at 200mV/division and 10ms/devision. If we trust this, we see about 250mV of noise at 50Hz (the AC mains frequency here in New Zealand). My previous attempt at filtering the noise out involved taking 10 samples and averaging them and it seems very likely that it failed because it was averaging a different part of a 20ms pulse each time. I don't actually know how long each ADC reading takes (I recall I chose the slowest ADC speed available but what that might be, I don't know).

I think the easiest solution is to continuously measure the voltage in the main loop and store a moving average of many many ADC readings. When a request for the voltage arrives or the internal cell management program needs the voltage, the current value of the average calculation is returned. This reduces latency on the RS485 bus as we don't have to wait a few hundred milliseconds to average out the noise. I will have to be careful that the main loop doesn't run at some factor of 20ms as this would cause aliasing.

You can also see a faint shadow below the main line, this isn't a camera artefact, but whether it's real, I do not know. It's not really obvious in the picture, but it almost looks like a mirror image of the main line. I haven't tried to filter out the 50Hz noise to see if this is some other higher frequency component.

I hooked up the EVD5 BMS to a set of 5 Thunder Sky LFP40AHA cells and did a first charge on them. These cells have been sitting for a little more than a year now, with no charging or other maintenance. I learnt several things.

• Making up wiring looms is extremely tedious, I really envy BMS designs where a board sits on each cell. Bob designed this BMS and he has this problem solved with his A123 packs -- he has a circuit board down the side of the pack connecting the junctions between cell layers to the BMS on top. Sadly prismatic cells don't lend themselves to this approach. My loom has three wires, one for voltage sensing, one for current shunting and one for the temperature sensor (the temperature sensor is only hooked up on one cell). I'm not yet sure if a Kelvin connection is required.
• The quality of your connections matters a lot. While I've got a separate shunting wire, these wires connect on top of the strap taking the full charging current. If the cells charge at 3.450V, and you start shunting at 3.550V, and you're charging at 15A you only need 7mΩ in the strap to cell joint (actually there are 3 joints in the charge current path, so they have to be even better) to make the difference between normal charging and the start of shunting. I could see this by tightening the cell bolts and watching the shunt lights go out.
• The noise problems I reported while charging in the car are still present with only 5 cells. This might be exacerbated by the big ball of wires between the BMS and the cells -- each one acts as an antenna.
• With 5 cells and a constant voltage charger, no intervention was necessary to turn down the charging current, at least during the charge presented below -- it looks like cell 0 and cell 3 might get out of hand soon. I don't yet have the BMS monitor in control of the charger, this will be the next improvement.
• I need to measure the charging current -- when I was charging in the car this was done with my EVision, out of the car with only 5 cells the EVision won't work (it needs 50 or 75V or something to work)
• There is a zero error in the shunt current measurement, this could be the firmware (it recall it doesn't turn down the current shunt properly), but there is a bug in the prototype hardware which certainly isn't helping.

Edward lent me an isolation transformer to make the PFC-30 charger safe. Without the transformer, the battery is connected to the mains and you'll get a shock if you touch it.

The New York Times has a story on International Battery, including a photo of a very clean prismatic cell layout (the little picture on the left, click to enlarge).

The Manzanita Micro PFC series chargers are renown for being noisy. The graph above shows just how noisy. Charging at about 10A starts at 50 seconds and continues for about 180 seconds. Charging resumes briefly at 40A. We can see about 50mV of noise while charging at 10A, and 200mV at 40A. Currently the EVD5 firmware does not average voltage readings, I had similar noise problems using a LabJack with the PFC-30 charger and averaging was very helpful.

The good news is that the BMS didn't crash. The LabJack crashed if I charged at more than 7A, while the EVD5 BMS, even with floating current sensors (I've only hooked up the voltage sense wires, the bypass circuit will come later) was happy at 40A, at least for a short time. I'll test high current more thoroughly when I've packaged enough BMS boards for the whole battery.

See evd5-pfc30.tar.bz2 for the raw data.

Today I finished the software addressing functions in my BMS firmware. I had previously been working with just one cell, getting the basic commands to work. Now I send a cell address and only that cell responds. Without this, all the cells respond at the same time and make a terrible din such that you can't understand any of them. My protocol isn't exactly fancy, but is a pain to type manually, so I wrote a very primitive monitor in C. With a computer sending commands, I found that the slave processors are too slow to keep up while they are actively monitoring the cell voltage, so I had to implement interrupt driven receive and a buffer to store the incoming command until the the slave has finished looking after it's cell.

The above graph shows 4 cells (my power supply only does 15V, which isn't enough for the 5th cell). All 4 cells are being charged at 350mA, and after 1000 seconds, cell 2's voltage hits 3550mV and the BMS starts to discharge that cell (i2 on the graph). The current lines appear to bifurcate because the current control is oscillating. The hardware isn't really designed to control current, I'm running a software control loop to make it do that, and it's a bit finicky. The software tries to keep the current within 50mV of it's target current, but the current control knob doesn't easily give it fine enough control to do that. Basically the program turns up the current, overshoots, turns it down, undershoots and repeats. I'll try a 100mV target next time.

The graph stops because my primitive monitor program detected a protocol error and stopped. The next change with be error recovery.

I expect to be hooking this up to the car and seeing what happens with the PFC30 charger in the next couple of days. Last year I made a simple BMS with a Labjack & a laptop which worked really well with my power supply but freaked out when I connected the big charger. The Manzanita PFC series is renown for injecting a lot of electrical noise into the battery.

See evd5-first-charge.tar.bz2 for the raw data.

My friend Philip had something of a setback in his electric race car project and has launched Tumanako, an open source electric car effort, in the hope of completing what couldn't be bought. I've been working on the BMS as I wasn't happy with any of the commercial offerings -- basically they were either too expensive or too opaque. When we're finished, the Tumanako BMS will provide valuable insight into the health of your battery. You won't one day get a red light and have no idea or information or history about what your battery was doing before something went wrong.

I'm converting Bob's assembly firmware to C. The BMS uses PIC processors and it's been about 10 years since I last played with them. A lot has changed. I've made quite a lot of progress in the last week or so, I

• modified a single pair RS485 - RS232 converter to work with a dual pair network
• made a cable to connect my programmer to the port on the BMS boards
• assembled Bob's original firmware
• wrote a new firmware in C which, so far, flashes lights in response to characters on the RS485 bus

The photo above shows one BMS slave board, capable of monitoring 5 cells, mounted on top of 5 A123 M1 cells in a test rig. The empty looking circuit board is a shunt board which holds the transistors to control the balancing current. The small circuit board with plugs at either end is the RS485 - RS232 converter. I don't have a photo of flashing lights and programming cables for you today, I'm sure if you try, you can imagine something approximating a christmas tree.