Help wanted: UT8803 protocol verification (real hardware needed)

[antoinecellerier]

Summary

The UT8803/UT8803E protocol has been implemented based on reverse engineering (vendor software decompilation, community implementations) but has never been tested against real hardware. Every aspect needs end-to-end verification.

What we need

Someone with a UT8803 or UT8803E multimeter and the CP2110 USB adapter.

What needs verification

• Frame extraction (21-byte frames, AB CD header, big-endian checksum)
• 0x5A streaming trigger byte — does the meter start streaming after this is sent?
• Mode byte mapping (23 position codes, 0x00–0x16) — do the mode labels match the meter's LCD?
• Range byte (0x30 prefix, like UT61E+)
• Display bytes (5 raw bytes) — ASCII or binary encoding?
• Flag byte → semantic flag mapping (HOLD, REL, MIN, MAX, AUTO, OL) — the raw-byte-to-status-word construction is complex; current bit assignments are plausible guesses
• Display value parsing (5 bytes → float) — are parsed values correct?
• Streaming rate (~2–3 Hz per manual)

Verification steps

1. Run the capture wizard

cargo run --bin dmm-cli -- --device ut8803 capture

The wizard will walk you through each measurement mode. Follow the prompts, confirm what the LCD shows vs. what the tool parsed.

2. Raw byte dump

If the capture wizard doesn't work at all (no response from meter), try a raw debug dump:

RUST_LOG=dmm_lib=trace cargo run --bin dmm-cli -- --device ut8803 debug

This shows raw HID bytes. Even if parsing fails, the raw dump tells us if framing is correct.

3. Basic reading

cargo run --bin dmm-cli -- --device ut8803 read --count 10

Compare each displayed value against the meter's LCD.

What to report

Open an issue or comment here with:

• Meter model (UT8803 or UT8803E)
• OS and version
• Result of each step above
• The capture YAML file (if the wizard produced one)
• Any raw debug output if things didn't work
• Screenshots of the meter's LCD alongside the tool's output are very helpful

Reference implementations

If you want to cross-check behavior:

• philpagel/ut8803e (Python, UT8803/UT8803E, detailed protocol docs)
• hskim7639/UNI-T (Python/Windows, UT8803E)

[antoinecellerier]

Protocol-correctness review update (2026-06)

A clean-room re-audit of the UT8803 parser against the uci.dll decompile (FUN_1001e5f0 + helpers) corrected the unit handling and the trigger attribution. All derived from the vendor binary — hardware still needed. The 2026-04 flag-bit mapping was independently re-derived and reconfirmed bit-for-bit, including the AUTO inversion.

Fixed (corrected from vendor, hardware confirmation pending)

• Unit magnitude prefixes — the display value is range-relative, and the vendor derives a prefix per (mode, range) via FUN_1001cdc0 (lines 23644-23700) plus base units via FUN_1001cff0 (23789-23829). We now emit the prefixed unit (mV/kΩ/MΩ/mH/nF/µF/mF/kHz/MHz); previously every reading carried the bare base unit, off by 10³–10⁶ on prefixed ranges. The ESR sub-modes (Inductance R, Capacitance R) are Ω, and the Q/D factor sub-modes are unitless. Confirm: e.g. a ~5.999 kΩ resistor should read "5.999 kΩ", not "5.999 Ω".
• 0x5A trigger removed — the vendor's CP2110 init (FUN_1001d460, 24031-24085) performs no UART write; the 0x5A belongs to the CH9325 init path (FUN_1001d360) for other meters. Does the UT8803 stream unprompted? Is a stray 0x5A harmful?

Still open

• Display-byte format/charset (padding char, sign, decimal point)
• Range-byte value per mode (needed to fully trust the prefix table)
• Flag polarities on a real meter (AUTO inversion, Over vs OL, Error/SEL/Diode bits)

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