Ahh I see what you are saying.
“You said that the overvoltage is when battery is full.”
Good point. I first witnessed the issue when my Truma started erroring that it was over voltage. I would have been oblivious otherwise. I sit close to the Truma screen when WfV (working from Van
:-).
I did a lot of testing and I can recreate the issue by going into the battery’s bluetooth app and turning off charging. This can be at any SOC.
So as it stands I can turn off the charging in the BMS so from that perspective I’m not sure whether the SOC is relevant to why the voltage climbs (and stays) at 16.6V.
It’s set to be rainy here for a couple of days so it’s impossible for me to see an SoC of 100% for days now.
Hi.
So if I understand right because DVCC is on the BMS in the battery actively sends a message to the Cerbo(?) and in this example it’s 14.7V?
Is this value regularly sent by the BMS? eg every x seconds?
I’m not getting too much luck from the battery provider and I strongly suspect that the BMS stops sending this CVL message and the MPPT doesn’t know what to do so just increases it to the max (based on a 12V system).
I may be barking up the wrong tree but I want to understand whether it’s an issue with the BMS or with the MPPT; or possibly the Cerbo?
The BMS is sending all the info when it sees a request/presence on 305 (with an, optional, inverter/protocol type on 307).
The info is received at Cerbo’s configured BMS port and then forwarded to the inverter.
Wait until SOC is 100% and the voltage is 16V and then make another dump and will see then.
If you can force the error by telling the BMS to turn off charging, then that 16V is the open circuit voltage hard coded inside the MPPT.
Probably when the SOC is 100%, then the BMS is disabling charging by disabling the charging FET and then the MPPT remains “open circuit” and “presents” that voltage.
The 305 and 307 are CAN IDs. Yes, the ones/lines in the dump that start with them.