evidence(RS-3.3): camera legs at the RS-12 operating point — 3 legs PASS, first live-traffic NO_PARK_LAST exercise

[dorkmo]

Three 300 s camera legs at 927.5 MHz (same-day spot-check clean: 60 s, 0 hot, max -99 dBm). Full narrative in bench-evidence/RS_3_3_camera_first_flight_2026-08-22/RESULTS.md (directory name is a misnomer kept for reference stability -- see framing correction below).

Framing correction (review catch): these are NOT the camera path's first flight. RS-3.3 flew 2026-07-31 (radio_monitor_20260731_213152_9db14d4d) with 472 frames delivered and 2381-2430 B keyframes -- multi-fragment trains included. These legs are the first camera legs at the post-RS-12 operating point (927.5 + NoParkLast strict hold) and the first live-traffic command-plane exercise for NO_PARK_LAST. The unexercised combination remaining is multi-fragment camera trains UNDER the strict hold -- the motion leg.

Leg	Config	Loss	Notes
1	kf disabled	0/587 = 0.0%	campaign-first zero leg; tractor tx_ok 609 = base rx_ok 609; crc closure exact
2	kf enabled (untriggered)	2/613 = 0.3%	clean link never pokes the kf machinery; trains stay 1-frag
3	kf + injection: 11 requests landed in-leg (22 x2-copy receptions). Injector emitted 12 of 24 configured before teardown stopped it; 1 post-leg, 12 never sent	1/614 = 0.2%	all 11 in-leg requests received and dispatched by the tractor during live image traffic

Evidence limitations (on the record in the RESULTS files):

• No archive from this session independently records -NoParkLast 1 (params.txt had no field; the daemon never logged it) -- this applies to the camera legs AND the synth control leg. The strict-hold attribution is transcript-attested, with the 3%-vs-42% penultimate signature as behavioral evidence. Fixed forward in this PR: harness writes no_park_last=; TX daemon logs no_park_last=/gap_ms=/pipeline_depth= at startup.
• The leg-3 TRACTOR counter bracket is invalid as a delta (the L072 reset between snapshots); all leg-3 numbers use the base brackets. Legs 1-2 tractor brackets verified internally consistent.

Code changes:

• rx daemon publish line carries the completing fragment train seq (train_seq_of(); published frame_id= prefix preserved for tools/bulk_loss_boundary.py). Publication block extracted as _publish_completed(); regression tests drive the real paths (batched, single, keyframe-in-batch, all three layouts, passthrough, and an emitted-log prefix-contract test).
• _env_int fix for NO_PARK_LAST_GAP_S -- heals the env-contract CI gate red on main since the RS-12 opening session — the bulk floor is a silent L072 URC drop, not RF #108 merge.
• Desk-checked: frame_id=0 is universal (TileDeltaFrame has no frame_id) -- expected, marked RESOLVED.

Also in this PR: RS-11.8 first chantab-grid survey (ticker-dominated -- 49/50 hot at 1-7 hits, maxima mostly -44..-58 with outliers -30/-35/-38; no valid single-survey pick), the 4th standard survey (927.5 clean 4/4 -- the sole stable channel), a 600 s tractor-side dwell at 923.5 MHz (strong emitter at -30 dBm on the ~7 s device-A grid; device B not directly confirmed), and the PM-1 charger-exposure artifact (pm1_charger_sysfs.txt: bq24190/bq24195, online=1, status observed live-updating).

Merge order: this PR first (heals main CI), then #110, then #109.

🤖 Generated with Claude Code

[Copilot]

Pull request overview

Adds first-flight evidence for the RS-3.3 camera transport path and exposes fragment-train sequence IDs in receiver logs.

Changes:

• Documents three camera-radio bench legs with logs and counter brackets.
• Adds a keyframe-request injector.
• Logs the completing train sequence on frame publication.

Reviewed changes

Copilot reviewed 18 out of 24 changed files in this pull request and generated 2 comments.

Show a summary per file

