diy solar

diy solar

DIY BMS design and reflection

I’ll do some calculations after I get home. I just tested my diy high-side switch not too long ago. The heat sink was the weakest link. That’s the reason I believe the fet ratio is four to one.
 
I know I'm coming to the party late, and I only skimmed the previous 24 pages of posts, but I have a few questions after looking at the Design and Reflection pages:
  • Have you considered multiple paths to the battery? Separate fail-safe connections for SCC and Loads so that the Loads could be disconnected but the SCC could still charge the battery or the SCC could be disconnected while Loads are able to keep going.
  • For the Human/Machine interface board, will that be able to accept custom code - what are you targeting for a platform/language?
  • Have you had a look at GWL's Cell Performance Monitor board?
I was considering piecing together the GWL board with something like a Raspberry Pi or Arduino so that I could control the SCC/Loads via CAN or Modbus while employing relays to handle soft-start, fail-safe hard disconnect of SCC and/or the Loads.

I've decoded the Schneider Modbus protocol and written some very rudimentary Python code to set the SCC and Inverter into STDBY/ONLINE as well as getting statistical data using Modbus TCP (but I could easily add RS-485 as layer 1 instead of TCP.) For Schneider, you have to have the Conext Gateway to achieve communication since they keep Xanbus pretty close to the vest. Given the specs for other mfgs, I could probably code that functionality as well. If your interface board can run a higher level programming language or even C, I could lend a hand with the communication.
 
I know I'm coming to the party late, and I only skimmed the previous 24 pages of posts, but I have a few questions after looking at the Design and Reflection pages:

It's never too late (well, at least until I have the finished product) ;)


Have you considered multiple paths to the battery? Separate fail-safe connections for SCC and Loads so that the Loads could be disconnected but the SCC could still charge the battery or the SCC could be disconnected while Loads are able to keep going.

Yes, that would be a separate port BMS but I chose to do a common port one since the BMS should not have to disconnect the battery in normal circumstances, a separate port one would be more complex and expensive for not a lot of advantages.


For the Human/Machine interface board, will that be able to accept custom code - what are you targeting for a platform/language?

The HMIB is only a secondary display of the main status and alarms , so it has no code running on it. The main interface will be a web page (self contained so very simple to use) which will do requests to the BMS JSON API over ethernet. So you can also do your own app in the language of your choice on the plateform of your choice very easily since the BMS itself provides an API instead of an UI directly.

The BMS runs on an arduino nano every and will be dev in "C+" (basically C++ but only using a small part of the object features) and will be open source so you can modify whatever you want however you want ;)


Have you had a look at GWL's Cell Performance Monitor board?

At first, no, as I didn't knew it existed when I started the project, but then I saw it a few months ago. It is far from having all the features I want but seems to be pretty nice otherwise.


I've decoded the Schneider Modbus protocol and written some very rudimentary Python code to set the SCC and Inverter into STDBY/ONLINE as well as getting statistical data using Modbus TCP (but I could easily add RS-485 as layer 1 instead of TCP.)

That's very nice, good job ;)


For Schneider, you have to have the Conext Gateway to achieve communication since they keep Xanbus pretty close to the vest. Given the specs for other mfgs, I could probably code that functionality as well.

Yea that's one of the big problems today; everything is a black box with proprietary protocols who aren't even documented properly...


If your interface board can run a higher level programming language or even C, I could lend a hand with the communication.

Thanks a lot ;) I started thinking of how I want to implement some critical stuff since the beginning but for now I really want to finish the hardware side before going too deep on the software side (especially since the software will be a lot easier to do than the hardware, and any problem is easily correctable).

I know I'm not the fastest but I don't have a 20 engineers team on hand and I want to do things the proper way instead of half-assing the thing just to be quicker... ?

