Help wanted: UT8802 protocol verification (real hardware needed)

[antoinecellerier]

Summary

The UT8802/UT8802N protocol has been implemented based on reverse engineering (vendor software decompilation, programming manual) but has never been tested against real hardware. Every aspect needs end-to-end verification.

What we need

Someone with a UT8802 or UT8802N multimeter and the CP2110 USB adapter.

What needs verification

• Frame extraction (8-byte frames, 0xAC header, no checksum)
• 0x5A streaming trigger byte — does the meter start streaming after this is sent?
• Position code mapping (35 codes, 0x01–0x2D with gaps) — do mode/range labels match the meter's LCD?
• BCD display encoding (5 nibbles from bytes 2–4) — are parsed values correct?
• Decimal point position (byte 5 low nibble, 0–4)
• AC/DC coupling flags (byte 5 bits 4–5)
• Sign/polarity (byte 7 bit 7) — does negation work correctly?
• AUTO flag inverted logic (byte 7 bit 2 clear = auto ON)
• Byte 7 flag bits: HOLD/REL/MAX/MIN — current bit assignments (6/5/4/3) are best-guess from Ghidra
• Byte 6 purpose — bargraph? secondary status? currently unused
• Overload detection (BCD nibble 0x0C)
• Streaming rate

Verification steps

1. Run the capture wizard

cargo run --bin dmm-cli -- --device ut8802 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 ut8802 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 ut8802 read --count 10

Compare each displayed value against the meter's LCD.

What to report

• Meter model (UT8802 or UT8802N)
• 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

Protocol reference

See docs/research/uci-bench-family/reverse-engineered-protocol.md for the full wire protocol specification.

[antoinecellerier]

Protocol-correctness review update (2026-06)

A clean-room re-audit of the UT8802 parser against the uci.dll decompile (FUN_1001e0a0 and its lookup helpers) found and fixed three mismatches — all derived from the vendor binary, so they still need a real meter to confirm. Sign and flag bits are unchanged.

Fixed (corrected from vendor, hardware confirmation pending)

• Display digit order — was decoded reversed. Vendor order is MSD = byte 4 low nibble, then byte 3 hi/lo, byte 2 hi/lo (uci_dll_decompiled.txt:24714-24719). Any reading with distinct digits (e.g. ~12.34 V) confirms this in one shot.
• Overload source — vendor's only OL mechanism is byte 7 bit 6 (sentinel + literal " 0L ", lines 24806-24821); we previously keyed on a digit nibble. Does a real OL set bit 6, send 0x0C digit nibbles, both, or neither?
• AC/DC determination — comes from a position-code lookup (FUN_1001ca30, table at 23411), not byte 5 bits 4-5, which are the diode/SCR probe-direction indicator. What do byte 5 bits 4-5 carry outside diode/SCR modes?

Still open from the original list

• 0x5A trigger byte — the vendor DLL sends 0x5A only on the QinHeng/CH9325 init path, never to CP2110 devices, so we no longer send it. Does the UT8802 stream unprompted, and is a stray 0x5A harmful?
• Byte 6 purpose (bargraph?), byte 4 high nibble (always 0?), and the byte-7 flag bits (MIN/MAX/REL/HOLD/AUTO) — one button-press session settles these.

Capture with cargo run --bin dmm-cli -- --device ut8802 capture (and RUST_LOG=dmm_lib=trace … debug for raw bytes).