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 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Ru8Lg9HkkYvX9VWWo65SmL
This commit is contained in:
2026-09-25 13:47:42 -04:00
co-authored by Claude Opus 5
parent 8b6c89da42
commit 992b84df51
+52
View File
@@ -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: