Tag: LVS

Current state of our electric installation

I recently wrote about our upcoming solar PV adventure. But before updating our system, I thought it was time to document and explain our current setup (with the help of KiCad).

This system is the main electricity for our barn and currently consists of three batteries with an energy (often referred to as “capacity”) of 3* 14.33kWh = 43kWh (battery bank A, A1:A2 on the plan). These batteries are charged by a JCB G20QS (B1) via three MultiPlus-II 48/5000/70 inverters/chargers (B1:C2) which are by default in “Charge Only” mode. The MultiPlus-II are configured in a 3-phase configuration but only turned on when 3-phase is actually needed.

The main power is delivered by a MultiPlus-II 48/3000/35 (B4:C5) that is connected to a separate battery bank (battery bank B, BYD LVS Premium Battery-Box with an energy of 8kWh). This latter MultiPlus-II is connected to L1 of the 3-phase MultiPlus-II. So, whenever the main batteries get charged the cascaded inverter will also be charged. In addition, we can then use PowerAssist to up to supply 8'000VA (= 5'000VA + 3'000VA) when running on batteries and up to 14'500VA (= 6'500VA + 5'000VA + 3000VA) on a single phase.

Though the generator can supply up 14'400W the chargers of the Multiplus-II can only charge with a power of up to 3* 48V* 70A = 10'080W. This is actually an advantage as the optimal efficiency factor of the generator is roughly at 12'000W. So with 210A we are pretty close. If we ever added more chargers to the system we could even slightly increase the charge current to 250A.

System A with the 3-phase inverter configuration is connected to a Lynx bus bar (A1:B4) that also includes a Lynx shunt (B3) used for measuring over all batteries. In addition, there is an islolated Orion-Tr DC-DC charger (A5) that constantly feeds system B.

System A and B are connected to their separate GX:

  • system A
    Cerbo GX, A5:A6
    MultiPlus-II via VE.Bus, Lynx Shunt via VE.Can, JK-BMS via RS485/USB
  • system B
    Raspberry Pi4 running VenusOS, B5:B6
    MultiPlus-II via VE.Bus, BYD BMS via VE.Can (on a Pi GPIO Hat)

And this is it for the electricity installation in our barn.

Note: This cascaded setup is officially not supported by Victron, but it has been working for us without problems for months now. This might be different in your case.

Configuration of electric components

Addendum

./.

Corrigendum

./.

Reverse engineering the BYD Battery-Box Premium LVS CAN Protocol for Victron Venus OS

On my goal, to build a battery with a Venus OS compatible CAN interface I decided to have a look at he BYD CAN protocol – for several reasons:

  1. It is supported with Victron and Venus OS.
  2. I happen to have a BYD Battery-Box Premium LVS dual battery system.
  3. I heard mixed information about the Pylontech CAN protocol implementation.

So, I got myself a Kvaeser Memorator Light, in order to be able to sniff the CAN traffic between a Venus OS and the BYD BMS. For whatever reason, I did not get it to work, so I ended up with candump – which proved to be more that sufficient for what I needed.

Note: of course, before I started reverse engineering the protocol, I made some effort to find resources and someone who might have already done that – but no luck. However, there were some fragments regarding HVS systems. But they did not seem to be compatible with the LVS implementation.

If you are interested in the result, you can head right here. Otherwise, stay with me and I explain my approach to correlate the identifiers and data pieces.

  1. First, I just started candump to check the general message flow and to see some recurring patterns (working/normal operation, UseCase A).
  2. I then verified that the communication (which runs at 500kb/s) only consists of 11bit identifiers and no FD frames.
  3. I then identified the several message ids based on sender (TX, Venus OS) and receiver (RX, BYD).
  4. I then monitored the message flow, when I disconnected the BYB BMS temporarily (UseCase B).
  5. And then I monitored the message flow, when there was no BYD BMS present at start and then powered it on (UseCase C).
  6. Have alarms and warnings being sent by the BYD BMS (UseCase D). (see note below)

Things to consider:

  1. What are the units of the data being sent (e.g. temperature came in Kelvin/K)?
  2. What is the byte ordering (e.g for WORDs expect the low byte first and then the high byte)?
  3. Is there a scaling on the data being sent (e.g. 1/10mV)?
  4. Is information distributed over different messages? Or does one message have a special meaning in correlation to another message? (e.g. cell voltage and temperature)

For most of the parts, I *knew* what data to expect or to look for. I just looked at the BMS device inside the Venus OS and looked for data that matched the information shown on the GUI.

In the end, I identified most of the messages. For alarms and events, I will verify them once I have a working prototype on my ESP32 by simulating and sending them to Venus OS. [Edit: Alarms and Warnings are now identified and described. Events seem to be not supported. With 17 frames/messages I can now setup a complete BYD battery simulation towards a Venus OS.]

Here is a Summary: BYD Battery-Box Premium LVS CAN Protocol. There you find also some image of Venus OS with the correspnding information as shown on the GUI.

Hope you find this useful.