Low cost / High performance universal BMS
 

Hi all,

As I said on the Paul and Sabrina AC controller topic, I developped a distributed battery management system to monitor lithium cell battery pack.
This BMS is based on the distributed technic, a small slave board is mounted on each lithium cell and monitor its voltage and temperature. All the small slave boards are connected each other with a single wire, and a BMS mother board can read in real time temperature and voltage of all cells. Each cell is numbered, so it's easy to preciseley monitor all cells.

I primary developed this BMS for my private use, and because I am perfectionist it was very interesting for me to try to optimise it again and again. I don't know if you know the Guillaume Apollinaire citation :

If I try to translate it gives :

So I think I am close to the perfection, because now it will be very difficult to optimise the BMS slave board ;)
The board is very small, 28x24mm, but reliability and measurement precision are high (I use a 0.25% voltage reference).
So I asked myself why not sell it ? Thus I hardly worked on industrialization to optimize this time the production process, and now I think I can propose very interesting price. Price calculs are not definitively adjusted, but normally I can reach approximatively 12$ for the slave board, for low quantity ordering. For high quantity ordering I think I can decrease slightly.
This price is for local production, boards produced in France, by a manufacturer within 100km from home. It's very important to my eyes, to be sure of the production quality.

Now let's talk about the BMS slave board itself !
I begin with a photo where you can see a similar product from Elithion. But It have some flaws, I can list them if you are interested !

http://chaenel.free.fr/images-forum/element_bms_2.jpg

- Size :

As you can see, my BMS slave board (in the middle, printed at 100% scale), is very small, even smaller than Ethition board, which is already small ! My board is 24x20mm (0.945x0.787in).

- Temperature :

The thermistor is at top left angle of the board, and a milling in the board permits to increase the thermal resistance with the rest of the pcb.
Thus you can directly stick the BMS slave board on the cell, with an optionnal drop of thermal paste under the pcb at the thermistor place to optimise the thermal conductivity. With high thermal resistance between the thermistor and the rest of the pcb, it can detect quickest temperature evolution.

But the milling also permits to directly plug and solder "a pod?" at the left of the board, to connect to the negative electrode of the cell, as the elithion board. In this configuration, the thermistor has a very low thermic resistance with the pod and then the electrode/busbar, then you can easily detect a bad busbar/electrode connection with temperature elevation during high current.

The resistance measurement of the thermistor is approx 1%, and the embedded thermistor precision is 5%.

If you want to do the temperature measurement in a special location of the cell where you cannot put the slave board, I integrated the possibility to deactivate the on board thermistor and solder your own thermistor with longer wire, to place it where you want.

- Voltage

The slave board can measure cell voltage in the 2V-5V range. The voltage reference used has 0.25% precision. The analogic to digital converter is 10 bits, where the Elithion board is 8 bits, so with 10 bits the resolution is 4 time better.

- Wiring :

Board can be used as is, with direct wire soldering to +/- electrodes and previous/next cell, or a "pod" can be soldered directly on the board for direct mount on negative electrode, and screw terminal can be mounted to offer easy wiring for next/previous cell or mother board connection.
Each cell is connected each other with one wire, and first and last cell are connected to mother board. These first and last cells are special but are the same as the other, with just an additionnal optocoupler mounted on the board. Thus there are only 4 wire between mother board and battery pack.

- Security

The 4 wire between mother board and battery pack are completely isolated from the pack, to respect total galvanic isolation in the case where the traction parts are completely isolated from the vehicle low voltage domain.

- Balancing

I integrated a balancing of 200mA @ 3.6V and then approx 233mA @ 4.2V (18r resistance). Balancing can be started ON/OFF by the mother board, permitting to optimize balancing algorithm if needed, and thus not just activate them when the cell reach max voltage, which is a terribly bad algorithm if the charger is not able to lower its current under the balancing current value !!
I integrated the possibility to add an external power resistance for those who want a bigger balancing current, with big and very accessible pads for easy soldering. Also, there is a timeout in the slave board, if balancing is not set to off after a period of time, it is set to off automatically, in case of communication loss with mother board for example, to not completely discharge the cell.

