East Tester ET4410&ET4510 Desktop LCR Meter

[thephil]

Success!

Although, I haven't managed to get the original updater tool from East Tester to work, I am done writing my own updater. The tool was written in Python and should work on all common operation systems. If you are interested in trying it out (or simply have given up on the manufacturer's tool) you can find it on github: https://github.com/philpagel/ET44.py/tree/main/tools/fwupdater

Any reports on your experience using it are welcome.


EDIT 2026-05-18: The original Python script has been superseded by a compiled version (for Windows and LINUX). That should make using it a lot easier. The link above is still relevant.

[thephil]

Attached is V6.00.2611.089 for the pictured ET44xx hardware revision. The firmware is current as of April 1, 2026.

I hope this is not an April fools edition because I just flashed it to my meter...

[thephil]

I have tried waiting up to a second and still get that.

At some point I had manages to send more data before seeing the overflow. Not sure, what is going on.

Turns out I probably managed to jam the bootloader. Everything resolved after leaving the meter without power over night. I guess, some capacitor kept providing some voltage to some component preventing it from recovering after a failed upload.

[w.v.s.]

Success!

Although, I haven't managed to get the original updater tool from East Tester to work, I am done writing my own updater. The tool was written in Python and should work on all common operation systems. If you are interested in trying it out (or simply have given up on the manufacturer's tool) you can find it on github: https://github.com/philpagel/ET44.py/tree/main/tools/fwupdater

Any reports on your experience using it are welcome.

Congratulations and thank you for sharing the code!

[jheissjr]

Just a coincidence for uploading April 1. The file is the real deal.

[jheissjr]

I don't know what the numbers in the firmware version represent. What is the decoding of the firmware digits? For example the current version V6.00.2611.089

[thephil]

I don't think there is an official statement about it. But it seems that the major version is V6.00 and there are minor release where the first two digits represent the year. After that I 'm lost...

[w.v.s.]

After the year -I would guess- comes the week, but I did not even check for plausibility.

[jheissjr]

Year and week looks close to the date stamp on the file. Good idea.

[jheissjr]

Does anyone see changes in the new V6.00.2611.089?

[thephil]

For anyone interested, this is how the firmware update process works internally:

• The communication settings are 19200baud 8N1. There is no need to set the baud rate on the device because  the bootloader always uses these settings.
• To trigger the bootloader, send the magic number 1b42543936057a (hex) repeatedly (every 100ms) while turning on the instrument
• Once the bootloader is active, a menu is shown and we need to select item 1 (firmware upload)
• The bootloader then erases the flash memory.
• Once erasing is done we can start uploading the hex file.
• The device expects to be fed row by row and sends "." (0x2e) as an acknowledgement after each row. This is used for flow control. Not additional delays are necessary.
• The hex files are sent verbatim. No need for translating anything, filtering addresses or dealing with checksums.
• In contrast to the ET54xx electronic loads, who buffer the entire firmware file before starting to program, the et44xx seems to program flash as it receives the data.
• After sending the hex file, the bootloader menu is shown again. This time we select option 2 to launch the newly programmed firmware.

[w.v.s.]

Thank you for the description! Nice additional feature of the tool might be checking if the hex-file looks valid before starting the actual process.

[thephil]

Thank you for the description! Nice additional feature of the tool might be checking if the hex-file looks valid before starting the actual process.

Do you mean a simple plausibility check, so that nobody tries to send their favorite sound file? Or a full validation of the hex file?

[w.v.s.]

Maybe non-truncated hex-file with valid checksums in every line as a start. Checking that's a LCR-meter-hex-file and not an electronic-load-hex-file can wait until V3.0 ;-)

[thephil]

Maybe non-truncated hex-file with valid checksums in every line as a start. Checking that's a LCR-meter-hex-file and not an electronic-load-hex-file can wait until V3.0 ;-)

I'll think about it. So far, I had just used objcopy to convert it to bin. More in order to snoop around in the file than for validation...

[Martin72]

Hi,

I've kind of lost track of what's going on here....
Does this new hex file actually work?

[thephil]

Hi,

I've kind of lost track of what's going on here....
Does this new hex file actually work?