NB: not sure if you saw it but I made a summary thread where you can find all the infos about the BMS in a condensed way (so you don't need to read all 24 pages of this thread). There's most notably a block diagram if you want to see what's the role of the different boards and how they work together, etc...
 
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.



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?
I built a 48V pack in 2 batteries of 7P7S cells, mostly so that each was physically manageable for moving etc. In hind-sight I'd have gone for slightly smaller batteries even if that meant more batteries in the pack. Might be moot for your own large system which is probably immovable but if you're designing for others to use then keep mobility in mind.
 
Yes, that would be a separate port BMS but I chose to do a common port one since the BMS should not have to disconnect the battery in normal circumstances, a separate port one would be more complex and expensive for not a lot of advantages.
Actually, I was thinking of controlling relays and not having any power go through the BMS. Are using a common port design to cut down on power consumption?

The HMIB is only a secondary display of the main status and alarms , so it has no code running on it. The main interface will be a web page (self contained so very simple to use) which will do requests to the BMS JSON API over ethernet. So you can also do your own app in the language of your choice on the plateform of your choice very easily since the BMS itself provides an API instead of an UI directly.

The BMS runs on an arduino nano every and will be dev in "C+" (basically C++ but only using a small part of the object features) and will be open source so you can modify whatever you want however you want ;)
A JSON based API does make it easy to manage remotely, it would seem to raise the bar for those less technically inclined. With your project goals in mind, it makes perfect sense though. And if someone like me could add to it and release that to the community, that could lower the bar as well.
At first, no, as I didn't knew it existed when I started the project, but then I saw it a few months ago. It is far from having all the features I want but seems to be pretty nice otherwise.
What features do you see it lacking? My new batteries are on the way, so I want to make sure I make as well of an informed decision as I can before committing both time and money to a BMS project.

Thanks a lot ;) I started thinking of how I want to implement some critical stuff since the beginning but for now I really want to finish the hardware side before going too deep on the software side (especially since the software will be a lot easier to do than the hardware, and any problem is easily correctable).

I know I'm not the fastest but I don't have a 20 engineers team on hand and I want to do things the proper way instead of half-assing the thing just to be quicker... ?
How far along would you say you are to having something to have others test? Like I said, I'm still waiting for batteries, so I'm able to do what I can to help and I want to make as informed a decision to manage my batteries (by far the largest investment in my solar setup.)
NB: not sure if you saw it but I made a summary thread where you can find all the infos about the BMS in a condensed way (so you don't need to read all 24 pages of this thread). There's most notably a block diagram if you want to see what's the role of the different boards and how they work together, etc...
I did look over the diagram, but I think I'll (re)read that summary thread again (or for the first time, since I think I missed it.) The diagram is where I got the information to post my original questions (and hopefully clarify some with this post.)

Good luck. I love to see this kind of work in the community.
 
I built a 48V pack in 2 batteries of 7P7S cells, mostly so that each was physically manageable for moving etc. In hind-sight I'd have gone for slightly smaller batteries even if that meant more batteries in the pack. Might be moot for your own large system which is probably immovable but if you're designing for others to use then keep mobility in mind.

I'm not sure about what you meant about the mobility; can you give more details or explain in another way? thanks ;)
 
Actually, I was thinking of controlling relays and not having any power go through the BMS. Are using a common port design to cut down on power consumption?

Not really if we're talking about SSRs, but yes, and by quite a bit, if we're talking about mechanical relays.


A JSON based API does make it easy to manage remotely, it would seem to raise the bar for those less technically inclined. With your project goals in mind, it makes perfect sense though. And if someone like me could add to it and release that to the community, that could lower the bar as well.

It'll be shipped with the web app of course, so anyone with a device having a web browser can use it ;) I'm not asking people to dev their own app using the API ^^ its just a possibility for those who want.

And, yep, this choice is because it is destined to be part of a bigger system with advanced features regarding energy management around the whole house (and that asks for any device to be able to have access to other devices data to make smart choices).


What features do you see it lacking? My new batteries are on the way, so I want to make sure I make as well of an informed decision as I can before committing both time and money to a BMS project.

Ethernet com, doesn't integrate the high power switch so you need to add/design your own, no shunt input so no coulomb counting, over current protection, etc..., lots of specifications are missing, not sure but I don't see any redundancy on the protections, ...

Basically it's a nice base plateform but for me it has all the details and interesting things missing so you would need to add that yourself (and for some of them, you can't).