- Firmware

If firmware is updated because of a bug or an additional feature, you can flash it yourself with a very low cost PIC programmer, without remove boards from the pack (just take care that the programmer is the only thing connected to the vehicle).

- Protocol

Because these BMS slave board needs a mother board to take decision (stop discharging, stop charging, display info,...) or manage the datalogging, and because the mother board development is not finished from my side, I took the decision to open the protocol to anyone, to communicate directly with the BMS slave boards and easily get the voltage/temp of any cell or set on/off the balancing of any cell, with any electronic device having an available RS232 port. Thus it can be a 8 bits micro-controller or a multi cores computer !
I will also provide the interface board and the schematic of the interface board to communicate with the cell slave with direct connexion on a RS232 port.

- Installation/configuration/debugging

As you can see, wiring is easy and clean. Configuration is also easy because....there is no configuration ! With the protocol I designed, cell addressing is automatic, you just get a dataframe with a header and data blocks, where each 5 bytes data block corresponds to a cell, from the first one to the last one. Also, a checksum permits to be sure data are not corrupted.

If there is any problem in the slave board daisy chain, the entire chain will be stopped, thus you can detect immediately there is a problem somewhere (you don't receive the frame answer form the pack). And because there is a led on the board which flash on each voltage/temperature frame request, and the frame request pass through all slave boards, you just have to look where the chain is broken because the led doesn't flash ! If just 3 leds flash, thus the problem is on board 3, board 4, or between the board 3 and 4 (wiring). World speed record to find where the problem comes from ! :p

As you can see, my message size is inversely proportional to the size of my BMS slave board :D
I think I don't forget anything, and I hope this message was not too soporific, you can wakeup now !! :D

nlc-

My ev is powered by lead-acid batteries, so I'm not up to speed on battery management systems, but my day coming - I will be sure to follow this thread! I love your quote from Apollinaire!

Can you explain the operation of the BMS a bit more? You can handle charging protection with the voltage sensing, but how do you handle discharge protection?

I'm already listening to this new thread, lets see the mini beast at work!!!!!

No problem !

Actually, the part I developed, thus the BMS slave boards,are just slave which measure voltage and temperature of cells, and send theses measure to a master (I call it mother board but master boars is a good name too).

The job of the master board is to request voltage and temperature of the cell from the slave, and take decision :
More important decision for example is to tell the charger to pass to low current charge mode for balancing, completely stop the charge, tell controller to stop discharging the pack (at a first low voltage threshold for example), and why not cut completely the power by opening the main contactor at a second lower voltage threshold.

From my side I have not finished the development of the master board, because I want to take time to really think it to be perfect for EV usage.

But because these slaves modules can be used as is with any device which have a RS232 port, with a very simple electronic interface, I think it can be useful for any DIY guy which want to closely monitor its lithium pack, why not do datalogging and so on.

I like the system, but I see a problem with only using voltage for your discharge protection. From my experience with the PHEV kit on my Prius, the variance in load and temperature drastically effect the voltage sag. Using at least a set voltage is not going to work. However, if you have enough data to create a variable voltage cutoff based on load and temperature that could work.

What I have done with my BMS system is I have used a current sensor to count how many amp hours have been used out of the batteries. I don't think this a great way to do it (peukert effect obviously effects even lithium chemistry), but its the best thing I've come up with.

You are right, but the job of the slave board I presented here is just to measure temperature and voltage of each element, and inform the mother/master board. The current measurement (which is mandatory to have a good management system) is the job of the mother/master board, which can do SoC and display it on a screen if necessary. The master board + slave board permits very modular system, because for example if you want to increase you battery pack voltage, you juste have to add slave board on the pack to monitor the new cells you added. You goal is here, modular system with illimited number or cell, and maybe different mother board depending on the user needs (complete SoC system with display, just datalogging of voltage/temperature of each cell, etc...)

But from my side the master board is not ready for now, but my idea was to propose the slave board alone for now, because with the open protocol I give they can be used by DIY guys with they own developments, to do a complete BMS system (the complicated part is to measure voltage and temperature of the cells, not pilot relays/contactor to start/stop charge or decharge, or measure current, etc...), or for example juste do precise monitoring and datalogging of the cell voltage during charge and decharge, and so on.

In my section "Installation/configuration/debugging" I forgot to say that the entire system can be tested before installation on just one element (or variable power supply). Just need to wire all negatives and positives poles of the slave boards in parallel on the same supply, and wire normally the daisy chain between slave board. It's possible because I designed the electronic to have the communication between slave board working even if slave board are on same ground potential (not possible on Elithion for example).

Very useful to simulate a true installation without having multiple elements en series, but just one power supply. Thus it also permits to verify that all slave elements gives exactly the same measured voltage and then precision is really in tolerance.

For the price, I just received a new quotation for the board manufacturing, within 60Km from house this time, very good new, it is less expansive than the first, and now I can propose the slave board for ~10$ !

Daox, I looked your link about your BMS. Typically, if you just add a very simple interface on an availlable RS232 port of your arduino board, you can be able to directly receive all the measured voltage and temperature of all the cell. Useful to do datalogging, monitor the cell voltage evolution associated to current, etc...
Or simply manage correctly the balancing function with activation of cell balancing with anticipation.

Oups !! I had not watched the change rate euro/dollar from long time, in fact 9€ is 12$ !!

Looking pretty good so far, sounds interesting. Hope you can make good progress on the master board.

For the master board, I continue to think about it, to be sure it will be usable by all DIY EV converter. In fact, for now I hesitate into 2 different concepts :

- The mother board is a BMS and nothing else, with ability to set on/off the charge, alert user, measure pack current, print info on pack SoC, manage the main power contactor (and the precharge) on ignition key request, do datalogging on SD card, and with communication port to get logs and configure the system on true rs232, rs232 over usb and rs232 over bluetooh.

- The mother board is a true complete "calculator" to manage all the EV : measure vehicle speed, propose some digital/analogic input to connect temperature sensors, current sensors, security switch and so on, manage main contactor/precharge, interface the BMS slaves directly to have direct access to voltage/temperature of all cells, having communication port for data-logging (CAN, rs232, usb etc...), and having a beautiful large color TFT screen to replace the original dashboard of the vehicle, with speed information, energy information, SoC, etc... In other words, a complete open platform specifically designed for EV, as a cycle analyst do for bike/scooter !

Wow! You have some pretty ambitious ideas. :thumbup: I want to start converting my own EV, but haven't got the money yet. You have a bunch of VERY good ideas with ease of use being important. will you be writing any code for accessing the BMS with a computer since you want to use a BlueTooth, RS232, or USB to access it?

I am a very bad PC/user interface programmer, and I hate that :D I am an hardware and embedded software developper, it's why I want to open code and protocol to permit a very generic platform usable on any EV, with a lot a technical possibility and possible evolution.

At the beginning, for the bluetooth my idea was to dowload the datalog from the BMS directly with a smartphone, instead plug/unplud SD card, because the mother board is generaly under the hood, not easy to often plug/unplug the SD :/

And also, the smartphone can become the display of the dashboard, no need for the display option for those which have a smartphone.

I like the idea of using a smartphone as your display for your BMS. All you would have to do is develop the app that would act as the interface and have it read the BT input then calculate and display the information. I've played with a little code for the PIC uC, and i've got a few programs I've developed that has a LCD that would display the information from the ADC and from other inputs. Only one of my programs has given me any trouble and that's the calculation of temperature from a temp sensor using the ADC. I've got some of my ideas on a forum called Electro-Tech Online. sorry if I hijacked your thread.

I see the thing in an other way, the display intelligence in the mother board and the screen just receive print and graphic commands. The advantage is to have minimum intelligence in the screen, thus it works only as a terminal. Thus the smartphone application is really simple, it just receive and execute print command, and send X/Y of the display touch action. By the way, there is alway just one firmware to release. I work I is for a customer and for the same product it can propose different screen options, or use a PC application to act as interface.


No problem !! But difficult to answer without having the complete explanation about the problem :)

