Hi All!
I had installed a 7kWp solar system ,10kVA Quattro and 3 Racpower blue nova li-ion batteries,2x MPPT 250/100.
Since then, the MPPTs were charging the batteries with on 16A, there wasn’t any day the MPPTs charged with a higher current because the CCGX was seeing just 1 Racpower.It would take the whole day to charge the batteries .I got in touch with bluenova support guys whom we took some time trying the DIP switches.Finally we got to a point where we found the correct DIP switch settings and the charge current went upto 50-60A,At this point the batteries wouldl be charged in very short time periods.After we had thought that we had solved the problem,we started getting high voltage alarms,high voltage peaks upto 98V for some seconds and also internal battery monitor error (512).These alarms go on whether on AC mains charging or MPPT charging.
Blue Nova support had suggested to change the BMAC but it looks like they also found that the BMAC is not yet ready for Racpower units.
What should I do with the system?Should I go back to the original set up where the batteries were charging with only 16A?
I don’t know BlueNova batteries specifically, but this is an issue we get a lot of with other batteries.
Many batteries simply go with one static charge voltage. For example, the BMS will say “please charge me to 56V”, and as long as the cells are fairly well balanced that’s 3.5V per cell and everyone is happy…
But if there is an imbalance, then 15 cells is at 3.45V and the last one is being pushed over 3.75V and the BMS is freaking out.
So the solution is almost always to lower your charge voltage. But in a DVCC system where the battery sets this, the user doesn’t have that control. At least not until this makes it into an official release.
The very high voltage peaks is sometimes the result of the BMS disconnecting rather than the cause of it. If the BMS disconnects the battery, then the only thing on the DC bus that can accept the charge current is the capacitors on the DC bus, and they spike up really quickly. I must say, I have never seen voltages higher than maybe 75V. And you may well begin to damage some of the equipment above that (eg, the SMPS of the GX device).
So you need to figure out why the BMS is freaking out (most likely a high cell), and once you determined if that is the case, then one needs to give the battery time to balance the cells so the condition goes away.
To do that, again, you need to lower the charge voltage. Which is what the above is about. But right now the only solution is to patch the python code on the GX device and force a lower voltage than the battery asks for.
HI, I want to make sure that your ESS as well as the config file on your Victron is configured correctly. What is your charge settings configured to on the Quattro? And how does that compare to the recommended charge voltage? What is the voltage settings on the MPPT’s for incase the ESS fails.
Also check the voltages logged by the other components (The VE.Bus voltage, and the Solar Charger). If it really went that high, I would have expected a lot of broken equipment. The GX device itself can only handle about 85V as far as I know.
I suspect the battery logged an incorrect value. Note that it is also logging an impossibly high current, and -273°C for the temperature. It is almost certainly wrong.
Question for the sharp people on the forum. Can you guess why it logs a temperature of -273? I know why… I want to see if anyone else does 
Isn’t that 0 Kelvin’s value in Celsius? So its temperature sensor is calibrated to Kelvin but converted to Celsius for user. So the sensor had a hick up and recorded a zero value?
CORRECT!
The protocol requires that you send the value in Kelvin (cause it is an SI unit). When you see a 273, it means there was a zero in the relevant block in the relevant CAN-bus data frame… which usually means some kind of malfunction. It is common to zero allocated memory to avoid accidental bugs, so when you get a zero value in a place it is not expected, it means some part of code did not fill in the value it should have.
So in short, I would not trust the other values that came from the BMS at the same time. Look at the voltages logged by the solar charger, those would be more trustworthy.
It looks like the temperature and state of health (interesting that it drops to 88, maybe some function taking a bunch of error values, in this clock cycle, in that just randomly gets to 88) are lagged one snapshot from the voltages. Perhaps the SoH and Temp doesn’t get updated at the same rate?
I’ve also wondered if there is some sort of pattern there. Sometimes it could be a kind of buffer overflow, if you think about putting two values next to each other in memory, and you write something to the first that ends up too big for the location and it spills over into the value next to it. It might not overwrite the neighbour completely, in a little endian architecture (which appears to be more common these days) it will tend to change the number slightly rather than massively… so you get a kind of random output. That much is true.
Reminds me of a story I heard of a guy who wrote code deliberately in a way that the last instruction in a loop caused an overflow that incremented a memory location… and then he put the loop counter exactly in that location. That meant he could save the CPU instructions required to increment the loop counter…
Oh this is very clever! Though these days it probably isn’t worth the effort…
That must have been in the days of Assembler or C.
Most popular modern compilers will complain and stop you from doing that.
Yes. Many modern day compilers spoil all the fun…
It did not however (recently) warn about an unsigned int which was accidentally made negative because the order of two subtracted variables were swapped. This caused the process to allocate just a little less than 64k of memory to handle each string (65535 minus whatever the actual string length was). And thankfully the GX has enough memory, so it wasn’t noticed until one day someone assigned a 1-character Custom Name to his solar charger. The code malfunctioned, allocated a zero-byte buffer (and if you realloc() zero bytes it is equivalent to free()) and boom… crashville, population… YOU!
I’ve seen that once of twice on the one BMS … I ignore them as it seems like dud data and it “fixes” itself sommer same time. All happens at the exact same second.
Upgrade to the latest firmware will solve this problem