mrkeyoor.com_
Sat 17 Oct 13:33 UTC
Self-Hostedevaluationupdated 12 Sept 2026

openflight review

OpenFlight is a self-hosted golf launch monitor built around a Raspberry Pi 5 and an OPS243-A Doppler radar, with a second radar available for measured launch angle. It gives golfers and simulator builders shot data without buying a closed monitor, provided they are willing to assemble and calibrate the hardware.

+12stars / 7d
Verdict

Our OpenFlight run installed 58 packages in 27 seconds, built in 8 seconds, and passed 1,341 tests, so the software deserves a trial if you are prepared to build the hardware. Use it for a DIY practice bay or simulator where ball speed matters more than production-grade spin. Buy a finished monitor if you do not want to solder or flash radar firmware. Careful mount measurements are another mandatory job.

We ran it

Lab card: what happened when we ran openflightScreenshot of openflight (open-flight.github.io/openflight)
Install✓ · 27s58 packages · 217 MB
Build✓ · 8s
Tests✓ · 58s1341 passed · 0 failed · 8 skipped of 1341 (pytest)
Known vulns0(pip-audit)
Repo697 files~139,805 lines of source · 109.4 MB · 4 CI workflows · tests dir

Answers from our run

Does openflight build from source?

Dependencies installed in 27 seconds (58 packages), and the build succeeded in 8 seconds. We cloned commit 1bdcce0 into a clean Debian container with 3 CPUs and no project-specific setup.

Do openflight's tests pass?

Yes. The project's own test command finished in 58 seconds and reported 1341 passed, 0 failed, 8 skipped (pytest).

Does openflight have known vulnerabilities in its dependencies?

pip-audit found none in the dependency tree at the time of our run.

Who should not use openflight?

Buyers who want a finished appliance: our 58-package install covered only software, while the roughly $400 build still needs assembly and radar setup.

What are the alternatives to openflight?

PiTrac, Garmin Approach R10, FlightScope Mevo+. Our OpenFlight run installed 58 packages in 27 seconds, built in 8 seconds, and passed 1,341 tests, so the software deserves a trial if you are prepared to build the hardware.

Setup2/5Code passed quickly; hardware still needs assembly and calibration
Docs4/5Detailed Pi, radar, cloud, and simulator guides expose real caveats
Community4/51,053 stars, a September push, and active issue discussion
Maturity3/51,341 tests passed, but spin and club path remain experimental

Who it’s for

Golfers comfortable wiring sensors who want a DIY monitor whose software installed 58 packages cleanly in our sandbox.
Indoor simulator users who want to send shots to GSPro or OpenGolfSim from a local Pi.
Python and React contributors interested in radar capture, ballistics, or touch-first interfaces.
Experimenters who can compare spin and carry estimates against trusted reference data.

Who it’s NOT for

Buyers who want a finished appliance: our 58-package install covered only software, while the roughly $400 build still needs assembly and radar setup.
Golfers who need dependable spin for fitting or carry calculations: the README calls spin experimental and keeps it out of production carry.
Owners of a WiFi OPS243-A who refuse an extra powered USB hub: that board cannot use the Pi GPIO UART alongside the IWR6843.
Closed-source vendors unwilling to meet AGPL-3.0 obligations for a networked derivative.
Users who require fixed behavior and formal releases: the README warns that features may be incomplete or change without notice, and GitHub lists no release yet.

Setup reality

Our sandbox install at commit 1bdcce0 succeeded in 27 seconds, adding 58 packages and using 217 MB. The build passed in 8 seconds. Pytest finished in 58 seconds with 1,341 passed, 0 failed, and 8 skipped. Pip-audit found 0 known vulnerabilities.

A working monitor needs Raspberry Pi OS, an OPS243-A, a sound detector, and one-time radar flash setup. The Pi guide also installs swig, liblgpio-dev, and python3-dev. The optional IWR6843 needs custom firmware plus measured mounting geometry. Basic local use needs no account; FlightWeb sync requires device linking.

The hardware is the hard part. The documented subtotal is about $400, or about $556 with measured launch angle. The sound detector may need a soldered resistor. A WiFi OPS243-A requires a separately powered USB hub with the second radar, and bad geometry can bias results without an obvious startup error.

A $400 build measures speed before it measures trustworthy spin

OpenFlight's 697-file application uses an OPS243-A radar to capture ball speed and club speed, then calculates smash factor and carry. The parts list comes to about $400 with a Raspberry Pi 5, a 7-inch screen, a sound detector, and supporting hardware. An optional TI IWR6843 raises the total to about $556 and adds measured launch angle plus experimental club path. Without that second radar, launch angle is estimated.

The application extends well beyond the sensor. The commit we tested filled 697 files, roughly 139,805 source lines, and 109.4 MB before installation. A Flask and WebSocket server feeds a React touchscreen interface with live shots, stored sessions, camera replays, player views, and debugging data. A separate browser display can put the current shot on a TV or tablet over the local network.

The 27-second install hides the wiring and flash work

Our tested Python 3.12 setup starts from 64-bit Raspberry Pi OS and an interactive script, but the Pi guide first asks for swig, liblgpio-dev, and python3-dev. The script creates the Python environment, builds the interface, configures the radar, and can install auto-start. Rolling-buffer mode must be saved to the OPS243-A flash, followed by a power cycle.

