diy solar

diy solar

DIY BMS design and reflection

BiduleOhm

Electronics Sorcerer
Joined
Jan 30, 2020
Messages
2,004
Location
France
Edit 2022-11-28: I made an index of the various parts of this thread to save you from scrolling too much: https://diysolarforum.com/threads/diy-bms-design-and-reflection.4065/page-31#post-650424


I did not want to start this thread until I would be far enough in the development but a post in another thread sparkled an interesting conversation so here we are :)

So I'll continue the conversation here to avoid polluting the other thread and I'll explain my current design just after (so if you don't care about the initial conversation you can jump directly to this part), be warned it'll be an in-depth technical description.


@Dzl
Not sure if its exactly what you are talking about but the maker of the SBMS0 (I highly suggest you learn about his projects, I suspect you will connect with his design style), recommends using Cat5 or Cat6 cable for external connections, I think this is not the same thing as what you are talking about, just the same cable. Here is a link to the manual.

Yes, I saw this BMS and his other projects, they are very interesting but they doesn't really do what I need/want (for example I need a 16s BMS, this one is 8s max). When I was talking about ethernet I should have been more clear: I want TCP/IP communication, not just using the ethernet hardware layer with another software protocol like UART, SPI, I2C, ... The main reasons are that I can easily use a switch to connect everything together without some central "brain" as if I was using a more usual MCU protocol, it is really well immunised to a lot of RFI, EMI, etc., it's galvanically isolated, it can go up to 100 m of cable without problems, it's fast, it has errors detection/correction built in, ...

I can understand wanting to maintain isolation and see the benefit of that approach. But I feel like how you define the BMS's 'job' is unnecessarily limited and absolutist. A BMS is a system of managing and protecting the battery. That means preventing overcharge, overdischarge, etc. Communicating with chargers and load side appliances (inverters, battery protects, etc), and telling them when its acceptable to charge/discharge the battery is within a BMS's scope of responsibility. Whether it communicates directly, or whether it opens/closes a relay, or handles the (dis)connection of charge sources and loads internally is a design decision. But all are methods of managing charging and discharging. Keeping each device ignorant and independent of the others as you advocate has its merits as you correctly noted, but being able to communicate with external devices has its own merits, and is in some ways might be a more elegant solution. I also want to clarify that I mentioned communicating with external devices, not controlling, which are somewhat different things.

When I said isolation I meant isolation in the functions, not isolation in the communication. It's not the job of a BMS to stop the SCC from charging, but it's the one of the SCC to interrogate the BMS and stop the charging. Another example would be the heat pump: it's not the BMS who tell the heat pump what to do, it's the heat pump who decide what to do after getting data from the BMS. Because otherwise you mix the BMS logic with a lot of other things' logics and you have a mess.

The distinction between ignorant and independent is really important: yes I want the devices to be independent (main reason after not having a big messy ball of things is failsafe: everything must still be working (even if in a degraded mode) if all communication is lost) but I certainly don't want them to be ignorant, that's why they communicate after all :p


@Steve_S
@BiduleOhm Many BMS' (all the smart ones in any case) can be communicated with. Most have a UART option if not already enabled. "Dumb" BMS' which have no comms at all (BT or otherwise) are moot on this point. Not all Inverters or SCC's can communicate with a BMS, it's only now starting to really come into play but really, many also do not even directly support Lithium Based batteries either yet. In a perfect world hat would be different but it is far from a perfect world. Are you aware that a RaspberryPi,, Arduino and similar can be used as an intermediary, a manager, a Modbus controller... various ones can accept RS232/485 directly with a "hat" add-on or various BMS' & other devices could also route through a USRIOT device (there are others as well but USR is top notch) https://shop.usriot.com/serial-to-ethernet/serial-ethernet-converter but these can also do Serial to WIFI, CanBus and more....

BTW: I run a Midnite Classic SCC, great controller but dumb as horse manure when it comes to BMS, Lithium Based Batteries but it can be programmed around to work (kludge IMO) but it works. My Samlex Inverter on the other hand CAN talk to a BMS and has some Lithium intelligence in it's programming.

As I said to Dzl I want TCP/IP, not just converting another protocol to ethernet. I also don't want to adapt everything to everything with arduino/RPi because it'll be a mess (I'll not have the choice for some things like the SCC, however I'll do the conversion once to TCP/IP instead of converting for every other protocols, but the less I have to do that the better of course).


So apparently I'm over the 10 kchars/post limit, oops... well, I'll split into 2 posts then.

Edit 2021-01-20: This thread is a very detailed record of the design process, the choices I made, etc... so I made this other thread if you just want to see the features list, the specs, the schematics, etc...
 
Last edited:
What I need/want

I originally planned to use Tesla modules in a 48 V configuration for my off-grid system but then I found the thread about the Xuba cells who are far cheaper and are LiFePO4 instead of NMC (a very good point for safety...) so the main differences are the number of cells (16 instead of 12) and the voltages limits, but besides that the idea stay the same.

The number one priority is safety (think: fire), then comes protecting the battery and then comes performance.

So it'll have all the usual BMS features (OTP, UTP, OVP, UVP, ...), redundant hardware protections, true disconnect (bidirectional, no mosfet diode problem), accept (low current) charging while in UVP, precharge capability and TCP/IP com with a full JSON API.

It'll be sized for a 48 V LiFePO4 16s battery with around 300 A continuous (400 A peak) charge/discharge current, but it'll be scalable for smaller and bigger batteries if needed.


The features

Sensors:
3 battery temp sensors
1 ambient temp sensor
1 BMS temp sensor
2 mosfets temp sensors
current sensor (shunt)

SW protections:
- over temp
- under temp
- temp mismatch
- over voltage (total and by cell)
- under voltage (total and by cell)
- over current (short term (30 sec) (400 A?) and continuous (300 A?))
- voltage mismatch at power-on

HW protections:
- fire input/output (active low, +5V 4.7k pull-up)
- over temp
- under temp
- over voltage (total)
- under voltage (total)
- over current (short-circuit (use dV/dT?) and continuous (350 A?), fuse (500 A?))

soft power-on/off (long button press)
UVP low current charging
precharge resistor (with low current fuse in series)
top balancing

monitoring:
- all SW protections status
- battery state (off, recovering, precharging, on)
- battery temp
- ambient temp
- mosfets temp
- BMS temp
- current (both directions)
- power (both directions)
- total voltage
- total energy in
- total energy out
- total cycles count (total energy in + out divided by battery nominal energy)
- each cell voltage
- each cell energy in
- each cell energy out
- each cell cycles count (very useful to detect a weak cell)
- SoC
- POH


The disconnect feature

The BMS will use a true disconnect which will interrupt the current in both directions unlike half of the BMS on the market who just use mosfets in the simplest configuration for the disconnect (so the mosfets' body diodes still allow current to pass in the charge direction even when the mosfets are off, not really a good thing in an over voltage situation...). The simple way to do that is to use a contactor (big relay) but the problem is the coil will eat 10 to 20 W all the time (that's 240 - 480 Wh/day...), so you can use a NC contactor but then the problem is the safety: you need to send power to disconnect the battery instead of just cutting power.

Well, I don't want this power hungry contactor, and I want the battery to be really disconnected when I need, not just in one direction... so my plan is to use mosfets but in an anti-series configuration: https://www.quora.com/Can-two-mosfets-be-used-for-bidirectional-current-flow and https://electronics.stackexchange.c...e-mosfet-gate-with-an-isolated-voltage-source are good explanations. Of course it's more complex and costly (double the mosfets, full galvanic isolation for the control side, ...), that's why some BMSs just use the basic configuration. I don't know about you but personally given the cost of the battery and a house I prefer to invest a few dozens dollars more to have this capability.


The precharge and some other related features

The precharge resistor will be in series with its own little disconnect and a mosfet with a (schottky) diode in anti-parallel; the whole thing will be in parallel with the main disconnect. Thanks to that we add 3 features at the same time: UVP low current charging, precharging, and voltage mismatch protection. The battery can be in 4 states: off, recovering, precharging, on:

- In the off state the main disconnect, the precharge mosfet and the precharge disconnect are off: the battery can't be discharged or charged.

- In the recovering state the main disconnect and the precharge mosfet are off, the precharge disconnect is on: the battery can't be discharged but can be charged at a low current through the precharge resistor and the diode. That's allowing to recover an over-discharged battery without having to by-pass the BMS (big no-no for safety...). The battery will stay in this state and not go into precharging until the under voltage protection is happy.

- In the precharging state the main disconnect is off, the precharge mosfet and the precharge disconnect are on: the battery can precharge the capacitors of an inverter without current spike through the precharge resistor and the precharge mosfet (by-passing the diode).

- In the on state the main disconnect, the precharge mosfet and the precharge disconnect are on: the battery is fully functional. But before the BMS decides to turn on the main disconnect it'll check the voltage across the precharge resistor (both directions), if it's over a certain limit it'll wait and let the battery in the pre-charge state until the voltage is under the limit, only then it'll turn on the main disconnect. [Note to myself: check voltage presence at the output side of the precharge circuit to validate the precharge disconnect, resistor, mosfet and fuse are OK before any other check and turning on the main disconnect] [Note to myself 2: electrical interlock: main disconnect can't be on unless precharge disconnect and mosfet are on]

The voltage mismatch protection is very useful if, for example, we have two battery packs connected to the main bus and we want to add a third pack: if its voltage is not close to the main bus voltage (because it is less or more charged than the other packs) a massive current would flow from/to this pack to the main bus (LiFePO4 have very low internal resistance and the main bus resistance should be even lower, so a small voltage difference can create a big current flow).

A long (> 5 sec) button press will be used to trigger a power-on (if current state is off) or power-off (if current state is anything but off).


Misc features

The balancing feature will be really simple: dump power from most charged cell (highest voltage cell) to a resistor if over a certain voltage or over a certain voltage difference with the closest voltage other cell. Will be somewhat high current, 2 to 5 A, compared to most BMS. No need to balance multiple cells at the same time or to have active balancing as history has shown packs stay balanced over a long time even without balancing.

The multiple temperature sensors are because of redundancy, a nice side effect is more accuracy too.

The current limits have question marks because right now I'm not sure about the exact values, they are probably right but might change a bit in the final design.

The main plateform will be an Arduino or Raspberry Pi (probably the arduino as the RPi eats a lot more power), all the other hardware will be custom (probably one PCB for the main disconnect/precharge feature and another one for everything else).

The main protections and other important status will be displayed on the battery itself with LEDs (red = bad, orange = warning, yellow = not normal but ok, green = ok) in addition to being available on the API alongside everything else.


If you have any advice/remark/criticism or just want to have some technical discussion (staying on topic would be great :p), feel free to post ;)

Please excuse any error; it took more than 3 hours to write this post (well, ok, I read a few new answers to others threads at the same time, so that can't help too :D) and my first language isn't english.
 
Last edited:
Very interested in this project! Looking forward to following along with your progress.
 
How do you plan on measuring the voltage of each cell?

Will you be able to measure each independently or will you measure and subtract?

What device do you plan to use for measuring?
 
Well, since your PM I was just researching the subject and come to a few conclusions...

There's not a million methods to do that:
- specialised chip like the one we talked in PM | Pros: everything in one chip, no calibration needed | Cons: very expensive ($20+), specialised, com is a PITA
- resistive dividers + 16 to 1 mux + ADC | Pros: simple, cheapest solution | Cons: lots of resistors with different values, worst accuracy solution, 16 values to calibrate
- 16 to 1 mux + resistive divider + ADC | Pros: very simple, only one value to calibrate | Cons: need a HV mux (very very expensive ($35+) and specialised)
- diff op-amps + 16 to 1 mux + ADC | Pros: accurate to very accurate (can be better than the one chip solution), 2nd cheapest solution | Cons: lots of op-amp and resistors (but same value for all, we can use resistors networks), 16 values to calibrate
- linear optocouplers + 16 to 1 mux + ADC | Pros: accurate, no calibration needed | Cons: 16 discrete devices (optos are 1 device per package items), use a lot of current (10-15 mA/opto), expensive


So to answer your questions:

I chose the op-amps + mux + ADC solution as it the best compromise (IMHO) between complexity, accuracy and cost.

I can measure independently but one at a time (or 2 at a time if two 8 to 1 mux + 2 channels ADC, may even be cheaper).

I don't know yet but something with a high CMRR, rail to rail, low supply current and a high number of devices per package for the op-amps; cheapest mux but of reputable brand; 14 ou 16 bits ADC (12 bits would be enough for 95 % of us but I'm of the 5 % :p ).


@all I forgot to mention it before but I'll try to not use specialised components, try to chose components available in DIP package in addition to SMD (for those who can't solder SMD) and try to stay under $100 (but I'll probably go beyond that, I hope not by too much...) as the goal is that anyone in the world can replicate it easily.

Note to myself: compensate for voltage drop due to balancing or kill balancing during measurement.

Edit: added linear optos solution
 
Last edited:
When I said isolation I meant isolation in the functions, not isolation in the communication. It's not the job of a BMS to stop the SCC from charging, but it's the one of the SCC to interrogate the BMS and stop the charging. Another example would be the heat pump: it's not the BMS who tell the heat pump what to do, it's the heat pump who decide what to do after getting data from the BMS. Because otherwise you mix the BMS logic with a lot of other things' logics and you have a mess.

I suppose we are in agreement here, A BMS should communicate, not necessarily control. Except I would say that it is within BMS' role to tell these other components what to do (as it relates to battery protection). Here I am differentiating the term 'tell' from 'control', a BMS shouldn't necessarily control these other components but it should be able to communicate: "hey SCC, cell 3 is reaching a dangerously high voltage, you need to shut off charging, until I tell you its safe again. If you don't do it before it reaches x voltage, I will take matters into my own hands and cut you off." I suppose we are not in disagreement, we are just defining things differently. Because I agree with you that each component should be in control of its area of responsibility and capable of operating independently of input from other components, while ideally communicating with one another and working in concert.

The distinction between ignorant and independent is really important: yes I want the devices to be independent (main reason after not having a big messy ball of things is failsafe: everything must still be working (even if in a degraded mode) if all communication is lost) but I certainly don't want them to be ignorant, that's why they communicate after all :p

I agree with you here

Overall, I think there isn't one right way to define the role of a BMS, or one right way to integrate the components. I think it depends on use case, priorities, and abilities. I get the feeling you are going to design a really cool, really resilient system that works for you.
 
I suppose we are in agreement here, A BMS should communicate, not necessarily control. Except I would say that it is within BMS' role to tell these other components what to do (as it relates to battery protection). Here I am differentiating the term 'tell' from 'control', a BMS shouldn't necessarily control these other components but it should be able to communicate: "hey SCC, cell 3 is reaching a dangerously high voltage, you need to shut off charging, until I tell you its safe again. If you don't do it before it reaches x voltage, I will take matters into my own hands and cut you off." I suppose we are not in disagreement, we are just defining things differently. Because I agree with you that each component should be in control of its area of responsibility and capable of operating independently of input from other components, while ideally communicating with one another and working in concert.

I agree on most points but I'm still not sure about what I'll choose to do about the com direction (is the BMS telling everyone "there's a cell OVP"? or is the other devices who get the value from the BMS?) because it impacts more than the solar install (a lot of things in the house will communicate on this same network) and I've not thought about that enough to have a definitive answer yet.

Overall, I think there isn't one right way to define the role of a BMS, or one right way to integrate the components. I think it depends on use case, priorities, and abilities. I get the feeling you are going to design a really cool, really resilient system that works for you.

Yes, I agree, when we go that much in-depth then lines start to become blurry and we can bend them how we prefer :)



