Help wanted: UT804 protocol verification (real hardware needed)

[antoinecellerier]

Summary

The UT804 protocol was implemented from reverse engineering (Ghidra decompilation of UT804.exe V2.00 and binary constant extraction) and has never been tested against real hardware. Every aspect needs end-to-end verification.

Key finding: the UT804 uses FS9721-style 14-byte framing but with proprietary structured data — nibbles carry explicit mode codes, range codes and digit values, not raw LCD segment data.

What we need

Someone with a UT804 multimeter and its USB cable (CH9325 HID bridge, 1A86:E008).

What needs verification

Each line is one step of dmm-cli --device ut804 capture; a box gets ticked when a report from a real meter confirms it.

• dcv — Set meter to DC V
• dcv_short — DC V mode: touch the two probe tips together.
• dcv_negative — Set meter to DC V with leads reversed (negative reading)
• acv — Set meter to AC V
• acdcv — Set meter to AC+DC V (if the meter has it)
• dcmv — Set meter to DC mV
• acmv — Set meter to AC mV (if the meter has it)
• ohm — Set meter to Resistance (Ω)
• ohm_ol — Set meter to Resistance (Ω) with open leads (overload)
• ohm_body — Resistance mode: hold one probe tip between the fingers of each hand (body resistance, hundreds of kΩ).
• ohm_short — Resistance mode: touch the two probe tips together.
• cap — Set meter to Capacitance
• hz — Set meter to Frequency (Hz)
• duty — Frequency mode: switch the display to Duty Cycle (%)
• rpm — Set meter to Tachometer / RPM (UT803 only)
• diode — Set meter to Diode
• cont — Set meter to Continuity
• temp — Set meter to temperature (K-type thermocouple, if available)
• dcua — Set meter to DC µA
• acua — Set meter to AC µA
• dcma — Set meter to DC mA
• acma — Set meter to AC mA
• dca — Set meter to DC A
• aca — Set meter to AC A
• adp — Set meter to ADP / logic (UT804 only)
• ma_percent — Set meter to % (4-20 mA loop)
• hold — Press HOLD (wire encoding unknown — capture needed)

The CH9325 cable is receive-only, so the tool cannot press buttons: the hold step asks you to press HOLD, and the report's raw frames are what settle the flag encodings. Framing, the marker nibbles, the digit encoding, the sign, overload, AC+DC, the ADP/logic mode and the streaming rate are settled by the steps above.

Not covered by a capture step:

• MIN/MAX, REL and the low-battery indicator — press each on the meter during an extra freeform capture and say which annunciator was lit; nibbles 12–14 are the candidates
• Whether the meter needs the 0x5A trigger byte — the tool does not send it; if nothing ever streams, say so

One box below is not a capture step. Auto-detection landed in #9 — --device auto is the default now, so the tool picks the meter itself — but only the UT61+ family has ever answered the detector on a bench. The UT804 arm was read off the vendor traces: the meter streams over the CH9325 cable, and detection tells a UT804 from a UT803 by the marker nibbles in the frame.

• Auto-detection names this meter with no --device given

Verification steps

Use a dev build newer than 6d035fc4e2d15b2b6df7d22ea1a70b6c39e3a9c4, or build from source with cargo build --workspace.

dmm-cli list                                         # the meter should be listed
RUST_LOG=dmm_lib=debug dmm-cli --device auto info    # detection (#9): does it name your meter?
dmm-cli --device ut804 capture --unverified          # the steps above, then attach capture-ut804.yaml

The tool captures each step on its own once the meter settles into the mode asked for, asks you to confirm readings against the LCD. It says up front what it needs on the bench (shorted leads, a DC source); tell it what you lack and those steps are skipped. The report auto-saves after each step, so an interrupted run can be resumed.

More options

dmm-cli --device ut804 capture --list-steps        # every step, ✓ where hardware already confirmed it
dmm-cli --device ut804 capture --steps dcv,acv      # a subset
dmm-cli --device ut804 capture                      # the full run, confirmed steps included
RUST_LOG=dmm_lib=trace dmm-cli --device ut804 debug --count 5   # only if `list` shows nothing or capture gets no frames

