Understanding the Victron BMS CAN

[Janvi]

My system constists of RS450 connected to a Cerbo by 250kbit CAN and 2 groups of Pylons connected to the 500kbit BMS CAN port using the pylon LV-Hub. Unfortunately I cannot find many informations about the CAN protocols.

As far as I understand, the Pylon CAN protocol is proprietary and does not contain proper data link, addressing and transport layer functionality like NMEA2000. This constraints require a second separate BMS CAN port for the CerboGX. Pylons cannot coexist to the VE-CAN with the RS450 chargers.

Recently some BMS became available, what are able to select diffrent CAN protocols. Examples are Seplos and JK-Inverter BMS. Screendump with selections attached. Beside own proprietary CAN protocol most emulate a Pylon and a Victron BMS protocol.

Is that Victron CAN BMS protocol same than the one used by the Lynx BMS?
Is the Victron CAN BMS using the NMEA PGNs for coexistance with VE.CAN/ RS450@250kbit?
Is the Victron CAN BMS addressing >16 batteries without additional hardware like the Pylontech LV-Hub? Therefore using the NMEA auto configuration feature for up to 50 devices?

[lxonline (LX)]

There are some technical documents here.

Can registers are publicly available.

And their data communication paper.

If you are wanting more then spend time in the modification section.

The 16 battery limit is an address limitations in the pylontec side. Same as the 8 used to be. Not related to Victron at all.

[Janvi]

Thanks for the links, mainly the vregs description. Its hard to read between the lines to understand the things.

1. The Victron CAN BMS protocol defined by Victron

is described in the VREGS Manual and is also known as VE-CAN. This is a NMEA2000 protocol using manufactuerer specific parameter group number (PGN) to identify diffrent BMS data. It is a true plug and play protocol working at 250kbit, using 29 bit CAN identifiers. The protocol features mandatory autoconfiguration for up to 50 devices. Battery aggregation happens inside Venus OS. Coexistance with other VE.CAN devices like the RS450 MPPT is no problem.

2. The Victron CAN BMS protocol defined by non Victron manufacturers

is described in several PDFs on the internet what might be written by manufacturers, solar enthusiasts or open source authors. This is a point to point comunication at 500kbit what suffers from missing transport layer. It does do not implement basic requirements like error recovery, reininitate connection, flow control. data segmentation and reassembly or retransmissions on timeout. It is abusing the CAN 11 bit identifiers to identify diffrent BMS data contents.

As a consequence of the point to point communication, the Cerbo GX offers a second CAN port beside the VE.CAN port what is known as the BMS-CAN port. The BMS-CAN port only works at 500kbit while the same setup is also available for the Cerbo VE-CAN port. The protocol to setup in setup>services>BMS-CAN>CAN-BusProfile is the „CAN-bus BMS LV @500kbit“. This is the protocol what other manufactures call the „Victron BMS protocol“. It is a superset or subset of the Pylon protocol, wether this is intentional or unintetional by incomplete implementaions of the diffrent manufacturers. The inventor of this protocol is possibly the SMA, as the sunny island seems older than Pylontech US2000.

Another consequence of the point to point protocol is, that devices on this 500kbit CAN bus cannot share the bus hardware with any other CAN bus devices. Even not with another battery from the same model. To solve this, Battery aggregation happens inside a so called master battery rack what is the CAN slave communicating with CAN master in Venus-OS. Connection of other slave batteries are limited to 8,12 or 16 devices and require again another completely undocumented CAN bus and/or RS485 hardware.

The things seem to go really messy, if this point to point protocol needs to connect more than one master battery. To solve this, undocumented handshake lines on the RJ45 pins 1,2,3 are used together with also undocumented RS485 communication in the background. To do the aggregation of the master batteries another hardware known as the Pylon LV-hub is required. To make this LV-hub working, suspicious procedures like „wait to 3 beeps of master battery and then plug in cable“ and changing the dip-switch setup at specific times are described in the Pylon LV-hub manual.