File	Description
RS_3_3.../RESULTS.md	Summarizes test outcomes.
RS_3_3.../kf_inject.py	Injects keyframe requests.
RS_3_3.../rs33_pre_base.txt	Leg 1 base pre-counters.
RS_3_3.../rs33_post_base.txt	Leg 1 base post-counters.
RS_3_3.../rs33_pre_tractor.txt	Leg 1 tractor pre-counters.
RS_3_3.../rs33_post_tractor.txt	Leg 1 tractor post-counters.
RS_3_3.../rs33kf_pre_base.txt	Leg 2 base pre-counters.
RS_3_3.../rs33kf_post_base.txt	Leg 2 base post-counters.
RS_3_3.../rs33kf_pre_tractor.txt	Leg 2 tractor pre-counters.
RS_3_3.../rs33kf_post_tractor.txt	Leg 2 tractor post-counters.
RS_3_3.../rs33l3_pre_base.txt	Leg 3 base pre-counters.
RS_3_3.../rs33l3_post_base.txt	Leg 3 base post-counters.
RS_3_3.../rs33l3_pre_tractor.txt	Leg 3 tractor pre-counters.
RS_3_3.../rs33l3_post_tractor.txt	Leg 3 tractor post-counters.
radio_monitor_...173616.../params.txt	Records Leg 1 parameters.
radio_monitor_...173616.../tx_daemon.log	Captures Leg 1 transmission.
radio_monitor_...174805.../params.txt	Records Leg 2 parameters.
radio_monitor_...174805.../tx_daemon.log	Captures Leg 2 transmission.
radio_monitor_...175441.../params.txt	Records Leg 3 parameters.
base_station/image_rx_daemon.py	Adds train sequence to publish logs.

Suppressed comments (4)

LifeTrac-v25/DESIGN-CONTROLLER/bench-evidence/RS_3_3_camera_first_flight_2026-08-22/RESULTS.md:63

• Only 11 publishes occurred inside the archived leg: the first received pair is at tx_daemon.log:719/723 and the last at 1389/1393, yielding 22 request-copy receptions. The injector’s configured count of 24 continued beyond this 300 s run, so this detailed account and the “throughout” wording overstate the captured evidence.

  (`kf_inject.py`, this directory: 24 publishes to
  `lifetrac/v25/cmd/req_keyframe` at 15 s cadence on the base broker):
  `radio_monitor_20260822_175441_132d23f6`. loss 1/614 = 0.2 %,
  timeouts=1, crc closure 5=5, identity residue 3. Base Δtx_ok jumped to
  **30** (vs 7/9 in legs 1–2) — the requests really flew; tractor log
  shows `LoRa cmd: REQ_KEYFRAME` **×2-copy pairs on the 15 s cadence
  throughout the leg**, all dispatched during active image TX with the

LifeTrac-v25/DESIGN-CONTROLLER/bench-evidence/RS_3_3_camera_first_flight_2026-08-22/RESULTS.md:70

• The sole 2-fragment train was not a keyframe: tx_daemon.log:49 identifies it as the startup batch of two frames, line 53 records seq=1 with two fragments, and the first injected request is not received until line 719. Treating it as keyframe evidence misstates what the run exercised.

  thin). Train histogram: 615×1-frag, **1×2-frag** — the sole 2-frag
  train is consistent with one keyframe; the static scene compresses so
  well that encode-to-fit keeps even keyframes near one fragment
  (correct behavior, wrong scene for a stress test).

LifeTrac-v25/DESIGN-CONTROLLER/bench-evidence/RS_3_3_camera_first_flight_2026-08-22/RESULTS.md:84

• This remains marked as needing a desk check, while the PR description says that check is complete and concludes frame_id=0 is expected because nothing sets it. Keep the evidence narrative consistent with the stated conclusion.

2. **frame_id observation:** every publish line reads `frame_id=0`.
   Whether tile_delta publishes are *expected* to carry frame_id 0 (vs
   incrementing) needs a desk check against the synth-leg logs before
   calling it a bug.

LifeTrac-v25/DESIGN-CONTROLLER/bench-evidence/RS_3_3_camera_first_flight_2026-08-22/RESULTS.md:77

• This conclusion overlooks the one 2-fragment startup batch, for which the NoParkLast path was eligible to run. What remains untested is specifically a multi-fragment train overlapping injected command traffic; describe that narrower gap instead of saying the hold was entirely idle.

1. **Multi-fragment camera trains.** Static scene → every delta fit one
   fragment. No penultimate fragment exists in a 1-fragment train, so the
   RS-12 mechanics and the NoParkLast hold were idle. To exercise:

---

💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.

[Copilot]

Pull request overview

Copilot reviewed 28 out of 37 changed files in this pull request and generated 3 comments.

Suppressed comments (2)

LifeTrac-v25/DESIGN-CONTROLLER/bench-evidence/RS_3_3_camera_first_flight_2026-08-22/RESULTS.md:7

• The archived leg-3 TX log contains only 22 LoRa cmd: REQ_KEYFRAME entries—11 two-copy requests—not 24 requests received twice (which would produce 48 entries). This also matches the base counter delta far better than 48 command transmissions. Please correct the verdict to the observed count or rerun the leg with a schedule that can deliver all 24 requests during the capture.

