From 61e8a5e2209b73afcee2e4baee14619c35c56224 Mon Sep 17 00:00:00 2001 From: serversdown Date: Fri, 25 Sep 2026 11:46:11 -0400 Subject: [PATCH] docs(series4): two poll checks, and only the status dial is honoured Corrects the previous commit. It claimed both intervals were set to 5 s, taken from a screenshot that turned out to predate the operator's change -- they were at 10 s. The "setting + 5 s" pattern I inferred from that does not survive, and is removed. What a longer capture with asymmetric intervals (connection 10 s, status 30 s) actually shows: There are TWO distinct checks, not one. The eleven-command sequence is the status check; there is also a three-command connection check, POLL -> SERIAL -> 0x49. With both dials EQUAL the connection check never runs separately at all -- every connection observed was the full eleven commands. It only appears once the intervals differ. That alone explains much of "changing the settings does nothing": at equal values you only ever get the expensive one. Steady state over 14 consecutive cycles: FULL at T short at T+10.1 short at T+25.3 FULL at T+30.4 status check set 30 s -> observed 30.4 s honoured connection check set 10 s -> observed 15.2 s 52% slow 27 consecutive connection-check gaps, all 15.1-15.3 s. Systematic, not jitter. 15.2 s is exactly half of 30.4 s and the two are phase-locked 2:1, suggesting the connection check runs at half the STATUS period rather than on its own setting. Flagged as a hypothesis with a sharp prediction: at status 60 s the connection check should land at 30 s whatever its dial says. Worth settling before SFM offers a similar control -- a dial that silently does nothing is worse than no dial. Co-Authored-By: Claude Opus 5 Claude-Session: https://claude.ai/code/session_01Ru8Lg9HkkYvX9VWWo65SmL --- docs/micromate_protocol_reference.md | 50 +++++++++++++++++++++++----- 1 file changed, 41 insertions(+), 9 deletions(-) diff --git a/docs/micromate_protocol_reference.md b/docs/micromate_protocol_reference.md index fc9bdf0..fa9e91d 100644 --- a/docs/micromate_protocol_reference.md +++ b/docs/micromate_protocol_reference.md @@ -1634,17 +1634,49 @@ A genuine liveness + state check is **`POLL` + `MONITOR_STATUS`**: two commands, 131 bytes of response. Same information about whether the unit is alive and whether it is monitoring, for a ninth of the traffic. -### Both intervals at 5 s produces one check every ~10 s +### There are TWO checks, and only one of the dials is honoured -Connection timestamps over three minutes: `11:31:48.7`, `11:31:58.9`, -`11:32:08.9`, `11:32:19.0`, `11:32:29.1`, `11:32:39.2`, `11:32:49.3`, -`11:32:59.4` — a **10.1 s** period, steady. +The eleven-command sequence is the **status check**. There is also a much +cheaper **connection check** — three commands: -So *"Check connection every 5 s"* and *"Check status every 5 s"* do not describe -two independent 5-second timers; together they yield one combined pass every ten -seconds. That is a plausible reason changing those fields appears to do nothing: -the relationship between the setting and the observed cadence is not what the UI -implies. +``` +connection check POLL → SERIAL → 0x49 +status check POLL → DEVICE_INFO → 0x49 → 0x5C → MONITOR_STATUS + → SETUP_NAME_READ → STORAGE_RANGE → 0x02 → OPERATOR + → 0x47 → CALLHOME_CFG +``` + +⚠ **With both dials equal, the connection check never runs separately at all** — +every connection observed was the full eleven. It only appears once the two +intervals differ. That alone explains a lot of "changing the settings does +nothing": at equal values you only ever get the expensive one. + +With *connection check = 10 s* and *status check = 30 s*, the steady state over +14 consecutive cycles is: + +``` +FULL at T +short at T + 10.1 +short at T + 25.3 (+15.2) +FULL at T + 30.4 (+5.1) +``` + +| dial | set to | observed | | +|---|---|---|---| +| status check | 30 s | **30.4 s** | ✅ honoured | +| connection check | 10 s | **15.2 s** | ❌ 52% slow | + +27 consecutive connection-check gaps, all 15.1–15.3 s. That is systematic, not +jitter. + +**15.2 s is exactly half of 30.4 s**, and the two are phase-locked 2:1 — which +suggests the connection check is not running on its own setting at all, but at +half the *status* period. + +⚠ **Hypothesis, not established.** It predicts sharply: with status at 60 s the +connection check should land at 30 s **whatever its dial says**. One capture +settles it, and it is worth settling before SFM offers any similar control — a +dial that silently does nothing is worse than no dial. ### ⚠ What this means for the "won't stay connected" failure