I would PM you but as my post count is still a little low, I'm gonna wait with that PM. It's just a calculation error i'm still trying to work out basically with the LM34 Fahrenheit Temp Sensor.

A very realistic idea would be to go modular for add on specific and complex features.
The function of pre-charge and main contactor handling is better handled by the motor controller by itself, don't bother.
If your concept of battery monitoring system is simple and straight forward, would be better.
It can be made more attractive with a large display connection on a VGA type of signal and better yet, touch sensitive control interface(USB)
Final customer choice of equipment, this monitors (7" and 8") are vast and very economic today days.
The small 4 line LCD modules are VERY difficult to read in a moving vehicle.

Just my 2 cents.

It's exactly this way I see things

Yes, they actually implements this feature because precharge is mandatory and it simplify the user reflexion about that, but logically it's not the job of the controller to do that.
But you are right, today all controller manage precharge, thus it's not mandatory to implement it on the BMS.
But to really have a generic platform, in the case of a true calculator managing all the EV instead of just a BMS board, my idea is to have a generic calculator with multiple input/output, and each one can be configured between some function. It can be for example :
- Contactor/relay output, with pwm possibility to ajust the contactor voltage and burst/continuous current
- Analog input (current sensor, temperature, throttle, brake, etc...)
- Analog output ( to pilot the controller for example)
- Digital input (various type switch, speed signal,...)