NB: keep in mind it's only a personal opinion for my use case, yours can be (and probably is) totally different.


How far along would you say you are to having something to have others test? Like I said, I'm still waiting for batteries, so I'm able to do what I can to help and I want to make as informed a decision to manage my batteries (by far the largest investment in my solar setup.)

It depends if we're talking of alpha testing or beta testing, but in either case it'll be at least a few months.


I did look over the diagram, but I think I'll (re)read that summary thread again (or for the first time, since I think I missed it.) The diagram is where I got the information to post my original questions (and hopefully clarify some with this post.)

Under that diagram there's also a few posts explaining in more details each board ;)


Good luck. I love to see this kind of work in the community.

Thanks ;)
 
It sounds awesome! I think our use cases are not that far apart. I"m big into home automation and I can definitely see the possibilities.

I didn't think about "coulomb counting" as I already have a Schneider BatMon using a 500A/50mV shunt. I did consider using the Raspberry Pi with a shunt or coulomb meter for others, but you're right - it's another add-on.

I'm inclined to wait for your project instead of Frankensteining my own with commercial pieces that will, in the end, probably be less efficient and more costly with less overall functionality. As I said, I don't have my new batteries yet, (still on the "slow boat from China") so I can sit tight.
 
It sounds awesome! I think our use cases are not that far apart. I"m big into home automation and I can definitely see the possibilities.

Then your use case isn't too far from mine ^^


I didn't think about "coulomb counting" as I already have a Schneider BatMon using a 500A/50mV shunt. I did consider using the Raspberry Pi with a shunt or coulomb meter for others, but you're right - it's another add-on.

Ok, since you already have a shunt with a monitor it's less important to have it on the BMS (well, you can't do things like OCP and that's kind of important to me...). However the BMS can do a lot more things if he knows the SoC of the battery (and the only reliable way with Li batteries is to use current over time; voltage isn't good enough to extrapolate the SoC like with lead batteries) so it boils down to what features you want exactly in the end.


I'm inclined to wait for your project instead of Frankensteining my own with commercial pieces that will, in the end, probably be less efficient and more costly with less overall functionality. As I said, I don't have my new batteries yet, (still on the "slow boat from China") so I can sit tight.

No problem ;) In the end it's the same as with everything: check out the BMSs on the market and make your choice ?

I should have some time this week to work on the HMIB PCB. I already solved all the physical constraints (this PCB being used for a front panel and as an optional means of supporting most of the other boards there's quite a few constraints...) ;)
 
Yep, order of contribution to temp increase is heatsink, PCB, thermal paste, solder.

It would be this one cut to 35 mm length. I can cut to a bit longer to lower the Rth but then it'll be longer than the PCB (not a big deal but not ideal).
Sorry to take the thread backwards. ?

Many of the new thermal pads are much more efficient than thermal paste. They are much easier to use also without all the cleanup.
They can get expensive, but there are some mid-range ones that still outperform paste.
 
Sorry to take the thread backwards. ?

Many of the new thermal pads are much more efficient than thermal paste. They are much easier to use also without all the cleanup.
They can get expensive, but there are some mid-range ones that still outperform paste.

"Thermal paste should be around 0.1 °C/W so 0.2 °C increase."

"The total is then a 37°C increase for a 40 °C budget."

OK, so we can reduce the 0.5% contribution by thermal paste to an even smaller amount.
:)

