diy solar

diy solar

Parallel Cell Capacity Balancing (PCCB) Procedure.

On page 18 is the start of section 3.3 Parallel Battery Bank Wiring. It describes the issues with paralleling 12V batteries into banks because small resistance/path differences can manifest in large charging/SOC differences for even matched batteries. Most of the examples are variations of approaches to match the current paths for parallel batteries.

This would take an alternative form for paralleling cells. See the image below on what I'm working on ( examples of an 8S and 4S battery made on 2P cells ). The series connections are made with copper buss bars and the parallel connections with lower current capacity protection PCB's (under development)

The document is by Victron which you can probably find somewhere else but I have it in my dropbox account.

 

Attachments

  • nS batteries from 2P cells.png
    nS batteries from 2P cells.png
    57.1 KB · Views: 13
This is equivalent to 16.8V!!! for 4S and far exceeds 3.65V (14.6V 4S) typically quoted. So while not advised to make a habit of it, as centra in amount fo voltage above 3.65 is tolerable. That said there does not seem to be much benefit for setting the upper voltage above perhaps 3.5V of 14.0V 4S provided cell balance is no tan issue.

This is what 'we' did in the old days before the chemistry was better understood. However if you look at the charge graph of a LiFePO4 cell, you can see that there is very little capacity in the range 3.55V to 3.65V. Going over 3.65V just puts more stress on the cell. I'm sure you know this, just thought I'd explicitly mention that for other future readers of the thread.

By the way, I did contemplate on doing something similar to what you did, but I just couldn't find time time to do this with 32 cells (or 64 cells this year). Good to see you wrote down the details here!
 
This is what 'we' did in the old days before the chemistry was better understood. However if you look at the charge graph of a LiFePO4 cell, you can see that there is very little capacity in the range 3.55V to 3.65V. Going over 3.65V just puts more stress on the cell. I'm sure you know this, just thought I'd explicitly mention that for other future readers of the thread.
Thanks for the clarification, I only went initially to 3.65v for top balancing and as an initial measure of capacity as that is what is in the spec sheet states as capacity test conditions. I never went down to 2.5V because my invertor would shut off before then.

Now I'm leery of even going to 3.5V especially with my bloated cells and looking t 3.45 has a happy medium between longevity and capacity.

By the way, I did contemplate on doing something similar to what you did, but I just couldn't find time time to do this with 32 cells (or 64 cells this year). Good to see you wrote down the details here!
Yes, I have seen comments reference some type of parallel balancing technique but no actual results. After going through the process It is surprising (although the mathematics back it up) how well this works. Basically, this can be more effective than any factory matching is likely to be. Getting 4 or 8 cells to match is going to be harder to beat, but the statistics work against you for a matched 32 or 64 cells set as there is going to be a higher probability of some outlier with low capacity.

With the pair matching, the more cells the better matching you can achieve. A suspect as 32 cell 16S2P will have excellent tracking. Even with my 4S2P example, the single lowest capacity pair sticks out like a sore thumb at 70mv on high and low ends.

It seems that parallel strings are more popular despite the fundamental safety issues so I assume this cell parallel technique is seen as less desirable which is something I can't figure out why?

 
Now I'm leery of even going to 3.5V especially with my bloated cells and looking t 3.45 has a happy medium between longevity and capacity.

Yes, no need to go that high unless you use (usually low current compared to cell capacity) active balancers.

It seems that parallel strings are more popular despite the fundamental safety issues so I assume this cell parallel technique is seen as less desirable which is something I can't figure out why?

Considering that many BMSes we use have individual charge and discharge control, and solar usually deals with relatively low C rates among other things, it's a pretty decent and flexible solution. A lot of the issues mentioned in the Orion document might also be more relevant to different chemistries than LiFePO4 - since the LiFePO4 curve is so flat, you don't have a lot of Eddy currents over the majority of the SoC for example.