I think more the board is generic, better it is, because with software the calculator can be integrated easily in all EV and propose powerful functionality.

Hum why not, it's a good idea, have you a link on this kind of display ?
From my side I was considering raw TFT screen + touchpanel, with integrated driver/framebuffer, we can now found very nice thing for very low price. Just need to add the backlight management (easy), and a LVDS serder to deport the microcontroller bus on the display with standard twisted cable as an ethernet cable.


Hum, I think that we can just say that these king of screen are really really unusable for this usage :D:D
And a "big" graphical black/white display is more expensive that a beautiful color TFT screen !!!

nlc,

Your contribution to EVs is much appreciated and making the protocol open is also commendable.

I have one question.

In the light of the "bricking" of the Tesla which is caused by leaving your vehicle alone for a long period of time with no way of "turning off" the drain on the traction pack, is there any state of the slave board where it does not drain any power? Can you "turn it off"?

This is the one characteristic that the slave board that is powered by the mother board that would enable total power off of the vehicle.

EDIT: sorry, that was a very poorly constructed English sentence.

Thanks, and great work in miniaturizing your slave board.

Eric

Thank you :)

The slave board turn automatically OFF when there is no communication for more than 10 seconds. It's not a true OFF state but a deep sleep state, and the current consumption on the cell is a few µA, thus much less than self-discharge of the cell. The slave board wake up automatically when it receives a request frame form the mother/master board.

And the mother/master board is completly OFF until ignition key is ON or charger is plugged.


No possible at my opinion, cost will be too high and wiring more complicated.

It's my case too ;)

NLC,

Are you going to design your “Master Board” to interface with the ReVolt Controller ?

A new version of the ReVolt Controller PCB that has the BMS master on-board would be very nice! You just directly plug in the distributed BMS slave boards to the new controller.

The ultimate would be an integrated BMS/Controller/Display & Charger?, just add batteries.

-Mark :D

I am not a big adept of the "all in one" philosophy (BMS/controller/display/charger), but more adept of the linux philosophy : a single and simple tool for a single/simple function.
And combine these simple (and then highly reliable because very specialized) tools together to do complex and sophisticated things.

For the openRevolt controller, there is absolutely no obstacle to directly connect and read the BMS slave board daisy chain, and do all we can imagine in internal controller firmware. For example SoC, limit discharge current to not have a brutal power off when battery are low, and so on.

To connect my BMS slaves, just need a free uart and very very simple interface, just some resistor/transistor, opto-isolation is directly on the BMS, on the first and last slave boards.

