You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
User decision 2026-07-04: first priority after the v1 cut. Until then, calibration happens on the timer (RotorHazard's own UI).
What
An RH-style tuning surface in the RD console, per timer, in the Timers menu: live per-node RSSI with the node's current enter/exit levels drawn as draggable lines, and an explicit Apply that writes calibration back to the timer.
Design commitments (from the design discussion)
Capability-gated, never timer-kind-gated: the Tune view appears only for timers whose plugin handshake advertises live-signal + calibrate capabilities (extends the existing PluginPresence.capabilities). A future LapRF adapter reporting the same capabilities gets the page for free; Mock offers nothing.
Tuning telemetry is EPHEMERAL, not evidence: bench/idle tuning streams must never touch the event log (race-time RSSI is logged because it backs results; tuning noise would bloat every event). On-demand plugin stream (subscribe on view open, stop on close) → in-memory per-timer state in the Director → live read/stream endpoint → console. The practice-board live-laps pattern is the precedent.
Preview-then-commit: dragging adjusts locally; per-node Apply sends gridfpv_calibrate {node, enter, exit} via the plugin (RHAPI alter; RH persists its own config). No streaming writes on drag.
Safety rail: Apply blocked while a heat is Running (mid-race detector changes are a results-integrity hazard); tune during practice/idle.
Labels: "Node N · ‹frequency›" honestly; resolve to the seated pilot's callsign when the active event has a heat staged (friendly-names rule).
Plugin handshake + capability list + versioned guided-install machinery (D16/S1) — a protocol/capability bump rides the existing skew handling.
gridfpv_calibrate write-back was designed in the plugin spike (docs/rotorhazard-plugin.html) and prototyped in the overnight S4 work ("staged for review", never merged).
Threshold-handle drag UX shipped in the marshaling tune panel.
The compounding follow-up
Once this exists, add "push these levels to the timer" on the marshaling tune panel — post-hoc discovery (what levels would have detected this heat right) becomes forward calibration in one click. Explicitly out of scope for the first slice of this issue; file separately when this lands.
User decision 2026-07-04: first priority after the v1 cut. Until then, calibration happens on the timer (RotorHazard's own UI).
What
An RH-style tuning surface in the RD console, per timer, in the Timers menu: live per-node RSSI with the node's current enter/exit levels drawn as draggable lines, and an explicit Apply that writes calibration back to the timer.
Design commitments (from the design discussion)
PluginPresence.capabilities). A future LapRF adapter reporting the same capabilities gets the page for free; Mock offers nothing.gridfpv_calibrate {node, enter, exit}via the plugin (RHAPI alter; RH persists its own config). No streaming writes on drag.Building blocks already in place
gridfpv_calibratewrite-back was designed in the plugin spike (docs/rotorhazard-plugin.html) and prototyped in the overnight S4 work ("staged for review", never merged).The compounding follow-up
Once this exists, add "push these levels to the timer" on the marshaling tune panel — post-hoc discovery (what levels would have detected this heat right) becomes forward calibration in one click. Explicitly out of scope for the first slice of this issue; file separately when this lands.
Related: #348 (threshold re-detection), #353 (full-audit model), D16 (plugin direction).