I also run parallel strings with 16 cells each. If you have a BMS that can control charge and discharge independently (essentially what's on page 13 of the pdf), pretty much all of the issues that are relevant are pretty much mitigated.
 
Last edited:
A lot of the issues mentioned in the Orion document might also be more relevant to different chemistries than LiFePO4 - since the LiFePO4 curve is so flat, you don't have a lot of Eddy currents over the majority of the SoC for example.
So I'm not sure exactly what is meant by eddy currents, but I have seen a significant charging imbalance from charging two 4S batteries. 20 amps in with a 16 and 4 amp split because of the way the cables were run from the charger to the parallel batteries. The point is that with the flat LiFePO4 voltage/SOC curves even very small voltage differences can result in high currents.

I also run parallel strings with 16 cells each. If you have a BMS that can control charge and discharge independently (essentially what's on page 13 of the pdf), pretty much all of the issues that are relevant are pretty much mitigated.
Thanks for pointing this out. I did not realize the author was probably describing BMS functionality using diodes(FET body diodes) and relays (FETS).

I know that makes it simpler to understand, but FETS fail 90% of the time in a short circuit configuration and breaker/contactor or relays should be used to back up to any FET design in the event of potential FET BMS failure. So for safety criticality, they should draw a distinction between the two.

You don't always have a backup every FET design with a breaker, but I am tending to have a mechanical-breaker with auto rest or pushbutton reset on all battery connections. Given what would likely happen with a shorted cell and a shorted BMS, a mechanical backup is going to be substantially improved fail-safe.
 
I would say that a breaker is always necessary, no matter if you're using a FET or Relay design - a Relay contact can fuse together as well.

So I'm not sure exactly what is meant by eddy currents

They mean currents going from one battery to the other directly.

because of the way the cables were run from the charger to the parallel batteries.

Yes, me too. Common bus bar and same length cable are good to have. Having bad wiring is detrimental to putting batteries in parallel since it causes all kinds of issues, including the one below.

The point is that with the flat LiFePO4 voltage/SOC curves even very small voltage differences can result in high currents.

But these usually only occur the moment the batteries are connected together, and these can be mitigated by being in the 'middle' of the curve when connecting (or fully charged and settled). I've not seen this once they are connected for a while (and sound connections exist).
 
But these usually only occur the moment the batteries are connected together, and these can be mitigated by being in the 'middle' of the curve when connecting (or fully charged and settled). I've not seen this once they are connected for a while (and sound connections exist).

Well, this is a hypothetical event with an assumed cell short. While my initial assumption is that any cell imbalance would be detected by the BMS and the string might be shut down, the flatness of the curve allows for large currents with minimal voltage drop. So this would seem to create a situation where say a single point cell failure would cause even a small (e.g. 0.050V) voltage drop but would involve a large current flow and that voltage drop although the BMS can see it it would not be enough to trigger a disconnect unless the voltage was at the bottom of the range.

We can clearly see (in the other Last Fire thread) the situation where high currents were sustained for a long period of time and likely with little voltage drop from the healthy cells (according to standard V vs SOC characteristics). So it would appear that detecting shorted cell faults using voltage sensing is going to have a fairly large window of unobservability for LiFePO4.

I'm obviously rethinking parallel cell vs parallel string in terms of an integrated system reliability/safety/maintainability or even more generally lowest downtimes. For example, I'm looking at designing parallel bus bars PCBs for direct current flow measurements between balanced parallel cells and or temperature sensors at each battery post to detect these types of events as a backup to simply relying on BMS voltage monitoring.

In order to avoid the rat's nest of the sensor wires, the only interconnects will be 4 conductor cables daisy charged between the bus bar PCBs where all communications is across I2C. This is going to require a central controller and in fact, would probably serve as a supervisor for the BMS.

The main motivation is for a hybrid battery backup solar for the house (32 x 280 amp-hr cells). This is all probably overkill for the van (8 x 100 amp-hr cells).
 
would probably serve as a supervisor for the BMS.

I'm actually building something similar to this: a supervisor that has full overview of the entire system and can communicate with every device. It's still a long way from being done due to lack of time... It actually came from the Grafana logging that @BarkingSpider was doing - I added some of my devices to that. As I was investigating the comms protocols I thought, why not expand on this and instead of just logging, build a system that has full overview of everything that goes on. Since we're logging all available data anyway, we can use it for something more.
My plan is to throw some AI/Statistical methods at it to be able to have a system that not only can react when things go wrong, but a system that can optimize based on usage patterns.
 
I'm actually building something similar to this: a supervisor that has full overview of the entire system and can communicate with every device. It's still a long way from being done due to lack of time... It actually came from the Grafana logging that @BarkingSpider was doing - I added some of my devices to that. As I was investigating the comms protocols I thought, why not expand on this and instead of just logging, build a system that has full overview of everything that goes on. Since we're logging all available data anyway, we can use it for something more.
My plan is to throw some AI/Statistical methods at it to be able to have a system that not only can react when things go wrong, but a system that can optimize based on usage patterns.

Yes, there are many things that can be done, but the problem is the return on investment. It is hard to justify the time/expense involved in this type of development for a 1 off. Although for a large house battery system the safety issues are very compelling and worth putting in the time. I have been evaluating various Arduino compatible ESP32 devices. I do mostly C++ development for embedded systems and these devices make it easy to develop a product where the CPU is a plugin. Of course, if you can find an open source project that does what you want there will be much less effort. I have noticed that Overkill Solar , Victron and Renogy/Rich have Arduino libraries to talk to their respective devices so there are several integration options available.

I am well into designing an alternator temperature-based charging controller for kind of put that on the back burner when I figured out I can buy a 300 amp alternator for $220!.


I was looking at this as a platform for a more sophisticated touch screen UI.


These are all BT, WiFi capable so the sky is kind of the limit, but I'm not falling all over myself to push data to the cloud to access analytics from my beach chair in the Bahamas LOL.

My first priority is to find a topology to isolate a single point cell failure to that cell so that it can be isolated (disconnected electrically) and insulated thermally in the pack. I don't know if that is better done in parallel or serial because I'm concerned with detection (as described before). The instrumented busbar is most useful for parallel cells although there are benefits that a sting approach could benefit from as well (i.e. thermal sense/shutdown at the cell/string level).
 
I'm actually building something similar to this: a supervisor that has full overview of the entire system and can communicate with every device. It's still a long way from being done due to lack of time... It actually came from the Grafana logging that @BarkingSpider was doing - I added some of my devices to that. As I was investigating the comms protocols I thought, why not expand on this and instead of just logging, build a system that has full overview of everything that goes on. Since we're logging all available data anyway, we can use it for something more.
My plan is to throw some AI/Statistical methods at it to be able to have a system that not only can react when things go wrong, but a system that can optimize based on usage patterns.
I found several references of fault detection but this one deals with single-cell ML to detect internal shorts.

The literature is rich with the methods of ISC detection in the LiBs. However, the following reasons limit the
applicability of the available methods for the detection of mechanical abused induced ISC in the smart phone’s
LiB.
1. Some of the reported methods are only applicable to the battery packs where multiple cells of similar specification
are present34,56.
2.) In the smart phones, the battery temperature40,42,57 at the appropriate spot may not be available. In addition,
the temperature rise happens just before the thermal runaway, therefore early warning may not be
possible.
3. In case of the smart phones, the normal device operation cannot be hampered by any special charge-discharge

profiles46,47,58,59.


So as I mentioned before, fault observability using cell voltage of an internal short is problematic (especially for LiFePO4 and it's flat curve). By paralleling cells, you get a redundancy at the cell level against degrading cells, but also in a failure mode, you will get a very good indication based on the current movement between the two cells which is not obvious from any voltage measurements at the string level. Even if it is detectable, it probably will not trigger the Min-Max cell/string level fault detection of a standard BMS.

So while I know it is very popular to do parallel strings for "redundancy", properly instrumented, the parallel configuration is intrinsically redundant because of current sharing at the cell level, but also the current sensing would give a much earlier detection of fault level current flows. Anyway, that is how I am leaning and looking for any good reasons why this is not going to be true.
 
properly instrumented

This is also the reason why (e.g. with 18650 this is often done) that individual cells are fused. I have yet to see anyone doing this with these LiFePO4 cells, but I have this nagging feeling that this would not be a bad idea.

the problem is the return on investment

I'm not too concerned about that aspect. I've got the communication with all my devices running over RS485, most of them using Modbus.
I have extensive background in embedded development, software engineering and electrical engineering, and this is a fun side project for me. If this ever gets more 'generic' I don't know.
 
They mean currents going from one battery to the other directly.
Wot?

That's not what eddy current is. Eddy current is induced current in a material from electromagnetic interactions.

Has nothing to do with current moving from one cell to another unless you're referring to generating magnetic fields while doing so, which is irrelevant in this context of simple current flow from cell to cell via voltage (or lack of).

 
This is also the reason why (e.g. with 18650 this is often done) that individual cells are fused. I have yet to see anyone doing this with these LiFePO4 cells, but I have this nagging feeling that this would not be a bad idea.



I'm not too concerned about that aspect. I've got the communication with all my devices running over RS485, most of them using Modbus.
I have extensive background in embedded development, software engineering and electrical engineering, and this is a fun side project for me. If this ever gets more 'generic' I don't know.

It seems as if the single-cell failure scenario while are fairly rare has such a high impact, it becomes a primary factor in a risk assessment for these Lithium battery systems. This has raised my awareness about the physical configuration of the compressed battery pack and how to insulate individual cells from the others while at the same time providing for compression ( to allow for expansion) but eliminate as much as possible electrical post stresses on the individual cells. This process is underway for a DIY solution. Quick question,m what are you doing for compression and how long have your cells been in service?

I looked at your blog and background. Nice cabin; it seems like a very nice off-the-grid retreat. You also have an impressive background; it is hard to imagine you have much time to act as an administrator here.

My background in Electrical Engineering and Systems theory (optimization, controls, and estimation) and is primarily in the US DoD, first on the contractor side and then on the government side. Obviously, complexity is recognized as increasing in everything, and there is a whitewater of activity with strong focuses on model-based development, agile processes, and agile enterprise-level business processes (e.g. SAFe).

Recognizing this (based on frustrations with program performance working in the government side), in about 2014-15 I started a project called SimPADS (for parafoil guidance systems with support from NPS) which had the stated goal to develop an integrated end-to-end toolchain for mixed development (Windows simulations targeting ARM platforms) applicable to small UAV programs which would be coming under higher levels of scrutiny by the FAA. Essentially this was a C++/UML/OOD modernization of the process I have spent about 10 years developing during the 1990's.

Quite surprisingly there were some fundamental theoretical findings on the structural global optimality of OO inheritance models/stacks that I discovered. So I started with Hann-Banach Dual Space optimization and jumped off into set theory, model theory, and even deeper into modal analysis and modal collapse. The objective is to confirm theoretically what this global optimality looks like and why it is so. Ultimately it is about models the correctness of which can only be demonstrated if they work.

In 2019 I completed and posted this preprint as a test of the theoretical proof (you may recognize the topic).


Based on comments received, I realized I needed to formalize what I call a Constructability meta-model (the basis for all optimal minimal constructions) all of which is what got me into model theory and ultimately a model of modal collapse. I never thought I would go so far afield into abstract mathematics and logic (it is all far different than engineering or even applied mathematics). But as it turns out there is as much if not more controversy in these areas as in systems engineering and probably software engineering as well (although my sense is the SWE is coalescing faster by necessity).

Here is a sample of an abstract, and I'm using UML to organize even this formal proof (again you may have heard of the topic before).



Thanks for your time reading my posts.
 
Wot?

That's not what eddy current is. Eddy current is induced current in a material from electromagnetic interactions.

Has nothing to do with current moving from one cell to another unless you're referring to generating magnetic fields while doing so, which is irrelevant in this context of simple current flow from cell to cell via voltage (or lack of).

Yea, in electrical engineering, IIRC, eddy currents typically only come up in magnetics, so there is a little bit of creative license here on what is an eddy current. If I have an array of cells in series/parallel configurations it is like a matrix of currents superimposed (remember sophomore year Circuits I/II) which can be described as eddy currents I guess but in my original comments, it is not really clear by any convention I am aware of.

EDIT, I just remember this is called mesh equations and definitely not eddy.


ParallelEddy.png
 
what are you doing for compression and how long have your cells been in service?


They've been in service for over a year now.

I looked at your blog and background. Nice cabin; it seems like a very nice off-the-grid retreat. You also have an impressive background; it is hard to imagine you have much time to act as an administrator here.

Thanks! Admin work for this site doesn't take much of my time. I manage the search engine side of things, and that server is used for other things so it's not that it takes an entire new one to manage separately.

Your background is interesting! I have done a DARPA project in the past so I'm aware of some of your frustrations :)
 

They've been in service for over a year now.



Thanks! Admin work for this site doesn't take much of my time. I manage the search engine side of things, and that server is used for other things so it's not that it takes an entire new one to manage separately.

Your background is interesting! I have done a DARPA project in the past so I'm aware of some of your frustrations :)
One of the projects we (Prof Yakimemnko from NPS, myself, and another) tried to get funded through the Office of Naval Research (ONR) was a typical example of the bureaucracy. The R&D project was to develop the logical and theoretical framework (in a pilot project) which is the equivalent of IoT for the DoD subject to the JCIDS Key Performance Paramemets for Logistics. Basically, it is the optimization (Ao vs Total life cycle cost) of the entire supply chain and maintenance process in response to mission demands; a giant multi-echelon machine learning application for tactical/logistics decision support.

Ultimately they did not care about saving money............................" Sorry not interested" although this is the stated top objectives from the Under Secretary of Defense (Circa 2010). The DoD is about spending money not saving money. The more efficiencies the more budget the more power the more they like it.
 
One of the projects we (Prof Yakimemnko from NPS, myself, and another) tried to get funded through the Office of Naval Research (ONR) was a typical example of the bureaucracy. The R&D project was to develop the logical and theoretical framework (in a pilot project) which is the equivalent of IoT for the DoD subject to the JCIDS Key Performance Paramemets for Logistics. Basically, it is the optimization (Ao vs Total life cycle cost) of the entire supply chain and maintenance process in response to mission demands; a giant multi-echelon machine learning application for tactical/logistics decision support.

Ultimately they did not care about saving money............................" Sorry not interested" although this is the stated top objectives from the Under Secretary of Defense (Circa 2010). The DoD is about spending money not saving money. The more efficiencies the more budget the more power the more they like it.
any entity that plays the "spend very little money until the end of fiscal year and then spend as much as you can so you do not lose money from your budget" could stand to have a few theoretical models to slow their roll on the supply/spending side. I have seen so much waste from the government I got sick of looking at it. Most of the time sending a complaint up is not worth the damage to ones career.

At your point of view it must be truly appalling. i was simply looking at it from a GS12 perspective on the management side.
 
Posplayr,

Just seeing this thread today. The engineer (mechanical) in me has been thinking of using this type of cell matching approach when my cells finally arrive. Your results have convinced me to pursue it.

Thanks!

100 Proof
 
Back
Top