Sooo, I was looking for the op-amps I'll use for the voltage measurement and I already failed something I wanted to do: it's extremely hard to find what I want in a DIP package so I think I'll ditch that rule. Sorry but nowadays it's SMD for everything... at least I'll chose easy to solder packages (SOIC for example, no TSOP, QFN, BGA, ...).

Currently first choice is OPA4990IDR from TI and backup choice is OPA4196IDR from TI.
 
I agree on most points but I'm still not sure about what I'll choose to do about the com direction (is the BMS telling everyone "there's a cell OVP"? or is the other devices who get the value from the BMS?) because it impacts more than the solar install (a lot of things in the house will communicate on this same network) and I've not thought about that enough to have a definitive answer yet.

Actually you bring up a good point that I hadn't considered too much (and in my case it may be moot because it may be out of my control).

But you've got me thinking about the pros and cons of the direction of communication

  1. Should the BMS simply report individual cell voltages (or if this is not practical/feasible report a binary healthy or dangerzone signal or trinary (is that a word) healthy, warning, dangerzone signal, and let the other components decide how to handle that information.
  2. Or should the BMS advocate for a particular action (and in practice would this be any different from the binary or trinary option)
 
trinary exists but ternary is more usual https://en.wikipedia.org/wiki/Ternary_computer :)

Now if we continue with this particular example I'll say the SCC should do nothing (whatever the com direction is) as shutting down the charging for all the strings in the battery just because one of them has a problem isn't really the best solution to me. The best would be to let the BMS disconnect the string and leave the rest of the installation alone. Also the BMS protections are really a last resort thing, they shouldn't be reached in normal conditions, so maybe not the best example here.

But if we ignore that, I'll say it's not the job of the SCC to guess if a cell is above a certain voltage as this voltage limit is (and should stay) internal to the BMS so the BMS should have a clearer status for other devices; something like "ok/can't accept charge/can't accept discharge/accept nothing/..."
 
trinary exists but ternary is more usual https://en.wikipedia.org/wiki/Ternary_computer :)

Now if we continue with this particular example I'll say the SCC should do nothing (whatever the com direction is) as shutting down the charging for all the strings in the battery just because one of them has a problem isn't really the best solution to me. The best would be to let the BMS disconnect the string and leave the rest of the installation alone. Also the BMS protections are really a last resort thing, they shouldn't be reached in normal conditions, so maybe not the best example here.

But if we ignore that, I'll say it's not the job of the SCC to guess if a cell is above a certain voltage as this voltage limit is (and should stay) internal to the BMS so the BMS should have a clearer status for other devices; something like "ok/can't accept charge/can't accept discharge/accept nothing/..."

Sounds like we have somewhat different models.

You make a good point. I was assuming a simpler system with a single BMS and a single 'string' but in a more complex setup, it might not be ideal to cutoff charging across the board based if you have multiple bms' / strings. But If you do only have one BMS it might make sense to communicate to your charger to shutoff charging so it can happen in a way that won't potentially damage the charger.
 
Ok so i'm sorry to ask this question as it is not your responsibility to teach me rudimentary electrical engineering. But what is the purpose of the opamp?

You can use op-amps (operational amplifiers) for a lot of things depending on how you configure them. Here it will be used as a differential voltage follower (differential to suppress the voltage of the cells below the one we measure and voltage follower because we don't amplify or attenuate, the gain will be 1), the simplified version look like this: https://circuitdigest.com/sites/def...ircuit-to-Measure-Individual-Cell-Voltage.png and the full circuit for one cell (just copy-paste for other cells) can be seen here: https://electronics.stackexchange.com/a/64382/54498

Sounds like we have somewhat different models.

You make a good point. I was assuming a simpler system with a single BMS and a single 'string' but in a more complex setup, it might not be ideal to cutoff charging across the board based if you have multiple bms' / strings. But If you do only have one BMS it might make sense to communicate to your charger to shutoff charging so it can happen in a way that won't potentially damage the charger.

Even for one string you shouldn't have to make this decision because the SCC should have stopped the charge long before the BMS hits the OVP. However you make a good point about the SCC being disconnected from battery but not from PV, in this case I would guess something like "I'll kill the battery in 1 sec" from the BMS to whoever device is interested could be a good idea so this device can do whatever he needs before the battery is disconnected. What I don't like too much is the necessary delay, to me the protection should act as fast as possible.

I can see a better solution where the SCC monitors the battery side and if it's gone then it kills the PV side too. Now this solution isn't perfect too as there will be a slight delay (ms) with no battery but PV power to the SCC. However the advantages are that it doesn't depend on com to work and it includes all the cases where the battery can be disconnected without the PV being disconnected.
 
Even for one string you shouldn't have to make this decision because the SCC should have stopped the charge long before the BMS hits the OVP.

ideally yes, but I could imagine scenarios where this might be the case since (as I understand it) the SCC only sees total pack voltage, and is ignorant of individual cell voltage. In most cases if you set a reasonable SCC high voltage disconnect voltage, it will cutout before any individual cell exceeds its safe operating voltage, but a bad cell that is substantially out of balance might surpass whatever buffer you set at the SCC and the SCC would have no idea anything is wrong.


I can see a better solution where the SCC monitors the battery side and if it's gone then it kills the PV side too. Now this solution isn't perfect too as there will be a slight delay (ms) with no battery but PV power to the SCC. However the advantages are that it doesn't depend on com to work and it includes all the cases where the battery can be disconnected without the PV being disconnected.

This seems like a reasonable solution
 
I like where you are going with this. I believe that the BMS should manage the batteries, have appropriate limits (user selectable) and a monitoring station to view the status of the batteries, and be able to communicate to future units of pending actions it plans to take. One could argue that the balancing function should be it's own module that talks to the management system.

Today, it seems that almost all the BMS's are a last straw were are in trouble situation take action now mentality.

Put me on the list, I'll take one!
 
ideally yes, but I could imagine scenarios where this might be the case since (as I understand it) the SCC only sees total pack voltage, and is ignorant of individual cell voltage. In most cases if you set a reasonable SCC high voltage disconnect voltage, it will cutout before any individual cell exceeds its safe operating voltage, but a bad cell that is substantially out of balance might surpass whatever buffer you set at the SCC and the SCC would have no idea anything is wrong.

I see, now the question is "should the SCC handle this problem?", to me it's a problem internal to the battery and it's the BMS' job to handle these problems, the job of the SCC is to handle the charging profile and charging problems, unbalanced pack is not a charging problem.

The way I see things the BMS detect this problem, warn other devices that it'll disconnect the battery and then disconnect the battery; in the mean time the SCC has been warned and has disconnected the PV panels to not harm itself.

However this is only working for a single string system, if we have multiple battery strings in // we want the SCC to continue charging the other strings.

Fortunately all of this is only software so it can be modified and updated easily, what can't be updated easily is the hardware.

I like where you are going with this. I believe that the BMS should manage the batteries, have appropriate limits (user selectable) and a monitoring station to view the status of the batteries, and be able to communicate to future units of pending actions it plans to take. One could argue that the balancing function should be it's own module that talks to the management system.

Today, it seems that almost all the BMS's are a last straw were are in trouble situation take action now mentality.

Put me on the list, I'll take one!

Don't worry about that, the user interface will be easy to do once the BMS is finished, you'll be able to change all the limits and monitor everything that can be monitored ;)

The balancing may be considered as a separate thing but it's so small and simple that it wouldn't make sense to dedicate a MCU (and an IP) just to this feature, that's why I include it in the BMS.


@all There's a little problem with the design I chose for the cells measuring circuit: I can only handle up to 10s (11s pushing it, 40 V is the hard limit) without splitting the mux into 2x 8:1 muxes and driving the upper one through opto-couplers. So that's not a big problem but it'll up the cost of this section by a few $ and take a bit more PCB real estate than what I anticipated.

I wonder if splitting the pack into 2 8s packs with 2 BMS would be a good idea... the BMS will be simpler but the cost per BMS wouldn't change a lot (because switching 400 A with mosfets is 400 A whether the voltage is 24 or 48 V, so same number of mosfets per BMS) so the price would nearly double... So it's a good idea for simplicity but a very bad idea for cost. Any input on that anyone?
 
Last edited:
Thanks for the response that makes so much more sense now.

I think having 2 BMS would work fine.

Since they are both copies people could make 1 or 2 depending on needs.

For example in my case I need 12s but only have max volts of 33 so I could get away with a single bms.
 
I re-read my post and saw the cost part could be misinterpreted so I made it a bit clearer.

I also thought about 2 BMS with only one disconnect but that's a bad idea for a lot of reasons.

Now that I had more time to think about it, I don't think the two BMS approach is a good one as the cost will skyrocket and that doesn't outweigh the slightly more complex circuit than what I was anticipating (that's just splitting things in 2 halves and adding 3 optos after all, not the end of the world). I would have maybe chose the two BMS option if it would simplify other things but that's not the case, everything else would be the same anyway.

Also if you want a 8s BMS it's pretty simple to take this one and remove what isn't useful in this use case.

12s is 43.8 V max (and that's with no margin), how do you have only 33 V?
 
I re-read my post and saw the cost part could be misinterpreted so I made it a bit clearer.

I also thought about 2 BMS with only one disconnect but that's a bad idea for a lot of reasons.

Now that I had more time to think about it, I don't think the two BMS approach is a good one as the cost will skyrocket and that doesn't outweigh the slightly more complex circuit than what I was anticipating (that's just splitting things in 2 halves and adding 3 optos after all, not the end of the world). I would have maybe chose the two BMS option if it would simplify other things but that's not the case, everything else would be the same anyway.

Also if you want a 8s BMS it's pretty simple to take this one and remove what isn't useful in this use case.

12s is 43.8 V max (and that's with no margin), how do you have only 33 V?
I am using LTO cells max volts of 2.8 per cell or a total of 33.6 volts
 
Again please excuse my ignorance of electrical engineering. What I have done is used 2 8 channel relay boards to measure the voltage of each cell starting from cell 1 and subtracting the previous cumulative voltages for cells 2 through 12 this gives me the voltage of each cell. It works quite fine but 2 8 channel relay boards are very large and I'm sure inefficient. I ran each measurement through a single voltage divider between my relays and the measuring device to overcome the high voltage of the upper cells in the series.

What I tried next was using mosfets to iterate through the cells but quickly found out that they don't exactly work that way.

Is there a way to use mosfets or BJT's to do this?
 
Back
Top