Ich antworte mal mit eine Zitat von einer anderen Website:
Message format:
The master battery sends out 6 different message packets. Each one ends up in TCP as 13 bytes long, but altogether – hence I mostly see buffers of 78 bytes arriving. The other buffers seen are 13 bytes (a heartbeat reply message from the inverter) or something between, which is just a part filled or chopped off buffer at the start, so I ignore those.
Parse buffer:
On the converter I use, each 13 byte buffer block (one ‘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 (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 holds the SOH and SOC, as 2 byte hex, so 100% SOH will typically show as 0x6400 unsigned integer, little endian, and the other 2 byes will be the SOC. Note that only half the 8 byte CAN data buffer is used here, a side effect of the converter putting variable length CAN messages into fixed length TCP packets.
Hier im Forum geht es meist um den klassischen CAN wie er im Automobilen verwenden wird. Daneben gibt es noch viele andere Einsatzgebieten, wie den SaftyCAN, TT-CAN, usw.
Bei dir scheint es sich um einen getriggerten CAN zu handeln, das beschreiben zumindest die anderen Foren zu Pylontech. Er funktioniert in etwa wie ein RS Protokoll (mit Handshake, zentrales Busmanagement, usw.). Anfürsich eine spannende Sache, aber ich befürchte, du wirst hier nicht so viel Support finden. Die Art von Protokoll ist einfach zu speziell.
|
Lesezeichen
Garage
FAQ, Impressum & Datenschutz
RSS-Newsfeed
Registrieren
Login