Bet I could get a lot more bang for the buck by positioning a paper towel roll as a chimney over the heatsink to enhance convective flow.

 
Sorry to take the thread backwards. ?

Many of the new thermal pads are much more efficient than thermal paste. They are much easier to use also without all the cleanup.
They can get expensive, but there are some mid-range ones that still outperform paste.

Thermal paste will be between the PCB and heatsink so that's quite a large area (around 130*35 mm twice), so I highly doubt thermal pads would be a good solution here but if you have a link I'll check it out ;)

Edit: actually there's another downside to thermal pads here: usually they have a lot of give and I don't want to put stress on the MOSFETs (PCB will flex but not the MOSFETs).


OK, so we can reduce the 0.5% contribution by thermal paste to an even smaller amount.

Yep, thermal paste is not really the first thing to improve here. I could use Arctic Silver 5 instead of the good old standard white one for example but the gains would probably be insignificant for a big increase in cost.


Bet I could get a lot more bang for the buck by positioning a paper towel roll as a chimney over the heatsink to enhance convective flow.

I thought about it but the main problem is it's not practical here. I'll probably have to add in the manual that for full current capability the DPB needs to be in certain orientations (mostly, not horizontal...) but maybe I'll have a good surprise during IRL tests (as I like using worst cases to design...) and that will not be needed even ?
 
I'm not sure about what you meant about the mobility; can you give more details or explain in another way? thanks ;)
Too heavy (or awkwardly shaped) to safely lift on your own & carry up/down stairs then twist/stretch to put on a shelf. In my first build, each battery box was well over 21kg. Not a technical thing but where tech meets humans you have to remember the poor puny humans!
 
Too heavy (or awkwardly shaped) to safely lift on your own & carry up/down stairs then twist/stretch to put on a shelf. In my first build, each battery box was well over 21kg. Not a technical thing but where tech meets humans you have to remember the poor puny humans!

Ok, I see ;)

But here I'm building a BMS, not a whole battery, so you can arrange your battery as you want for mobility or other purposes.


For the cell sensors, have you thought of a distributed system to massively reduce wiring clutter & allow much wider scaling?
https://en.wikipedia.org/wiki/Battery_management_system#Topologies E.g. "Distributed Regular" here https://emusbms.com/application-examples

Yes, but I find it's actually more clutter (and a PITA on the mechanical side too) to have one PCB per cell and still at least a wire pair for daisy chaining, for only 16 cells. However it makes sense for higher voltage packs like in EVs for example. It would also be more expensive and complex since you would need to duplicate the analog to digital conversion circuitry.
 
For the total thermal power, yes, but the main limit is the individual thermal power and it'll be too high if you put only 1/4 of the MOSFETs because then you'll have double the current per MOSFETs so 4x the dissipated power per MOSFET.

Here's how I see it. You're using 20 FDBL86361_F085 fets in a back-to-back configuration. In other words 10 pairs of fets. Per spec, ON resistance is 1.1 mOhm at 25C. Figure 12 of spec states ON resistance is about 1.6 times greater at 110C junction temperature. I'm assuming 110C is operating temp when conducting 300A. ON resistance is 1.1 mOhm * 1.6 = 2.2 mOhm.

Power dissipation per fet at 300A: P = I^2 * R = 30A * 30A * 2.2 mOhm = 2 W

Total power dissipation: P = 2W/fet * 20 fet = 40 W

The fet has a thermal impedance (j-c) of 0.35 C/W. Temperature rise is 2W * 0.35C/W = 0.7 C

The big unknown if the thermal resistance of the heat sink. It might be around 2 C/W. In that case, temperature rise in heatsink is 80 C.

If ambient temp is 30 C, fet junction temp is 30 + 80 + 0.7 = 110.7 C.

*********************************************************************************

In a separate port design, using just 5 fets we get:

Power dissipation per fet at 300A: P = I^2 * R = 60A * 60A * 2.2 mOhm = 7.92 W

