question

pfalzkind avatar image
pfalzkind asked

MPII: redundant overvoltage protection in case of BMS fail ?

Hello,

I'am using a MPII 48/3000/35-32 connected via a MK3 USB interface to a Rasperrry 2B VenusOS 2.94 as controller. I'm using the ESS assistant with a 16s 230Ah EVE Battery. The BMS is a JKBMS, connected to the Rasperrry VenusOS via 2 converters (? -> RS85 and RS485 -> USB). Serial battery driver 0.14.3 is installed, and I think I've understand how to limit charge current via SOC and cell voltages. VRM is not activated.

Generally, everything works fine so far.

A minor issue is, that I lowered the overvoltage protection to 3.53 V in the BMS, and limited the charge current to 0 Amps by serial battery driver (utils.py) at 3.5 V. This is to let the cell voltage regulary bounce against overvoltage protection in BMS, which leads reliable to a SOC of 99%. If there's a greater gap, SOC does not reach 99% and drifts down. So I regularly get overvoltage alarms, but this seems to be no problem until now.

My question is, what happens, if the BMS fails in the way, that it measures to low voltages. Or if it fails in cutting off the battery from the MPII in case of overvoltage. In the MPII datasheet I could not find the maximum voltage it can put on the battery. There's an absorbtion voltage of 57.6 V, but as some guys build 18s batteries, maximum voltage may exceed 65 V, I'm not sure.

The szenario, that a BMS fails is real, it happend to a friend of mine. Ok, he charged the battery with a china solar charger, not with a MPII. The solar charger exposed the battery to the voltage of the solar panels, which is much to high, and the BMS did not cut off.

To put the question in other words: When the MPII listens to the BMS (concerning voltage, SOC, current limits), does it still also listens to the voltage it measures on its own ? This would be some kind of redundancy, which would calm my sorrow.

regards
Pfalzkind

overvoltage.jpgvenus1.jpgvenus2.jpg

Multiplus-IIBMSserial
overvoltage.jpg (86.7 KiB)
venus1.jpg (30.5 KiB)
venus2.jpg (31.6 KiB)
2 |3000
Toggle Comment visibility. Current Visibility: Viewable by all users

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

2 Answers
nickdb avatar image
nickdb answered ·

You should be manually setting limits via veconfigure on the multi and mppts that suit your battery.

In any case if the system is using a managed battery and the bms is not seen, mppts will stop charging with an error 67 (bms lost).

2 comments
2 |3000
Toggle Comment visibility. Current Visibility: Viewable by all users

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

pfalzkind avatar image pfalzkind commented ·
Thank you nickdb, good to know this behavior. Before I connected the JKBMS to the raspi VenusOS, I configured the multi, more precisely the ESS the way you point out. And it worked. So I think in case of loosing connecting between BMS and MPII it'll work fine.

But I thought of a malfunction of the JKBMS, measuring e. g. wrong voltages. Do you know, if at some level of difference (between voltage from BMS and self measured voltage of the MPII) the MPII no longer trusts the BMS?

0 Likes 0 ·
nickdb avatar image nickdb ♦♦ pfalzkind commented ·
The system will honour the lowest setting, so if the multi and mppt's are configured with the correct max CVL, even if the BMS goes off piste, the chargers will be capped to what you set them to. Same applies to CCL.
0 Likes 0 ·
Mike Dorsett avatar image
Mike Dorsett answered ·

and I think I've understand how to limit charge current via SOC and cell voltages.

Charge current should be regulated on the highest cell voltage: such that the current srtarts to tail off above 3.48V and reaches zero by 3.55V (typ cell voltages). I set The ABS Max cell voltage for alarm at 3.6V, and the charge volt limit at 3.55V. This way I slowly charge at the rate permitted by the balancing circuit above 3.48V and it can take 5 hours or so to go from ~95% soc to 100%.

SOC is a calculated parameter for a battery, and should not be used for regulation or protection limits.

1 comment
2 |3000
Toggle Comment visibility. Current Visibility: Viewable by all users

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

pfalzkind avatar image pfalzkind commented ·

Thank you Mike, yes you're right, I should remove charge current limits based on SOC, although serial battery driver offers this feature.

My settings in utils.py concerning charge current limitation based on cell voltages are:

CCCM_CV_ENABLE = True
CELL_VOLTAGES_WHILE_CHARGING         = [3.50, 3.45, 3.40, 3.30]
MAX_CHARGE_CURRENT_CV                = [   0,    5,  30,  60]

Cell overvoltage protection in JKBMS is set to 3.53 V, balancer starts balancing at 3.45 V.

So I think, balancer can work quite well with this settings. I also reach 99% SOC and there's no SOC drift (hopefully), which would eventually trigger battery health feature of the Multi. But a minor issue is, that I get battery overvoltage alarms (see screenshot in the original post).

0 Likes 0 ·