does anyone have this working with A20 tester?

[fredkehler]

I was looking for software that was linux based for my zketech A20 battery load/tester, this package looks great .. I have this compiled and seemingly running on ubuntu 20.04, Interface looks really good.. but am not able to successfully talk to my A20 tester... basic ON/OFF is working but not able to configure or monitor tester, chart keeps logging '0'. The lazarus environment is brand new to me... so a bit of a stretch to try and enable debugging?

[ajay10000]

I am also trying to use this program with an EBC-A20. Could someone please explain how the identification byte is decoded? The console shows: R:FA7400C83A5D00040000013E0C6C044C06CEF8 CE I have added the EBC-A20 tentatively as:

[Models] Name_1=EBC-A05 Name_2=EBC-A10H Name_3=EBC-A20

[EBC-A20] Ident=CE IFactor=1 UFactor=1 Connect=fa 05 00 00 00 00 00 00 05 F8 Disconnect=fa 06 00 00 00 00 00 00 06 F8 Stop=fa 02 00 00 00 00 00 00 02 f8

It doesn't appear to be connecting correctly, so hopefully the ID is what is required. It is running on a Raspberry Pi 3B+ with bullseye aarch64.

Thanks in advance, Andrew

[JOGAsoft]

Hi. I'm the original programmer for this project. Sorry for my late reply, I haven't touched the project in a while. I don't know how you found out about it, but I announced it on EEVblogs forum and I got the same request in a PM on the forum from a user called "Aurgelme". I did some preliminary work to help him(?) with A20. Since I don't have an A20 myself, I haven't really found a solution, but maybe the person I talked with on the forum got it to work? I think I may have a slightly newer version on my harddrive that I maybe haven't committed to github yet. I will check that. I also found a nasty bug due to the not-so-clear protocol description that was only available to me in Russian, a language I don't speak. The bug affected large capacities, when the measured capacity rolled over from 9.999 Ah to 10.00 Ah, if I remember correctly. That may be important for you with the larger devices. I don't remember if the version in git has a stopgap fix (letting the computer calculate and ignoring the cumulative capacity reported from the device).

My advice on the fly, without much investigating, is to try with other ID values. 0xCE seems "too high". 0xCE may be the checksum. Maybe try 0x20 or 20 decimal and see if it connects? Bit-snooping of the stock software may work (if you have access to Windows which I normally haven't).

Also, I'm very happy that someone shows interest for my program! First time I use github and actually try to share a program! Please excuse my newbie approach to github/software management. If you somehow succeed to connect, maybe I can use the data to see how things needed to be scaled, if any. The "IFactor" and "UFactor" constants is for scaling, if a trivial problem occurs like the software reports 10 times too high or low for a value (eg. I=1.00A when it's really 10.0A).

Hope this helps a little!

[ajay10000]

