diy solar

diy solar

CAN Bus ... standards? compatibility?

Surferdudemi

Solar Enthusiast
Joined
Dec 18, 2020
Messages
244
I did a quick search and didn't find any kind of comprehensive discussion about CAN bus and how it's implemented on various components. From the few snippets I found, it seems like some components are compatible (use the same message formats) and some aren't. Is there a cross-reference anywhere that tells which BMS / inverters / displays are compatible with each other. or use which variant of message formats? I'm guessing that many of the device internals are incestuous, so there is some commonality amongst the mfrs.

If there's no cross-reference, can we start one?
 
copapasta

Beginning with its official introduction in 1983, the standard CAN Bus message frame used only an 11-bit message identifier (CAN 2.0A), which is sufficient for the use in regular automobiles and any industrial application, however, not necessarily for off-road vehicles.

The Society of Automotive Engineers (SAE) Truck and Bus Control and Communications Subcommittee had developed a family of standards concerning the design and use of devices that transmit electronic signals and control information among vehicle components. As a result, the higher layer protocol SAE J1939, based on CAN Bus, was born, which was required to provide some backward-compatible functionality to older RS485-based communication protocols (J1708/J1587).

To serve these demands, the CAN standard needed to be enhanced to support a 29-bit message identifier. The ISO 11898 amendment for an extended frame format (CAN 2.0B) was introduced in 1995.

The ISO 11898 Extension (CAN 2.0B)

The 29-bit message identifier consists of the regular 11-bit base identifier and an 18-bit identifier extension. The distinction between CAN base frame format and CAN extended frame format is accomplished by using the IDE bit inside the Control Field. A low (dominant) IDE bit indicates an 11-bit message identifier, a high (recessive) IDE bit indicates a 29-bit identifier.

An 11-bit identifier (standard format) allows a total of 211 (= 2048) different messages. A 29-bit identifier (extended format) allows a total of 229 (= 536+ million) messages.

extension-from-11-bit-to-29-bit-can-bus-identifier.jpg


The above picture shows a comparison between a standard CAN data frame with an 11-Bit identifier and a CAN data frame in extended format (29-Bit identifier). Both frames contain an Identifier Extension Bit (IDE), which is at a low level for the standard frame and high for the extended data frame. CAN controllers must be designed in a way that they check the IDE to distinguish between the two possible frame formats.

Both formats, Standard (11-bit message ID) and Extended (29-bit message ID), may co-exist on the same CAN bus. During bus arbitration, the standard 11-bit message ID frame will always have higher priority than the extended 29-bit message ID frame with same 11-bit base identifier and thus gain bus access.

The Extended Format has some trade-offs: The bus latency time is longer (minimum 20 bit-times), messages in extended format require more bandwidth (about 20 %), and the error detection performance is reduced (because the chosen polynomial for the 15-bit checksum is optimized for frame length up to 112 bits).

From what I've seen most of the CAN bus stuff is still on the old RS485 (J1708/J1587) stuff. If we are talking about typical non-certfied Chinese stuff then I would not have high hopes that they conform to correct CAN protocol.

So to answer you question, I know of no list that is complieing the information you seek or is otherwise verifying that its claim of "CAN buss" is something that will even talk to each other.

Growatt goes as far as to allow you to configure the RS485 com port in software as I guess they know there are issues with the way everyone pin's their own RS485 ports and that they are clearly not all playing on the same "standard".
 
CAN Bus is pretty well locked down in terms of signaling and basic data structure.

Each manufacture can do their own thing. OBD2 uses CAN at the hardware layer and defines it's own way of sending the data within the confines of the CAN specification.

Perhaps CAN Open will help you get an idea of how it is used.
 
I have used Batrium and REC with SMA over CANBUS, and if you look at the REC website they publish their CANBUS message protocol.

It follows that any BMS using the same protocol will work.

I have just purchased a ZEVA BMS that has the same protocol, as does the EMUS BMS.

I would be interested to know if other Inverters/Chargers use the same protocol as SMA.
 
I wonder if there's a way to WireShark the communication to see what's going on. I know that some people have used Arduinos to capture the data, and I'm planning on trying to hook the BMS that's on its way to an ESP32. Ultimately I'd like to get the BMS to work with whichever hybrid inverter I decide to get. Maybe there's a market for a translater, LoL. A micro like ESP32 or just plain Arduino Uno between devices, doing the conversion between different message protocols.

I didn't see the protocol on the REC site. Will go take another look!
 
Ultimately I'd like to get the BMS to work with whichever hybrid inverter I decide to get.
Then it would be important to know what commands, if any that inverter will respond to. Even though I bought an inverter which said it had CANBUS, I cannot get any definition from manufacturer.
 
Then it would be important to know what commands, if any that inverter will respond to. Even though I bought an inverter which said it had CANBUS, I cannot get any definition from manufacturer.
Yeah, that seems to be a huge problem. Few of them publish specs on their CAN bus messages. Hence my thought of collecting compatibility here in the forum - not necessarily on a post like this.
 
Just to toss a Rock in the Pond. ;)

If anyone plays with Raspberry Pi's and might be curious, there are Node-Red flows available.
Library - Node-RED
Those look like generic CAN bus drivers/flows (I only just started using RPi for HomeAssistant, so not sure what they are called), and not specific to BMS.
 
Those look like generic CAN bus drivers/flows (I only just started using RPi for HomeAssistant, so not sure what they are called), and not specific to BMS.
I use Node-Red flows for ModBus via TCPIP to interact with my Midnite SCC and Samlex Inverter. The ModBus stack, like CanBus is generic, you have to know the target devices usage. I have not furtled with CanBus as I do not have anything that uses it actively (Well the Samlex systems have it) but not practical for me to look into as my Midnite SCC does not do CanBus.

Before anyone asks: I Cannot disclose nor provide any information on Samlex Protocol Stacks as I have a Developers NDA and none of that information is released to the public.
.
 
Back
Top