EEVblog Electronics Community Forum

Electronics => Open Source Hardware => Topic started by: green-bms on August 28, 2021, 08:18:52 am

Title: Open source smart BMS
Post by: green-bms on August 28, 2021, 08:18:52 am
Hello, I would like to share my project with you..
I made a BMS that I installed in my daughter's e-max scooter (16s 48v)
It is a BMS for prismatic cells, with modules that are fixed to the positive pole of each cell.
Each module is based on Attiny microcontroller and communicates in I2c with the control unit based on Arduino Mega.
The BMS is controlled and managed via an Android application on a smartphone connected to the BMS via Bluetooth.

Web Site: (
Youtube channel: (
Android app: (

All project files of Green BMS project are available at the following link: (

Green BMS has been certified as open source hardware by the Open Source Hardware Association, with the UID: IT000007 (

Title: Re: Open source smart BMS
Post by: Siwastaja on November 21, 2021, 06:25:06 pm
Add a thermal fuse coupled to the power resistors!

I looked into failed BMS designs a decade ago and this is one of the classic ways to start a battery pack fire. (4.2V)^2 / 3ohms = 5.9W, this is a lot of power in a tight hotspot, especially if cooling is hindered by some thermal insulation etc., if the software fails leaving the balancers on, or the MOSFETs fail short.

Are you sure you need this much balancing current? This should be good up to some 1000Ah banks, is this intentional? Thermal (and mechanical) design would be much easier with lighter shunting, and you can do it for longer time by adding a bit of intelligence on the algorithm.

The classical miniBMS used a PTC polyfuse coupled to the balancing resistor for a cheap solution, balancing current was some 500mA AFAIK and was one of the highest on the EV market, many had 200-300mA. I used some 50mA balancing current in my design and a 100mA fuse limiting highest possible fault power dissipation to below half a Watt. This 50mA balancing current was tested good on a second-life 250Ah Ah pack with a few cells that were likely slightly damaged by overdischarge and leaking more charge than others.

Exceptionally well organized design files, thanks for sharing.
Title: Re: Open source smart BMS
Post by: green-bms on November 23, 2021, 05:57:15 pm
Thank you Siwastaja for your suggestion.
A thermal fuse could be a good solution and maybe  1A of balancing is too much, I will consider your opinion in a future upgrade.

But consider that the system is not without high temperature protections: there is a TMP36 temperature sensor attached to balance resistor that is used by the software to cut balancing command if temperature reaches the overtemperature parameter threshold.
There is a second mosfet p-channel drived by the controller that have the function of balance enable and open the balance circuit if the cell voltage goes under 3,2 volt...this is to protect the cell in case of a fault on Mosfet N.

In any case thermal fuse is a very good idea: at which temperature you'd cut off the balancing? Can you suggest to me a small and cheap thermal fuse type in order to stay in a small space? Thank you!
Title: Re: Open source smart BMS
Post by: Siwastaja on November 26, 2021, 05:46:04 pm
Thermal fuse is so that software failure cannot set the thing in fire. Microcontroller can glitch and leave the gate drive on.

If you need to cut balancing regularly due to heat, you are balancing at lower average power; can just as well use lower-power resistors to begin with. Taken into extreme, if you use small enough balancing power, you can guarantee by (simple) thermal design (even testing could suffice) that overtemperature cannot happen at given current, after which you can guarantee maximum overcurrent by using just normal fuse, which is even simpler and cheaper than thermal fuse. I went that way in my design (with a 100mA fuse, which can be guaranteed to blow at 200mA in short enough time).

For thermal fuse, the key is coupling it to the resistors. Maybe a relatively high temperature like 120degC would be acceptable for fire protection. Then your software needs to detect much lower overtemperature (like 70 degC) to prevent that fuse ever blowing during edge cases of normal operation. Look at parametric search of your favorite distributor.

You get more space on the PCB by reducing balancing current.
Title: Re: Open source smart BMS
Post by: strawberry on December 06, 2021, 07:19:29 pm
BMS power consumpion?
Title: Re: Open source smart BMS
Post by: green-bms on December 10, 2021, 04:15:09 pm
BMS power consumpion?
Each cell module takes 10-15 mA (no balancing), during balancing you can set the current from 0% to 100% (1,2 A if you use n.4 12ohm power resistors).
The control unit consumes about 5,5 watts ... I know it's a lot, it's one of the parts of the project to improve in the future...
Title: Re: Open source smart BMS
Post by: Siwastaja on December 12, 2021, 10:56:23 am
BMS power consumpion?
Each cell module takes 10-15 mA (no balancing),

That's a huge issue, not only because it makes the pack self-discharge, but because large current in reality also means large current differences* between the units, making this an unbalancer. Even just 1mA difference causes 24mAh per day or 720mAh per month, requiring full hour of balancing at 720mA, a massive balancing current that produces a lot of heat!

*) unless most of that 10-15mA originates from small value resistor divider network and you use 1% resistors to build it, in which case the consumption would be actually self-balancing.

If your balancer only activates at the end of charging cycle, now you need to guarantee that the end-user follows such usage pattern of regularly fully charging the pack "just because". This, OTOH, isn't at all what's best for the lifetime of li-ion cells, so forcing users to do "wrong thing" just to make the BMS not destroy the pack is counterintuitive.

I don't want to sound harsh, this is just a perfect replication of the problems a few failed BMS's I analysed a decade ago, the end-result is a failed pack and loss of $10000 worth of cells in a conversion EV.

It's important to minimize quiescent current using sleep modes etc., for example a few µA is achievable with many microcontrollers. But it's also important to minimize on-state current because a usage pattern might be such that the device is powered for a significant part of time, you don't want to unbalance the cells in such case.
Title: Re: Open source smart BMS
Post by: green-bms on December 12, 2021, 12:49:06 pm
I don't want to sound harsh, this is just a perfect replication of the problems a few failed BMS's I analysed a decade ago, the end-result is a failed pack and loss of $10000 worth of cells in a conversion EV.

No problem, I appreciate the sincere opinions of others.

But I don't agree with you at all.

10 mA is a modest self-discharge for a 60Ah battery pack like mine: the pack self-discharges in 6000 hours = 250 days = about 8 months !!!

Furthermore, 10 mA are quite the same on all cells because the modules have the same components and therefore the same absorption.
Even if there were any differences, charging and balancing daily or weekly at 700mA compensates itself in a short time ... do you build a battery pack to use it or to keep it still??

10 mA is a small price to pay to have a smart BMS configurable from an Android phone and always connected to the central control unit ...

Huge issue? In my opinion you are exaggerating.
Title: Re: Open source smart BMS
Post by: Siwastaja on December 12, 2021, 01:54:51 pm
Thanks for appreciating my input really, I indeed want to help you avoid the same old mistakes. I don't want to just say "you are doing it wrong", I also want to provide pointers to how to fix it.

But I reiterate that yes, it's really a huge issue, based on the number of destroyed-by-BMS conversion EV projects I have seen personally, or analysed on the interwebz. Don't be one of those guys, focus on the core reliability issues at the expense of "nice features". It would be a good practice for a BMS designer to wake up every morning, and ask themselves: What is my task? - To always keep the cells within safe operating area regardless of what buttons end-user presses! If not this, why need BMS at all? In other words, BMS ain't entertainment gadget, it's a safety-critical component, also a component which manages expensive assets, and thus requires due diligence.

The problem isn't only the self-discharge of the pack.

(This actually is a problem, as well; as you calculated, if you lose 100% capacity in 8 months, you are already doomed. If the user runs the pack down to 10%, which is totally sensible cut-off limit as you don't want to waste expensive and heavy energy storage into excessive safety margins, this is already down to 3 weeks. As the consequence is serious, loss of expensive property and based on my observations, death of the project or company, I think this is a problem. You can't blame the user by not seeing the "if you run this flat, don't leave it standing for a few weeks but go charge immediately" warning. Robust products do not require such instructions, actually the only task of the BMS is to take care of the battery, not incur extra responsibilities to the user, then destroy the pack if the user fails to follow these often unwritten rules.

I witnessed a €50000 conversion EV self-destroy exactly because this, 12V lead acid battery ran flat, doors were locked so no one used it two months or so, during that relatively short time BMS self-destroyed half of the cells. It was also a very nice BMS with many features (including then-trendy redistributive balancing!) likely "worth" that consumption if you asked the designer. But in the end, the massively expensive and "advanced" BMS failed its only real job. That also triggered the re-design of the BMS into something that does not do that, focusing on core reliability instead of feature creep. Sadly, that resulting BMS project, after being tested in a few vehicles and energy storage systems for a few years, ended up in my drawer but such is life; the last 5% takes most of the time, and proving a supposedly good design really is good, is tedious work.)

But, the problem I focused on in above reply is unbalancing of the cells.

If one cell module leaks 10mA and another leaks 12mA, the cell charge levels drift apart at 2mA. Your balancer needs to correct this unbalance. Now if the balancer has 0.1% duty cycle to do balancing work (how do you even prove that assumption?), required balancing current just to correct the imbalance the BMS caused is already 2A.

You can solve this in a few ways,

First the obvious one is to reduce the imbalance you cause by minimizing the current draw. The limitation is at some point, actual self-discharge of the cells (the reason why you balance in the first place!) dominates again. But at 2mA difference for example, the BMS-induced imbalance will dominate. First get this down to numbers where you are not causing the problem you are solving.

The second one is to make the balance current higher. This usually leads nowhere since you can't go arbitrarily high or you hit thermal issues, or complexity/cost issues (by making it charge redistribution type BMS). IMHO, you already have moar power than I'm comfortable with, so you need to look further...

The third one is to increase the duty cycle of balancing, in other words, let it do its job often. This increases algorithmical complexity, which is a bitch to prove. The "classic" "trig balancing during CV phase of charging" won't cut it. The real challenge is to prove the minimum duty cycle over all typical and nontypical use cases!

My BMS design focused on things #1 and #3 and sacrificed #2. I brought quiescent current down to some 20µA, and active-state current to some 0.5mA IIRC, then implemented balancing algorithm which senses the amount of imbalance (as delta V between the cells) near the end of charge, but stores that information and keeps doing the balancing work even after charging is terminated, even if the EV is driven. The algorithm was something like this (assuming LFP):
V1 = 3.50V
V2 = 3.55V
V3 = 3.60V <-- this causes the charge cutoff

--> calculated shunting time:
Cell 1 = 4 hours
Cell 2 = 2 hours
Cell 3 = 0

There was a self-adjusting gain term etc., but that's the general idea.

Now what comes into the price to pay, it's great to have Android app, but really, does that require that you consume charge from individual cells? In the end, what is the task the cell modules have to do, or what they even can do? Measure voltage. Maybe measure temperature at each individual cell. Cell-level actions? Consume charge from the cell to balance. That's pretty much it. Current measurement already goes into the master module; Android communication should go as well. Amount of data to transfer between the cell modules and master is minuscule because voltages and temperatures are slowly changing variables. This doesn't need to consume so much current.

OTOH, you may be completely right that you don't have current variation issue, or you have advantageous current variation; that's the case if you have high-accuracy constant resistance load, as they will draw more current at higher voltage, balancing the cells. But, semiconductors (including microcontrollers) have large unit-to-unit variations, and specifically temperature variations. It's only matter of coincidence whether these random variables balance or unbalance the pack. Maybe you don't have a problem. Maybe you do. Maybe the problem only manifests itself years later, after a batch of 100 cell modules is made in such a way that some of the MCUs happen to come from a different batch. IMHO, BMS can't be designed this way. It needs to be robust and reliable even in varying conditions, and you need to prove as much as humanly possible, because human errors lurk in anyway. If you ignore alarming calculations regarding the most basic functions and use cases, you are taking a huge risk.
Title: Re: Open source smart BMS
Post by: green-bms on December 13, 2021, 10:43:32 am
If the user runs the pack down to 10%, which is totally sensible cut-off limit as you don't want to waste expensive and heavy energy storage into excessive safety margins,
I understand your point of view, what you say is interesting.
I have actually underestimated the problem that can cause a 10mA draw.
In the next version of Green BMS I will significantly reduce this absorption.
In fact, when the battery pack is in standby (no charge and no discharge) it makes no sense that the cell modules communicate frequently with the Control Unit .... for example I could increase the data exchange rate, putting the cell modules in sleep mode between one data exchange and the next.

It must be considered that Green BMS is a DIY project that I decided to share with the opensource community, to make it open to changes and improvements by everyone or to be taken in part and used in other people's projects.
I have tried my best to make the BMS safe and reliable, but I cannot rule out mistakes in my work.
As I clearly wrote in the "Warning" paragraph on Github, anyone who decides to use Green BMS must be aware of this.

Where can I find your BMS project, Siwastaja? Can you send me the link? Thanks
Title: Re: Open source smart BMS
Post by: Siwastaja on December 13, 2021, 12:55:19 pm
My BMS project is sadly not open source, but I started the development as a quick&dirty hobby project and early code (and some documentation in form of .txt files) can be seen at , feel free to take influence. Note this does not represent the final system, it's just my own personal repository and pushed later into Github "as backup" and for everyone to see, also there was no effort to make it readable for others. The HW itself basically was not much more than fuse, ATTiny25, communication AC coupling capacitor, voltage measurement resistor divider and an LED with the series resistor. Start/End chain modules included additional optoisolation. Most of the magic was in the master module which I produced at least three different versions of, and another team member one of their own.

I understand the amount of work that goes into maintaining an actual open source project with proper documentation etc. I have the bad habit of leaving that for others to do. Somehow getting paid for writing documentation makes it happen :).