What to report

• Meter model and firmware version if shown at power-on
• OS, version and architecture; which archive, or dmm-cli --version for a source build
• The cable: bundled or bought separately, and its VID:PID (CH9325 1A86:E008; lsusb, ioreg -p IOUSB -l, or Device Manager)
• The capture-ut804.yaml file — it holds every frame the meter sent and every parse rejection, so no separate trace run is needed unless the meter is not detected at all
• An LCD photo beside the tool's output for any reading the tool got wrong

Protocol reference

docs/research/ut803/reverse-engineered-protocol.md

[antoinecellerier]

Protocol-correctness review update (2026-06) — major parser overhaul

The analyzed UT804.exe (MD5 matches the spec) was recovered and the parser fully re-derived, with string constants and the bundled LCD fonts resolved from the binary. An independent adversarial pass reproduced every finding. All decompile-derived — a real UT804 is still needed.

Fixed (corrected from vendor, hardware confirmation pending)

• Negative sign — nibble 9 bit 2 (we had labeled it HOLD, so every negative reading parsed positive with a phantom HOLD flag). In frequency mode the same bit selects the duty-% display.
• Decimal point — positions count from the left; the old places-from-right reading inverted every table (DC V range 1 rendered 3.999 as "3999").
• Mode table — wrong for 9 of 15 codes; corrected from unit-string constants + font glyphs: 6 = °C, 7 = µA, 8 = mA, 9 = A, A = Continuity, B = Diode, C = Frequency (duty-% via the sign bit), D = °F, E = unknown (W glyph; hFE?), F = mA% (4-20 mA loop?).
• Overload — frame with nibble 1 = 0xA (not an "AC flag mode").
• Frequency / Ω range boundaries corrected (Hz: 0-1, kHz: 2-4, MHz: 5-7; Ω: 1, kΩ: 2-4, MΩ: 5-6).

Resolved gap

• Nibbles 12-14 confirmed never read by the vendor parser (frame parsed as a Delphi Copy() string of hex chars). MIN/MAX/REL/low-battery / UT804 HOLD encodings are still unknown — they may live in those nibbles.

Highest-value captures

• One frame per dial position (mode codes + decimal tables)
• Negative reading + overload
• MIN/MAX/REL/low-battery toggled in turn
• Modes 0xE (W glyph) and 0xF (mA%) dial positions; which of modes 1/2 each V dial sends

Capture with cargo run --bin dmm-cli -- --device ut804 capture.

[clazie]

I tryed it under linuxmint and here is the output:

zielke@X1-Yoga-CZ:~/Schreibtisch/dmm-tools-linux-x86_64$ ./dmm-cli list
[0] /dev/hidraw9 [CH9325] — USB to Serial
zielke@X1-Yoga-CZ:~/Schreibtisch/dmm-tools-linux-x86_64$ RUST_LOG=dmm_lib=debug dmm-cli --device auto info
dmm-cli: Befehl nicht gefunden.
zielke@X1-Yoga-CZ:~/Schreibtisch/dmm-tools-linux-x86_64$ RUST_LOG=dmm_lib=debug ./dmm-cli --device auto info
Error: unknown device: auto
zielke@X1-Yoga-CZ:~/Schreibtisch/dmm-tools-linux-x86_64$ RUST_LOG=dmm_lib=debug ./dmm-cli --device ut804 info
[2026-09-16T16:45:51Z INFO  dmm_lib] found CH9325 adapter (VID=0x1a86 PID=0xe008)
[2026-09-16T16:45:51Z DEBUG dmm_lib::ch9325] CH9325: opening device (VID=0x1a86 PID=0xe008)
[2026-09-16T16:45:51Z DEBUG dmm_lib::ch9325] CH9325: trying primary init (2400 baud + trigger)
[2026-09-16T16:45:52Z DEBUG dmm_lib::ch9325] CH9325: primary init succeeded (8 bytes received)
[2026-09-16T16:45:52Z INFO  dmm_lib] connected to UNI-T UT804 (FS9721)
[2026-09-16T16:45:52Z DEBUG dmm_lib::protocol::fs9721] fs9721: init (no trigger needed, meter streams on CH9325 connect)
WARNING: UNI-T UT804 support is EXPERIMENTAL (unverified against real hardware).
Run 'capture' to generate a report for validation:
  dmm-cli --device ut804 capture
