diff --git a/docs/micromate_protocol_reference.md b/docs/micromate_protocol_reference.md
index fa9e91d..5901d1f 100644
--- a/docs/micromate_protocol_reference.md
+++ b/docs/micromate_protocol_reference.md
@@ -1669,14 +1669,62 @@ FULL    at T + 30.4      (+5.1)
 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.
+> ⚠ **A "half the status period" hypothesis was raised here and REFUTED.**  It
+> predicted that with status at 60 s the connection check would run at 30 s.
+> Measured: **60.5 s**.  Recorded rather than deleted — the prediction was sharp
+> and it was wrong.
 
-⚠ **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.
+### The connection dial sets a COUNT, not a period
+
+Three configurations, each measured over many cycles:
+
+| status | connection | status observed | connection observed | separate conn checks per status cycle |
+|---|---|---|---|---|
+| 10 s | 10 s | 10.1 s ✅ | — | **0** (none ever ran) |
+| 30 s | 10 s | 30.4 s ✅ | 15.2 s ❌ | **2** |
+| 60 s | 30 s | 60.5 s ✅ | 60.5 s ❌ | **1** |
+
+**The status dial is honoured in all three** — within about 1%.
+
+**The connection dial is not honoured in any of them.**  What actually holds is:
+
+```
+separate connection checks per status cycle  =  (status ÷ connection) − 1
+```
+
+1 → 0 checks, 3 → 2 checks, 2 → 1 check.  So the field does not set a period; it
+sets how many checks fit inside a status cycle, and it is off by one.
+
+Consequences worth naming:
+
+- **Setting the two dials equal yields zero connection checks.**  Every
+  connection is then the expensive eleven-command status check.  That is the
+  default-looking configuration, and it is the worst one.
+- **"Every 30 s" with status at 60 s gives one check per minute** — half the
+  advertised rate.
+- The observed cadences are not multiples of the connection setting at all
+  (10 s → 15.2 s; 30 s → 60.5 s), so no simple scale factor describes it either.
+
+⚠ The *timing within* a cycle is still not fully explained.  At status 30 /
+connection 10 the two short checks landed at T+10.1 and T+25.3, where an evenly
+divided cycle would put them at T+10 and T+20.  The count rule holds across all
+three configurations; the phase does not follow from it.
+
+**For SFM:** this is the concrete argument against exposing a dial whose
+behaviour is not what it says.  If a control sets an interval, it should set that
+interval — and if the effective rate is derived from something else, the UI
+should show the derived value, not the input.
+
+### Traffic at each configuration
+
+| status / connection | per minute | per day | per month |
+|---|---|---|---|
+| 10 s / 10 s | ~13 KB | **18.8 MB** | **563 MB** |
+| 60 s / 30 s (current) | ~3.4 KB | **4.9 MB** | **147 MB** |
+| a minimal check at 60 s | ~0.2 KB | **0.3 MB** | **9 MB** |
+
+The last row is `POLL` + `MONITOR_STATUS` only — enough to answer "alive?" and
+"monitoring?".
 
 ### ⚠ What this means for the "won't stay connected" failure