Thank you for your response @JOGAsoft. I found out about your software through google, on the EEVblogs forum (https://www.eevblog.com/forum/projects/linux-software-for-zketech-ebc-a05-and-ebc-a10h).

I was hoping there was an alternative to the Chinese EB software that could be modified, as they haven't provided any updates in a while. I know you have put an incredible amount of work into your program and it is a great achievement, especially with the extra features! I program with python and simple C++ but don't follow pascal well. I have looked through the code to see if I can convert it but it's beyond my level of expertise.

I tried some ID's up to 08 before in ebcc.conf, so now I'm trying some higher ones. I'll report back.

Regards - Andrew

[hajo2020]

Hello, I am here for the first time and Linux beginner. I would like to use the EBC controller under Linux. Unfortunately, I quickly came to my limits. I have installed the packages TLazSerial and Jujibo. But what do I have to do now? sudo socat -d -d pty,raw,echo=0 /dev/ttyUSB0,raw,echo=0 I have entered and get 2022/07/01 16:23:07 socat[10579] N PTY is /dev/pts/1 2022/07/01 16:23:07 socat[10579] N opening character device "/dev/ttyUSB0" for reading and writing 2022/07/01 16:23:07 socat[10579] N starting data transfer loop with FDs [5,5] and [7,7] reported this back. Who can help me now?

Thanks Hermann

[JOGAsoft]

Hi Hermann. I'm unsure. I'm unfamiliar with the socat tool and when I have serial problems (in Debian) it's usually that my main user isn't part of the "dialout" group which is needed for tty/ttyUSB access. I don't know if the serial port needs to be configured in any special way beforehand. I setup the port in the program according to the protocol description (which is 115200-8-n if I remember correctly). I probably need a bit more information in order to help you. Regards, JOGA

[JOGAsoft]

...btw I don't seem to be able to push updates. Git needs a incomprehensible "personal access token" because they seem to have decided that strong passwords are out of fashion... I'm used to CVS och Subversion. Git doing things "different", have a different nomenclature and just cannot work properly...

[JOGAsoft]

Ok, I did manage the github thing. Tried to commit, but it apparently is the latest version on github.

[JOGAsoft]

I found a text file on my computer that I've copied from some forum probably. Someone claims that the original ZKE software DO run under linux with Wine. I haven't had any success myself, that's why I wrote my program, but maybe this can be a solution for some of you:

I have been using the ZKE EBC-A05+ for a while now.

For those Linux users, the ZKE software works fine in Linux, under WINE. Just install the software and the driver in WINE. You will then need to make a symbolic link to com2 .

To do this, just open a terminal in your directory:

/home/[your home directory]/.wine/dosdevices

Then type in the following command:

sudo ln -s /dev/ttyUSB0 com2

Enter your sudo password when prompted and you should be good to go.

You may need to change the USB and com port numbers, depending upon your Linux distribution and hardware.

---

(Also: add user to the dialout group!)

Regards, JOGA

[JOGAsoft]

Now I have made some (untested - my EBC isn't near at the moment) updates. The program should now say something like "NN unknown" in the connected info field, where NN is a hex byte of the returned model number. This maybe could help with creating the right identifiers in the .conf file. It uses all other parameters from the first (EBC 05) unit in the conf file.

Please come back to me and tell me what it reports on your EBC A20, and what changes you deduce you need to the ebcc.conf/.init files.

Regards, JOGA

[ajay10000]

Hi JOGA, I've had some success with the update! Thank you for your work on this.

I recompiled the program in Lazarus on the Raspberry Pi 3B+ with bullseye aarch64. On starting the program ebcc, it showed Connected: 09 unknown

I was able to discharge a battery and monitor voltage and current, as shown in the attachment. When charging, the EBC-A20 relay clicks on and off within one second and does not start charging. The discharging was 10 times the current selected, so I have updated ebcc.conf with the IFactor=10 as per the following: [Models] Name_1=EBC-A05 Name_2=EBC-A10H Name_3=EBC-A20

[EBC-A05] Ident=05 IFactor=10 UFactor=1 Connect=fa 05 00 00 00 00 00 00 05 F8 Disconnect=fa 06 00 00 00 00 00 00 06 F8 Stop=fa 02 00 00 00 00 00 00 02 f8

[EBC-A10H] Ident=06 IFactor=1 UFactor=1 Connect=fa 05 00 00 00 00 00 00 05 F8 Disconnect=fa 06 00 00 00 00 00 00 06 F8 Stop=fa 02 00 00 00 00 00 00 02 f8

[EBC-A20] Ident=09 IFactor=10 UFactor=1 Connect=fa 05 00 00 00 00 00 00 05 F8 Disconnect=fa 06 00 00 00 00 00 00 06 F8 Stop=fa 02 00 00 00 00 00 00 02 f8

Regards, Andrew

[ajay10000]

After making that change and restarting ebcc, the port is not recognised as per this image:

I will restart the Raspberry to see if it will work again.

Update: After restarting both the Raspberry Pi and the EBC-A20, I can't connect anymore. I will wait to see if the first working test provides any clues. Thank you!

[JOGAsoft]

Hi! That's some progress! Now we know that the A20 probably has the device number 09. If you can't connect again, check first that the serial interface still is ttyUSB0. But according to your picture, that's not the problem since you got some replies in the console. I guess it's from the same connection attempt? I shall try to decipher the console data later. One first thought is that the connection packets may differ from A05/A10H and the program doesn't consider itself connected with a unusual reply.

But, if you managed to connect before and it worked, hmm, that means it's something else. Had you updated the conf file when you succeeded, or did it work when the device was "09 unknown"? I haven't tested the latest update myself due to no access to my devices at the moment, but I may fool around a little later. Regards, LL

[JOGAsoft]

Committed a new version with a bug fix. Of course I introduced a bug by adding code without testing. After the last commit, all devices were suddenly "Unknown". Fixed.

[ajay10000]

Hello again and thanks for the update. After the update it was very similar to last time. The EBC-A20 connected as '09 unknown' and discharge worked well. Charging stopped again quickly as above. I think it is fair to say charging is not sending/receiving the correct command/s, but discharging is working.

Anyway, I took the next step of adding the device to ebcc.conf as per above, and unfortunately that had the same result of stopping it from working completely. Somehow it seems to save a setting or crash something that cannot recover.

To answer your previous question, it worked until I changed ebcc.conf.

If I can help at all by sending output, etc. please let me know. I will try again tomorrow after a fresh restart. Regards, Andrew

[JOGAsoft]

I'm afraid the only way around is to sniff the communication between the original program from ZKE and the A20. My program just know the commands for the EBC 05, and it happens to work with A10. There may be software tools to sniff the traffic, but otherwise one can put the TX and RX lines to RX on two separate serial ports and read the traffic. Unfortunately I don't have a A20, so I can't do it. I've searched the net high and low for the protocol, but found nothing.

[ajay10000]

Thanks JOGA, some progress to report and I'm trying to understand how it all works and comes together.

I sniffed the serial port using the original software and attach a CSV file of the results. I have divided the commands with a blank line: Turn device on, Connect (fa 05 00 00 00 00 00 00 05 f8), Start charging (fa 21 00 0a 00 00 00 00 2b f8), Change settings and continue (fa 21 00 32 06 00 00 0a 1f f8), Stop (fa 02 00 00 00 00 00 00 02 f8), Disconnect (fa 06 00 00 00 00 00 00 06 f8). ebc-a20 220714 p1.csv

I have also compiled the ebcc program on Windows 10 and found that the EBC-A20 acts in a very similar way to how it worked on the Raspberry Pi with linux:

1. The discharge command works, but it doesn't send the configured settings, so it is using last settings.
2. When charging, it starts then stops immediately.
3. However it is not showing the readings as per the screen shot below.
4. Some screen shots: Error before GUI window displays:

Main EBCC window after connection to COM3:

I added the device in ebcc.conf: [EBC-A20] Ident=09 IFactor=10 UFactor=1 Connect=fa 05 00 00 00 00 00 00 05 F8 Disconnect=fa 06 00 00 00 00 00 00 06 F8 Stop=fa 02 00 00 00 00 00 00 02 f8

[bdynamic]

I received my EBC-A20 today as well. After compilation i added the following entries to the config:

[Models]
Name_1=EBC-A05
Name_2=EBC-A10H
Name_3=EBC-A20H

[EBC-A20H]
Ident=09
IFactor=10
UFactor=1
Connect=fa 05 00 00 00 00 00 00 05 F8
Disconnect=fa 06 00 00 00 00 00 00 06 F8
Stop=fa 02 00 00 00 00 00 00 02 f8

The EBC-A20 model name gets correctly displayed. Unfortunetly it seems that singe charging doesn't work.

I used the following settings:

• PbAC
• Cells 6
• Cutoff current 0.1 after 2 min
• Charge current 1A

This is the console output.

R:FA7400C83A5D00040000013E0C6C044C06CEF8 CE
cCurrent: 0.2
Time: 1
cCapacity: 1E1000
cEnergy: 1E1000
S: fa6100000006000067f8 67
S: fa0200000000000002f8 02
S: fa0200000000000002f8 02
S: fa0500000000000005f8 05
E: fa0200003518006600000064060000140936f8fa0200003518006600000064060000140936f8 36
cCurrent: 0.2
Time: 1
cCapacity: 1E1000
cEnergy: 1E1000
S: fa610428000600004bf8 4B
E: fa7a0000351800000000013e0c7d08b809a0f8fa0200003518000000000214000600140922f8 A0
S: fa0200000000000002f8 02
S: fa0200000000000002f8 02
cCurrent: 0.1
Time: 2
cCapacity: 1E1000
cEnergy: 1E1000
S: fa610428000600004bf8 4B
E: fa16000034ea0000000002140006001409c5f8fa02000034ea0000000002140006001409d1f8 C5
S: fa0200000000000002f8 02

The relay clicks and the fan goes on but no charge.

[nodurah]

Hello,

my experience with the EBC-A20 is the same as bdynamic's. The fan starts a relay clicks and then it stops. I tried it with the charging and discharging mode.

For testing purposes I used a single cell NiMH setup.

The Console looks like this:

For Charge:

R:FA7400C83A5D00040000013E0C6C044C06CEF8 CE
S: fa0200000000000002f8 02
S: fa0500000000000005f8 05
cCurrent: 0.06
Time: 0
cCapacity: 1E1000
cEnergy: 1E1000
S: fa21003b000100001bf8 1B
E: fa160000051b00000000003b0001000a0931f8fa020000051b00000000003b0001000a0925f8 31
S: fa0200000000000002f8 02
S: fa0200000000000002f8 02

For Discharge

cCurrent: 0.06
Time: 0
cCapacity: 1E1000
cEnergy: 1E1000
S: fa21003b007500006ff8 6F
E: fa160000051b00000000003b0075000a0945f8fa020000051b00000000003b0075000a0951f8 45
S: fa0200000000000002f8 02
S: fa0200000000000002f8 02

Any help would be appreciated. Thanks in advance!

[JOGAsoft]

Hi everybody! I haven't really had the time to investigate this further but I consider buying an A20 to settle this once for all. But, there seems to be different models, A20 and A20H and I think I've seen different variations on those models too. I have an A05 and an A10H. Which exact versions do you all have? Hopefully I can investigate a bit in the coming week. /Joga

[nodurah]

Hello JOGA, thanks for the reply and looking into it! I can offer help in testing. I own an EBC-A20. Cheers

[LesniakM]

Hello guys.

I've got EBC-A10H and I'm trying to get rid of cable (wifi connection via esp12E instead) and just like @JOGAsoft, I'm writing my own app, simply because of limitations of the original one.

I'm writing my app in python 3.9 with Tkinter gui and so far I've figured out what most data in the packet means (correct me if I'm wrong):

b0: always have value FA it's frame start or model number b1: values from 00 to aprox 71 - work/mode status b2, b3: Received current: simply divide DEC value by 100 to get Amps b4, b5: Received Voltage: multiply it's value in DEC by 0,0096330275 to get Volts. b6, b7: Capacity, just convert to DEC to get value in mAh. b8, b9: Always 00, no clue what that is. b10, b11: Setted current. b12, b13: Setted voltage. b14, b15: Setted max time or cut off value (differs in distinct modes). b16: Always 06, don't know that's. b17: Checksum. b18: Always F8, end symbol or something like that.

I've tried to understand @JOGAsoft's code, but since I never used Pascal, I pretty much failed to understand how CRC checksum is calculated.

Could you guys help me with some tips which bytes I have to use to calculate checksum and what algorithm is used?

Would be cool to know what b8, b9 and b16 does.

I really appreciate any help. Cheers.

[ajay10000]

Hi everybody! I haven't really had the time to investigate this further but I consider buying an A20 to settle this once for all. But, there seems to be different models, A20 and A20H and I think I've seen different variations on those models too. I have an A05 and an A10H. Which exact versions do you all have? Hopefully I can investigate a bit in the coming week. /Joga

Hi @JOGA, As far as I can tell, there is only one EBC-A20 model. 'C' stands for charger in the model line I believe. There is a "EBD-A20H", which only discharges. There is also a "EBC-B20H" which is higher voltage and higher current charging. I have attached the model line-up from the ZKETech website. The posters above seem to be interested in the EBC-A20 model, as am I.

[ajay10000]

Hello guys.

I've got EBC-A10H and I'm trying to get rid of cable (wifi connection via esp12E instead) and just like @JOGAsoft, I'm writing my own app, simply because of limitations of the original one.

I'm writing my app in python 3.9 with Tkinter gui and so far I've figured out what most data in the packet means (correct me if I'm wrong): ... I've tried to understand @JOGAsoft's code, but since I never used Pascal, I pretty much failed to understand how CRC checksum is calculated. ...

Hi @LesniakM, good luck! I wish I could help with the code but it is beyond me. If @JOGAsoft is able to help at all, I would also be very interested to understand how the serial packets are decoded. Do you have a github where we can follow your progress? I would be happy to help you and @JOGAsoft with testing.

Cheers - Andrew

[LesniakM]

Hey guys,

I've already figured out how to calculate CS in python. If someone is curious, example code is below:

"""
This is example full frame of data sent from PC to battery tester:

    [0xfa, 0x71, 0x00, 0x32, 0x01, 0x70, 0x00, 0x05, 0x37, 0xf8]
    START   b0    b1    b2    b3    b4    b5    b6    CS    END

It is 9 bytes length, but for checksum calculation we use only bytes from b0 to b6.
Since we sniffed it, we know all values. But normally we know START and END (always same) and figure out bytes
from b0 to b6 by calculating its values from current, voltage and other variables.
But CS cannot be calculated using simple 'human' math.
That's why we need to use checksum function."""

example_frame = [0xfa, 0x71, 0x00, 0x32, 0x01, 0x70, 0x00, 0x05, 0x37, 0xf8]
not_full_frame = [0xfa, 0x71, 0x00, 0x64, 0x01, 0x70, 0x00, 0x10]  # CS and END missing in this frame

def byte_xor(byte1: int, byte2: int):
    """
    Since there is no simple method to perform XOR on bytes in python, this function is used to do that.
    For example:
    0xfa is 250 in DEC or 1111 1010 in bin.
    0x71 is 113 in DEC or 0111 0001 in bin.
      XOR result is then  1000 1011, which gives us 139 in DEC or 0x8b in hex.

    :param byte1: any integer in range 0-255
    :param byte2: any integer in range 0-255
    :return: result in range 0-255
    """
    assert 0 <= byte1 <= 255
    assert 0 <= byte2 <= 255
    xor = 0
    for bit1, bit2 in zip(format(byte1, '08b'), (format(byte2, '08b'))):
        xor = xor*2 + int(bit1) ^ int(bit2)
    return xor

def checksum(data: list[int]) -> int:
    """
    CS is calculated by performing XOR CRC on bytes from b0 to b6. START, CS and END bytes are excluded.
    https://en.wikipedia.org/wiki/Cyclic_redundancy_check
    :param data: list of bytes in int format.
    :return: Checksum as int.
    """
    cs = 0
    for byte in data:
        cs = byte_xor(cs, byte)
    return cs

check = checksum(example_frame[1:-2])  # We drop START byte and CS, END bytes by slicing [1:-2]
print(f"Calculated CS is: {hex(check)}, should be: {hex(example_frame[-2])}")
print(f"'not_full_frame' should have CS equal to: {hex(checksum(not_full_frame))}")

@ajay10000 currently I don't have repo for this project, but pretty sure I will publish one in the future. Decoding data from each frame is pretty simple. That's example frame sent from tester to PC:

Let's split it to each byte, all in hex:

(edit: 22.12.2022 - there are small mistakes with more significant bytes, please take a look at my next comment) START: fa - Always same b0: 11 - Mode value, 0x11 means C-CV, 0x0a means D-CC, each mode have its own value. b1: 00 - Current value, more important byte b2: 64 - Current value. 0x0064 is 1000 in DEC. And its corresponds to 1.00A charge current. b3: 0e - Voltage value, more important byte b4: cf - Voltage value 2nd byte. 0x0ecf is 3791, multiply it by 0,00096330275 and we got 3,652V b5: 00 - Capacity so far, more important byte b6: 01 - Capacity next byte. 0x00 01 is just 1 in DEC, what means so far we charged 1mAh. b7: 00 - Don't know. b8: 00 - Don't know either. b9: 00 - Current value that were set, more important byte b10: 64 - Current value that were set, more less byte. Here it's again 0x0064 -> 1.00A b11: 01 - Voltage target value, more important byte b12: a0 - Voltage target value, less important byte. 0x01a0 is 416, multiply it by 0,0096330275 and we got 4.00V. b13: 00 - Current cutoff (for C-CV), more important byte b14: 05 - Current cutoff (for C-CV), less important byte. 0x0005 is just 5 in DEC. 5/100 = 0.05 -> 0.05A. b15: 06 - Not idea CS: 73 - Checksum. If wrong value is delivered, based on previous bytes, frame is rejected. END: f8 - Always same.

[ajay10000]

Thanks for the explanation @LesniakM! It is a great help to step through each value and learn how the device works. I wonder if one of the missing values may be battery chemistry? Cheers - Andrew

[LesniakM]

I don't think so. When you choose different battery type, for example Pb or nimh byte corresponding to workmode changes, but not these zeros.

[skeutmeier]

Hey, Very nice to see this project. Based on your experience by adding the 20amp version, do you think the 40amp version will work aswell? Because I am thinking of purchasing this one https://dutch.alibaba.com/product-detail/Zketech-5v-12v-24v-48v-60v-1600406120439.html?spm=a2700.pccps_detail.0.0.7df8412761IFpN

Would be great to be able to run it on linux

[dev-strom]

I did a Wireshark dump on a Windows machine running the original software from zktech (EB Tester Software V1.8.5) talking to my EBC-A20:

C-CV 4.2V 0.1A Cut off

OUT fa0500000000000005f8                     CONNECT
IN  fa02000010b300020000003b01b4010a092ff8
IN  fa66000010b300020000013e0c5e08af0904f8
IN  fa02000010b300020000003b01b4010a092ff8
IN  fa66000010b300020000013e0c5e08af0904f8
IN  fa02000010b300020000003b01b4010a092ff8
OUT fa21006401b4000a0af8                     C-CV - 4.2V, CutOff 0.1A
IN  fa70000010b300000000013e0c5e08af0910f8
IN  fa0c0064116b00000000006401b4000a09c0f8
IN  fa700064117200010000013e0c5e08af09b5f8
IN  fa0c0062117800010000006401b4000a09d4f8
IN  fa700060117800020000013e0c5e08af09b8f8
IN  fa0c005e117800020000006401b4000a09ebf8
IN  fa0c005c117800030000006401b4000a09e8f8
IN  fa0c005a117800030000006401b4000a09eef8
IN  fa0c0059117800040000006401b4000a09eaf8
IN  fa0c0057117800040000006401b4000a09e4f8
IN  fa0c0056117800050000006401b4000a09e4f8
IN  fa0c0054117800050000006401b4000a09e6f8
OUT fa0200000000000002f8                     STOP
IN  fa020054117800060000006401b4000a09ebf8
IN  fa02000010d700060000006401b4000a0911f8
IN  fa02000010d100060000006401b4000a0917f8
IN  fa02000010d100060000006401b4000a0917f8
OUT fa0600000000000006f8                     DISCONNECT

The test stopped at capacity 6mAh and energy 0.021

I hope it is usefull! Sadly it looks like the format is different from the A10H as described by LesniakM.

@LesniakM: the value 0x06 in b15 is the hardware model. 0x06 is the EBC-A10H, 0x09 is the EBC-A20.

Here are some different charging commands:

OUT fa21006401b4000a0af8  C-CV - 4.2V, Current 1.0A, CutOff 0.1A
OUT fa21006401aa000ae4f8  C-CV - 4.1V, Current 1.0A, CutOff 0.1A
OUT fa21003201aa000ab2f8  C-CV - 4.1V, Current 0.5A, CutOff 0.1A
OUT fa21003201aa0014acf8  C-CV - 4.1V, Current 0.5A, CutOff 0.2A

[LesniakM]

@dev-strom Thanks for info about 15th byte. And yeah, your communication differs a bit, for example I'm using 0x71 to start C-CV charging, and you 0x21.

I must add, that there was slight error in my previous table. I'm talking about these bytes: " b3: 0e - Voltage value, more important byte b4: cf - Voltage value 2nd byte. 0x0ecf is 3791, multiply it by 0,00096330275 and we got 3,652V b11: 01 - Voltage target value, more important byte b12: a0 - Voltage target value, less important byte. 0x01a0 is 416, multiply it by 0,0096330275 and we got 4.00V. "

I was a bit confused about this 0,00096330275 value. When I sniffed communication with different voltages I figured out what was wrong.

Let's take 4.00V, which should result in values 0x01 at byte 11th, and 0xa0 at 12th. Previously I were calculating voltage with formula: Hbyte * 256 + Lbyte = 256 + 160 = 416. Then I needed to multiply it with factor of 0.00095 to 0.00098 to get correct value, aka 4.00V.

It's simply because more significant byte should be multiplied by 240, not 256: Hbyte + 240 + Lbyte = 240 + 160 = 400. Now only division by 100 is needed for bytes 11/12 or by 1000 for bytes b3/b4.

Same thing happends with more significant current byte. Now we have got all bytes properly decoded :D

[ajay10000]

I did a Wireshark dump on a Windows machine running the original software from zktech (EB Tester Software V1.8.5) talking to my EBC-A20:

Hi @dev-strom that's great! How did you get the dump from Wireshark? I have been able to get each byte in a usb.capdata column, but if you have a better solution, it will save me writing a routine to consolidate it. Example: Leftover Capture Data fa0500000000000005f8 fa 02 00 00 1a b9 00 09 00 00 00 1e 03 00 00 0a 09 b6 f8

I got my earlier posted CSV data from a trial/limited version of Device Monitoring Studio.

Thanks to @LesniakM and others for combined wisdom in this thread! It would be great to get a dump of data for the EBC-A10H for comparison.

I have analysed the available data in Excel and it has helped me visualise it. I've attached the workbook for anyone to play with. EBC hex decode v1a.xlsx

-So far b7 and b8 are both always zero (00) in received data. -The multiplier for voltage is different in the sent data (i.e. 420) vs received data (i.e. 4200), highlighted in the spreadsheet.

Cheers - Andrew

[dev-strom]

@ajay10000 Capturing usb traffic on a windows machine is really easy. You need https://desowin.org/usbpcap/, but it is already included in the setup files of wireshark 4.0.2. Before you start to capture the traffic, you have to choose the usb device you wish to monitor. While wireshark is running you can filter all the massive usb traffic. To do so, you have to enter (usb.transfer_type == 0x03) && (usb.data_len > 0) into the filter field.

The result looks like that (last line is what you want):

[ajay10000]

Thanks @dev-strom, I was getting a similar result, except that the "Packet Data Length" for me is 1 instead of 19, which is why I'm getting only one byte at a time. If you have any thoughts on that please let me know.

Cheers!

[rburkovsky]

Did someone managed to get it working with A20? I am just looking for an alternative for the original software, not necessarily want to run it on Linux, but willing to try. The problem with the original software is that it stops updating the data though the tester itself continues to run and updates the Capacity value on its display. Didn't do deep dive into the problem, so I don't know what that really is and if it is even related, but saw the phrase that "after the last updates Windows blocks PL2303 driver". Does anyone have experience of successful running A20 on Windows 10?

[tux-]

Tried win11, works a little bit, then windows updates driver, I choose to rollback, it works again, then windows updates driver while test is running, and program stops updating, etc, etc. A nightmare. Tried this version with the A20 and it does not work, just shows inf voltage, etc. Found doc here on how to make win version work with wine and bingo! Now something works at least. I had to first start the wine app, then bind port (on xUbuntu 22.04). Seems like every time I start the wine app, it will rebind com2 to the wrong path and I manually have to override the symlink again. Hope to one day see a nodejs package or something with just the communication, so I can make anything on top (would be nice to have live cli logging for remote monitoring, etc)

[dev-strom]

For all the people who like the ESP microcontrollers and don't want to run a PC or notebook all the time during cell testing, maybe this project could be interesting for you: esp-ebc-mqtt.

[ardiehl]

just made some compare between what the windows software and ebcc send for charging for the A20: `; sent from Windows software - charge

fa 21 00 64 01 b4 00 0a 0a f8 ; C-CV 1A 4.2V 0.1A fa 02 00 00 00 00 00 00 02 f8 fa 06 00 00 00 00 00 00 06 f8

fa 21 00 c8 01 b4 00 0a 56 f8 ; C-CV 2A 4.2V 0.1A fa 02 00 00 00 00 00 00 02 f8 fa 06 00 00 00 00 00 00 06 f8

fa 21 01 a0 01 b4 00 0a 3f f8 ; C-CV 4A 4.2V 0.1A same

fa 21 01 a0 01 a0 00 0a 2b f8 ; C-CV 4A 4.0V 0.1A same

fa 21 01 a0 00 64 00 0a ee f8 ; C-CV 4A 1.0V 0.1A

fa 21 01 a0 00 64 00 64 80 f8 ; C-CV 4A 1.0V 1A

fa 21 01 a0 00 64 00 96 72 f8 ; C-CV 4A 1.0V 1.5A

fa 21 01 a0 00 64 01 3c d9 f8 ; C-CV 4A 1.0V 3A | ----- ----- ----- -- | | | | |-------------- Checksum | | | |------------------- Cutoff current | | |------------------------- Voltage | |------------------------------- Charge current |------------------------------------ Command

; send from Linux software

fa 41 04 28 00 01 00 00 6c f8 ; C-CV 1A 4.2V 0.1A - with IFactor=10, UFactor=1, what is command 41 (LiPo) when windows software sends 21 (NIMH) ?

fa 41 00 64 00 01 00 00 24 f8 ; C-CV 1A 4.2V 0.1A - with IFactor=1, UFactor=1 fa 41 00 c8 00 01 00 00 88 f8 ; C-CV 2A 4.2V 0.1A - with IFactor=1, UFactor=1, charge current: correct, voltage: wrong, cutoff current: wrong

Tests

fa 71 - no reaction on A20 `

Looks like the windows software is always using the command 41 and the cutoff voltage and/or the cutoff current is not send by ebcc.

[ardiehl]

charging with the A20 works.

EBC-Controller

found some inconsistency in the checksum as well, the start and end codes (0xfa, 0xf8) are not accepted as a checksum on the A20, the device expects 0x0a and 0x08 instead. Changed that in the checksum sent and receive procedures as well.

The last time i wrote code in fpc/delphi/lazarus is about 25 years ago, so i'm a liitle bit slow ;-)

Discharge to be checked.

Thanks JOGAsoft to make this software available on github. From my point of view it would make sense to transfer my changes back to your github repository when it works finally.

BTW: The A20 does not have charging profiles for different types of batteries like the other models seem to have. Voltage, current and dropoff voltage have to be specified in the charge-start package (0x21).

[JonasForssell]

Dear @ardiehl ,

Since you have forked the development and made emhancements for ebc-a20 support, perhaps you can concider adding support for calibration?

I have nuked my unit and need a complete reset of the calibration, but the PC software is useless for this. A feature in your software to either reset to good default values for calibration or allow calibration in detail would be enough.

I can go into detail on the calibration procedure if you want.

Thanks /Jonas

[ardiehl]

Hi Jonas,

unfortunately i'm using the windows software leveraging wine on linux to debug what the original software send to the device. I have already contacted ZKE tech and they will not provide any information about the protocol at all. My goal is to get charging and discharging working for the A20 and A40 (works with charging and discharging already, program to be checked and fixed). Sorry but i can not help you with calibration.

[ardiehl]

first release for the A20 and A40 published (Linux and Windows) ebcc-2.15

[ardiehl]

second release for the A20 and A40 published (Linux and Windows) mainly fixed a divide by zero only affecting connection to device under windows

[JonasForssell]

Hello! I am following your progress and it is great that you are developing this software. Calibration should be made in a similar manner as you are already working by sending commands across the serial link. I understand if you will not want to develop this part of the software but I will keep following your progress. Keep up the good work. /Jonas

Skickat från Yahoo Mail för iPad

Den onsdag, oktober 4, 2023, 10:06 em, skrev ardiehl @.***>:

Hi Jonas,

unfortunately i'm using the windows software leveraging wine on linux to debug what the original software send to the device. I have already contacted ZKE tech and they will not provide any information about the protocol at all. My goal is to get charging and discharging working for the A20 and A40 (works with charging and discharging already, program to be checked and fixed). Sorry but i can not help you with calibration.

— Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you commented.Message ID: @.***>

[cnrd]

@ardiehl I just tested v2.16 on windows 11.

While charging, the voltage overshoot the charging target. Had it set to 16.8V but ended up seeing the battery rising to 16.9V before I shut it down. The voltage kept climbing while the current was kept at a constant 2A.

Switching back to the "EB Tester Software" i did not observe any issue. As soon as voltage reached 16.8V, it was clamped and A fell slowly.

Not at all sure about the cause, just wanted to let you know.

[Davem734]

For Linux users, the ZKE "EB Tester Software" works in Linux, under WINE. If you are using an older kernel version you will probably have to update the ch341 driver to get the software to work with wine COM ports. Not sure if this is a problem with native Linux software (I never got EBC-controller to compile on my old laptop) but it probably is since the driver problem is related to the serial port parity settings.

Here are the steps that I used to get it to work with Ubuntu 14.04 on an old eeePC:

  Update Wine (https://tipsonubuntu.com/2019/02/01/install-wine-4-0-ubuntu-18-10-16-04-14-04/):
    $ wget -nc https://dl.winehq.org/wine-builds/winehq.key
    $ sudo apt-key add winehq.key
    $ sudo apt-add-repository -y "deb https://dl.winehq.org/wine-builds/ubuntu/ $(lsb_release -sc) main"
    $ sudo apt-get update
    $ sudo apt-get -y install --install-recommends winehq-stable
    $ sudo apt -y remove brltty                                     # It claims ttyUSB0 and is unnecessary unless you are using a braille e-reader  

  Update the USB driver (ch341.ko) in Ubuntu 14.04 is borked (https://github.com/WCHSoftGroup/ch341ser_linux):
    $ ls -l /lib/modules/$(uname -r)/kernel/drivers/usb/serial/                                                                                               # look for ch341.ko
    $ sudo mv /lib/modules/$(uname -r)/kernel/drivers/usb/serial/ch341.ko /lib/modules/$(uname -r)/kernel/drivers/usb/serial/ch341.ko.$(date +%y%m%d-%H%M%S)  # save the old driver
    - Build and install updated USB Driver, See: (https://github.com/WCHSoftGroup/ch341ser_linux) 
    $ sudo apt-get -y install git
    $ mkdir -p ~/Apps/CH341USB
    $ cd ~/Apps/CH341USB
    $ git clone https://github.com/WCHSoftGroup/ch341ser_linux
    $ cd ~/Apps/CH341USB/ch341ser_linux/driver
    $ make
    $ sudo make install

  Connect the USB cable to the Zketech EBC
  Plug the USB cable into the computer.
  Find the usb device assigned to the Zketech EBC
    $ lsusb
        Bus 002 Device 003: ID 1a86:7523 QinHeng Electronics HL-340 USB-Serial adapter
    $ sudo dmesg | grep ch341
        [   13.252672] usbcore: registered new interface driver ch341
        [   13.252806] usbserial: USB Serial support registered for ch341-uart
        [   13.252857] ch341 2-2:1.0: ch341-uart converter detected
        [   13.332276] usb 2-2: ch341-uart converter now attached to ttyUSB0
    $ ls /dev/tty*
      In this example the usb device assigned to the Zketech EBC (ch341) is ttyUSB0 (it will be ttyCH341USB0 if you updated the driver)

  Override Wine's default device mapping: 
    $ wine regedit
      Note: this is a GUI and can not be used via SSH
    Create string entries in HKEY_LOCAL_MACHINE\Software\Wine\Ports 
      The entry name is the Windows device name COM2
      The entry value is the path to the Unix device /dev/ttyUSB0 (or ttyCH341USB0 if you updated the driver)
      Also want to create an entry named COM33 with  /dev/ttyS1 to remove the COM33 device which is now a duplicate of COM2. 
    Shut down Wine: 
      $ wineserver -k 

  Add your user to the dialout group:
    $ sudo adduser $USER dialout
    $ groups $USER

  You will also have to create symbolic links in ~/.wine/dosdevices (may not be needed in newer versions of Wine) 
    Look for a symbolic link from ttyUSB0 to com2:
      $ ls -l ~/.wine/dosdevices/
    Make a symbolic link from ttyUSB0 to com2 (if it is not there already):
      # $ cd ~/.wine/dosdevices
      # $ sudo ln -s /dev/ttyUSB0 com2
      $ sudo rm ~/.wine/dosdevices/com2
      $ sudo rm ~/.wine/dosdevices/com33
      $ sudo ln -s /dev/ttyUSB0 ~/.wine/dosdevices/com2
      $ sudo ln -s /dev/ttyS1 ~/.wine/dosdevices/com33
          You may need to change the USB and com port numbers, 
          depending upon your Linux distribution and driver version.

  Reboot the computer
    $ sudo reboot 0

  Test COM2 port:
    Plug in USB serial port adaptor  
    $ stty -F ~/.wine/dosdevices/com2 -a
      should return somthing like:
        speed 9600 baud; rows 0; columns 0; line = 0;
        intr = ^C; quit = ^\; erase = ^?; kill = ^U; eof = ^D; eol = <undef>; eol2 = <undef>; 
        swtch = <undef>; start = ^Q; stop = ^S; susp = ^Z; rprnt = ^R; werase = ^W;
        lnext = ^V; flush = ^O; min = 1; time = 0;
        -parenb -parodd cs8 hupcl -cstopb cread clocal -crtscts
        -ignbrk -brkint -ignpar -parmrk -inpck -istrip -inlcr -igncr icrnl ixon -ixoff -iuclc -ixany -imaxbel -iutf8
        opost -olcuc -ocrnl onlcr -onocr -onlret -ofill -ofdel nl0 cr0 tab0 bs0 vt0 ff0
        isig icanon iexten echo echoe echok -echonl -noflsh -xcase -tostop -echoprt echoctl echoke    

  Install the "EB Tester Software" in WINE.
    ! Do NOT install the driver .exe file !
    Right click on the EB Tester software .exe file and select "open with wine" to install. 

  Power up the Zketech EBC
    Click on Desktop Icon
      or:
    Wine->Programs->ZKETECH->EB Tester Software

Hopefully this will be useful to someone here...

[Davem734]

Here are the steps that I used to get the latest Lazarus IDE and the latest (forked to support the A20 and A40) EBC-controller software to work on my old eeePC (Ubuntu 14.04.6LTS Trusty Tahr i386):

  Ubuntu 14.04 USB driver is borked (See: https://github.com/WCHSoftGroup/ch341ser_linux)
  Remove the old Ubuntu ch341 USB driver:
    $ ls -l /lib/modules/$(uname -r)/kernel/drivers/usb/serial/                                                                                               # look for ch341.ko
    $ sudo mv /lib/modules/$(uname -r)/kernel/drivers/usb/serial/ch341.ko /lib/modules/$(uname -r)/kernel/drivers/usb/serial/ch341.ko.$(date +%y%m%d-%H%M%S)  # save the old driver

  Build and install the updated USB Driver: 
    $ sudo apt-get -y install git
    $ mkdir -p ~/Apps/CH341USB
    $ cd ~/Apps/CH341USB
    $ git clone https://github.com/WCHSoftGroup/ch341ser_linux
    $ cd ~/Apps/CH341USB/ch341ser_linux/driver
    $ make
    $ sudo make install

  Connect the USB cable to the Zketech EBC
  Plug the USB cable into the computer.
  Find the usb device assigned to the Zketech EBC
    $ lsusb
        Bus 002 Device 003: ID 1a86:7523 QinHeng Electronics HL-340 USB-Serial adapter
    $ sudo dmesg | grep ch341
        [   13.252672] usbcore: registered new interface driver ch341
        [   13.252806] usbserial: USB Serial support registered for ch341-uart
        [   13.252857] ch341 2-2:1.0: ch341-uart converter detected
        [   13.332276] usb 2-2: ch341-uart converter now attached to ttyCH341USB0
    $ ls /dev/tty*
      The usb device assigned to the Zketech EBC (ch341) is ttyCH341USB0

Install the current version of Lazarus IDE:

    $ sudo apt-get -y install git
    $ sudo apt-get -y install gdb
    $ sudo apt-get -y install libgtk2.0-dev
    # do not install lazarus from the Ubuntu repo 
    $ sudo apt -y remove lazarus* 
    $ sudo apt -y remove fpc-*
    $ sudo apt -y remove fp-compiler
    $ mkdir -p ~/Apps/FreePascal
    $ cd ~/Apps/FreePascal
    # i386 v3.2.2 (https://sourceforge.net/projects/lazarus/files/Lazarus%20Linux%20i386%20DEB/Lazarus%203.2/)
    $ wget --no-check-certificate https://downloads.sourceforge.net/project/lazarus/Lazarus%20Linux%20i386%20DEB/Lazarus%203.2/fpc-laz_3.2.2-210709_i386.deb     # fpc-laz
    $ wget --no-check-certificate https://downloads.sourceforge.net/project/lazarus/Lazarus%20Linux%20i386%20DEB/Lazarus%203.2/fpc-src_3.2.2-210709_i386.deb     # fpc-src
    $ wget --no-check-certificate https://downloads.sourceforge.net/project/lazarus/Lazarus%20Linux%20i386%20DEB/Lazarus%203.2/lazarus-project_3.2.0-0_i386.deb  # lazarus-project
    $ sudo dpkg -i ./fpc-laz_3.2.2-210709_i386.deb
    $ sudo dpkg -i ./fpc-src_3.2.2-210709_i386.deb
    $ sudo dpkg -i ./lazarus-project_3.2.0-0_i386.deb
    $ sudo apt-get install -f
    Open Lazarus IDE (it may ask for the following):
      Lazarus IDE->Configure Lazarus IDE->Lazarus Tab->Lazarus Dir: /usr/share/lazarus/3.2.0/ide
                        Configure Lazarus IDE->Compiler Tab->Compiler Dir: /usr/bin/fpc
                        Configure Lazarus IDE->FPC Sources Tab->/usr/share/fpcsrc/$(FPCVER)
    Install LazSerial package from the online Package Manager:
      Note that the Lazarus menu is accessed by clicking a little hidden downarrow 
        next to "Lazarus" in the status bar but only when the "Lazarus IDE v3.2" window is selected.
        hover the pointer next to "Lazarus" in the status bar and the downarrow will appear.
      Select the "Lazarus IDE v3.2" window
        Downarrow->Package->OnlinePackageManager
          Filter by Packages & LazSerial
          Click the box next to "LazSerial" in the list
          Click the "Install" icon at the bottom
          Click "yes" to confirm installation
          Click "yes" to confirm "rebuild Lazarus"  
    Install JujiboUtils package from the online Package Manager:
      Select the "Lazarus IDE v3.2" window
        Downarrow->Package->OnlinePackageManager
          Filter by Packages & JujiboUtils
          Click the box next to "JujiboUtils" in the list
          Click the "Install" icon at the bottom
          Click "yes" to confirm installation
          Click "yes" to confirm "rebuild Lazarus"  

Download, compile and run the EBC-controller software:

    $ mkdir -p ~/Apps/EBC-controller
    $ cd ~/Apps/EBC-controller
    $ git clone https://github.com/ardiehl/EBC-controller
        Select the "Lazarus IDE v3.2" window
          Open Lazarus IDE->Open->"~/Apps/EBC-controller/EBC-controller/ebcc.lpi"
      Select the "Lazarus IDE v3.2" window
        Downarrow->Run->Compile
        Downarrow->Run->Build
        (Alt-Tab to the "Messages" window to watch the progress)  
        Downarrow->Run->Run

Be sure to set the serial port to "ttyCH341USB0" so the EBC-controller software can connect with your battery tester.

Hopefully this post will help someone who would like to use an old i386 laptop to control their battery tester.

So far EBC-controller looks like a big improvement over the Zketech software. A big thanks to everyone who worked on EBC-controller.