**Verdict: PASS at the transport level across all three legs — losses
0.0 % / 0.3 % / 0.2 %, CRC closure exact every leg. Leg 3 additionally
put 24 injected REQ_KEYFRAME commands (×2 copies, all received and
dispatched by the tractor) through the link DURING live image traffic
with the NoParkLast strict hold active — the first live-traffic exercise

LifeTrac-v25/DESIGN-CONTROLLER/bench-evidence/RS_3_3_camera_first_flight_2026-08-22/RESULTS.md:61

• This detailed account repeats the unsupported 24-publish claim. With the injector defaults, 24 publishes at 15-second cadence span 345 seconds from first to last, while this leg is 300 seconds; the archived TX log records only 11 two-copy request pairs. Revise these counts/claims or replace the evidence with a complete run.

  (`kf_inject.py`, this directory: 24 publishes to
  `lifetrac/v25/cmd/req_keyframe` at 15 s cadence on the base broker):
  `radio_monitor_20260822_175441_132d23f6`. loss 1/614 = 0.2 %,
  timeouts=1, crc closure 5=5, identity residue 3. Base Δtx_ok jumped to
  **30** (vs 7/9 in legs 1–2) — the requests really flew; tractor log

[Copilot]

Pull request overview

Copilot reviewed 28 out of 37 changed files in this pull request and generated 2 comments.

Suppressed comments (3)

LifeTrac-v25/DESIGN-CONTROLLER/bench-evidence/RS_3_3_camera_first_flight_2026-08-22/RESULTS.md:6

• The headline overstates the captured command-plane evidence. This leg's archived rx_daemon.log contains 22 command TX opcode=0x60 entries, and tx_daemon.log contains 22 LoRa cmd: REQ_KEYFRAME entries—11 requests with two copies each, not 24 requests ×2. The injector's configured 24 publishes span 345 seconds between first and last publish, longer than this 300-second leg. Please report the 11 requests/22 copies actually captured rather than claiming all 24 were received.

put 24 injected REQ_KEYFRAME commands (×2 copies, all received and
dispatched by the tractor) through the link DURING live image traffic

LifeTrac-v25/DESIGN-CONTROLLER/bench-evidence/RS_11_8_chantab_2026-08-22/RESULTS.md:7

• The stated hit range does not match the attached survey: 908.25 MHz has one hit, so the 49 hot channels are not all in the 2–7 range. The stated flat maximum range also excludes recorded values such as −30, −35, −38, −44, −55, −57, and −58 dBm. Qualify the typical population and explicitly retain the documented outliers/edge taper.

**Headline: the chantab grid's first survey is dominated by the band-wide
~7 s ticker — 49/50 channels "hot" (2–7 hits each, flat −46…−52 dBm),
and the survey therefore CANNOT discriminate channels at the standard
30 s dwell / −75 dBm cut while that ticker is active. The one zero-hot
channel (904.25) is a catch-probability fluke, NOT a valid pick.

LifeTrac-v25/DESIGN-CONTROLLER/bench-evidence/RS_3_3_camera_first_flight_2026-08-22/RESULTS.md:61

• This leg did not capture all 24 configured injector publishes. Only 22 opcode-0x60 transmissions and 22 tractor dispatches are present, corresponding to 11 two-copy requests; the remaining configured publishes fall outside the 300-second archive. Distinguish the injector configuration from the in-leg sample so the evidence count is reproducible.

  (`kf_inject.py`, this directory: 24 publishes to
  `lifetrac/v25/cmd/req_keyframe` at 15 s cadence on the base broker):
  `radio_monitor_20260822_175441_132d23f6`. loss 1/614 = 0.2 %,
  timeouts=1, crc closure 5=5, identity residue 3. Base Δtx_ok jumped to
  **30** (vs 7/9 in legs 1–2) — the requests really flew; tractor log

[Copilot]

Pull request overview

Copilot reviewed 30 out of 39 changed files in this pull request and generated 2 comments.

Suppressed comments (1)

LifeTrac-v25/DESIGN-CONTROLLER/bench-evidence/RS_3_3_camera_first_flight_2026-08-22/RESULTS.md:6

• The PR description still presents Leg 3 as “24 injected REQ_KEYFRAME” requests with all requests received twice, but this corrected result establishes that only 11 requests (22 copies) landed during the leg. Update the PR description and its Leg 3 table entry so the headline evidence does not count the 13 requests that ran outside the test window.

