Help wanted: UT171 protocol verification (real hardware needed)

[antoinecellerier]

Summary

The UT171A/B/C protocol has been implemented based on reverse engineering but has never been tested against real hardware. Every aspect needs end-to-end verification.

What we need

Someone with a UT171A, UT171B, or UT171C multimeter and the CP2110 USB adapter.

What needs verification

• Frame extraction (1-byte length field, little-endian checksum)
• Connect command (AB CD 04 00 0A 01 0F 00) — is it needed before streaming starts?
• Mode byte mapping (26 modes, 0x01–0x24) — do mode labels match the LCD?
• Float32 little-endian value parsing — are values correct?
• Flags byte: HOLD (bit 7), AUTO (bit 6, inverted), Low Battery (bit 2)
• Range byte (raw, 1-based)
• Extended frame (28 bytes, frame type 0x03) — currently not parsed
• Status2 byte (offset 13) — meaning unknown
• Aux value interpretation

Verification steps

1. Enable USB communication on the meter

On UT171 series, go to the meter's SETUP menu and enable Communication ON.

2. Run the capture wizard

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

Follow the prompts, confirm what the LCD shows vs. what the tool parsed.

3. Raw byte dump

If the capture wizard doesn't work (no response), try:

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

4. Basic reading

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

Compare each value against the meter's LCD.

What to report

• Meter model (UT171A/B/C) and firmware version if known
• OS and version
• Result of each step
• The capture YAML file if the wizard produced one
• Raw debug output if things didn't work
• LCD screenshots alongside tool output are very helpful

[antoinecellerier]

Protocol-correctness review update (2026-06) — framing was wrong

The review found the UT171 frame extractor used a framing model that cannot validate any real frame, so a real UT171 would never have produced a reading. Now fixed; needs hardware to confirm end-to-end. (UT171 has had zero hardware verification — the 2026-04 hardware work was UT181A.)

Fixed (corrected, hardware confirmation pending)

• Framing — it is byte-identical to UT181A: 2-byte LE length = payload + checksum, total = length + 4, LE16 sum over [2..len+2). The old 1-byte-length model (total = length + 5) was decisive against: the known connect command AB CD 04 00 0A 01 0F 00 only checks out under the corrected model (len 4, sum 04+00+0A+01 = 0x000F LE). Cross-confirmed by gulux/Uni-T-CP2110's capture-driven UT171A.py (lendat >= 21/== 27). Capturing one real measurement frame closes this.
• Resistance scaling — the float is range-relative; unit is now kΩ on range bytes ≥ 2 and MΩ on ≥ 5 (gulux's hardware-derived d[8] >= 2 / >= 5 ×1000 scaling).
• Aux value — labeled as a frequency in kHz on V AC / mV AC (gulux modes 0x3/0x6); other modes' aux semantics unknown.

Retracted

• The spec's frame-validation citations (FUN_0065478e etc.) were Delphi Midas/ClientDataSet packet code (magic 0xBDE01996, SafeArrayAccessData, ROWDATA/DATAPACKET strings), not the wire protocol. Header validation and the flag bits 0/1/3, plus the status2 byte (offset 13), are downgraded to capture-deduced — all need hardware.

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