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'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 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 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?
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?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.
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.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
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.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.
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.)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... ?
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.)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 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.
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?
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.
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.
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.)
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.
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.
Sorry to take the thread backwards. ?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.
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.
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!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!
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
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.
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.
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?
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.