Regular unexplained BMS-related fault messages and cancellations

Good-day,
We are experiencing an unusual phenomenon on a system with 1 x Quattro 48/10k, 3 x SmartSolar MPPTs, 1 x GX and 3 x Freedom Won eTower 5 kWh batteries. In the space of 1 minute there are 4 fault reports followed by 4 fault cancellations. As follows :-

#67 No BMS on Solar Charger [258]
#67 No BMS on Solar Charger [256]
#67 No BMS on Solar Charger [288]
Low Battery on VMS Bus System [0]
BMS lost on VMS Bus System [0]
#67 No BMS cleared on Solar Charger [258]
#67 No BMS cleared on Solar Charger [256]
#67 No BMS cleared on Solar Charger [288]
Low Battery cleared on VMS Bus System [0]
BMS lost cleared on VMS Bus System [0]

The behaviour of the system does not seem to be adversely affected.
ESS is enabled.
The sequence seems to happen regularly twice every day, seemingly when

  1. The battery SOC falls to the low threshold
  2. The battery SOC rises to 100%.

Has anyone seen this before ?
Any suggestions as to what the cause /resolution might be ?

I am seeing the same thing with one brand of batteries we use that has RS-485 to USB communications to the Cerbo GX. Please share the D-Bus round-trip time from the system. Here is an example of what’s going on with the one system I mentioned above.

What appears to be happening is 3.6x versions of VenusOS have pushed the Cerbo GX past its capabilities. Under load, when we have several VE.Direct MPPTs, a SmartShunt, a MultiPlus-II 24/5000 and four 24V batteries that communicate to the Cerbo via USB we get those errors, and occassionally the equipment shuts down because the “No BMS” issue takes too long before it clears. My vendor is working on their driver to try and reduce load on the Cerbo. Apparently the Ekrano doesn’t suffer this issue nearly as much because it has 2x the CPU cores.

I’m sharing what I’m being told and I’m working with them to test the VenusOS driver. There are other posts on the forum with similar issues to yours.

I don’t know the Freedom Won batteries. Do they communicate via CANbus or some other way?

Thanks!

Hi Ed,

Thanks for this feedback – it provides useful clues as to the possible cause.

Freedom Won batteries use CAN-Bus. They are a popular brand manufactured and sold in South Africa, but based on an original Chinese design and cells from China.

We will look into possible ways to resolve this such as firmware upgrades and so on.

The problems started after the system was re-positioned and a slightly (2-3m) longer CAN-bus cable was used.

It may be cable quality combined with increased workload as the thresholds are processed.

Regards,

For the record, I haven’t seen these issues with my customers using Pytes batteries connected via CANbus, but I also haven’t upgraded most of them to 3.6x. I think VenusOS needs to stabilize a bit before I start upgrading my customers.

That said, I run Pytes batteries on my three phase system in my shop on 3.7x BETAs and have had no problems. But, I only have one VE.Direct device on that system. The MPPTs are VE.Can. I’m also running Victron Smart LFP NG batteries in my RV with a Lynx BMS 500 NG and I have four VE.direct devices, but the BMS is VE.Can. No problems there either.

My gut tells me this is related to processing serial communications at too high of a polling interval. But I’m just a lowly hardware guy :slight_smile:

What GX do you have? What versions are in use.
How is the bus terminated?
I would check terminators aren’t loose or missing, and start with cables since that was the trigger.
Pace is commonly used, if there was a broader issue we would see it by now.