v0.4.0-dev.1211

What's Changed

• Claude/update integration by @Cormac131 in #3

Full Changelog: v0.4.0-dev.1203...v0.4.0-dev.1211

v0.4.0-dev.1203

Full Changelog: v0.3.0-dev.1202...v0.4.0-dev.1203

OpenFlight v0.3.0

Added

• Electron kiosk shell. scripts/start-kiosk.sh now opens the UI in a pinned
  Electron window (electron@44) instead of whichever system browser happens to
  be installed. Chromium remains a fallback if Electron is not installed (including
  when Node is older than 22.12 or npm install fails and ui/dist already
  exists). Installing Electron needs Node.js 22.12 or newer. See
  Electron Kiosk Shell.
• Stable and experimental release workflows. Pushing a vX.Y.Z tag
  publishes a stable GitHub Release; every push to main publishes a
  vX.Y.Z-dev.N pre-release on the experimental channel. Both ship
  openflight-<tag>.tar.gz (source tree, prebuilt ui/dist, release.json)
  with a checksum and announce on Discord. scripts/release/ holds the
  changelog roll, artifact build, and announcement tooling; see
  docs/release-process.md.
• Build identity and release channels (stage 1). The server now knows
  which build it is running: src/openflight/release.py reads a release.json
  shipped in release artifacts (channels stable and experimental) and
  falls back to source with the short git commit for plain checkouts. The
  version and channel appear in the kiosk menu under System, in
  openflight-server --version, in openflight-cloud status, in the cloud
  upload manifest, and in each session log's session_start record
  (app_version, new app_channel). pyproject.toml now takes its version
  from openflight.__version__ (hatch dynamic version). The release
  workflows that produce the artifacts are planned in
  docs/plans/2026-09-04-release-channels-plan.md.
• Profiles replace players. Shots are now attributed to a server-owned profile
  (a person or a place) with a stable id, persisted to
  ~/.config/openflight/profiles.json (override with OPENFLIGHT_PROFILES_PATH
  or --profiles-path). Profiles can be renamed without orphaning their shots.
  Removing a profile is refused while it still has session rows. The socket
  exposes a single authoritative profiles snapshot plus
  set_active_profile / add_profile / rename_profile / remove_profile.
  Breaking: set_player / player_changed are gone, Shot.player_name is replaced
  by profile_id + profile_name, and existing browser-local player rosters are
  discarded.
• Automatic OV9281 exposure control. High-speed camera capture now measures
  the impact area every five seconds, restores the last known-good setting at
  startup, and selects a shutter/gain combination that preserves club contrast
  without excessive clipping or motion blur. Large lighting changes re-enter
  fast convergence while smaller changes require confirmation. Camera-derived
  shot analysis is withheld when lighting is unsuitable, but radar processing
  and shot display continue normally with an operator-facing lighting warning.
• Instrument-panel kiosk UI. The dashboard is a tabbed shell (Live, Stats,
  Shots, Camera, Profiles, Debug) instead of the previous stacked shot and stats
  views. Tap a Live metric to pin it top-left while keeping all ten metrics
  visible. The footer logo opens units, dark/light theme, language, simulator,
  and ball-detection status; a persistent footer power button opens the shutdown
  confirmation. Club (or training implement) selection is a Live header action.
  See the UI README.
• Kiosk languages. English, Spanish, French, and Portuguese. Choice is
  stored in localStorage (openflight.locale:v1).
• Dark and light themes. Toggle in the footer menu; stored as
  openflight.theme (default dark).
• Synchronized OV9281 high-speed camera capture. OpenFlight can now retain
  pre- and post-impact camera frames from the shared sound trigger, align them
  with OPS243 and IWR6843 captures, and use camera-assisted or camera-only
  fallbacks for horizontal launch, club path, and angle of attack. The Camera
  tab adds live alignment, crop, orientation, and lighting controls while the
  rolling buffer remains armed. See OV9281 Camera.
• On-demand camera shot replay. Camera-backed shots can open a 60 FPS
  slow-motion impact player from Live or Shots, with touch controls, scrubbing,
  and a trigger-frame impact marker. MP4 conversion starts only after a manual
  Replay selection, caches the result beside the raw capture, and reports
  retryable preparation or playback failures without affecting shot results.
• Battery and external-power status for Raspberry Pi UPS boards. OpenFlight
  can now display charging state and battery percentage, issue dismissible 20%
  and 10% warnings while discharging, and record throttled power telemetry in
  session logs. Enable the initial Geekworm X1202/X1206 provider with
  --battery geekworm; monitoring remains disabled when no provider is
  selected. The accompanying Pi setup installs native Linux power-supply
  telemetry and optional taskbar capacity support without enabling automatic
  shutdown or charging control. See Battery Monitoring.
