diy solar

diy solar

Why Does My Battery Bank Now Top Out at Only 88% Capacity?

I thought about this thread overnight and the only thing I can come up with is what I stated already: Disconnect communication between the BMS and the rest of the system and see what happens.
Well thanks for the suggestions. How should I go about doing this? Just unplug the CAN cable on the top battery of the stack, which connects the batteries to the CerboGX so that it no longer communicates with the CerboGX? What could go wrong?

How about your other suggestion of charging to what Pylontech wants vs. what Victron thinks Pylontech should charge to? I can set absorption voltage and float voltage as well as absorption time with the VEconfigure software I have. What should I set for each value?

Have you tried disconnecting the BMS communication from the rest of the system?
It is my understanding that a Pylontech US3000 battery has a built-in BMS, therefore I'm not sure your comment makes sense. I'm not the kind of person that opens and dissects batteries like Will Prowse. Even if I were, I would refrain since they're under warranty.

For what it's worth, the Victron Touch50 (the touchscreen visual front-end for the CerboGX) on my system tells me the temperature of (I'm assuming) the battery whenever the battery triggers a low temperature alarm, which means that the system itself is able to measure such temperatures. Therefore, in my opinion if this is the root problem I'm having with the batteries then the system should be able to override the erroneous alarm. I don't think that is the root problem. I'm leaning more towards the "info" from the Cerbo being a misidentification of the actual problem. Either way, it sounds like a very annoying, minor, hard-to-diagnose glitch that sounds perhaps like a preview of coming attractions for dealing with this system over the course of its lifetime.

Have you verified that all four batteries are at the exact same voltage and state of charge?
No. Pylontech said I would need some special cable set for that. I reached out to my distributor. Crickets. Reached out to another vendor in Peru. More crickets. Looks like I'd have to have Pylontech send them directly from China. (Unless you can help me come up with another way to verify voltage and soc of each battery).

Here is my latest update from the Victron forum I posted today. The only other thing I tried were the suggestions from Snoobler about Float/absorption/absorption time. Finally had the time today to try those suggestion. It didn't matter. No difference:

From what I can gather, there are two issues:

1) The third battery in the battery bank is preventing the entire battery bank from charging to full capacity.

2) This battery has a red alarm light that comes on once or twice a week. The cerbogx states this is a low battery temperature alarm even when the temperature is 25C (77F). I'm thinking the cerbogx is just misidentifying/mislabelling the actual problem.

Hypothetically speaking, if you could somehow get just one battery in your stack to reach dangerous low temperatures, would that cause the entire battery bank to stop charging when in the 84-89% range?

Yes, my batteries now will not even get above 84% SOC!

The low temperature alarm may or may not be the root cause of this issue. If there's a faulty temperature sensor, then why would it cause the batteries to limit capacity even when no alarm is triggered? As I said, the low temperature alarm is only triggered randomly a couple times per week at most.
 
There are likely tens of thousands of members on this forum that use a BMS that doesn't communicate with anything else in the system. Your battery should be able to stand on it's own. Simply disconnect the communicate cable and see what happens.

Maybe I missed it but are you getting a low temperature alarm? Is the ambient temperature below 32°F / 0°C? I wouldn't expect the upstream components (inverter, solar charge controller, etc) to be able to over-ride a low temperature alarm. In my system where the BMS doesn't communicate with anything, a low temperature situation - as detected by the BMS - would absolutely cut off charging no matter how much the other components wanted to continue charging.
 
There are likely tens of thousands of members on this forum that use a BMS that doesn't communicate with anything else in the system. Your battery should be able to stand on it's own. Simply disconnect the communicate cable and see what happens.

Maybe I missed it but are you getting a low temperature alarm? Is the ambient temperature below 32°F / 0°C? I wouldn't expect the upstream components (inverter, solar charge controller, etc) to be able to over-ride a low temperature alarm. In my system where the BMS doesn't communicate with anything, a low temperature situation - as detected by the BMS - would absolutely cut off charging no matter how much the other components wanted to continue charging.
Yes, Ive been getting a low temperature alarm on that problematic battery every once in a while. The alarm usually comes on when the ambient temperature is like 77F/25C. Pretty silly. It's happened about five or six times in the past two months. It never gets cold here in our climate, so don't ever need a low temperature alarm.
 
Is that a total of four, 48v batteries in parallel ?

Have you tried setting the victron charging profile to have a higher float value for a while, much higher, closer to the bulk charge value, to force it to send a higher voltage to the combined packs longer? Maybe then the under performing pack would balance back up.

Alternatively, can you afford to break up the parallel stack and just let it charge the under performing one by itself for a bit? Maybe run each battery by itself for a day or so until they are all fully charged and then stick them back together?
 
Is that a total of four, 48v batteries in parallel ?

Have you tried setting the victron charging profile to have a higher float value for a while, much higher, closer to the bulk charge value, to force it to send a higher voltage to the combined packs longer? Maybe then the under performing pack would balance back up.