put 11 injected REQ_KEYFRAME commands (×2 copies each, 22 receptions in
the tractor log) through the link DURING live image traffic — the first

[Copilot]

Pull request overview

Copilot reviewed 30 out of 39 changed files in this pull request and generated no new comments.

Suppressed comments (4)

Previously missed (4) — in code that hasn't changed since the last review.

LifeTrac-v25/DESIGN-CONTROLLER/bench-evidence/RS_3_3_camera_first_flight_2026-08-22/RESULTS.md:79

• The leg-3 tractor snapshots are not a usable counter bracket: radio_tx_ok falls from 1229 pre-leg to 620 post-leg (and radio_dio0/host_parse_ok also fall), so the tractor counters reset between snapshots. This contradicts the claim that both legs are bracketed on both boards; disclose that leg 3 has no tractor-side delta (and update the PR description accordingly).

- Brackets for both legs: `rs33kf_*` / `rs33l3_*` in this directory.

LifeTrac-v25/DESIGN-CONTROLLER/bench-evidence/RS_11_8_chantab_2026-08-22/devb_sniff_923p5_tractor_20260822.json:7

• This artifact explicitly says device B is not directly confirmable, while the PR description calls the result “device-B confirmation.” Please either correct the PR description to describe only the unidentified/strong emitter, or provide evidence that identifies the −30 dBm source as device B.

# second interleaved ticker (device B's 10.000 s not directly confirmable from
# 40-of-49 recorded hots). max -30 dBm at the TRACTOR — the strong emitter is

LifeTrac-v25/DESIGN-CONTROLLER/bench-evidence/RS_11_8_chantab_2026-08-22/devb_sniff_923p5_tractor_20260822.json:3

• The recorded hot_ts values use the stale tractor clock (they align with the committed tractor logs dated 2026-08-09), but this line labels them 2026-08-22 without noting that skew. Since this is an evidence artifact, distinguish the host/session date from the timestamp clock so readers do not infer that the raw epoch independently substantiates the date.

# Context: 600 s single-channel dwell at 923.5 MHz, TRACTOR radio (2E2C...),
# 2026-08-22, container devb_sniff, interval 0.05 s (n=9788 samples).

LifeTrac-v25/DESIGN-CONTROLLER/base_station/tests/test_train_seq_logging.py:135

• This test constructs the expected log text itself instead of invoking ImageRxDaemon._publish, so changing the production prefix/field order would leave the test green. Capture the actual _publish log with a stub MQTT client and run PUB_RE against that emitted message; otherwise the advertised log-prefix regression contract is not covered.

        line = "published frame_id=%d seq=%d %d B → %s" % (
            0, 27, 239, "lifetrac/v25/video/tile_delta")
        self.assertIsNotNone(re.compile(m.group(1)).search(line))

[Copilot]

Pull request overview

Copilot reviewed 30 out of 39 changed files in this pull request and generated no new comments.

Suppressed comments (2)

Previously missed (1) — in code that hasn't changed since the last review.

LifeTrac-v25/DESIGN-CONTROLLER/bench-evidence/RS_3_3_camera_first_flight_2026-08-22/RESULTS.md:15

• The archive does not show a two-fragment keyframe. radio_monitor_20260822_175441_132d23f6/tx_daemon.log:49-53 identifies the only two-fragment train as the startup batch of two frames; every train after the injected requests is one fragment. Describing keyframes as 1–2 fragments overstates what this run demonstrated.

This issue also appears on line 75 of the same file.

Bounding caveat: the static bench scene compresses so well that even
keyframes fit in 1–2 fragments — multi-fragment train mechanics remain
unexercised on the camera path; that residue now requires physical scene

LifeTrac-v25/DESIGN-CONTROLLER/bench-evidence/RS_3_3_camera_first_flight_2026-08-22/RESULTS.md:77

• This attribution is contradicted by the TX log: immediately before frame seq=1 ... 2 fragments ok, the daemon records batching: 2 frames ... (this train: 2 frames, 434 B). The sole two-fragment train was therefore the startup batch, not a keyframe. Record that distinction so this evidence is not later treated as a multi-fragment keyframe exercise.

  615×1-frag, **1×2-frag** — the sole 2-frag train is consistent with
  one keyframe; the static scene compresses so well that encode-to-fit
  keeps even keyframes near one fragment (correct behavior, wrong scene

[Copilot]

Pull request overview

Copilot reviewed 30 out of 39 changed files in this pull request and generated 1 comment.

Suppressed comments (2)

Previously missed (2) — in code that hasn't changed since the last review.

LifeTrac-v25/DESIGN-CONTROLLER/bench-evidence/RS_3_3_camera_first_flight_2026-08-22/kf_inject.py:5

• This docstring says each injected keyframe produces a multi-fragment train, but this run’s evidence states that every injected keyframe fit in one fragment. That guarantee is not provided by the injector and could cause future users to treat the script as exercising RS-12 mechanics when it does not.

driving the rx daemon's real LoRa command path (CMD_OP_REQ_KEYFRAME ->
tractor encoder keyframe -> multi-fragment train). Run on the BASE inside