• System Prerequisites: Documented missing binary dependencies (swig, liblgpio-dev, python3-dev) required prior to executing ./scripts/setup/setup.sh.
• Environment Reload Guidance: Added instructions for reloading terminal environment variables (source ~/.bashrc) when installed dependencies or scripts (setup.sh, start-kiosk.sh) are not recognized in the current terminal session.
• Configurable IWR6843 capture compression. One firmware image can now
  switch at runtime between the recommended 24-frame, 3 ms, 53-bin IQ16
  profile and an advanced 36-frame, 2 ms, 32-bin IQ8 profile. Both retain the
  same 72 ms shot movie and all 3 TX x 4 RX channels. Per-frame range windows,
  timing, and IQ8 scales are carried in the dump so offline and live processing
  use the actual capture geometry. The dense profile uses a sparse scale
  preview to sustain the 2 ms HWA rearm budget and exposes missed frames,
  overruns, and clipped components through firmware stats.
• OPS243 over the Raspberry Pi GPIO UART. The radar can now run on the J3
  header instead of USB, which frees the Pi's USB power budget for the TI angle
  radar. Baud is the real wire rate on that transport and the factory default of
  19,200 would stretch a 40.6KB dump to 21 seconds, so the driver probes for the
  rate the board is actually using and raises it to 230,400 (I5), bringing a
  dump down to ~1.8 seconds. Every dump timeout now scales with the negotiated
  rate, so a link that settles low runs slowly instead of truncating captures.
  Pass --radar-port /dev/ttyAMA0 (and optionally --ops-baud); USB behaviour
  is unchanged. diagnose.py --ops-port adds a preflight for the three
  UART-only failures that all look like an unresponsive radar — missing device
  node, a login console holding the port, and the OPS USB cable still plugged in
  (which silences the UART). See
  Moving the OPS243 from USB to the Pi GPIO UART.
• Flash IWR6843 firmware directly from a Raspberry Pi. Contributors no
  longer need an Intel Mac, UniFlash, or TI Cloud Agent for routine firmware
  updates. The guided terminal workflow verifies the image hash, offers a
  non-destructive bootloader probe, erases the existing image, transfers the
  replacement in acknowledged chunks, and requires the radar's ROM bootloader
  to verify the completed image. The current IWR6843LEVM still requires its
  physical flash-mode switch and reset button.
• Experimental three-transmitter capture for horizontal launch direction.
  The TX2 firmware variant captures all three transmitters while retaining the
  TX1/TX3 vertical array, giving the offline and live pipelines the antenna
  diversity needed to begin measuring left/right start direction.
• On-chip range snapshots for smaller IWR6843 shot captures. The radar uses
  its hardware accelerator and EDMA to retain 53 selected complex range-FFT
  bins in moving early, middle, and late windows instead of every raw ADC
  sample. The production ring keeps 18 frames at 4 ms spacing in a 549,542-byte
  dump while preserving vertical and horizontal processing inputs.
• --kld7 now delivers the full launch-angle pipeline by default. Enabling
  the K-LD7 radars turns on the two-ray multipath vertical launch-angle
  estimator (per-frame demodulation that separates the ball from its floor
  reflection to recover true elevation instead of averaging across the
  multipath) plus the ball-speed cosine correction (OPS radial → true
  speed). Each shot is graded into a tour-derived Tier-1/Tier-2 confidence with
  a tour-average boost for suppressed reads; measurements that clear the
  physics guard but trip a soft consistency guard are shown as marginal
  (one-dot) confidence rather than silently replaced by the club estimate.
  Far-net flights are de-aliased past the FSK range wrap (--net-distance).
• --kld7-mount-tilt is required with --kld7 (measure with a phone
  inclinometer — no safe default). --kld7-angle-offset defaults to the
  calibrated 1.5.
• --calculated-spin (opt-in, off by default): replaces radar spin with the
  kinematic estimate 170·v·sin(LA)^1.2; the measured value is retained in
  spin_rpm_measured for scoring.
• --kld7-vertical-raw test mode surfaces the raw radar angle for every shot
  (all display guards bypassed).
• Offline scripts/analysis/session_shot_report.py per-shot HTML report, a
  visual explainer (docs/kld7-launch-angle-explained.html), and a
  setup/usage guide (docs/kld7.md).
• Club path from the IWR6843's pre-impact frames. Shot.club_path_deg has
  been wired end to end since the K-LD7 era but unpopulated since that radar
  was deprecated. It now comes from the six pre-impact frames the L3-dump
  firmware already retains. The ...

v0.3.0-dev.1202

What's Changed

• chore(release): v0.3.0 by @Cormac131 in #2

Full Changelog: v0.2.0-dev.1200...v0.3.0-dev.1202

v0.2.0-dev.1200

What's Changed

• Claude/release integration by @Cormac131 in #1

New Contributors

• @Cormac131 made their first contribution in #1

Full Changelog: https://github.com/Cormac131/openflight/commits/v0.2.0-dev.1200