From 8a0134070b3448fd2962acf97f13d2efe15579b2 Mon Sep 17 00:00:00 2001 From: serversdown Date: Fri, 25 Sep 2026 20:35:13 -0400 Subject: [PATCH] docs(series4): soften the cable finding -- well-supported, not proven The operator pushed back on calling this solved, correctly. Adjusting the wording to match what the evidence actually carries. What IS supported: on this bench setup, the modem and cable work bidirectionally (laptop round trip, 700 ms), the same cable/modem pairing answers for a laptop and not for the Micromate, and neither firmware image contains a Prolific driver. Observation plus mechanism. What is NOT: that this explains the field failures. Those cables cannot be inspected, and the timeline does not fit -- a wrong cable fails from the first packet, and that unit reportedly worked before degrading. A gap in the bench claim itself, now stated: "no driver" is inferred from ABSENCE of strings. usbHostDelete_* reads like a complete per-class list, which is good evidence, but driver code can exist without a matching string and the USB enumeration path has not been disassembled. Names the test that removes the inference entirely: try an FTDI cable (VID 0403) on the same modem. Either it works or it does not. Co-Authored-By: Claude Opus 5 Claude-Session: https://claude.ai/code/session_01Ru8Lg9HkkYvX9VWWo65SmL --- docs/micromate_protocol_reference.md | 16 +++++++++++++--- 1 file changed, 13 insertions(+), 3 deletions(-) diff --git a/docs/micromate_protocol_reference.md b/docs/micromate_protocol_reference.md index c124e4a..c3154be 100644 --- a/docs/micromate_protocol_reference.md +++ b/docs/micromate_protocol_reference.md @@ -2086,10 +2086,20 @@ usbHostDelete_HUB / HC / USBH strings in each, and **zero** matches for `prolific`, `pl2303`, `cp210`, `ch34` or `silabs` in either. The firmware line makes no difference here. -⚠ **So a Prolific PL2303 cable (VID `067b`) cannot work with a Micromate.** The -unit has no driver, never enumerates the device, and the serial path simply does +⚠ **So a Prolific PL2303 cable (VID `067b`) very probably cannot work with a +Micromate** — no driver, so the device never enumerates and the serial path does not exist. Use an **FTDI** cable (VID `0403`) or a CDC-ACM one. +**Calibration.** This rests on *absence of strings*, plus the observation that a +laptop answers on the same cable where the unit does not. `usbHostDelete_*` reads +like a complete per-class list, which is good evidence — but driver code can exist +without a matching string, and the USB enumeration path has not been +disassembled. + +**The test that would remove the inference: try an FTDI cable on the same modem.** +Either it works or it does not, and nothing is left to argue about. Until then +this is well-supported, not proven. + ### How this was isolated — the method is reusable A Micromate on an RX55 was unreachable from THOR. Rather than guess, each layer @@ -2116,7 +2126,7 @@ device with something known-good and re-run the same test.** It converts "the unit is not answering" into "the unit is not receiving", which are very different problems. -⚠ This explains the **bench** setup conclusively. Whether it explains the +⚠ This is the best explanation for the **bench** setup. Whether it explains the 2026-09-22 field outage is **not** established — that unit reportedly worked at first and degraded, which a wrong cable would not do. Treat them as separate until the field unit's cable is identified.