From my opinion, the perfect EV infrastructure is :
- A mother board calculator (brain of the EV), manage all input/output, precharge/main contactor, throttle/breake, charge relay, current measurements, motor temperature and so on.
- The daisy chained slaves board directly connected to calculator to always have in real time all cell voltage and temperature, and be able to do SoC and other useful function
- One or more controller which receive their torque consign from the mother board (with CAN bus). Very useful configuration for multiple controller/motor EV, because the differential gear is totally natural in torque consign mode (current mode).
- A tactile optionnal display, connected on the mother board calculator, and deported on the dash board. Display which can be a smarphone if motherboard implements bluetooth :)

I designed the power train of this without driving license vehicle, and exactly used this architecture. There is a controller on each hub motor wheel, thus 4 motors/controllers (the controller I talked about in the Paul and Sabrina AC controller topic), connected to the mother board with CAN bus, and this architecture is really simple, evolutionary and reliable !!

That sounds like a good idea sawickm. That makes for a very revolutionary system that gives the EV user good control over management of the EV systems, as few as they are. It would probably ease the conversion of EVs from ICE.

Yes but with all in one concept, there is no modularity to work with absolutely all user :
- What controller voltage ?
- What controller current ?
- What charger input voltage accepted ?
- What charger output voltage/current ?

Easiest at my opinion to have 3 separate system but with easy wiring and configuration, every one choose the best component for its personal use. It can be also revolutionnary to have some bms / controllers / charger / mother board specially designed to work easily together with open protocol.

Flaws in the Elithion BMS?
 

I wrote you privately, but you must have not seen it, as I did not get a response.

Since you state that our BMS has flaws, could you be so kind as to please write us directly and tell us what those flaws are? (This forum will not allow me to post links, so I must ask you to please use the contact page on the Elithion website.)

Thank you for your time, and I wish you the best with your BMS project.

Davide

I just checked for that but I have not found any message for you :confused:
Maybe you just have clicked on "preview" and not "send", I made this mistake one time or two.

Hummm, I don't know what to say to you !! Yes from my opinion your board have some flaws, but give them to you will be the best way to explain you how to improve your products !! In another situation it would have been a pleasure to do that, but because I want to try to propose a high perf low cost BMS and more generally a complete master board / display system for DIY EV conversion, I think you will understand I prefer to not list these flaws now :)


I don't know if it's really sincere, but thank you anyway ;)

Of course we're striving to make our product the best that it can be: you can't blame us for that.

We are flattered that you chose our BMS, presumably because you felt it was the best one out there, and the one that you wished to reverse engineer; I see from your description of your BMS that you were successful in doing so, as you copied most of the features, technologies and functions of our BMS. Good for you! And thank you for the compliment implied by your choice.

Oh, absolutely! I meant it. I am sorry if you may be so jaded that you can't accept a sincere well wish without suspicion. I can prove that I meant it: on our site we take pain to list every BMS out there (again, I can't put a link because this forum will not let me); that is because we wish success to all the BMS companies. We all are doing something good for the world, and we need to work together, not against each other.

In fact I have not wished to reverse engineer any BMS, not chosen yours. I developed for a customer some month ago a special BMS for the car it develops (I also developed for him the FOC controller I talk about in the Paul and Sabrina topic). But it's a more sophisticated BMS because it uses capacitive balancing. For installation cost he asked me to have one small board by cell, same principle than a lot of other BMS manufacturer. But on this BMS, there are 4 wire between each cell, for the communication daisy chain (there is not a lot of way to do a Tx/Rx daisy chain, not necessary to look how other do that !!), and capacitive balancing needs.

After that I thought it would be a good idea to simplify it in a extreme way for my personal use (I try to convert a gazoline car to electric), and why not propose a low cost high perf BMS based on this principle for DIY EV conversion community, in France and world wide. More generally I want to propose a generic calculator to manage all the EV car, the slave BMS being just a part of the complete system.

