dorkmo · Oct 25, 2026 · Oct 25, 2026 · Oct 25, 2026
diff --git a/LifeTrac-v25/DESIGN-CONTROLLER/TODO.md b/LifeTrac-v25/DESIGN-CONTROLLER/TODO.md
@@ -2697,7 +2697,7 @@ conflicts. Every leg needs GO; radios stay parked between legs.
   setting a `host_parked` flag that gates every arm path, puts the modem
   to SLEEP, cleared by a host RXCONT write (`sx1276_rx_note_external_arm`)
   or reset; host-check pinned; flashed and verified at a GO. Until then
-  PARK_OK means "asleep now and nothing re-armed it", not "cannot wake". **Open, 2026-10-24 (FHSS leg 2b_f3, [RESULTS](bench-evidence/bench_session_2026-10-24/RESULTS.md), Anomalies): the base never LOCKED during a leg (counters); leading hypothesis (H1, unverified): its cold-start scan ran out into the same absorbing FAILED and the follower then never hopped.** Observed: its first frame came 138.0 s after its profile activation, past the 4 x 30 s scan budget (1 of 27 archived profile-1 legs past 120 s). The base heard 5 of the tractor's 606 frames, on channels consistent with a receiver parked on the walker's last channel and then on each PROBE's TX channel (44, 6, 6, 18, 18); by the firmware a follower in FAILED never hops (the slot follower needs LOCKED + an adopted grid, or originator authority). Base Δ`clk_demotion_reset` 0 and Δ`fhss_dec_aligned` 0 (never LOCKED); post `radio_state` 4 on both boards (2 on the other five legs); the tractor sent all 606 normally. The base's 0x0D faults are not logged (`image_rx_daemon.py` drops FAULT URCs), so the FAILED entry is inferred. SIL, 2026-10-24 (no radio): `check-rx-scan-failed-follower` (`firmware/murata_l072/bench/host_proto/rx_scan_failed_follower.c`, the real `sx1276_rx.c` / `sx1276_tx.c`, in `make check`) reproduces the mechanism under H1's premise (no frame for the 120 s budget) and pins it as a known defect: four 0x0D (sub 20 21 22 A3), FAILED, STANDBY on ch 9; then frames are adopted but never LOCK or hop, each later catch is on the previous PROBE's channel, never ALIGNED, ends in RX_CONT. That is a model, not a hardware observation: the base's faults are still unlogged. It also pins a tractor twin (RS-12.15): an originator in FAILED that adopts a command heard in a camera stall loses authority and self-follow for good. Walker model over the 27 legs: about 7-8 % per 2 fps one-fragment leg (4-10 % by leg), 21-31 % at 1 fps, under 1 % at 2.4+ TX/s; the base tick at 610-1400 ppm slow moves it by under 2 points; a six-leg 2 fps round loses a leg 34-40 % of the time (model output; the archive has 1 of 8 such legs). Options (a)-(d) with their SIL results, the 0x0D code collision and the HSI16 clock item: [FHSS_SCAN_FAILED_OPTIONS.md](firmware/murata_l072/FHSS_SCAN_FAILED_OPTIONS.md). Recommendation for the design owner: (b) + the loss-timer fix + a 2 s dwell, flashed with this row's park command (which (b) needs) and a new code for TX_FIFO_RB_MISMATCH; the fix and the dwell also change the tractor's RS-12.15 decay window (memo section 5). Next, no radio: log the base's FAULT URCs (0x0D decoded), the acquisition check in the leg report, a pass-rule clause for a leg whose base never locks. Radio only on a new GO (first: a forced-FAILED leg on main). **Built 2026-10-25; flashed on both boards and verified on the bench 2026-10-25** (the design owner's decision of 2026-10-24, [DECISIONS.md](DECISIONS.md) D-FHSS1: memo section 5 item 2, with the decay-window trade-off of item 3 accepted; branch `fhss-scan-recovery-2026-10-24`): scan option (b) + L + d2; this row's firmware park command, `HOST_TYPE_RADIO_PARK_REQ` 0x04 answered by `RADIO_PARK_URC` 0x84 {status 0 PARKED / 1 already / 2 refused, RegOpMode} (a `host_parked` flag gates every RX arm path and SLEEPs the modem; a host raw RXCONT, a profile activation or a reset ends it; a TX_FRAME_REQ while parked gets ERR_PROTO; VER/READY capability bit 7); and the 0x0D split (TX_FIFO_RB_MISMATCH on 0x0F, a compile-time duplicate check of the fault codes). `HOST_PROTOCOL_VER` / `HOST_WIRE_SCHEMA_VER` unchanged: additive changes (host_types.h). Pinned by `check-radio-park`, `check-rx-scan-failed-follower` and `check-rx-reverse-delivery`; host side `radio_park.py` (the firmware path by the VER bit, a 2.5 s settle) and `rs12_leg_report.py` / `rs13_probe_score.py` (`--scan-image`: on this image a final 0x0D is a 30 s report). Bench `0daae27978089eb97ab35c18718b62b0`, production `2c5e055abff95126309a62409fafc654`, 25 324 B each (the same from a clean copy of the tree and after `mingw32-make clean`). **Flashed and verified 2026-10-25** on the operator's GO by memo section 6.1 ([RESULTS](bench-evidence/bench_session_2026-10-25/RESULTS.md)): tractor then base with `flash_l072.sh`, `Verify OK` and `flash_rc=0` on both; `radio_park.py` `PARK_OK` with `cap_bitmap` 0x000000FF, `path` firmware, PARKED on both, still 0x80 at the check-only 2 min 52 s later. R1 (2c_r1, a 300 s cold-start leg): base `cap=0x000000FF`, ACQUIRED 11.0 s after its profile-1 activation (599 of 609 fragments), no 0x0D or 0x0F line on either board during the leg, Δ`tx_fifo_rb_bad` 0, PROBE 204/204; the leg-end firmware park still read 0x80 2 min 11-16 s later with profile 1 active, so the park gate holds (a post-bracket probe caught the tractor's scan sending a final 0x0D 5 s before that park). R2 (2c_r2, the leg-X shape, 480 s): tractor 0x0D `name=RX_SCAN_FAILED` sub 0x00/0x01/0x02/0x83 at L072 uptime 33.6/63.6/93.6/123.7 s, `-InjectOn fault:0x0D:final` fired on the 0x83 line only, 93/95 base commands heard in scan FAILED; parks held (0x80 at 15:02:35Z / 15:02:55Z). Both boards now run bench `0daae279`; the flown `e083ae46` copy is the rollback image. The leg-6 defect (a follower stranded in an absorbing FAILED) is fixed in the firmware; the cold-start rate on air is still to measure: T2 (about 10 cold starts), T1 (forced FAILED; needs a harness option to delay the tractor's stream, not built) and T4 with camera stalls, each on its GO.
+  PARK_OK means "asleep now and nothing re-armed it", not "cannot wake". **Open, 2026-10-24 (FHSS leg 2b_f3, [RESULTS](bench-evidence/bench_session_2026-10-24/RESULTS.md), Anomalies): the base never LOCKED during a leg (counters); leading hypothesis (H1, unverified): its cold-start scan ran out into the same absorbing FAILED and the follower then never hopped.** Observed: its first frame came 138.0 s after its profile activation, past the 4 x 30 s scan budget (1 of 27 archived profile-1 legs past 120 s). The base heard 5 of the tractor's 606 frames, on channels consistent with a receiver parked on the walker's last channel and then on each PROBE's TX channel (44, 6, 6, 18, 18); by the firmware a follower in FAILED never hops (the slot follower needs LOCKED + an adopted grid, or originator authority). Base Δ`clk_demotion_reset` 0 and Δ`fhss_dec_aligned` 0 (never LOCKED); post `radio_state` 4 on both boards (2 on the other five legs); the tractor sent all 606 normally. The base's 0x0D faults are not logged (`image_rx_daemon.py` drops FAULT URCs), so the FAILED entry is inferred. SIL, 2026-10-24 (no radio): `check-rx-scan-failed-follower` (`firmware/murata_l072/bench/host_proto/rx_scan_failed_follower.c`, the real `sx1276_rx.c` / `sx1276_tx.c`, in `make check`) reproduces the mechanism under H1's premise (no frame for the 120 s budget) and pins it as a known defect: four 0x0D (sub 20 21 22 A3), FAILED, STANDBY on ch 9; then frames are adopted but never LOCK or hop, each later catch is on the previous PROBE's channel, never ALIGNED, ends in RX_CONT. That is a model, not a hardware observation: the base's faults are still unlogged. It also pins a tractor twin (RS-12.15): an originator in FAILED that adopts a command heard in a camera stall loses authority and self-follow for good. Walker model over the 27 legs: about 7-8 % per 2 fps one-fragment leg (4-10 % by leg), 21-31 % at 1 fps, under 1 % at 2.4+ TX/s; the base tick at 610-1400 ppm slow moves it by under 2 points; a six-leg 2 fps round loses a leg 34-40 % of the time (model output; the archive has 1 of 8 such legs). Options (a)-(d) with their SIL results, the 0x0D code collision and the HSI16 clock item: [FHSS_SCAN_FAILED_OPTIONS.md](firmware/murata_l072/FHSS_SCAN_FAILED_OPTIONS.md). Recommendation for the design owner: (b) + the loss-timer fix + a 2 s dwell, flashed with this row's park command (which (b) needs) and a new code for TX_FIFO_RB_MISMATCH; the fix and the dwell also change the tractor's RS-12.15 decay window (memo section 5). Next, no radio: log the base's FAULT URCs (0x0D decoded), the acquisition check in the leg report, a pass-rule clause for a leg whose base never locks. Radio only on a new GO (first: a forced-FAILED leg on main). **Built 2026-10-25; flashed on both boards and verified on the bench 2026-10-25** (the design owner's decision of 2026-10-24, [DECISIONS.md](DECISIONS.md) D-FHSS1: memo section 5 item 2, with the decay-window trade-off of item 3 accepted; branch `fhss-scan-recovery-2026-10-24`): scan option (b) + L + d2; this row's firmware park command, `HOST_TYPE_RADIO_PARK_REQ` 0x04 answered by `RADIO_PARK_URC` 0x84 {status 0 PARKED / 1 already / 2 refused, RegOpMode} (a `host_parked` flag gates every RX arm path and SLEEPs the modem; a host raw RXCONT, a profile activation or a reset ends it; a TX_FRAME_REQ while parked gets ERR_PROTO; VER/READY capability bit 7); and the 0x0D split (TX_FIFO_RB_MISMATCH on 0x0F, a compile-time duplicate check of the fault codes). `HOST_PROTOCOL_VER` / `HOST_WIRE_SCHEMA_VER` unchanged: additive changes (host_types.h). Pinned by `check-radio-park`, `check-rx-scan-failed-follower` and `check-rx-reverse-delivery`; host side `radio_park.py` (the firmware path by the VER bit, a 2.5 s settle) and `rs12_leg_report.py` / `rs13_probe_score.py` (`--scan-image`: on this image a final 0x0D is a 30 s report). Bench `0daae27978089eb97ab35c18718b62b0`, production `2c5e055abff95126309a62409fafc654`, 25 324 B each (the same from a clean copy of the tree and after `mingw32-make clean`). **Flashed and verified 2026-10-25** on the operator's GO by memo section 6.1 ([RESULTS](bench-evidence/bench_session_2026-10-25/RESULTS.md)): tractor then base with `flash_l072.sh`, `Verify OK` and `flash_rc=0` on both; `radio_park.py` `PARK_OK` with `cap_bitmap` 0x000000FF, `path` firmware, PARKED on both, still 0x80 at the check-only 2 min 52 s later. R1 (2c_r1, a 300 s cold-start leg): base `cap=0x000000FF`, ACQUIRED 11.0 s after its profile-1 activation (599 of 609 fragments), no 0x0D or 0x0F line on either board during the leg, Δ`tx_fifo_rb_bad` 0, PROBE 204/204; the leg-end firmware park still read 0x80 2 min 11-16 s later with profile 1 active, so the park gate holds (a post-bracket probe caught the tractor's scan sending a final 0x0D 5 s before that park). R2 (2c_r2, the leg-X shape, 480 s): tractor 0x0D `name=RX_SCAN_FAILED` sub 0x00/0x01/0x02/0x83 at L072 uptime 33.6/63.6/93.6/123.7 s, `-InjectOn fault:0x0D:final` fired on the 0x83 line only, 93/95 base commands heard in scan FAILED; parks held (0x80 at 15:02:35Z / 15:02:55Z). Both boards now run bench `0daae279`; the flown `e083ae46` copy is the rollback image. The leg-6 defect (a follower stranded in an absorbing FAILED) is fixed in the firmware; T2 (ten 180 s cold-start legs) flew 2026-10-25 and passed ([RESULTS](bench-evidence/bench_session_2026-10-25_t2/RESULTS.md)): 10 of 10 starts ACQUIRED, first frame 11.0-62.4 s after activation (median 11.1 s), none past 120 s, every leg-end park `PARK_OK` on the firmware path, 0x80 on both at the end. The harness starts both boards the same way every leg, so T2 sampled a few start phases: the random-phase cold-start rate on air is still to measure (it needs a random delay between the tractor reset and the base's activation, not built). T1 (forced FAILED; needs a harness option to delay the tractor's stream, not built) and T4 with camera stalls are still to fly, each on its GO.
 
 - [x] **RS-12.11 — base command scheduler vs fragment arrivals: DONE 2026-09-12
   (PR #118, gate passed, see above).**