serversdown/seismo-relay
1
0
Fork 0
Code Issues 6 Pull Requests Actions Packages Projects Releases 1 Wiki Activity

docs(series4): a live monitoring unit displayed as Idle -- and a flag I got wrong

Browse Source 
The operator's test: start monitoring from the unit's keypad and see whether THOR
notices.  It does not.

At 13:21:15, verified by an independent probe through the same relay:

    unit on the wire    0x49 data[11]=0x02, 0x1C data[12]=0x0c  -> MONITORING
    THOR last contact   13:10:37 (a stop-monitoring command it issued itself)
    THOR display        Connected . Monitoring Mode: Idle . Last Updated 1:04:22

A unit is actively recording and THOR shows it as Idle.  Had an event triggered
in that window THOR would not have known and would not have collected it.  That
is the operational consequence of the wedge -- not a wrong indicator, but a
monitoring system that has silently stopped monitoring its monitor.

Further detail: THOR DID contact the unit at 13:10:37 and read MONITOR_STATUS,
yet Last Updated still reads 1:04:22.  A successful exchange does not refresh
that timestamp; only the full status check does.  The one honest field on the
screen is honest about the wrong thing, which makes it useless as a staleness
indicator exactly when staleness is the problem.

CORRECTS a documented constant.  SUB 0x1C data[12] was recorded as "0x0E
monitoring / 0x00 idle".  It read 0x0E on 2026-09-24 and 0x0C on 2026-09-25, both
while monitoring, so it carries sub-state in its low bits and is not a flag.  Test
for NON-ZERO, never against a constant -- an implementation comparing to 0x0E
would have reported this unit idle.  Same caution noted for 0x49 data[11], which
has only ever been seen as 0x02.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Ru8Lg9HkkYvX9VWWo65SmL
This commit is contained in:
serversdown
2026-09-25 13:21:49 -04:00
co-authored by Claude Opus 5
parent d93ebe2322
commit 8b6c89da42
1 changed files with 33 additions and 3 deletions
Download Patch File Download Diff File Expand all files Collapse all files
docs/micromate_protocol_reference.md
+33 -3
View File
@@ -1091,7 +1091,7 @@ zero-data response. Thor follows each with a `SUB 0x1C` status read to confirm.
### `SUB 0x1C` — monitor status, 55-byte data
```
data[12] monitoring flag 0x0E monitoring / 0x00 idle
data[12] monitoring flag NON-ZERO = monitoring, 0x00 = idle
data[13] day
data[14] month
data[15:17] year, uint16 BE
@@ -1103,8 +1103,11 @@ data[-8:-4] memory total, uint32 BE = 15,000,000 bytes exactly
data[-4:] memory free, uint32 BE
```
⚠ **The monitoring flag is `0x0E`, not Series III's `0x10`.** Do not reuse the
Series III constant. Only five bytes differ between the monitoring and idle
⚠ **Test `data[12]` for non-zero — do NOT compare against a constant.** It read
`0x0E` on 2026-09-24 and `0x0C` on 2026-09-25, both while monitoring, so it
carries sub-state in its low bits rather than being a flag. Series III's `0x10`
does not apply either. `SUB 0x49` `data[11]` read `0x02` in every monitoring
sample so far, but the same caution applies until more values are seen. Only five bytes differ between the monitoring and idle
responses: the flag, `data[17]`, the clock, and the memory-free field.
Memory free dropped by exactly **4,096 bytes** across the ~70-second monitoring
@@ -1877,6 +1880,33 @@ It explains, too, why the field symptom resisted characterisation. The unit is
perfectly reachable throughout. Poke it and it answers. Nothing is wrong with
the unit, the modem, or the link.
### The stale display extends to monitoring state — a live unit shown as Idle
The operator's own test: start monitoring **from the unit's keypad**, and see
whether THOR ever notices.
At **13:21:15**, verified by an independent probe through the same relay:
```
unit, on the wire SUB 0x49 data[11] = 0x02 MONITORING
SUB 0x1C data[12] = 0x0c MONITORING
device clock 13:21:14
THOR's last contact 13:10:37 (a stop-monitoring command it issued itself)
THOR's display Connected · Monitoring Mode: Idle · Last Updated 1:04:22 PM
```
**A unit is actively recording and THOR shows it as Idle.** Had an event
triggered in that window, THOR would not have known and would not have collected
it. This is the operational consequence of the wedge: not merely a wrong
indicator, but a monitoring system that has silently stopped monitoring its
monitor.
One further detail. THOR **did** contact the unit at 13:10:37 and read
`MONITOR_STATUS` — yet `Last Updated` still reads 1:04:22. So a successful
exchange does not refresh that timestamp; only the full status check does. The
single honest field on the screen is honest about the wrong thing, which makes it
useless as a staleness indicator precisely when staleness is the problem.
### Design consequences for SFM
0. **Connection status must EXPIRE.** The single highest-value fix here. If the