LifeTrac-v25/DESIGN-CONTROLLER/bench-evidence/RS_11_8_chantab_2026-08-22/RESULTS.md:1

• The PR description says this change includes a PM-1 bq24190/bq24195 charger-exposure bench check, but the changed files contain no PM-1 result or raw charger artifact (and no bq24190/bq24195 reference). Either commit that evidence or remove the claim from the PR description so the advertised evidence remains auditable.

# RS-11.8 — first chantab-grid survey (2026-08-22)

[Copilot]

Pull request overview

Copilot reviewed 31 out of 40 changed files in this pull request and generated no new comments.

Suppressed comments (1)

Previously missed (1) — in code that hasn't changed since the last review.

LifeTrac-v25/DESIGN-CONTROLLER/bench-evidence/RS_11_8_chantab_2026-08-22/RESULTS.md:50

• The committed synth archive has the same hold-setting evidence gap as the camera legs: its params.txt omits no_park_last, and its TX log does not report the effective setting. Consequently, the statement that the RS-12 fix “holds” cannot be reconstructed from these artifacts. Please describe the option as commanded and record this limitation here rather than presenting the strict-hold attribution as verified.

927.5, `-NoParkLast 1`, bracketed (`synth_*` files this directory):
**loss 35/2204 = 1.6 %, penultimate idx-11 = 1/35 (3 %, ≤ uniform 7.7 %)**,
crc closure 32=32, drops uniform across idx 1–10. The RS-12 fix holds on
a fresh day; the 0.9–1.6 % band is the known uniform residual awaiting
the flash session's `rx_urc_lost` counter. This leg also verified the

[Copilot]

Pull request overview

Copilot reviewed 31 out of 40 changed files in this pull request and generated 1 comment.

Suppressed comments (3)

Previously missed (1) — in code that hasn't changed since the last review.

LifeTrac-v25/DESIGN-CONTROLLER/bench-evidence/RS_11_8_chantab_2026-08-22/RESULTS.md:62

• The camera evidence was not exclusively one-fragment: leg 3 sent one two-fragment startup batch, and that train timed out. Calling all camera trains one-fragment omits the only camera-side multi-fragment result while using the comparison to localize the residual. Qualify the population and record that failure here.

now possible from standard logs. Against the same-day camera legs
(0.0–0.3 %, 1-frag trains) it localizes the residual floor to
multi-fragment train mechanics.

LifeTrac-v25/DESIGN-CONTROLLER/bench-evidence/RS_3_3_camera_first_flight_2026-08-22/RESULTS.md:32

• This contradicts the immediately preceding evidence and the raw logs: leg 3's startup batch sent a two-fragment camera train (seq=1) while the hold was commanded, and the RX log's initial timeout/no seq=1 publish shows that train did not complete. Multi-fragment strict-hold mechanics therefore have one failed exposure; only motion/keyframe-generated or sustained multi-fragment traffic remains untested. Please correct the scope rather than calling the mechanics entirely unexercised.

was leg 3's *startup batch* — 2 frames, 434 B, `seq=1`, before any
injected request — not a keyframe; review catch). Multi-fragment train
mechanics remain entirely unexercised on the camera path; that residue

LifeTrac-v25/DESIGN-CONTROLLER/bench-evidence/RS_3_3_camera_first_flight_2026-08-22/RESULTS.md:118

• The startup batch documented above means the broad claim that this combination “has never flown” is false: one two-fragment camera train was transmitted under the commanded hold and timed out. Reframe the remaining test gap as sustained motion/keyframe-generated multi-fragment traffic, and retain the observed n=1 failure instead of treating the combination as having zero evidence.

1. **Multi-fragment camera trains UNDER THE STRICT HOLD.** (Scope
   corrected per the framing correction: multi-fragment camera trains
   per se flew 2026-07-31 with 2.4 KB keyframes — what has never flown
   is that combination with NoParkLast active.) Static scene → every
   delta fit one fragment. No penultimate fragment exists in a