Thanks for the links, mainly the vregs description. Its hard to read between the lines to understand the things.
- 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.
- 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?