Report feedback: https://github.com/antoinecellerier/dmm-tools/issues/16
Device: (name not supported)
Transport: CH9325
  CH9325 HID-to-UART bridge (WCH)
zielke@X1-Yoga-CZ:~/Schreibtisch/dmm-tools-linux-x86_64$ ./dmm-cli --device ut804 capture --unverified
error: unexpected argument '--unverified' found

Usage: dmm-cli capture [OPTIONS]

For more information, try '--help'.
zielke@X1-Yoga-CZ:~/Schreibtisch/dmm-tools-linux-x86_64$ ./dmm-cli --device ut804 capture
WARNING: UNI-T UT804 support is EXPERIMENTAL (unverified against real hardware).
Run 'capture' to generate a report for validation:
  dmm-cli --device ut804 capture
Report feedback: https://github.com/antoinecellerier/dmm-tools/issues/16
Checking meter communication...

USB adapter found but the meter is not responding.
To enable data transmission:
  1. Connect the USB cable to the meter
  2. Turn the meter on

Then run this command again.
[2026-09-16T16:46:53Z ERROR dmm_cli] meter not responding
Error: meter not responding
zielke@X1-Yoga-CZ:~/Schreibtisch/dmm-tools-linux-x86_64$ 

• Version of my UT804 is not shown
• Version for dmm-cli is 0.6.0
• it's the budled cable, CH9325 adapter (VID=0x1a86 PID=0xe008)
• The LCD shows "SEND"

The GUI shows also "NO response from meter"

[antoinecellerier]

Hi @clazie , thanks for trying this out! --device auto and capture --unverified semantics are only available in builds after 0.6.0, which you can get by using the latest dev build at https://github.com/antoinecellerier/dmm-tools/releases?q=prerelease%3Atrue . That being said, while the connection itself works, capture gives up before its first step when nothing it receives decodes as a reading, and it doesn't save what it did receive. I'm fixing that.

In the meantime, this dumps the raw bytes the meter sends. Could you attach its output as a txt file? That's the most useful next step:

RUST_LOG=dmm_lib=trace ./dmm-cli --device ut804 debug --count 5 > ut804-trace.txt 2>&1

Thanks a lot!

[antoinecellerier]

@clazie a follow-up to my last comment: the capture fix is in (0c27f67). While looking into your log, I also found that UNI-T's own UT804 software sets up the cable differently from dmm-tools 0.6.0, so the new dev build uses UNI-T's setup instead (17ea18f). It's here (linux-x86_64 archive): https://github.com/antoinecellerier/dmm-tools/releases/tag/dev-17ea18f

Along with the ut804-trace.txt from 0.6.0, could you run the same command from the dev build's folder and attach that output too? Comparing the two shows which setup works with your meter.

RUST_LOG=dmm_lib=trace ./dmm-cli --device ut804 debug --count 5 > ut804-trace-dev.txt 2>&1

If the dev build shows readings, ./dmm-cli --device ut804 capture walks through each dial position and saves a report to attach here. If it still says the meter isn't responding, it now saves what it received to capture-ut804-no-response.yaml; please attach that instead.

🤖 Generated with Claude Code

[clazie]

Here are the raw bytes the meter sends.

ut804-trace.txt

[clazie]

... mand here th bash log:

