Communication between BYD Battery and Kostal Plenticore Inverter

huntworker

New member
Joined
Feb 16, 2021
Messages
14
Sometimes (every few hours) I get a response starting with 0x06 from the battery. The rest of the content is the same as the 0x0A messages.
And the query from the inverter was the same as well. Somebody a glue on that?
Example from this morning:
Code:
06 E2 FF 02 FF 29 04 40 87 43 01 0F 8D 43 66 66 AA 41 33 33 93 40 7B 14 96 40 01 03 48 42 01 03 C8 41 01 14 A0 41 33 33 B7 41 66 66 A6 41 75 93 58 40 27 31 58 40 FE 02 01 02 4D 01 01 02 65

The checksum for the short messages
Code:
09 62 FF 02 FF 29 53 03 1F
08 E2 FF 02 FF 29 06 EF
09 62 FF 02 FF 29 4A 04 27
is easy, this is just the sum of all bytes inverted, but starting on the 2nd byte. So the first byte is not secured with the checksum.

more complicated is it with the long 0x0A (and 0x06) message. If I do the same calculation, I do not get the correct answer.
I used this one https://www.scadacore.com/tools/programming-calculators/online-checksum-calculator/ and took the CheckSum8 2s Complement result.
Maybe the checksum is calculated before the "defusing" of the 0x00 bytes. I changed all the 0x01 to 0x00 but didn't get the correct answer.

I guess "00" is a special symbol, so the number 0x438D000 is encoded as 0x438D, and the zeroes are omitted.
Also, I think "01" marks the start of a segment, followed by its length. The length byte is included in the total length.
But the length of the messages is not changing over time. While the numbers of 0x01 is changing.
Example message when the battery is fully charged -> allowed charging current is nearly 0 A.
Code:
    0A    E2    FF    02    FF    29    1D    5A    85    43    01    03    8D    43    01    03    AC    41    01    01    01    01    01    01    01    01    01    03    48    42    01    03    C8    41    01    01    01    05    CD    CC    B4    41    01    0C    A4    41    A4    70    55    40    7D    3F    55    40    FE    04    01    40    64    01    01    02    56
The Battery current is 01 01 01 01 (two times) and the maximum charge current is 01 01 01 05
Any Idea for this?

Cycle current is 0xFE by the way. :)
 

Attachments

  • FullyCharged.png
    FullyCharged.png
    14.4 KB · Views: 3

yasko

Member
Joined
Nov 10, 2017
Messages
39
@huntworker
About your last message:
Code:
0A E2 FF 02 FF 29 10 D8 81 43 01 07 8D 43 33 33 9F 41 01 01 01 01 01 01 01 01 01 03 48 42 01 03 C8 41 01 03 A0 41 01 07 90 41 CD CC 80 41 01 08 50 40 64 3B 4F 40 FA 02 01 02 14 01 01 02 C7
I think that correct splitting is:
Code:
0A E2 FF 02 FF 29 1D 5A 85 43
01 03 8D 43
01 03 AC 41
01 01 01 01 01 01 01 01
01 03 48 42
01 03 C8 41
01 01
01 05 CD CC B4 41
01 0C A4 41 A4 70 55 40 7D 3F 55 40 FE
04 01 40 64 01 01 02 56
So, the max charge current is encoded as 01 01, which should be equal to zero.
But the length of the messages is not changing over time. While the numbers of 0x01 is changing.
I agree that the long message is always 64 bytes. We can compensate for the length change by fragmenting the data. Each time we split it, there are additional two bytes: 01 XX (XX is the length of segment).
I was thinking about the long message checksum, and maybe we should exclude from it all "special" symbols (with value < 0x20).
 

huntworker

New member
Joined
Feb 16, 2021
Messages
14
Okay, I think I got it (basically)
example:
Code:
0A    E2    FF    02    FF    29    0C    92    85    43                           
01    0F    8D    43    9A    99    99    41    33    33    73    40    32    33    73    40   
01    03    48    42                                                   
01    03    C8    41                                                   
01    03    A0    41                                                   
01    10    8C    41    9A    99    81    41    54    E3    55    40    68    91    55    40    FB
02                                                               
01    02    28                                                       
01    01                                                           
02    CD
every "01 xx" will be replaced by "00 00". Then I get correct data until the "FB" Byte. Because after that I would expect "01" again, because the block is only "10" long. But there is a 02 coming.

