DALY? BMS RS232 communication protocol CRC calculation

mbeq99

New Member
Joined
Apr 4, 2021
Messages
7
Hello,

with my ENERGY BMS, I think this is a DALY BMS does not work as a known protocol: e.g. [DD A5 05 00 FF FB 77]

After installing [Sinowealth BMS Tool Setup V0.2.msi], I could read and administer everything with the PC.

When scanning the first battery cell, a very simple protocol emerges:
0x0A -> I think start
0x01 -> battery cell 1
0x02 -> I think 2 bytes are being sent

The following is received:
0x0D, 0x3D -> 3389 mV o.k.!
0x47 -> CRC? but how is it calculated

In any case, the CRC is also calculated from the bytes sent

Last weekend I tried to solve the problem with the help of the Internet, without any result.

Is there any indication of how the CRC is calculated, I've tried about 20 exotic CRC calculations without results.




RS232.jpgEnergy_BMS.jpg
 

Diysolar123

Solar Addict
Joined
Feb 28, 2021
Messages
642
the daly bms protocol is open source...
 

mbeq99

New Member
Joined
Apr 4, 2021
Messages
7
I know this page well enough, but I cannot find a solution here.

Here 7 bytes are sent and approx. 30 bytes are received

With the protocol of [Sinowealth BMS Tool Setup V0.2.msi]
3 bytes are sent and 3 bytes are received and that works, see scan.
 

mbeq99

New Member
Joined
Apr 4, 2021
Messages
7
This is the approved protocol A5 05 ...
See first sentence of my request

3 bytes are sent and 3 bytes are received including the checksum
 

mbeq99

New Member
Joined
Apr 4, 2021
Messages
7
Thanks for the answer.
I know this crc calculation but it only works with the 7 byte protocol, e.g.
DD A5 04 00 FF FC 77.

The Sinowealth program communicates via a 3 byte protocol, for which I do not know any protocol description or crc calculation.
 

Diysolar123

Solar Addict
Joined
Feb 28, 2021
Messages
642
Thanks for the answer.
I know this crc calculation but it only works with the 7 byte protocol, e.g.
DD A5 04 00 FF FC 77.

The Sinowealth program communicates via a 3 byte protocol, for which I do not know any protocol description or crc calculation.
well, you will want to start by collecting a variety of samples with minimal changes...
this really is not enough to determine the relationship if its a valid secondary protocol type; is it even a crc, is it just an end frame indicator?
cannot tell with one sample.
as to testing "exotic crc's"...it is unlikely to be that.
it is almost always simple sums or xors..."almost" always; but more samples are needed, asking to "solve this" with three hex values makes it a bit tough.
 

mbeq99

New Member
Joined
Apr 4, 2021
Messages
7
Here is a small selection for battery cells 1 and 2

In column B, 01 = battery cell 1 02 = battery cell 2

Column D is constant 0x0d for the measurement period

Column E here the low byte of the voltage is output.

Table sorting according to column E ascending.

In column F the ceksum is shown.

In column G you can see the decimal value of column E

Lines 16 and 17 are of great interest, here the same voltage is output for battery cells 1 and 2 but with a different checksum (0x72 vs. 0x48)


ABCDEFG
send in hex [3 bytes]receive in hex [3 bytes]decimal
10A02020d273b
39​
20A02020d2911
41​
30A02020d2a18
42​
40A02020d2c0a
44​
50A02020d3545
53​
60A02030d3545
53​
70A02020d364c
54​
80A02020d374b
55​
90A01020d480b
72​
100A01020d4b2
75​
110A01020d4b2
75​
120A01020d4c17
76​
130A01020d4d10
77​
140A01020d4f1e
79​
150A01020d5043
80​
160A02020dE172
225​
170A01020dE148
225​
 
Last edited:

jblance

New Member
Joined
Apr 14, 2020
Messages
3
This doesnt seem like a crc to me (at least not as presented in the above list)
Do you have the result from the above returned data? Maybe byte 3 is part data
Have you tried 'faking' the BMS with another serial output and sending the 3 bytes?
 
Last edited:

mbeq99

New Member
Joined
Apr 4, 2021
Messages
7
Hello Jblance,
I think you are right, this is not a CRC.
With your reference to the "wrong" transmission dates, I was able to confirm your acceptance.
I will study it further and present the result here
 

xury

New Member
Joined
Aug 10, 2021
Messages
2
CRC is sum of all bytes and Modulo 256 - CRC8 %256
also sum of all bytes &FF generate same value eq:
a5 40 90 08 00 00 00 00 00 00 00 00 and checksum 7d
a5+40+90+8= 17D
both sum%256(0x100)
sum&255(0xFF)
gives same result - 7D
 
Last edited:

birdie1234

New Member
Joined
Jun 20, 2021
Messages
2
I just startet reverse engineering the daly/sinowealth protocol and took the 3 byte protocol from the sinowealth bms tool. The last bit must be some kind of checksum, but I didn't figured out how.
If you are interested (Will add more parameter the next days): https://github.com/birdie1/bms-reader
 
Top