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
serversdownandClaude Opus 5
61e8a5e220