Then I tried another block
Code:
0A    E2    FF    02    FF    29    1D    5A    85    43           
01    03    8D    43                                   
01    03    AC    41                                   
01    01                                           
01    01                                           
01    01                                           
01    01                                           
01    03    48    42                                   
01    03    C8    41                                   
01    01                                           
01    05    CD    CC    B4    41                           
01    0C    A4    41    A4    70    55    40    7D    3F    55    40    FE
04                                               
01    40    64                                       
01    01                                           
02    56
and was wondering about the four last lines. I expected them to start with 01, but it is starting with 04. Do you have a glue why?

And, if every 01 xx byte is replaced by 00 00, how is it possible to only add one 00 byte?

To the checksum:
If I replace all the 01 xx bytes by 00 00 and ignore the last 04, 01, 01, 01 and 02, i get the correct checksum with an offset of 5.
So I am still curious about the last bytes. Maybe it will show up when the cycle count gets over 255.
Current cycle count is 254.
 

yasko

Member
Joined
Nov 10, 2017
Messages
39
OK, so we have that long message, and it's divided into the blocks of data. Each block has a header in the format 01 XX, where XX is block length excluding starting byte 01. When some parameter is zero, it's replaced by 01 01 (or 01 01 01 01), and I think that the order of battery parameters is fixed within the message.
Now remains the last block of 8 bytes, and we know for sure there is a SOC byte and checksum byte. But other bytes are still a mystery. There should be some status byte.

One other thing, which is not directly related to the current topic - in the message below, we have 100%, and voltage is 266.76V. That is a somehow low voltage for 100% SOC. I'm expecting a voltage closer to 280V.
Code:
0A E2 FF 02 FF 29 C5 60 85 43 01 07 8D 43 9A 99 A5 41 01 01 01 01 01 01 01 01 01 03 48 42 01 03 C8 41 01 01 01 12 CD CC B0 41 66 66 9E 41 06 81 55 40 DF 4F 55 40 FD 04 01 40 64 01 01 02 D6
Now let's see here:
Code:
06 E2 FF 02 FF 29 04 40 87 43 01 0F 8D 43 66 66 AA 41 33 33 93 40 7B 14 96 40 01 03 48 42 01 03 C8 41 01 14 A0 41 33 33 B7 41 66 66 A6 41 75 93 58 40 27 31 58 40 FE 02 01 02 4D 01 01 02 65
The voltage is 270.5V, and the SOC is 77%. These values are more relevant.
 

huntworker

New member
Joined
Feb 16, 2021
Messages
14
One other thing, which is not directly related to the current topic - in the message below, we have 100%, and voltage is 266.76V. That is a somehow low voltage for 100% SOC. I'm expecting a voltage closer to 280V.
Thats quite normal behavior of the batteries. If the battery is charged nearly 100% the voltage is around 276 V. If it is then fully charged and the allowed current drops to 0 A, the voltage drops down as well. That is okay that the voltage is not at maximum the whole time. Thats the reason why you need to do coulomb counting instead of voltage measurement for the soc.
The voltage is 270.5V, and the SOC is 77%. These values are more relevant.
Didn't have a closer look for the current, but if there is a higher charge current, the voltage will be higher.


06 E2 FF 02 FF 29 04 40 87 43 01 0F 8D 43 66 66 AA 41 33 33 93 40 7B 14 96 40 01 03 48 42 01 03 C8 41 01 14 A0 41 33 33 B7 41 66 66 A6 41 75 93 58 40 27 31 58 40 FE 02 01 02 4D 01 01 02 65
What I am more wondering about is this message beginning with 06. These are the messages I want to check today. The 0A messages show an end of a segment after 0x0A Bytes. But this one does not have a 01 at this position. I do not have an explanation why this message starts with 06 instead of 0A. Everything else is similar to the other messages. Is this somehow to insert just 00 instead of two bytes 00?

I will write a small program to calculate the float values if some more points (mostly the 06 frames) are cleared to log the currents, voltages and SOC. Hope to get things even more clear.
 
Top