ZKETECH EBC-A20 Battery Tester

The control protocol exchanges packets (also called "frames" in this document) between the controller PC and the battery tester. The packets are binary encoded, a typical packet is shown below in hexadecimal:

The basic structure of the encoded packet is shown below:

Each packet begins with a 0xfa byte and ends with 0xf8. These are labeled as SOF and EOF. The payload are the bytes between offset 1 and 16 (inclusively). A packet also contains a "CRC" which is a simple checksum not an actual Cyclic redundancy check. It can be calculated by performing a XOR operation on the payload bytes:

>>> hex(0x0c ^ 0x00 ^ 0x00 ^ 0x02 ^ 0x1e ^ 0x00 ^ 0x00 ^ 0x00 ^ 0x00 ^ 0x00 ^ 0x0a ^ 0x01 ^ 0x3c ^ 0x00 ^ 0x0a ^ 0x09)
'0x24'
>>>

A number of packet types sent by the battery tester to the PC or vice-versa have been identified. They are listed in a table below. In order to help in understanding the details about each packet type and example packet and its description has been shown below. This packet is sent by the PC to the charger when the controlling software requests cell charging:

The first payload byte is the packet type (PT) identifier - 0x21 represents the Start charging packet. Next there are 3 16-bit fields encoding:

• the charging current (in units of 10 mA)
• the charging voltage (in units of 10 mV)
• the cutoff current (in units of 10 mA)

Each 16-bit field value is encoded with 2 bytes using the following scheme:

>>> I1 = 0x00
>>> I2 = 0x32
>>> 240 * I1 + I2
50

In effect this is a "base240" encoding and it's purpose is likely to prevent values larger than 240 (0xf0) to be present in the packet bytes. This makes sense when you consider the fact that bytes 0xfa and 0xf8 are used as "control codes" to mark start and end of packets. In summary the packet above encodes the following fields:

>>> I1 = 0x00
>>> I2 = 0x32
>>> 240 * I1 + I2
50
>>> V1 = 0x01
>>> V2 = 0x3c
>>> 240 * V1 + V2
>>> CUT2 = 0x0a
>>> 240 * CUT1 + CUT2
10
>>>

Fields which contain measurable physical quantities like voltage, current and charge are furthermore processed so that the precision and range information is encoded. Explaining this encoding in prose would be tedious therefore a Python implementation of the decoding algorithm is provided:

def decode_ranged(h: int, l: int) -> float:
    """
    Decode a base240 value to a float taking into account different offsets and scaling
    factors for multiple ranges.
    """
    if h & 0x80 == 0x80:
        if h & 0xe0 == 0xe0:
            # range is > 200.0
            v = 240 * (h & 0x3f) + l
            m = 0.1
            offset = 0x1c00
        else:
            # 10.00 < range < 200.0
            v = 240 * (h & 0x7f) + l
            m = 0.01
            offset = 0x800
    else:
        # range is < 10.00
        v = 240 * h + l
        m = 0.001
        offset = 0

    return (v - offset) * m

The above code was created based off of the algorithm implemented in the esp-ebc-mqtt code.

What follows is a table with descriptions of all of the packets that have been observed so far together with their types, encoded fields and other extra information.

Fields like current or voltage have common encoding for all packet types:

This table does not exhaust all of the packet that I have seen while sniffing the traffic between the original software and the battery tester. A bit more is documented in the Python code.