zielke@X1-Yoga-CZ:~/Schreibtisch/dmm-tools-dev-17ea18f-linux-x86_64$ ./dmm-cli --version
dmm-cli 0.7.0-dev (17ea18f)
zielke@X1-Yoga-CZ:~/Schreibtisch/dmm-tools-dev-17ea18f-linux-x86_64$ ./dmm-cli list
[0] /dev/hidraw9 [CH9325] — USB to Serial
zielke@X1-Yoga-CZ:~/Schreibtisch/dmm-tools-dev-17ea18f-linux-x86_64$ RUST_LOG=dmm_lib=debug dmm-cli --device auto info
dmm-cli: Befehl nicht gefunden.
zielke@X1-Yoga-CZ:~/Schreibtisch/dmm-tools-dev-17ea18f-linux-x86_64$ RUST_LOG=dmm_lib=debug ./dmm-cli --device auto info
[2026-09-16T20:38:40Z INFO  dmm_lib] found CH9325 adapter (VID=0x1a86 PID=0xe008)
[2026-09-16T20:38:40Z DEBUG dmm_lib::transport::ch9325] CH9325: opening device (VID=0x1a86 PID=0xe008)
[2026-09-16T20:38:40Z DEBUG dmm_lib::transport::ch9325] CH9325: trying primary init (2400 baud + trigger)
[2026-09-16T20:38:40Z DEBUG dmm_lib::transport::ch9325] CH9325: primary init got a report carrying 0 meter bytes
[2026-09-16T20:38:40Z DEBUG dmm_lib::detect] detect: listening on CH9325 for fs9721 stream
[2026-09-16T20:38:41Z DEBUG dmm_lib::detect] detect: nothing recognisable on CH9325
No meter answered over the USB cable.

UT803, UT804
  1. Connect the USB cable to the meter
  2. Turn the meter on

If the meter is on and transmitting but still not recognised, name it:
  dmm-cli --device <id> ...      (dmm-cli --help lists the ids)
and please report it with RUST_LOG=dmm_lib=debug output at
  https://github.com/antoinecellerier/dmm-tools/issues
Error: device not identified
zielke@X1-Yoga-CZ:~/Schreibtisch/dmm-tools-dev-17ea18f-linux-x86_64$ ./dmm-cli --device ut804 capture --unverified
WARNING: UNI-T UT804 support is experimental (unverified against real hardware).
Run 'capture' to generate a report for validation:
  dmm-cli --device ut804 capture
Report feedback: https://github.com/antoinecellerier/dmm-tools/issues/16
Checking meter communication...

USB adapter found but the meter is not responding.
To enable data transmission:
  1. Connect the USB cable to the meter
  2. Turn the meter on

Then run this command again.
Bytes received: 44, saved to capture-ut804-no-response.yaml
If the meter is on and still not answering, attach that file to https://github.com/antoinecellerier/dmm-tools/issues/16
[2026-09-16T20:39:33Z ERROR dmm_cli] meter not responding
Error: meter not responding
zielke@X1-Yoga-CZ:~/Schreibtisch/dmm-tools-dev-17ea18f-linux-x86_64$ ./dmm-cli --device ut804 capture
WARNING: UNI-T UT804 support is experimental (unverified against real hardware).
Run 'capture' to generate a report for validation:
  dmm-cli --device ut804 capture
Report feedback: https://github.com/antoinecellerier/dmm-tools/issues/16
Checking meter communication...

USB adapter found but the meter is not responding.
To enable data transmission:
  1. Connect the USB cable to the meter
  2. Turn the meter on

Then run this command again.
Bytes received: 44, saved to capture-ut804-no-response-2.yaml
If the meter is on and still not answering, attach that file to https://github.com/antoinecellerier/dmm-tools/issues/16
[2026-09-16T20:40:18Z ERROR dmm_cli] meter not responding
Error: meter not responding
zielke@X1-Yoga-CZ:~/Schreibtisch/dmm-tools-dev-17ea18f-linux-x86_64$ 

and the log file:

ut804-trace_dev_ver.txt

Greetings Claus

[clazie]

... and the two yaml files failed to upload