Alternatively, can you afford to break up the parallel stack and just let it charge the under performing one by itself for a bit? Maybe run each battery by itself for a day or so until they are all fully charged and then stick them back together?
Who's to say it's undercharging? It might be overcharged for all I know.
 
Who's to say it's undercharging? It might be overcharged for all I know.
Indeed. It could be it's the only one that's actually working properly and the other three are either overcharged or undercharged. They are ganging up on it and making it look like the guilty one.
 
Today I moved the problematic battery to the master position, and it just gave me an "internal failure" alarm and shows only the red alarm light and none of the charging lights on the module. Got the victron display to read 83% though, which is an improvement from the 82% it was stuck on. The other three batteries seem to be OK (their charging lights are on the same page as each other, and they aren't generating an alarm light).
 
Today I moved the problematic battery to the master position, and it just gave me an "internal failure" alarm and shows only the red alarm light and none of the charging lights on the module. Got the victron display to read 83% though, which is an improvement from the 82% it was stuck on. The other three batteries seem to be OK (their charging lights are on the same page as each other, and they aren't generating an alarm light).
Lots of detail here ... skip to the last paragraph for the crux. Keep in mind that no SOC monitor on a LiFePO4 can simply measure SOC. All it can do is track changes in energy in and out over time and accumulate those. So, that 83% reading only tells you there has been some charging since 82%. It does not necessarily tell you the actual SOC is 83%. As others have noted, unless the SOC monitors have been "synchronized" with a full charge (typically indicated by seeing a voltage somewhere above 3.5V per cell), the reading is suspect. Some 12V batteries with built-in BMS need to see 14.4V to synchronize.

That said, SOC readings tend to drift up over time, not down (between synchronizations). The reason: Most SOC monitors ignore LiFePO4 battery internal losses that occur during charging and discharging because they are small, even falling below levels that the SOC shunt can reliably quantify. Ignoring losses during charging gives a high reading because the SOC monitor reads current in, a bit of which is losses that does not become charge in the battery. Likewise, during discharge, some energy is removed from the battery charge inside of the battery and this is not registered at the shunt. Effectively, the SOC monitor is over stating the charge and understating the discharge. So, cycling a battery without "synchronizing" the SOC monitor occasionally normally results in an SOC reading that is higher than actual.

An SOC reading can also drift upward if there is a load on the battery that is below the SOC monitor's current reading threshold. This threshold varies but is typically down around 0.1 amps (though I had a Lifeblue that ignored any load below 0.7 amps).

About the only way an SOC monitor can read lower than actual SOC is if there is a very small charging current flowing that is below the SOC monitors current threshold. Or the SOC monitor is somehow disconnected when some charging is occurring. Either would be very unusual.

Bottom line is that SOC monitoring is tricky business and one has to really understand how it works and be sure it is maintained (with re-synchronization) from time to time (weekly or sooner).

As such, limiting charge voltage to a level below the SOC reset/re-synchronization voltage can result in a lack of reset and SOC reading drift. Again, this is usually an upward drift, not a downward one.

It seems you have no reason to believe your SOC readings are higher than actual. While it is unusual, there is the possibility they are low. Unlikely, but can't be ruled out. At rest, fully charged LiFePO4 prismatic cells are right at 3.33V. That's 50.025 volts for 15 cells. At rest means the battery is fully charged and then has sat unloaded long enough for self-discharge to bring voltage down to a steady state. Alternatively, a small load for an hour or two can being the voltage down to rest (with the battery still over 99% SOC). Seeing 50.025 V at rest would tell you the bank is fully charged. Down around 49. 6V the battery would be at around 80% SOC. You need to get at the individual cells with a good volt meter to have confidence that the balance is good. Alternatively, some BMS do read out individual cell voltages fairly accurately (within a few mv).
 
Last edited:
Today I moved the problematic battery to the master position, and it just gave me an "internal failure" alarm and shows only the red alarm light and none of the charging lights on the module. Got the victron display to read 83% though, which is an improvement from the 82% it was stuck on. The other three batteries seem to be OK (their charging lights are on the same page as each other, and they aren't generating an alarm light).
Turned off the "internal failure" battery and removed from the stack. Updated VEconfigure to reflect the new capacity of the smaller stack, but the remaining batteries still aren't charging to full capacity. It's been two days, and lots of sun. They get stuck at 84%. The bottom battery actually shows a full six charge lights on the module, whereas the top two only show five charge lights.
 
Lots of detail here ... skip to the last paragraph for the crux. Keep in mind that no SOC monitor on a LiFePO4 can simply measure SOC. All it can do is track changes in energy in and out over time and accumulate those. So, that 83% reading only tells you there has been some charging since 82%. It does not necessarily tell you the actual SOC is 83%. As others have noted, unless the SOC monitors have been "synchronized" with a full charge (typically indicated by seeing a voltage somewhere above 3.5V per cell), the reading is suspect. Some 12V batteries with built-in BMS need to see 14.4V to synchronize.

That said, SOC readings tend to drift up over time, not down (between synchronizations). The reason: Most SOC monitors ignore LiFePO4 battery internal losses that occur during charging and discharging because they are small, even falling below levels that the SOC shunt can reliably quantify. Ignoring losses during charging gives a high reading because the SOC monitor reads current in, a bit of which is losses that does not become charge in the battery. Likewise, during discharge, some energy is removed from the battery charge inside of the battery and this is not registered at the shunt. Effectively, the SOC monitor is over stating the charge and understating the discharge. So, cycling a battery without "synchronizing" the SOC monitor occasionally normally results in an SOC reading that is higher than actual.

An SOC reading can also drift upward if there is a load on the battery that is below the SOC monitor's current reading threshold. This threshold varies but is typically down around 0.1 amps (though I had a Lifeblue that ignored any load below 0.7 amps).

About the only way an SOC monitor can read lower than actual SOC is if there is a very small charging current flowing that is below the SOC monitors current threshold. Or the SOC monitor is somehow disconnected when some charging is occurring. Either would be very unusual.

Bottom line is that SOC monitoring is tricky business and one has to really understand how it works and be sure it is maintained (with re-synchronization) from time to time (weekly or sooner).

As such, limiting charge voltage to a level below the SOC reset/re-synchronization voltage can result in a lack of reset and SOC reading drift. Again, this is usually an upward drift, not a downward one.

It seems you have no reason to believe your SOC readings are higher than actual. While it is unusual, there is the possibility they are low. Unlikely, but can't be ruled out. At rest, fully charged LiFePO4 prismatic cells are right at 3.33V. That's 50.025 volts for 15 cells. At rest means the battery is fully charged and then has sat unloaded long enough for self-discharge to bring voltage down to a steady state. Alternatively, a small load for an hour or two can being the voltage down to rest (with the battery still over 99% SOC). Seeing 50.025 V at rest would tell you the bank is fully charged. Down around 49. 6V the battery would be at around 80% SOC. You need to get at the individual cells with a good volt meter to have confidence that the balance is good. Alternatively, some BMS do read out individual cell voltages fairly accurately (within a few mv).
I got the cables for my laptop to hook up and read this sort of data with the BatteryView software. Not sure how to use the software though. Pylontech tech support is extremely lacking.

Are those voltage levels in your last paragraph always the same? Victron states that they cap the Pylontech charge voltage at 52.4V. That would be 3.49V per cell. How long would it take for the batteries to get to a steady rest state in order to be able to measure the resting voltages? How should I acheive this? Unplug the refrigerator at night and take some readings of the battery modules first thing in the morning? I don't see how I would really know if the batteries are in a steady rest state. E.g. If I were to wait another hour or two, maybe the voltage would continue dropping.

I'll probably have to have someone experienced come out here and get to the bottom of what's going on. It's not longer as simple a task as just sending in the "internal failure" battery and getting a new one in return.

What should be done? If someone comes out here, I need to make sure they are covering all bases.

Thanks for the responses. You sound knowledgeable. You do understand that these Pylontech batteries are "smart" batteries with their own internal BMS, right?
 
Wow what a gauntlet. The three remaining batteries managed to reach a SOC of 91% today. They were stuck at 89% for almost the entire day, but managed to jump up to 91% later in the day. I decided to reconnect the fourth battery (the one that has been the most problematic) to the master position, and it didn't generate any alarms this time! I bought the recommended USB-RS232-Rj11 cables online, but still couldn't get BatteryView to connect properly to my batteries. Not sure why. My distributor was pretty clueless too. The small manual sent to me by Pylontech was really lacking detail, so there's a few things that could probably make the difference.

So the three batteries are almost balanced with each other, but I reconnected the problematic one that I had disconnected three days ago and put it in the master position again. It shows only 3 charge lights vs. the 5-6 charge lights on the other batteries. I'm curious to see what will happen tomorrow as it looks like the other three were getting pretty close to reaching a 100% SOC. Either way, I definitely don't trust this battery bank for the long haul.
 
Last edited:
How many amps were you charging with?
I'm not sure how to tell how many amps were charging. This is a graph of the last 24 hours of my system.
I don't believe it's deliberate, but the way you asked the question seems to imply that I was somehow controlling the amount of amps my system was being charged with. The system was just receiving PV power via my MPPT.
Screenshot 2022-08-15 211404.jpg
 
No hidden agenda or question really. I was trying to understand why it stayed so long at that % state of charge.

On the first graph, I don't understand why your voltage drop at the end occurs without a correlating discharge amperage.
 
No hidden agenda or question really. I was trying to understand why it stayed so long at that % state of charge.

On the first graph, I don't understand why your voltage drop at the end occurs without a correlating discharge amperage.
That probably was the moment when I re-added the fourth battery to the stack. I put it in the master position and it was significantly more discharged than the other batteries.

The next day, the entire bank of four batteries was able to produce a SOC of 94%, which obviously was a huge improvement. Yesterday and today, however, We are stuck at 88% again.
 
Back
Top