Battery Management System

I've been fairly quiet recently, mostly because I fell off the blog wagon after going to Samoa on an olpc jaunt (see our report for details).

I have been making slow progress on the EVD5 BMS. I fixed no less than 5 bad joints in my backplane arrangement (I specified the wrong size hole and ended up drilling them bigger and soldering the top and bottom, but not so well) and have the BMS behaving well on my 36 cell battery.

I haven't implemented the necessary code to deal with voltage drop in the wires while shunting because I'm going to get rid of the wires. The wires are a disaster from a safety and construction point of view. Constructing the wires out of ribbon cable with soldered in fuses takes a very long time and I've already had to replace two blown ones (don't know the cause). My earlier backplane design packs too many boards too close together and makes me nervous.

Removing the scary difficult wire while keeping the 5 cell EVD5 BMS is possible, if you make a backplane like Tritium's IQCell system. The squiggly bits in the circuit board will allow the cells to move as the car jiggles down the road. The problem with this is that the EVD5 has an awful lot of wires to each cell -- temperature, sense, shunt+ and shunt- and I'm having trouble getting them all through the squiggles. It's worse if I want to mount the shunt transistors away from the main EVD5 board. You'll note that Tritium's hardware is a lot simpler than the EVD5, this comes from more R&D, when Bob designed the hardware (in 2007!) it was much less clear what was needed, so he designed it to be very flexible.

Its fair to say that the EVD5 isn't really suitable for prismatic cells and while this is true, it isn't a really a fair criticism as it was never designed for this purpose. It was designed for Bob's particular cylindrical cell construction.

I've put together a schematic with only 3 wires to each cell and none of them carrying current by putting the shunt transistor at the cell and only passing it's gate back to the central EVD5 board. To control current, I abandon the current sensing system in the EVD5 and add a series resistor. I haven't yet done the layout and seen if this works better -- thinner and one fewer wires isn't all that compelling.

If you've been watching the commit log, you'll see I've made a fair amount of progress with the software, with a bunch of small improvements to the laptop based monitor and better use of the LEDs on the EVD5 board.

I also found another hardware bug, the reset line on U10, the 555 timer in the RS485 section is floating. This is a FET based part and it doesn't take very many electrons to reset the timer and stop communications. With this line tied high, I don't have problems with the software addressing any more.

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.