From 992b84df51a769b4b980212a3051c47eab35a445 Mon Sep 17 00:00:00 2001 From: serversdown Date: Fri, 25 Sep 2026 13:47:42 -0400 Subject: [PATCH] docs(series4): modem settings live in SysParm.cfg, not the setup -- deliberately Settled by a clean experiment. The call-modem setting was changed on the keypad from 'generic' to 'USB to PC', then the ACTIVE SETUP was switched from TEST1 to test2 on the device. The setting did not change. So it is device-global, in the SysParm.cfg the firmware strings already hinted at alongside SysPref.bMonitorScheduler -- not a per-setup field. That closes a hypothesis this document was chasing: the ~102 bytes a .MMB file carries beyond the 2,090-byte config block are NOT where this lives. Those bytes remain unexplained but are no longer a candidate. CORRECTS an over-reading in an earlier commit. "The call-home block (0x2C) was byte-identical across 218 samples today" does not bear on this question: the last 0x2C sample was at 13:30:23 and the keypad change came around 13:35, so no sample exists on the far side of it. Why the split is right, and the operator's reading of it: you do not want modem settings reachable remotely, because getting them wrong over the air destroys the connection you would need to put them back, and the unit must then be visited. So SUB 0x2C is not an incomplete view of the modem configuration -- it is the deliberately-chosen subset that is SAFE to change remotely (enable, dial string, retries, timings), and the unreachable remainder is unreachable on purpose. Records the design principle for SFM: for settings whose misconfiguration destroys the channel you would use to fix them, either do not expose them for remote write, or require commit/confirm with automatic rollback (apply, require a call-back within N minutes, revert otherwise). Always allow READING them, so an operator can diagnose a unit they cannot reconfigure. Instantel chose the first option and given the failure mode that is worth copying rather than improving on. Co-Authored-By: Claude Opus 5 Claude-Session: https://claude.ai/code/session_01Ru8Lg9HkkYvX9VWWo65SmL --- docs/micromate_protocol_reference.md | 52 ++++++++++++++++++++++++++++ 1 file changed, 52 insertions(+) diff --git a/docs/micromate_protocol_reference.md b/docs/micromate_protocol_reference.md index e948a44..53e12b8 100644 --- a/docs/micromate_protocol_reference.md +++ b/docs/micromate_protocol_reference.md @@ -1677,6 +1677,58 @@ jitter. > Measured: **60.5 s**. Recorded rather than deleted — the prediction was sharp > and it was wrong. +### Modem settings live in `SysParm.cfg`, not in the setup — and that is deliberate + +**Settled by experiment (2026-09-25).** The unit's *call modem* setting was +changed on the keypad from `generic` to `USB to PC`. Then the **active setup was +switched from `TEST1` to `test2` on the device**, and the setting was checked +again: **unchanged.** + +So it does not travel with the setup. It is device-global, in the `SysParm.cfg` +the firmware strings already hinted at, alongside `SysPref.bMonitorScheduler`. + +That closes a hypothesis this document was pursuing: the ~102 bytes a `.MMB` +**file** carries beyond the 2,090-byte config block are **not** where this lives. +Those bytes remain unexplained, but they are no longer a candidate for it. + +⚠ It also means the earlier observation "the call-home block (`0x2C`) was +byte-identical across 218 samples today" **does not bear on this** — the last +`0x2C` sample was at 13:30:23 and the keypad change came around 13:35. No sample +exists on the far side of it. + +#### Why the split is the right design + +The operator's reading, and it is convincing: **you do not want modem settings +reachable remotely.** Get them wrong over the air and you lose the connection +you would need to put them back — the unit must then be visited physically. + +That explains the shape of the protocol rather than treating it as an oddity: + +| | reachable over the wire? | +|---|---| +| Call Home **enable**, dial string, retries, timings (`0x2C` / `0x7E`) | **yes** — recoverable if wrong | +| **Modem type** and the rest of `SysParm.cfg` | **no** — a wrong value is unrecoverable remotely | + +`SUB 0x2C` is not an incomplete view of the modem configuration. It is the +deliberately-chosen subset that is **safe to change remotely**, and the +unreachable remainder is unreachable on purpose. + +#### Design principle for SFM + +There is a class of setting whose misconfiguration **destroys the channel you +would use to fix it** — modem type, baud, serial parameters, the call-home +destination itself. For those: + +1. **Do not expose them for remote write**, or gate them behind an explicit + confirmation that names the risk. +2. If they must be writable, use a **commit/confirm with automatic rollback** — + apply, require the unit to call back within N minutes, revert if it does not. +3. **Always allow reading them**, so an operator can diagnose a unit they cannot + reconfigure. + +Instantel chose option 1. Given the failure mode, that is defensible, and worth +copying rather than improving on. + ### The connection dial sets a COUNT, not a period Three configurations, each measured over many cycles: