I have a situation where my MPPT seems to undershoot the CCL of the batteries, resulting in a periodic charge/discharge cycle when the batteries are full.
Setup:
3 Phase Multi RS (off grid for all intents and purposes)
2 strings of PV, approximately 3kWp each. One attached to L1, another to L3
6x Hubble AM-2, communicating via a Cloudlink to the Cerbo GX
As can be seen from the graph below, when the CCL drops to 30A, the MPPT drastically reduce the charge power resulting in about a 17A discharge from the batteries to cover the house load. Once the battery is a bit discharged, the CCL raises again to 120A and the MPPTs cover the house load and charges up the batteries. This happens approximately every 60s.
As can be seen, I am still way under CVL and when the CCL limit lowers, the system drastically undershoots. Most of the time, the charge current was even below the 120A CCL to start with.
What I have noticed is that the battery information (voltage, current, SoC, CCL, etc) only update once every 10s. This is in my opinion extremely slow and can mess with a control loop, but I would expect more of a dead time behaviour than this step response. I believe the slow update rate is due to the Cloudlink is acting as an RS232 to CAN gateway. The batteries do have a CAN onboard, and I will make up a Type B cable to test, but this is unsupported by Hubble.
I have tried the following, all unsuccessful:
Limit the DVCC charge voltage to 53.6V (CVL-0.3V)
Change the battery monitor to the RS for a faster response
I want to eliminate this charge/discharge cycle that happens for most of the day. Any advice would we much appreciated.
PACE BMS’s like Hubble use have a chequered history.
Have you checked, with a meter, that the voltages at all the inverter/battery terminals agree?
There may be a disparity which is throwing the system off.
I changed over to the built in Pace BMS and it seemed to be working, except for refusing to charge the batteries. The BMS is detected, parameters are shown, all Multi RS unit pick up BMS control (after resetting) but no charge. Interestingly, the Multi RS unit do not indicate “Charger Off”, there is just no current flowing.
Did you fully power off the RS and internal solar chargers?
Disable your minimum CVL setting, it should not be needed.
The state of the BMS says “requests charging = no”
I think the BMS is unlikely compatible or configured to work in this way.
The Hubble’s send 53.9V, then later drops it. I have found them much happier to limit
This occurs on many Pylontech BMS and only comes on after a deep discharge. Like the battery requests a gentle charge up. I have other installations happily charging up with this off
Looks like I might be stuck with the 10s RS232 update rate
Hubble have not yet responded. My request ticket to them is to speed up the RS232 comms, of possible.
If that is not possible, I will request using the CAN Bus. They are quite vociferous about using a Cloudlink with Victron, so I’m not sure they’ll entertain the request.
My previous support equipment with them was not great, but I do have a contact that I might escalate to if required.
This can affect balancing. Dropping CVL is the preferred way to manage charge vs a fixed CVL. Freedom do it as well and this results in irregular discharge cycles for final balancing but not the regular ones you see, unless it is a “feature” of Hubble’s bms config.
Hubble technical support has disabled a feature that they call “Adaptive Cell Limits”. This was apparently causing the fluctuating CCL.
They will monitor my batteries and report back.
I still maintain the MPPT’s control loops would be able to handle the drop in the CCL if the BMS didn’t take 10s to report the response in PV to the loop.
