Problems with Main Battery and Starter Battery both on CAN BUS?

Q&A and troubleshooting
, ,
1

I have recently created the following system in a VW Vanagon:

  • Multiplus Compact 12/2000
  • Orion XS
  • Cerbo GX Mk2
  • MPPT 50/100
  • Lynx Distributor
  • Epoch Pro-Series Dual Purpose LiFePO4 300Ahr House Battery
  • Epoch Pro Series Dual Purpose LiFePO4 120 Ahr Starter Battery

I have the batteries connected to the starter via a Blue Sea switch that allows 1-2-off positions. Position 1 is normal position and connects the Starter battery to the starter/alternator. If for some reason, the starter battery is drained, I can switch over and start from the House battery as both are dual purpose batteries. This part works great.

Both batteries have CAN bus connections and built-in BMSs. My plan was to connect then both to the cerrbo gx via VE.Can and configure the house as the main battery to monitor and the battery for controlling DVCC charging via the Lynx side. The starter battery charges itself directly from the alternator. My goa The menu items seem to support this. I set up the 300Ahr batt as “House” on VE.Can1 and the 120Ah as “Starter” on VE.can2. I can see both in the UI and their respective SOCs, etc. I set up “House” as the DVCC battery and the main battery to monitor.

All seemed great for a short while and then there were (severe) problems.

The problems:

  1. The GX seems to get them confused all the time. Sometimes the battery named “House” will switch and point to the 120AHr Starter battery. THIS IS BAD. At the time, the true “House” was charged to 100% and the true “Starter” was at 60%. When the GX flipped them, it showed the “House” at 60% and calling for charging so through DVCC it told the mulitplus to send the voltage and current requested by the 60% SOC starter battery (it now has it re-labelled “House”) to the only battery that the multiplus can charge, the true 300Ahr house that is actually at 100%. This resulted in an over-voltage alert from that battery’s BMS. If I reboot and unplug, replug eventually I can get to correctly (re)recognize both batteries with the proper assigned names. But in short orrder, it will loose its mind.
  2. This is somewhat minor, but when it was working and we would start the van, we would receive a “high output current” alert/alarm from the starter battery. I could not find any way to disable this alarm as it makes no sense for a dual-purpose battery that is intended to be used as a starter battery to complain about …well… doing it job as as starter battery. I would really love to tell the GX to ignore this alert.

Right now, my solution is just to unplug the starter battery CAN bus connection, but the behavior that I am seeing seems like a bug. With it unplugged I can’t monitor the charge status of the starter battery via the GX. With it unplugged it all functions fine. The Orion XS detects engine start and pulls current to charge the house leaving enough to charge the starter battery. (I have those settings tuned properly.)

My ideal world would would be this:

  • both batteries connected and reliably monitored via CAN with the House being reliably/stably designated as the DVCC controlling BMS
  • Ideally I would love DVCC to be “aware” that I have a CAN Bus connected starter battery on the other side of the Orion XS and instead of just assuming that the starter battery only needs a few minutes to replenish itself after engine start before it starts pulling to the House (open loop), it would allow all of the alternator current to go to the starter battery until the starter battery SOC is greater than some threshold (e.g. 95%).

My question here:

Is this known behavior? The UI seems to recognize both batteries and allow (encourage even) me to a) name them and b) assign those names as “battery monitor and DVCC charge controller.” But then, it routinely scrambles not only the names but then proceeds to use the BMS parameters from one battery to determine the charging parameters from the other battery (this is bad and I was fortunate the BMS saved me). In the UI if I tell it to re-detect the batteries it does give me a weird warning that it might scramble the names for a while which seems to indicate some knowledge of the problem here?|

is there something that I could be doing differently here? I have the batteries on differen Ve.Can busses but I think they might have the same ID?

Any help would be appreciated.

Carl

2

Yes, the CAN data from both batteries will have the same ID’s so they do have to be kept on separate CAN busses.

However, the main issue, to do with the swapping of the battery function, is the problem of the Venus software - this is not designed to cope with this, but expects 2 connected batteries to be connected in parallel.I’m not aware of any solution to this problem, as it would require charging sources and loads to be individually allocated to each battery (name). In the short term, it may be better to add a second gx device, and separate the 2 systems. Then set up a node red flow in one Gx to read modbus data from the other to a custom display.