Total power dissipation: P = 7.92W/fet * 5 fet = 39.6 W

Temperature rise per fet is 7.92 W * 0.35C/W = 2.8 C

Heatsink temp rise: T = 39.6 W * 2 C/W = 79.2 C

If ambient temp is 30C, fet junction temp is 30 + 79.2 + 2.8 = 112 C.

110.7 C is virtually equal to 112 C.

*********************************************************************************

Conclusion: you can use 4 times fewer fets with a separate port design if just the load is switched. Charging sources are disabled at their input and not high-current output. The design is much simpler and has a sizable cost savings ($60 vs $15 for the fets).

What happens in an over voltage fault condition when the body diode conducts? I don't think the fets can survive 30A * 0.7 = 21 W dissipation/fet, or 230 W at the heatsink.
 
You forgot I'll have two heatsinks, and with 5 FETs you would have only one of the two, effectively doubling the global heatsink Rth (hence why you have a 4x factor where I calculated 2x).

You also ignored the PCB Rth (+ the solder and TMI Rth, but those are less important) which is important since it's 3 times bigger than the FET Rj-c.

What happens in an over voltage fault condition when the body diode conducts? I don't think the fets can survive 30A * 0.7 = 21 W dissipation/fet, or 230 W at the heatsink.

Yep, that's also my opinion, and why I did a bidirectional switch ;)
 
  • Like
Reactions: Cal
You forgot I'll have two heatsinks, and with 5 FETs you would have only one of the two, effectively doubling the global heatsink Rth (hence why you have a 4x factor where I calculated 2x).

You also ignored the PCB Rth (+ the solder and TMI Rth, but those are less important) which is important since it's 3 times bigger than the FET Rj-c.



Yep, that's also my opinion, and why I did a bidirectional switch ;)

We need to keep the heatsink Rth equal in the two comparison (apples to apples). If you are using 2 heatsinks each having 2 C/W then that equates to an effective capability of 1 C/W. Attach a 1 C/W heatsink to the 5 fet system and the factor again is 4x.

I ignored PCB Rth in my analysis as the effect is minimal. No need to clutter up a simple thermal analysis.

Don't understand your bidirectional switch comment. By design, back-to-back fets make a bidirectional switch. That doesn't answer the issue of the body diode conducting during a fault. Are you implementing Pidjey design where current flow direction eliminates body diode conduction?
 
We need to keep the heatsink Rth equal in the two comparison (apples to apples). If you are using 2 heatsinks each having 2 C/W then that equates to an effective capability of 1 C/W. Attach a 1 C/W heatsink to the 5 fet system and the factor again is 4x.

In that case, yes, the factor will be 4x ;)


I ignored PCB Rth in my analysis as the effect is minimal. No need to clutter up a simple thermal analysis.

Ok, but why caring about the Rjc then?


Don't understand your bidirectional switch comment. By design, back-to-back fets make a bidirectional switch. That doesn't answer the issue of the body diode conducting during a fault. Are you implementing Pidjey design where current flow direction eliminates body diode conduction?

With back to back MOSFETs the diodes can't conduct since they are back to back.
 
  • Like
Reactions: Cal
In that case, yes, the factor will be 4x ;)




Ok, but why caring about the Rjc then?




With back to back MOSFETs the diodes can't conduct since they are back to back.

Glad we're in agreement regarding 4x fet reduction when implementing separate ports. :)

Why care about Rjc? The ultimate goal is to calculate junction temperature. Even if the value is small, it's an essential component for thermal flow: junction-to-case-to-heatsink-to-ambient. The starting point (ambient temp) and the end point (junction temp) should be documented in the thermal equation. Minor impedances in-between can be neglected for the sake of simplicity.

Perhaps you haven't understood my question. How do you prevent the body diode from conducting load current in a single port system when a over-voltage fault is active? In other words, charging is disabled, but load current is enabled.
 
Back
Top