CAN messages are arriving late

Hello forum,

I have a battery storage system from Pylontech with a BMS. I read the BMS data using a Raspberry PI 3b and a CAN HAT. It works well so far. I send a watchdog signal once per second on the CAN bus and receive "one" response. Unfortunately, I'm seeing a delay in the display of the current BMS values. What could be the reason?

"I'll respond with a quote from another website:"

Message format:
The master battery sends out 6 different message packets. Each one ends up in TCP as 13 bytes long, but altogether – which is why I mostly see buffers of 78 bytes arriving. The other buffers observed are 13 bytes (a heartbeat reply message from the inverter) or something in between, which are just partially filled or truncated buffers at the beginning, so I ignore them.

Parse buffer:
On the converter I use, each 13-byte buffer block (representing a 'standard length' CAN bus message) consists of a length field (1 byte), the CAN bus frame ID (2 bytes at offset 3), and a data packet of 8 bytes (at offset 5). I only need the frame ID and the data packet. After that, each frame type is then decoded to extract the data fields.

ID 0x355 is the message that contains the Start of Header (SOH) and End of Content (SOC) data, represented as a 2-byte hexadecimal value. Therefore, a 100% SOH will typically appear as 0x6400 when interpreted as an unsigned integer in little-endian format, and the subsequent 2 bytes will represent the SOC. Note that only half of the 8-byte CAN data buffer is used here, a side effect of the converter placing variable-length CAN messages into fixed-length TCP packets.

Here in this forum, the discussions usually revolve around the classic CAN bus as it is used in the automotive industry. In addition to these, there are many other applications, such as SafetyCAN, TT-CAN, and so on.

It seems you have a CAN bus that's being triggered. At least, that's what other forums about Pylontech suggest. It functions similarly to an RS protocol (with handshake, central bus management, etc.). It's an interesting thing in itself, but I fear you won't find much support here. The type of protocol is simply too specific.

Okay, thank you for the response.