Assume all, the Victron CAN BMS protocol defined by non Victron manufacturers or CAN-bus BMS LV @500kbit ist not what Victron users expect from trouble free operation for safety critical functionality with potential dangerous LiFePo battery devices. For this reason it seems to be important to know about the diffrences between Victron CAN BMS protocol and Victron CAN BMS protocol not only for DIY users. The only way to find out what battery uses what protocol is not reading the manuals but to buy it and then see its not working like expected. To be honest: Are there any known batteries what use the No. 1 Victron CAN BMS protocol except Victrons own Lynx BMS?

[lxonline (LX)]

There are quite a few bms that are plug and play even though they are not officially supported.
The following BMS systems are known to correctly follow the Victron battery specification (but are not tested by Victron!):

123\SmartBMS - Victron instructions
REC BMS - https://www.rec-bms.com/ (various Victron documentation on their website)
Boostech GmbH BMS - https://www.boostech.de/bms-konfigurator/

All that is needed in some cases is a driver to be loaded. And then git hub is your friend.
The most well known one is this one here by Louis van der Walt

[lxonline (LX)]

On the ekrano there is no bms can. Just can.
The cerbo it is defined but mainly it is the speed that is set to 500. Not 250 like the mppts use. Some batteries need 250

A specific example of a battery using can redflow.

The cans are not specific otherwise.

[TheGrandPoohBah]

My understanding is the JK-Inverter BMS runs on 250kbit but uses a special cable to connect to the ve.can bus on a GX device. Will it play nice with a set of ve.can solar controllers connected to the jk-inverter control board and terminated at the solar control end.

[MikeD (Mike)]

The main reason the Pylontech BMS and the Victron VE-CAN cant exist on the same bus is the difference in data rates, rather than the protocol.
Pylontech and most BMS use 500kBit/s, the other bus defaults to 125 or 250kBit/s.
Typical can interface chips that handle the physical layer protocol cannot deal with 2 different data rates. They can deal with both standard and extended frames.

[msevestre]

The non understandable thing here is why doesn’t victron switch (or at least offer the option to) their MPPT communication to 500kbps… I do not trust it would be a chip issue on the MPPT side…

[Janvi]

The protocol rules are not made by Victron, its NMEA widely used for yachts. For batteries, the cycle time would increase if there are more than 16 bus members why this bus is separate using hubs for data aggregation. Dbus concept also allows to add any number of CAN bus interfaces to Venus, each one using diffrent or proprietary CAN format.

[msevestre]

Indeed, NMEA is key for yachts…

My comment was more in a general way, as many of the Victron bricks are used in non-yachting environment (so I was a bit off-topic, I admit). And for such situation, it is sole Victron decision.

[M_Lange (Matthias Lange - DE)]

The Venus GX, Cerbo GX and Ekrano GX have 2 CAN bus’.
So you can use one for the battery at 500kbit/s and one for VE.Can at 250kbit/s.

Also most Victron devices with VE.Can can also communicate via VE.direct.

[Janvi]

It is not the decision of Victron. They need to be compatible with other products, mainly batteries from Pylontech, Pytes, Liontron and the hudreds of Chinese copies of them.

This battery protocols are more a quick and dirty P2P Link using the buildt in CAN hardware. Its not a protocol according to the ISO/OSI Layers. This might work typically but cannot coexist with devices from other manufacturers on same CAN bus line. They have not implemented the functionality with basic layers of the OSI Model like NMEA is doing.

Anyway, Venus is not depending from poor CAN devices as we can always add another CAN hardware port to connect a 3rd party battery or product for a poorly designed point to point connection. Thats why my Cerbo screendump shows 4 CAN ports and using Venus it is easy to do this for n CAN ports.

[MikeD (Mike)]

One other point to bear in mind is that no BMS I have seen so far does auto negotiation of CAN bus I’d’s. The Spec is not written that way. I’ve found one motor supplier (DC motors) that has got Auto negotiation - that is if you have 2 or more (up to 4) motor controllers on one but they each take a separate CAN ID.
The lack of this auto negotiation means that you can only have one BMS master on each CAN bus.
Part of this is that the extended ID’s are not used for different data sets from each BMS, rather a new BASE id is used. This makes auto negotiation virtually impossible.