question

abrahamsolar avatar image

Quattro based SOC % counts down too slowly but CCGX displays correct AC load wattage

Hello, Community folks from Colorado, USA, on 1/29/2020~

My client has a triple stack of Quattro 15's, 50 hz, with firmware version 2656465 on all three. All the PV power is AC coupled via Fronius, so I used VEConfig software to "Enable Battery Monitor" on all three Quattros. I entered 1600 amp hours based on the battery mfr. data & 95% charge efficiency (again from our lithium battery manufacturer).

The Quattro's are presently running only light loads during our shakedown testing. The battery system has its own web portal where it displays AC load wattage & the state of charge that the battery bank is reporting. When the CCGX shows AC loads ~500 watts, the battery smarts are also tracking a very similar wattage.

However, the Victron SOC calculation counts down from 100% much slower than the rate at which the battery bank is counting down the SOC. Could this be due to higher losses per AC watt in the Quattros since they're running at a small portion of their capability?

If that theory is right...shouldn't the Victron logic be more "fuzzy" to report faster battery depletion when the DC to AC battery losses are higher than that assumed by the SOC calculation algorithm?

Assuming 15kVA Quattro machines as in this example, is there a wattage delivery range that was assumed when the SOC calculation algorithm was devised? When AC coupled PV wattage shows up for recharge, I have a similar question: is there a wattage range when charging via AC coupling that is most likely to yield accurate state of charge calculations?

I have a third similar question for when generator driven recharge occurs in this off grid power system: is there a "power band" that was assumed when the Quattro SOC algorithm was developed?

My clients have a BMV 700 with 2000 amp shunt that is running but not presently networked to the CCGX--so we don't have a third SOC opinion in the mix. Would I serve our mutual clients better by networking the BMV & asking CCGX to use that instead of using the Quattro SOC counter?

It seems logical for the Quattro's to calculate SOC since all the energy back & forth to the battery is moving through the Quattro stack. However, I now wonder if the Quattro SOC logic needs more fuzziness.

Reply when convenient, Victron team; thanks in advance~

MultiPlus Quattro Inverter ChargerCCGX Color Control
10 |3000 characters needed characters left characters exceeded

Up to 8 attachments (including images) can be used with a maximum of 190.8 MiB each and 286.6 MiB total.

2 Answers
abrahamsolar avatar image
abrahamsolar answered ·

Greetings & thanks, Daniël. Perhaps one of your colleagues at Victron can further address my question about the reason for the Quattro state of charge inaccuracy. Can you point this out to a staffer who might contribute?

I agree that the battery's reported state of charge always trumps that of any instrumentation. Our lithium battery only displays that via the manufacturer's web portal, however, and the project will not always be internet connected. The clients would like an accurate SOC display that could be seen by people standing within my containerized energy system.

I may go hunting for a display that can show the battery's reported SOC via the local area network LAN that I built into the container. OR: maybe I need to activate the BMV700 monitor so it can report SOC on the Color Control.

Thanks again & sunny days~

Share
10 |3000 characters needed characters left characters exceeded

Up to 8 attachments (including images) can be used with a maximum of 190.8 MiB each and 286.6 MiB total.

Daniël Boekel (Victron Energy Staff) avatar image
Daniël Boekel (Victron Energy Staff) answered ·

Hi @abrahamsolar

A BMV is always more accurate, than an inverter in calculating SOC.


Usually the batteries BMS knows best (not always), so why not use that?

Share
10 |3000 characters needed characters left characters exceeded

Up to 8 attachments (including images) can be used with a maximum of 190.8 MiB each and 286.6 MiB total.