RS485 protocol

[mvdklip]

I am trying to communicate with the BMS in a battery over RS485 but do not know the protocol details. I tried to load the aia file on Kodular to find out but I get errors loading the blocks when I do this. Can you tell me how to communicate with the BMS? Is there a list of messages / bytes and their meanings?

[Xmanu12]

Hi mvdklip, can you be more detailed about the issues you have ? . Do you build the interface ? the RS485 module plus the BT module ? At basic level the protocol is 9600bps 8n1 and with the interface connected by the RS845 side to the bike and the BT module linked to any android phone, for example, open a program like "serial terminal bluetooth 1.40 " app and you start to see all the trafic of the bike bus. Make the interface conect to your android phone and open and conect to the Bluetooth module with the "Serial Terminal Bluetooth" and let me know what characters scroll in your screen. ML

[Xmanu12]

Note: if you connect only to the battery there are no RS485 out from the BMS until receive a control word from bike or charger, if you woul like to see any answer from battery alone, connect to the SuSoDev interface and hit "enter" from "serial terminal bluetooth" linked with the BT of the interface. You would see anwer of
5 HEX chars. Hope this helps, too.

[mvdklip]

Hi Xmanu12, thanks for your answer. My issue is not really with the tool but that I can't find anywhere what has been found out about the RS485 internals using this tool. I guess by now the tool has been used to identify what messages can be send to the BMS (for example) and what answers it will supply. I only have a battery for now so I'm mostly interested in this communication. To put it simple: I want to ask the BMS about the current SoC and/or SoH.

I already have some sort of serial communication working at 9600 8n1. When I sent the BMS the following message:

0x01 0x03 0x00 0x00 0x00 0x01 0x84 0x0A

It responds with:

01 03 00 00 F1 D8

This is very similar to modbus but not quite the same. Maybe it's cdbus or something proprietary. Anything you can share on how to decipher the packets would help. Thanks.

[Xmanu12]

Hi Matthijs, well, internals of the RS485 messages was directly implements and decodes in the app, never have time to write any document about my findings this is the reason to publish the source of the version 04 aia. Here you can find. Anyway I take time to write some guide to you regarding the battery messages you have interest.
basic_RS485.docx
Unfortunately SoH is not currently located, but have some ideas to look for, if you have experience with Java decoding.
Let me know if the document attached is clear.

[mvdklip]

Thanks! If I understand correctly that document tells me what messages the TC and TCMAX chargers send and what answer they get. Is the answer documented the one from the BMS?

The message seems to have the same length as I discovered (modbus like) which is 8 bytes long and ends with a 2-byte modbus CRC. Not sure why it starts with C5 5C but maybe these are just magic bytes? :-)

It seems 5A is the id of charger and AA might be the id of the answering device in this case. So then the format would be:

<magic> <magic> <source> <destination> <length> <data> <checksum> <checksum>

[Xmanu12]

Hi Matthijs, yes the documented answer is from the BMS. Too much assumtions, not sure if the format you write is correct. For example, b6 6b start appear in other messages of the bus, but comming from the ECU. For sure the end of the messages is always 0d, and is not part of the checksum, it only have 1 byte lenght, for sure. And regarding 8 bytes long, my observations resumed as <Header><Header><Source><Destination><Length><Data><Checksum><End> the 80% of the messages is 10 bytes data, 9% is 14 Byte data, 1% is 1 Byte data, 1% is 2 Byte data, more or less, so not really modbus, if you like " far family". ;-)

[mvdklip]

Ah yes, missed that "end" 0d. Weird because I have observed that my modbus like messages have to be ended in a two byte modbus CRC so maybe the BMS understands two different kinds of messages? Wednessday I'll be back in the workshop and will try sending one of your example messages.

Question: how do you calculate the 1 byte checksum?

[Xmanu12]

Hi Matthjis,
-- Question: how do you calculate the 1 byte checksum?
At this moment, as we only read from the bus of the Bike, dont need to calculate the Checksum, only ignore it and believe that all the messages are correct.

[mvdklip]

Already found it. It's a simple XOR of the data bytes starting with the length byte.

01 97 => 96
01 9a => 9b
0a 42 4b 1e 00 00 0d 00 41 00 00 => 51

Which makes the packet format:

<header> <header> <source> <destination> <data-length> <data-bytes> ... <data-xor> <end>

Also found a small error in your doc, I believe. The "charging or not" is in byte 10 for me, not in byte 7. Byte 9 went from 0 to 1 after doing a full charge to 100% and the charging stopped. Might have a meaning.

[mvdklip]

I have just checked all (single-byte) requests and I get different responses from the battery for requests 9A and 9C:

c5 5c 5a aa 01 9a 9b 0d => b6 6b aa 5a 02 00 02 00 0d
c5 5c 5a aa 01 9c 9d 0d => b6 6b aa 5a 10 41 54 36 30 34 33 32 32 30 32 32 34 30 37 31 31 07 0d

Ofcourse I do not know the meaning of this yet, but I saw you had 9A in your document for the TCMAX charger. Do you know the meaning of 9A?

[mvdklip]

I also tried all source and destination addresses. Interestingly enough the BMS sends the following:

• Source 5A, dest AA => response from AA to 5A
• Source 5A, dest 5A => response from AA to 5A
• Source A0, dest AA => response from AA to A0

This makes me think that 5A=Charger, AA=BMS and A0 might be ECU. It's kind of silly that the BMS also responds to a request from charger to charger but this might be a bug.

[Xmanu12]

Hi Matthjis, Great !! all your new findings. Congratulations for the Checksum generation, I test few other messages bus and is correct, its a Xor sum, this is great news because now we are ready to "create" messages and build for example an other brand of Smart BMS like ANT or DALY and make a translator to answer like a SS BMS. Great !!

[Xmanu12]

-- Also found a small error in your doc, I believe. The "charging or not" is in byte 10 for me, not in byte 7. Byte 9 went from 0 to 1 after doing a full charge to 100% and the charging stopped. Might have a meaning. --

Maybe you are right, let me confirm with my battery if bytes change as you observed.

[Xmanu12]

c5 5c 5a aa 01 9a 9b 0d => b6 6b aa 5a 02 00 02 00 0d
c5 5c 5a aa 01 9c 9d 0d => b6 6b aa 5a 10 41 54 36 30 34 33 32 32 30 32 32 34 30 37 31 31 07 0d

For me, 00 02 data for the first message is an "incompatible charger"
The other message, is strange, first of all, is not "standard" all the good relevant messages have a data lenght of 0a, this however is 10H, so 16 Bytes, mmmm.
Let me know, what is yout battery model ? know the LiPo serial strings number ? and model of your Bilke and Charger ?

--Do you know the meaning of 9A?
At this moment, for me 9A is the code for a 72V 10A original SS charger for TCMax. So a BMS of 72V nominal with 20 LiPo serial strings will accept and answer correctly when receive a c5 5c 5a aa 01 9A 9b 0d, other codes than 9A are refused and the BMS dont answer about his status. ( But charge if the Voltage of the charger is between the minimun and the maximum allowed by BMS )

[Xmanu12]

--This makes me think that 5A=Charger, AA=BMS and A0 might be ECU. It's kind of silly that the BMS also responds to a request from charger to charger but this might be a bug.--
Yes, maybe they newer think in two chargers in the same bus ;-)) Looks like BMS accept all messages from 5A because is only for the BMS interest. Or a bug, really.