From 062d65ba6911b29e9f842413cf190ef29cbfc6f7 Mon Sep 17 00:00:00 2001 From: serversdown Date: Fri, 25 Sep 2026 20:54:56 -0400 Subject: [PATCH] docs(series4): purchasing history corroborates the cable finding TMI's order history shows TWO kinds of USB-to-serial cable in circulation: Sabrent USB 2.0 to serial FTDI chipset -> Micromate has a driver Benfei USB to RS-232 Prolific PL2303 -> no driver So both types are in the supply and indistinguishable by eye. A unit handed the wrong one has no working modem port and nothing about the cable says so. That moves the PL2303 explanation from "a theory about one odd cable" to a known mix. Adds the identification note: check chipset with lsusb, not appearance -- FTDI is VID 0403, Prolific 067b -- and flags that counterfeit FTDI chips are common in cheap cables, carrying FTDI's VID without behaving like one. An embedded host with a single driver is far less forgiving than Linux. Also records honestly that this does NOT fit the 2026-09-22 field outage as reported: a Prolific cable never enumerates, so it cannot fail gradually, and that unit was described as working before degrading. Notes the one story where it would fit -- if the initial success was over the USB PC port or a bench test before deployment, the modem path would have been broken from deployment onward and the recollection would be conflating two connection types. Plausible, unverified, recorded as such. Identifying that unit's cable settles it. Co-Authored-By: Claude Opus 5 Claude-Session: https://claude.ai/code/session_01Ru8Lg9HkkYvX9VWWo65SmL --- docs/micromate_protocol_reference.md | 35 ++++++++++++++++++++++++++-- 1 file changed, 33 insertions(+), 2 deletions(-) diff --git a/docs/micromate_protocol_reference.md b/docs/micromate_protocol_reference.md index c3154be..f2c5bb3 100644 --- a/docs/micromate_protocol_reference.md +++ b/docs/micromate_protocol_reference.md @@ -2097,8 +2097,39 @@ 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. +Either it works or it does not, and nothing is left to argue about. + +✅ **Corroborated by purchasing history (2026-09-25).** TMI has bought **two** +kinds of USB-to-serial cable: + +| cable | chipset | works with a Micromate? | +|---|---|---| +| **Sabrent** USB 2.0 to serial | **FTDI** | ✅ driver present | +| **Benfei** USB to RS-232 | **Prolific PL2303** | ❌ no driver | + +So both types are in circulation and indistinguishable by eye. A unit handed the +wrong one has no working modem port, and nothing about the cable's appearance +says so. + +⚠ **Identify cables by chipset, not by looks.** `lsusb` on any Linux box: +FTDI is VID `0403`, Prolific is `067b`. Note also that counterfeit FTDI chips +are common in cheap cables — they carry FTDI's VID but may not behave like one, +and an embedded host with a single driver is far less forgiving than Linux. + +### Does this explain the 2026-09-22 field outage? + +⚠ **Not on the timeline as reported.** A Prolific cable does not fail +*gradually* — it never enumerates, so the modem port never works at all. The +unit was described as working at first and degrading. + +There is one story where it fits: if the initial success was over a **different +path** — the USB **PC** port, or a bench test before deployment — that would work +regardless of which serial cable was attached. The modem path would then have +been broken from the moment it was deployed, and "it worked and then stopped" +would be a recollection conflating two connection types days after the fact. + +Plausible, unverified, and recorded as such. Identifying that unit's cable would +settle it. ### How this was isolated — the method is reusable