BMS simulation

Capture d'écran de 2016-03-04 14:49:15

How to make a BMS simulator to test the AVR program? I wanted to keep the original AVR sources but test them as a linux app. I decided to separate the hardware and pure software sides of the BMS program. I modified the source code such that everytime the hardware is used, it is through a C function with no hardware includes. Therefore replacing the hardware C function calls to software C++ simulations and calling the state machine in a loop makes a simulator. I needed to add a graphic view of the battery packs (made with the SDL2 graphic calls) and voilà.

The BMS has a USB serial port to be able to update firmware and to communicate the battery information. This could be simulated with the tty simulator interface included in Linux. But I stayed with my first idea of using a named pipe. Because when created with mkfifo, you chose the name of the pipe, no need to pass it to the second app. I just needed two named fifos in /tmp/, one for each direction. I implemented them in a child class of the serial communication class. In that way the “BMS manager” app can dialog with the simulator or with the real hardware with the same functions.

Simulation speeds up the development process. Because it is easier to recompile and run from the PC than having to turn on and off switches on the battery pack test setup. I had a ton of bugs and still have to clean shit. I prefer bugs in the simulation than fearing of a balancing error killing batteries on the real hardware.

As you can see on the picture, the simulator allows to plug/unplug the charger, run/stop the motor, and change temperature. It is easy to check the diverse safety cases.

The GUI is coded with FLTK. From the internet pages about FLTK it looked like it only suports OpenGL 1.5 but in fact I ported the 2D drawing library using OpenGL 2.0 from Scoreview and it worked fine. So FLTK has this common point witht he SDL: it gives an OpenGL context directly.

And finally I burnt my 2 AD7280A, when installing the board on the test battery pack. I had reverse currents going up the AD7280A  and down to the µController (confused a via silkscreen circle with the 1 pin dot and mounted the ships with a -90° angle). I changed the design anyway, the fact that it is powered by the battery itself makes subtle changes from a standard design for a car.

 

Lithium batteries voltages.

I am working on a golf cart modification for lithium batteries for the go-lithium company in Romania. Two things are annoying with the lithium batteries:

  • if you go out of the specifications (temperature/current/tension) you destroy them.
  • measuring the sate of charge cannot be based on voltage unless you have a precise model of each battery and a temperature input.

In this article I will discuss the battery voltage behaviour on LiFePO4 batteries. And the consequences on the development process.

Encountered phenomenon:

When you charge, the electric tension is higher than at rest tension (say 39V against 37V in my example) and when you stop charging, it will slowly go down to a rest tension (37V) during approximately half an hour. But when you start using the battery pack, it will go down to the lower value (say 33,2V at 200Amps). The drop in tension is proportional to the current used, the more current used, lower the drop. But when you stop using current it will NOT return to the rest value found one hour after the charge. During 20 seconds after use, it will go back to another rest tension (say 36V) with a logarithmic curve shape, this is the “relax” time. And more over, all the measured thresholds will also change with temperature. (you can find a graph explaining this behaviour in Texas Instrument’s SLUA450 pdf document ti SLUA450)

So if you want to use the tension for balancing or you want to use the voltage measurement to know the State Of Charge, it will not be easy to calculate nor reliable. Unless a test bench is used to make a model. But even with a test bench, how to be sure that it will behave the same model after many years. And what if the chemical formula changes at the factory?

Knowing the SOC (State Of Charge) can be done with current measurement. Using a shunt or a hall effect current sensor and counting down micro Amp/Hours from a full charge value. The SOC problem can be solved with current measurement and Coulomb counting.

However for simple passive balancing you have to use the voltage measurement during the charge. But when stopping the charger for a wile to do passive balancing you will face the fancy capacitive behaviour of lithium batteries. And the reference tensions taken before stopping the charger will mean nothing after 2 minutes of balancing. Voltage will drop faster at the beginning of passive balancing and maybe go below the lowest battery.

This behaviour pushed me to create a simulator for the micro-controller program. And I believe that the simulator spares me a lot of error and trial. In fact it speeds up error and trial. I can test charge and discharge at high currents and test current protection without raping the pack. I can test the balancing algorithm at hight speed by skipping frames on the simulator.

Actually I am in the process of simulating the behaviour of the LiFePO batteries. It implies a state machine, and Vbat functions depending on time since state transitions (states like: charging, charger_stoped, running, relax…). I believe that otherwise, the design of advanced algorithms would be a nightmare.