A Micromate on an RX55 was unreachable from THOR. Isolated layer by layer with
bridges/mm_probe.py, and the answer turned out to be the cable.
The USB-A port is a HOST port with a fixed driver set, identical in both firmware
lines:
CDCACM FTDI MFS (mass storage) PRINTER HUB HC USBH
11 FTDISER strings and 22 CDCACM strings in each image, and ZERO matches for
prolific / pl2303 / cp210 / ch34 / silabs in either. So a Prolific PL2303 cable
(VID 067b) cannot work with a Micromate on any firmware -- no driver, no
enumeration, no serial path. It needs an FTDI cable (VID 0403) or CDC-ACM.
The isolation method is the part worth keeping. Eliminated in turn: public IP
(static APN), firewall (probe got TCP connect in 268 ms from a whitelisted
source), network path, baud, the unit's modem-type setting, and THOR itself
(the probe bypasses it). Then the decisive pair -- a Linux box was swapped in
for the unit on the SAME cable and modem:
* POLL arrived at the serial side byte-perfect
* a canned reply came back over TCP, full round trip in 700 ms
So the modem, PAD config, firewall and network are all clean, and the only
element that changed is what sits at the end of the cable. Substituting a
known-good device converts "the unit is not answering" into "the unit is not
receiving" -- very different problems. Adds scratch/fake_unit.py for that.
Flagged: this explains the BENCH setup conclusively. It does NOT establish the
cause of the 2026-09-22 field outage, which reportedly worked at first and
degraded -- a wrong cable would not do that. Kept separate until that unit's
cable is identified.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Ru8Lg9HkkYvX9VWWo65SmL