Yes, it does. I have flashed it to my et4410 and things seem to work. But I did not have the time to really test that firmware version. The rest of the recent chit-chat was about building a less nerve wrecking firmware update tool.

[cbelcher2020]

Attached is V6.00.2611.089 for the pictured ET44xx hardware revision. The firmware is current as of April 1, 2026.

I hope this is not an April fools edition because I just flashed it to my meter...

That would have been a really bad joke to pull on this forum, particularly this thread.

Going to pull your GitHub project and see if I can get my 4510 updated.
Keep you posted.

[w.v.s.]

I did some firmware-digging and I think I've found a reason for the next possible update:

Code: [Select]

ub_80515b0 calls sub_8040612 with the model-number-string as second parameter
sub_80515b0 is called by:
sub_805148c
in this context
sub_8054b62
sub_8040980(r0_18, &data_80515d8) // 00 00 00 00
sub_8040980(r0_18, &data_80515e0) // "MEASUREMENT"
->sub_8040980(r0_18, sub_80515b0) // model number
sub_8040980(r0_18, &data_80515ec) // "COMP"
sub_8040980(r0_18, &data_80515f4) // "COMPSET"
sub_8040980(r0_18, &data_80515bc) // "COMPset"
sub_8040980(r0_18, &data_80515fc) // "SYST"
sub_8040980(r0_18, &data_8051604) // "SYSTEM"
!!sub_8040980(r0_18, &data_80515c4) // "STSTem"
sub_8040980(r0_18, &data_80515cc) // "LIST"

*(uint32_t*)0x20000114 = 4;
*(uint32_t*)0x2000142f = 1;
goto label_80515a2;
*(uint32_t*)0x20000114 = 1;
goto label_80515a2;
*(uint32_t*)0x20000114 = 2;
goto label_80515a2;

According to this, I would assume, that the device reacts on "SYST", "SYSTEM" and  "STSTem" but not on "SYSTem" via SCPI  .

The "STSTem" is still in the latest firmware. So this appears not to be fixed, yet.

[cbelcher2020]

@thephil

Update:

Your Python script ran flawlessly.

Environment:

Model: ET4510
SN: 10772438001
Firmware prior to update: V6.00.2423.059.hex

Hex File used: ET44_V6.00.2611.089.hex

Windows 11 23H2 Build: 10.0.22631.6199
No-name USB to Serial interface
Chipset info:
   FTDI Chipset
   VID: 0403
   PID: 6001
Driver:
   Provider: FTDI
   Driver version: 2.12.36.20
   Driver date: 10/28/2024

PowerShell: 7.6.0
Python: 3.14.3

Followed your instructions and zero issues.

Did come back up in Chinese.  SET -> Up Arrow, will get you back in English.

Man, that was several orders of magnitude easier then that abomination East Tester provided.

 

[thephil]

Thanks for trying it and for the report.

[Martin72]

Why did you include the Chinese characters, anyway?
I’m going to give that a try over Easter.
At the same time, I sent an email to my former contact at East Tester asking for a changelog.
Maybe we’ll get lucky and he’ll reply.
Because, basically, with this kind of company from China, those contacts are just people in sales who have no idea about the rest of the business.
If I catch him on a good day, he’ll take the time to ask a colleague from development.
We’ll see.

[thephil]

Why did you include the Chinese characters, anyway?

I wanted the process to be fully transparent. In case something goes wrong you get the original error message and can translate it. If you don't like the verbosity, you can use the -q flag to make the tool silent.

[KungFuJosh]

Why did you include the Chinese characters, anyway?

I wanted the process to be fully transparent. In case something goes wrong you get the original error message and can translate it. If you don't like the verbosity, you can use the -q flag to make the tool silent.

Why not include the original Chinese and English beside it?

[thephil]

Why not include the original Chinese and English beside it?

Maybe later. For now the focus is to ensure it works reliably. It does in my hands but I'm looking forward to hearing what others experience. Once I'm confident that it also works stably for other people/OSes/meter models, I may add a few bells and whistles. Or make quiet the default. For now, I think the verbatim log is useful in case of error reports.