serversdown/seismo-relay
1
0
Fork 0
Code Issues 6 Pull Requests Actions Packages Projects Releases 1 Wiki Activity

docs(series4): purchasing history corroborates the cable finding

Browse Source 
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 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Ru8Lg9HkkYvX9VWWo65SmL
This commit is contained in:
serversdown
2026-09-25 20:54:56 -04:00
co-authored by Claude Opus 5
parent 8a0134070b
commit 062d65ba69
1 changed files with 33 additions and 2 deletions
Download Patch File Download Diff File Expand all files Collapse all files
docs/micromate_protocol_reference.md
+33 -2
View File
@@ -2097,8 +2097,39 @@ without a matching string, and the USB enumeration path has not been
disassembled. disassembled.
**The test that would remove the inference: try an FTDI cable on the same modem.** **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 Either it works or it does not, and nothing is left to argue about.
this is well-supported, not proven.
✅ **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 ### How this was isolated — the method is reusable