Our test method used a clean Python 3.12 container, where we installed 58 packages in 27 seconds and used 217 MB. That result says the checked-out software is well packaged. It does not verify the sound detector wiring or radar alignment. The sound-trigger build may require soldering a resistor because the detector runs at 3.3 V and its output can stick high.

What happened when we ran it

Our sandbox installed commit 1bdcce0 in 27 seconds, built it in 8 seconds, and completed the test step in 58 seconds. Pytest reported 1,341 passed, 0 failed, and 8 skipped. Those are unusually reassuring code results for a project whose README opens with an active-development warning. They do not test a golfer, an OPS243-A, or an IWR6843 inside our unprivileged container.

Pip-audit found 0 known vulnerabilities among the installed Python packages. The checkout had 4 CI workflow files and a tests directory, while our scan found no Dockerfile. Installation used 217 MB on disk after the 58 packages landed. A container image is not the natural delivery unit here anyway: USB and GPIO access, systemd startup, a touchscreen, and physical radar configuration all point toward a dedicated Pi.

Spin stays experimental, and carry fills missing inputs

The 109.4 MB checkout includes a production capture path that freezes 4,096 I samples and 4,096 Q samples around impact. OpenFlight constrains its spin candidate to 1,500 through 11,000 RPM, labels the value experimental, and excludes it from spin-adjusted carry. Its guide says multipath and capture geometry can produce plausible but wrong readings. Golfers comparing balls or shafts should not treat that field as fitting data.

The 139,805-line codebase includes a ballistic model, but an open physics issue explains why model output still needs outside checks. Issue 230 argues that the current lift curve cannot represent the measured peak at higher spin ratios. A follow-up comparison covers 417 archived shots and reports better carry and apex errors with another equation, while spelling out limits in the sample. The issue remains open, so we would validate carry against a trusted monitor.

Measured angles require a second radar and exact geometry

The checked-in IWR6843 firmware is 346,820 bytes, and its setup path is demanding. Stock TI demo firmware cannot expose the radar cube OpenFlight needs. Builders must reach the boot switch and reset button, flash the custom image, then record radar-to-ball distance, radar-to-net distance, radar height, ball height, and tilt. Wrong values bias the answer instead of causing a clear failure.

Adding that radar takes the listed hardware from about $400 to $556. It also exposes a power and compatibility snag that a quick software trial cannot reveal. The Pi cannot power both radars over USB in the validated layout, so the OPS243 moves to GPIO UART. A WiFi-equipped OPS243-A already uses that UART internally and must stay on USB through a separately powered hub. The 8-second build gives no shortcut around those constraints.

Local simulator and cloud links are useful secondary features

OpenFlight supports 2 endpoints for simulators, GSPro and OpenGolfSim, with each shot field marked measured or estimated. Connectors are optional and can run together. An August issue reports that the documented OpenGolfSim Developer API route stayed in an initializing state; the reporter connected after installing its OpenConnect plugin and changing ports. This makes an end-to-end simulator trial essential.

Cloud sync is opt-in and filters uploads on the Pi. The guide says raw I/Q captures remain local while shot results and session metadata can go to FlightWeb. A dry-run command shows the outbound records, and a roughly 10-minute systemd timer retries interrupted uploads. Our 3-CPU, 8 GB sandbox did not exercise a simulator, cloud account, radar, camera, or touchscreen, so the 58-second test result cannot certify those integrations.

September activity has not produced a stable release yet

GitHub recorded the last push on September 10, 2026, and listed 31 issues and pull requests when fetched. Issue 189 received discussion that day about replacing or eliminating the sound-trigger board, including regression work against newer OPS firmware. That combination shows active maintenance around real builds. GitHub's latest-release endpoint returned no release, and the README still warns that features can change without notice.

The clean run matters: 1,341 passing tests, an 8-second build, and 0 known dependency vulnerabilities make OpenFlight easier to trust as a software project. The hardware claims deserve a stricter standard. Spin and club path remain experimental, carry depends on fallbacks, and measured angle adds a second flashed radar with exact mounting inputs. For a golfer who enjoys building instruments, those are acceptable jobs. For someone who only wants numbers after a swing, they are reasons to buy an appliance.

Alternatives

ProjectWhat it isPick it when
PiTracA GPL v2.0 Raspberry Pi and camera DIY monitor that calculates speed, angles, and spin.pick this instead when you prefer a camera-based design and accept a more involved build with printed parts.
Garmin Approach R10A packaged portable radar monitor with a vendor app and setup path.pick this instead when warranty, portability, and a finished product matter more than source access.
FlightScope Mevo+A packaged radar monitor aimed at practice sessions and golf simulators.pick this instead when you want measured shot data from supported retail hardware and have a larger budget.

What people are saying

  1. [github-trending] jewbetcha/openflight

Sources

  1. OpenFlight GitHub repository and README
  2. OpenFlight parts list
  3. OpenFlight Raspberry Pi setup guide
  4. OpenFlight IWR6843 operator guide
  5. OpenFlight rolling buffer and spin detection guide
  6. OpenFlight issue 189: Switch out the sound trigger board
  7. OpenFlight issue 230: Lift model form
  8. OpenFlight issue 186: OpenGolfSim Developer API

More self-hosted reviews

playport · edge-smart-doh · Comma · ProsperoEden · zulu · node_exporter · the whole board →