Golf’s Data Problem: Open Source Fix with FRP and PiTrac
What is the Flight Relay Protocol and why does it matter for your home sim? FRP is an open standard for streaming launch monitor shot data — the first real attempt to solve the interoperability problem that has fragmented the golf tech ecosystem. If it gains adoption, your launch monitor will finally talk to your watch, your swing analyzer, and your sim software without third-party hacks. It matters because the data you’re generating right now is trapped in silos, and the first company or standard that unlocks it will transform how you practice and play.
Your R10 knows your club speed, ball speed, launch angle, and spin rate for every shot you hit in the sim. Your Approach watch knows your heart rate, step count, and — if you tap the button — which club you used on each hole. Your Arccos sensors know exactly how far you hit each club in real conditions: real grass, real wind, real consequences.
None of these devices share data with each other. The information is trapped in separate app ecosystems that treat interoperability like a security vulnerability rather than a feature.
This is the most consequential problem in home golf tech, and nobody in the commercial sector is solving it. The open source community is.
The Absurdity of the Current State
Walk through a typical week for a golfer who owns a sim and a wearable.
Monday night: You hit 50 balls in the garage. Your R10 captures club speed, ball speed, smash factor, launch angle, spin rate, carry distance, and total distance for every shot. You review the session in the Garmin Golf app. Your driver club speed averaged 104 mph. Your 7-iron carry was 165 yards. Good data.
Saturday morning: You play 18 holes. Your Approach watch tags each shot. You shoot 88. The watch knows you hit driver 240 yards — carry plus roll, no launch angle, no spin data. It syncs to Garmin Connect.
Sunday night: You want to compare your sim driver numbers to your on-course driver numbers. Am I swinging the same speed indoors? Is my carry distance matching? Are my launch angles different on the course?
You can’t answer any of these questions. Not without manually exporting CSV files from two different apps and running the analysis yourself in a spreadsheet. The data exists. It’s your data. You generated it. But the two systems do not talk to each other.
This is like owning a gym where every machine tracks your workout but none of them share data — so you have to scribble your bench press numbers on a napkin to compare them with your squat numbers.
The Walled Gardens
Every major golf tech company has built a walled garden. It’s a standard business strategy: lock users into your ecosystem, and they’ll buy your next product, your next subscription, your next accessory. Apple does it. Google does it. Garmin does it. Foresight does it. Uneekor does it.
Garmin has the most complete ecosystem of any company in golf. Launch monitors (R10, R50), smart watches (Approach S62, S70), a rangefinder, and the Garmin Golf app that ties it all together. If you only buy Garmin products, the integration is decent. Your R10 data syncs to Garmin Connect. Your watch data syncs to Garmin Connect. You can see both in one place.
But try to get Garmin data into GSPro without a third-party hack. Try to get your Arccos club distances to show up in your Garmin Golf app. Try to export your Garmin session data to a format that works with a coaching platform.
Foresight has a similar setup with Link-Enabled technology. You can sync your GC3 or Bushnell Launch Pro data to a Bushnell rangefinder for on-the-course club recommendations. That’s smart — it’s the closest thing to closing the loop that exists today. But it only works within the Foresight/Bushnell ecosystem. Your Arccos data doesn’t feed into it. Your watch data doesn’t feed into it.
Shot Scope is the most integrated option for the budget-conscious golfer. Their LM1 launch monitor ($199) syncs to the same app as their PRO V5 GPS watch. You can see your range session and your on-course round in one place. It’s a walled garden, but at least there’s a gate.
Nobody has closed the loop completely. The closest anyone has come is “you can see your data in one app.” That’s not closing the loop. That’s putting two folders in the same drawer.
The Open Source Rebellion
The most interesting thing happening in golf tech right now is coming from a group of developers who are tired of the silos. No company is driving this.
The Flight Relay Protocol (FRP) is an open standard for streaming launch monitor shot data over WebSocket. It defines a common event format — shot_trigger, ball_flight, club_path, face_impact, shot_finished — so any launch monitor can talk to any simulator without proprietary SDKs or reverse-engineering.
This is the interoperability problem that the commercial vendors have refused to solve. Every launch monitor speaks a different language. Foresight has its own protocol. Garmin has its own protocol. Uneekor has its own protocol. If you’re an open source project that wants to support multiple monitors, you either negotiate SDK access with every vendor individually (good luck) or reverse-engineer them (fragile, breaks on firmware updates).
FRP solves this by defining a thin output layer. Launch monitor vendors implement FRP once and instantly support every FRP-compliant project. Open source projects implement FRP once and instantly support every FRP-compliant monitor. The protocol is CC0 licensed — implement it anywhere, open or closed, without attribution.
The pitch is elegant: “Your firmware, your signal processing, your ball flight modeling, your proprietary app — none of that changes. FRP sits at the output layer: you emit shot events in a standard format.”
If every launch monitor shipped with FRP support, you could plug any device into any simulator, any data logger, any analysis tool. The developer community would build the connections that manufacturers won’t.
Flighthook is a bridge built on top of FRP. It connects to launch monitors, decodes shot data, and forwards it to GSPro. It exposes a REST and WebSocket API so any third-party app can subscribe to shot data in real time. A developer could build a custom dashboard, a data logger, a video overlay — anything — without needing permission from Garmin or Foresight.
KW Golf’s ShotBridge takes a different approach. Instead of reverse-engineering protocols, it uses OCR to read shot data from the launch monitor’s companion app. If it shows numbers on screen, ShotBridge can read them. It works with 13+ launch monitor apps. It’s inelegant software that gets the job done.
These are the early signs of a rebellion. Developers are building the bridges that manufacturers won’t. But it’s still a patchwork. The average golfer shouldn’t need to install a Rust CLI tool or configure a WebSocket server to get devices to talk to each other.
The Hardware Side: PiTrac and the DIY Movement
While FRP attacks the software interoperability problem from the protocol layer, a parallel rebellion is happening in hardware. The open source golf sim ecosystem is building an entire parallel infrastructure — and it’s moving faster than most people realize.
PiTrac is the most ambitious project. It’s a fully functional golf launch monitor you build yourself. The hardware list: a Raspberry Pi, a Pi Global Shutter camera (about $50), some 3D-printed parts, a custom PCB that costs a few dollars to fabricate, and a few other components. Total cost: under $200.
It’s a photometric system — it uses cameras to capture the ball at impact, then calculates speed, launch angle, and spin in all three axes. It interfaces with GSPro and E6 through the GSPro Open Connect protocol. The documentation is thorough, the community is active on Discord, and the project has been in development for several years.
The honest take: PiTrac is not a commercial launch monitor. It’s not as accurate as a $3,000 GC3. It doesn’t have the polish of a $600 R10. It requires assembly, calibration, and troubleshooting. But it’s a working launch monitor that costs less than a dinner out for four people, and it’s only getting better.
OpenGolfSim is the most established open source golf simulator software. Built on Unity 6, it runs on Windows and Mac. It has direct Bluetooth integration with the Garmin R10, 120fps webcam swing capture, a course creation tool, and a mobile remote app. Fifteen public repos on GitHub. It’s free — no trial, no limited tier, no upsell. The course library is thin compared to GSPro’s 4,000+, but the practice range is functional and the ball physics are decent.
Open-Birdie is the newest entrant (launched June 2026) and the most interesting architecturally. Instead of shipping with a fixed course library, it pulls courses directly from OpenStreetMap and uses AWS Terrain Tiles for elevation data. That means any mapped golf course in the world is potentially playable. The physics is calibrated against Tour-level TrackMan numbers. It’s early — zero GitHub stars, one contributor, visuals that top out at “good indie sim” — but the architecture is right.
OpenShotGolf (formerly JaySimG) runs on the Godot Engine, an open source game engine gaining traction as an alternative to Unity. It has the most community engagement (54 stars, 11 forks) and the most thoroughly documented ball physics model of any open source project — there’s a full Reynolds number analysis in the repo explaining how drag and lift coefficients change across different speed regimes.
The Hidden Story: Why FRP Is the Real Inflection Point
The open source simulators are impressive. But the most important project in the ecosystem is the one that doesn’t have a GUI.
FRP matters more than any single simulator because it addresses the root cause of the fragmentation. The commercial vendors have no incentive to make their data portable. The open source community does. FRP is the mechanism.
The ecosystem stack is already forming:
- FRP — the shot-data streaming standard
- Render Relay Protocol (RRP) — the rendering counterpart
- Flighthook — the multi-device management bridge
If one major launch monitor vendor ships FRP support — even as an optional mode — the network effect kicks in. Every open source simulator instantly supports that monitor. Developers stop spending time on reverse-engineering and start spending time on features. The walled gardens still exist, but the walls get a lot lower.
What This Means for Your Home Setup Today
If you’re building a home sim right now, here’s how the open source ecosystem fits into your decision.
For the budget builder: OpenGolfSim plus a Garmin R10 is a fully functional free setup. You lose GSPro’s 4,000-course library, but you gain a free practice range with ball data and webcam capture. If you’re not sure whether you’ll use a sim enough to justify $250 a year, start here.
For the tinkerer: Open-Birdie and PiTrac are the projects to watch. Open-Birdie’s approach of pulling courses from OpenStreetMap is clever, and PiTrac is a launch monitor you can build yourself for $200. If you enjoy the build as much as the play, these are your projects.
For the ecosystem watcher: FRP is the sleeper. If it gains adoption from even one major launch monitor vendor, it changes the entire interoperability landscape. The open source sim ecosystem would go from “fragile per-device integrations” to “implement once, support everything.”
For everyone else: Keep paying for GSPro. It’s worth the money. But check back in a year. Open source moves fast, and the community that built Linux, Blender, and Krita is now building golf simulators.
Where This Is Headed
The open source golf sim ecosystem is at the same stage that 3D printing was in 2010 or that Linux was in 1995. The technology works, the community is passionate, and the commercial alternatives are expensive enough to create demand for a free alternative. But it’s not ready for the mainstream yet.
The inflection point will be FRP adoption. The second inflection point will be course quality on the open source side — when Open-Birdie’s rendering pipeline improves to the point where courses look good on a 1080p projector, the use case expands from “free practice range” to “free course play.”
Neither of these things has happened yet. But they’re closer than they were six months ago. And in open source, things happen fast.
The first company that closes the loop — that lets you practice in your sim, see those numbers on the course, and bring the course results back to your sim — will win. It will win in product sales, sure. But more importantly, it will win in loyalty. That’s the company that understands what golfers actually want: a connected system that makes them better, not more gadgets.
Until then, we’re all manually exporting CSV files and pretending that’s fine.
This article synthesizes reporting from two beat writers: Mulligan’s analysis of the golf data silo problem and Ace’s deep dive into the open source golf sim ecosystem. For the full picture of the sim software landscape, see our best golf simulator software guide, GSPro software review, and budget launch monitor guide.