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
The inbound call-home session is the last unmapped part of the Series IV
protocol, and it may well not be a separate protocol at all. Series III's
answer, from the 72 ach_inbound_* sessions on disk, is that the unit DIALS IN AND
THEN WAITS: ach_server.py accepts the socket, wraps it in SocketTransport ->
MiniMateClient, runs the ordinary handshake and drives with the ordinary command
set. If Series IV behaves the same way, this file is just MicromateClient
attached to an inbound socket.
THE ONE QUESTION THAT MATTERS IS PUSH VS PULL, and no packet capture can answer
it -- you have to connect and keep quiet. So the server says NOTHING for --grace
seconds after accepting. Bytes in that window mean the unit speaks first, and it
reports the hex, the ASCII, and whether they parse as a response frame (series III
sends an "Operating System" banner on cold boot, so a banner is the likely shape).
Silence means pull, and the normal handshake follows.
READ-ONLY, and deliberately more so than its series III sibling: that one has
"rescue actions" that stop monitoring and disable ACH on a runaway unit, and
those are absent here. No command has ever been originated against a unit by
this project, and an inbound session is the worst place to break that. --depth
defaults to walking the event chain WITHOUT downloading.
Captures land as raw_bw_*/raw_s3_* so scratch/mm_frame_parse.py reads the pair
with no arguments, plus a session.json recording what was learned -- including
the push flag, which is the result worth keeping. The session directory is
created only after the handshake succeeds, so a port scanner leaves nothing on
disk.
Smoke-tested both paths against a fake unit that dials in: PULL detected over
silence and driven to a full chain walk (33 frames, 0 bad checksums, parses with
the existing tool), and PUSH detected from a 10-byte banner with the frame-parse
attempt reported honestly as "none parsed".
Worth recording for the setup: for series III the call-home DESTINATION lived in
the MODEM's config (ACEmanager), not in the seismograph. If that holds for the
RX55 then nothing on the instrument needs changing, which keeps the no-writes
line intact. If it has to come from the unit, its 0x2C block holds a 40-byte
dial string -- and writing that is THOR's job, not ours.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Ru8Lg9HkkYvX9VWWo65SmL
serversdownandClaude Opus 5