During development of my board I talked about my project to some friends some week ago, and one of them told me that it already use this kind of BMS, and it was yours ! He asked if I can be able to repair some broken board, I say yes I can try and this is at this moment I studied your board and saw some flaws I did not have on my own board (from my opinion of - maybe too much !? - perfectionist developer !!). Also, at this moment I seen that your hardware daisy chained principle is even simpler than mine, but I prefer mine anyway because I don't like directly input a signal in a microcontroller, even trough a resistor.
Also, I don't know how your protocol works, and it's better like this, I prefer implement it myself, it's really exciting to try to simplify it in an extreme way keeping high perf and high reliability (as you know the internal clock of this microcontroller can severely deviate in all the -40/+125° range).

Happy to hear this, thus I gladly accept your wish and I thank you very much for that ! :thumbup:

Great work.
May I suggest the "brains" for your BMS. There is a single credit card size motherboard available. It's called raspberrypi (.org)
It's has a lot of connection possibilities and it is cheap and based on arm linux. Do you want to make this BMS project open source?

regards

Yes I heard about this board. But at my opinion this board is too much generic and cannot be used as is for automotive use. Need to add specific board for supplies, input/output interface, and so on.

I think a specific board is better for this kind of use. But yes I want to develop it in an open source way (hardware + software)
I already drew a first diagram for this board, opinions are welcome !! In some case some function will not be used (the precharge/main contactor part for example), but I take them into account to have a very generic board which can be used in all EV cases.

Here is the diagram :

http://chaenel.free.fr/images-forum/...er_board_1.png

This is looks great!!
I can not wait to see the finished product.

Have you seen the forum. There are several project focusing on interfaces. There is even a CAN bus interface project.
www raspberrypi .org forum projects-and-collaboration-general can-interface

"But It have some flaws, I can list them if you are interested !"

I'm interessted.. what are the Elithon flaws?

RE RPi
 

I have been following the Raspberry Pi project.
I wouldn't use it for the master board, it would only be possible to use it for display purposes, logging, connectivity etc. which means one level higher.

sudo bmsmaster --restart --force anyone? :)

BTW, the availability is not there yet - there are a lot of unhappy people who did get one and have to wait 58 days plus to get one each...

I'd prefer ATMEL or PIC, maybe an Arduino that you can interface to with whatever you want.
This is just my opinion, of course - what do you think?

As you can see Elithion follows this topic, and its posts has shows that they have a sympathetic attitude, I am not sure it's really correct to do that now on a public forum :/

I send you a PM, but remember it's the opinion of a perfectionist developer :)

I'm not an expert at this, but isn't 200mA a bit small for balancing? Is it possible to increase this by decreasing the resistor?

I have the same opinion, no need of this king of board and operating system for the master board, which need to startup instantaneously when ignition turn ON. I use embedded linux on a lot of project, but I don't see the advantage here.

Anyway, at my opinion there is absolutely no need to choose the microcontroller or other component now, the important step is to validate the general architecture of the board, to decide which functions the board must implement or not. The microcontroller choice is almost the last step :)

I need to add on my general architecture image that the digital outputs must have the PWM capability.

The resistor is 1W, cannot lower the value. I don't want to have a bigger balancing current because :

- It's a generic board, no need to have a big current for small cell capacity
- The balancing algorithm can be improved, to have the balancing during the charge and no only at the end of the charge. For a 10h charge for example, it's almost 2Ah balancing at 200mA !
- A bigger current will perturb the on board temperature measurement

But for those which really want a bigger current, I put on the board 2 big and beautiful pad, to easily solder an external power resistor. The mosfet I put on the board can switch more than 4A, more that enough for everyone :thumbup:

Only a single person on that thread has actual knowledge, and there is almost no experience with actually using what they are suggesting.

If you want to try socketCAN, you can buy existing boards that run Linux and have CAN controllers built in. I have a half dozen within arms length right now. But I still do all of my EV CAN work either directly programming the CAN controller (without trying to use socketCAN), or accept the bandwidth and functionality limits of ELM327 parts to get data to a laptop.