Correcting an implication I made. The 72 ach_inbound_* sessions in
bridges/captures/ are MiniMate Plus, and I framed the Series III ACH setup as
though it transfers to a Micromate. It is not known to.
What we actually have for Series IV is prior, not observation:
- THOR manual 6.2 and the firmware's own strings
(CMD_EXIT_CALL_HOME_DELETE_EVENTS_START_MONITORING, "Call Home Deleting
Events") say the unit dials in and waits to be told what to do -- server-driven,
the same shape as Series III's pull model.
- UM12947's 0x2C dial string reads literally "RADIO RING", which is modem ANSWER
vocabulary rather than a destination. With the RV50 debug string
ATQ1 ATE0 ATS0=2 ... RADIO RING -- ATS0=2 being auto-answer-after-2-rings --
that reads as the unit arranging to ACCEPT calls, i.e. the call-UP path. Which
argues the ACH destination lives in the modem, as it does for series III.
If both priors hold, mm_ach_server.py is just MicromateClient on an inbound
socket and the unknown evaporates. But there is a specific failure mode worth
naming in advance:
THE MICROMATE DEMONSTRABLY TALKS AT TO ITS MODEM. If it drives an AT dial for
call-home, that exchange happens on the SERIAL LINK and a TCP listener sees none
of it. So the first experiment has an AMBIGUOUS NULL -- no connection could mean
the trigger did not fire, or that the interesting part is invisible from the
network. The escalation is a serial-level capture between unit and modem, not
more fiddling with the server.
Recorded in both the protocol reference and the server's own docstring, so
whoever runs the experiment reads the caveat before being puzzled by a silence.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Ru8Lg9HkkYvX9VWWo65SmL
serversdownandClaude Opus 5
bdf4909d2a