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 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Ru8Lg9HkkYvX9VWWo65SmL

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`,
+The eleven-command sequence is the **status check**.  There is also a much
-`11:32:08.9`, `11:32:19.0`, `11:32:29.1`, `11:32:39.2`, `11:32:49.3`,
+cheaper **connection check** — three commands:
-`11:32:59.4` — a **10.1 s** period, steady.
 
-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
+connection check   POLL → SERIAL → 0x49
-seconds.  That is a plausible reason changing those fields appears to do nothing:
+status check       POLL → DEVICE_INFO → 0x49 → 0x5C → MONITOR_STATUS
-the relationship between the setting and the observed cadence is not what the UI
+                   → SETUP_NAME_READ → STORAGE_RANGE → 0x02 → OPERATOR
-implies.
+                   → 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