Everything about Sail Race Tracker, answered in depth.

Sail Race Tracker is a low-cost, SIM-free, open-source GPS race-tracking system for youth sailing dinghies. It brings America's-Cup-style live fleet maps to club and school regattas for a fraction of the usual cost, letting anyone follow a race from the shore in a web browser. Its tagline sums it up: "See the whole race. From the shore." You can learn more at https://www.sailracetracker.live.

I did — I'm Jack Harker, a competitive youth sailor from Auckland, New Zealand. I race in the Starling and 29er classes and, at the time of building it, was a Year 10 student at ACG Parnell. I designed, coded, assembled and field-tested the whole system myself, and you can reach me at jackharker000@gmail.com.

Youth sailing is thrilling but almost impossible to follow from shore, so parents and coaches often can't actually see the race. Big regattas can have 100–200 dinghies on one course, and today people follow along in powerboats that are costly, noisy, risky and fuel-burning. Sail Race Tracker fixes this by putting a tiny GPS tracker on each boat and streaming live positions to a map anyone can watch from land, no chase boat required.

Commercial sailing trackers such as RaceQs, TracTrac, Yellowbrick, Sailmon MAX and WAIV cost roughly NZ$500–900 per unit plus subscription fees, and they rely on a SIM card or a phone paired over Bluetooth. That's a problem, because phones are banned in dinghy racing for safety and class-rule reasons. Sail Race Tracker is designed to cost under NZ$50 per unit, needs no SIM card, no subscription and no phone on the boat, using long-range LoRa radio instead. As far as the project can tell, no other product offers real-time, waterproof, affordable, SIM-free GPS tracking for dinghy fleets.

Sail Race Tracker is a working end-to-end proof of concept that has been field-tested on the water, not yet a finished commercial product. The 2025 version proved the whole chain works, from boat to shore dashboard, during real sail training. A 2026 rebuild with custom firmware and a cloud backend is currently underway to move it closer to production.

Not yet — Sail Race Tracker is currently a proof of concept rather than a product you can buy off the shelf. That said, I'm keen to hear from anyone interested in trialling a prototype, sponsoring the project, or partnering with a club or school. The best way to enquire is to email me directly at info@sailracetracker.live.

Sail Race Tracker is a cheap, waterproof GPS tracker for youth sailing dinghies that streams every boat's position to a live map you can watch from the shore on any phone, tablet or laptop. It uses long-range LoRa radio instead of a SIM card, targets a build cost of under NZ$50 per unit versus NZ$500–900 for commercial gear, and it's open-source and community-driven. In short, it gives club and school regattas the kind of live fleet view normally reserved for the America's Cup.

Yes. Sail Race Tracker won 1st Prize in the Years 7–10 category of the Samsung Solve for Tomorrow 2025 competition, awarded on 30 October 2025 with an NZ$9,000 prize pool in partnership with MOTAT and TENZ. It also took 1st place in the Technology category at the 2025 NIWA Auckland City Science & Technology Fair. These wins recognise both the engineering and the potential impact on youth sailing.

The project's website at https://www.sailracetracker.live hosts a self-contained Tracker Demo with multi-race replay, showing boat arrows, coloured trails, course marks, a wind dial and a live leaderboard. One of the demo races (Race 1) is a genuine on-water LoRa recording captured at the Royal Akarana Yacht Club. There is also a Samsung Solve for Tomorrow film on YouTube at https://youtu.be/KwD-CH28lW8.

Each dinghy carries a small waterproof box holding a microcontroller, a GPS module, a LoRa radio and a battery, which broadcasts its position every few seconds. A gateway on the support or committee boat picks up those signals over LoRa radio and passes them to a small computer, which stores the data and serves it to a live web map. The result is a real-time fleet view you can open in any browser from the shore, with no internet needed on the race boats and no SIM cards anywhere.

"SIM-free" means Sail Race Tracker sends its data over free long-range LoRa radio rather than a cellular network, so there are no SIM cards, no mobile contracts and no monthly data plans. This matters for two big reasons: it removes the ongoing running costs that make commercial trackers expensive, and it avoids relying on phones, which are banned in dinghy racing. It keeps the system cheap to run and legal for youth racing.

Sail Race Tracker is built for four groups: sailors who want GPS replays to learn tactics faster, race officials who need a live full-fleet view for safety and fairer starts, coaches who want to review whole sessions and compare sailors, and spectators such as parents who want to follow the racing from shore. It targets popular youth classes including the Optimist, Starling, 29er, ILCA and iQFOiL. There are thousands of youth sailors in New Zealand who could benefit.

Yes. Sail Race Tracker is built on an open-source, community-driven ethos, with the deliberate goal of being affordable and accessible rather than a locked-down commercial product. I'm especially keen to hear from makers, engineers and people in the LoRa and open-source communities who want to contribute to the firmware, web app or hardware. Contributions and collaboration can be arranged via info@sailracetracker.live.

Yes. Sail Race Tracker was featured on RNZ (Radio New Zealand) Nine to Noon in a segment titled "Solve for Tomorrow winners tackle race tracking and mountain bike safety." It has also been covered by Samsung NZ, Idealog, MOTAT and TENZ, and there is a dedicated Samsung Solve for Tomorrow film about the project. A podcast interview, "Sailing Smarter — How One Young Innovator Built a Low-Cost Race Tracker with Open-Source Tech," is available as well.

Yes. I presented Sail Race Tracker to the NZIODA National Committee (New Zealand International Optimist Dinghy Association) on 1 July 2025, where it drew strong interest and support, with officials noting that reliability is essential for race-official use. During field trials at the Royal Akarana Yacht Club, coaches were impressed at being able to track boats from shore without chasing them, parents were keen to watch from the clubhouse, and sailors were excited to see more. It remains an early-stage proof of concept, but the reception has been encouraging.

Youth sailing is thrilling, but it is almost impossible to follow from the beach or clubhouse. Once the fleet heads out to the race course, the boats become tiny specks on the water, and parents, coaches and race officials often can't see who is leading, where the action is, or how the race is unfolding. Unlike stadium sports, there is no easy vantage point — the racing happens spread across open water, sometimes kilometres from shore.

To follow a race up close, spectators and coaches have to head out in powerboats and chase the fleet around the course. This is costly, noisy and risky, it burns fuel, and it congests the race area with extra traffic. At a big regatta, dozens of chase boats and safety craft can crowd the course, which is neither safe nor pleasant — and most parents simply can't follow their child's race at all.

Phones are banned in dinghy racing. It comes down to safety, distraction and class rules — a sailor focused on a screen isn't focused on the boat, and a phone is easily lost overboard in a capsize. Because commercial trackers rely on either a SIM card or a Bluetooth pairing to a phone, they don't fit the reality of youth dinghy racing where phones can't be on board.

SIM-based trackers carry ongoing costs — typically NZ$30 or more per month per unit for data — which quickly becomes unaffordable across a whole fleet. They also depend on a phone or cellular connection being present on the boat, which isn't allowed in racing. Sail Race Tracker was designed to be SIM-free precisely to avoid these contracts, running costs and rule conflicts.

Commercial sailing trackers cost roughly NZ$500–900 (or €400–500) per unit, plus subscriptions of $30 or more per month for data. A major regatta can have 100–200 dinghies on one course, so kitting out a 200-boat fleet with commercial gear would cost over NZ$180,000 in equipment alone — before any ongoing data charges. That price is far out of reach for clubs, schools and youth sailing programmes.

Professional events such as the America's Cup (AC75) and SailGP use impressive GPS overlays and augmented-reality graphics, but those systems are expensive, custom-engineered and built for elite racing. They are simply not suitable — or affordable — for club, school and youth use. Sail Race Tracker aims to bring that same America's-Cup-style live fleet view to youth regattas for a tiny fraction of the cost.

Products like RaceQs, TracTrac, Yellowbrick, Sailmon MAX and WAIV do exist, but each costs roughly NZ$500–900 per unit plus monthly subscriptions, and all rely on a SIM card or a Bluetooth phone pairing. That makes them too expensive to deploy across a whole youth fleet and incompatible with the no-phones rule of dinghy racing. None of them is built for cheap, waterproof, SIM-free, fleet-wide tracking of youth dinghies.

No — that is the gap Sail Race Tracker exists to fill. There is no existing product offering real-time, waterproof, affordable, SIM-free GPS tracking for dinghy fleets, and there are no New Zealand companies offering it. Every option on the market is either too expensive, dependent on a SIM or phone, or built for professional rather than youth and club racing.

The market splits into two extremes: cheap consumer GPS that needs a phone or SIM, and expensive professional systems built for elite events. Nothing sits in the middle for youth and club dinghy racing — affordable, waterproof, SIM-free tracking that can scale from a five-boat training session to a 200-boat regatta. Sail Race Tracker was designed specifically to fill that gap, with a target production cost of under NZ$50 per unit.

Sail Race Tracker targets a production cost of under NZ$50 per unit, compared with NZ$500–900 (or €400–500) for commercial systems. It achieves this by using low-cost off-the-shelf parts — an ESP32 board, a u-blox GPS module and a LoRa radio — and by being SIM-free, so there are no subscriptions, data plans or contracts. The result is near-zero running cost after the initial build.

Chase boats and spectator powerboats burn fuel, create noise, and crowd the water every time they follow a race. If parents and coaches can watch the whole race live from shore on a phone or tablet, there is far less need to take a powerboat out at all. That means lower fuel use, less on-water congestion and a safer, quieter race course.

Yes. A live full-fleet view lets race officials quickly locate distressed, capsized or drifting boats, which supports faster response and can reduce the number of safety powerboats needed on the water. Fewer chase and safety boats crowding the course also lowers the risk of collisions and congestion. Better visibility from shore means better oversight of everyone racing.

There are thousands of youth sailors in New Zealand across classes like the Optimist, Starling, 29er, ILCA and iQFOiL, and most clubs and schools can't justify the cost of professional tracking gear. An affordable, SIM-free system means live tracking, replays and coaching feedback become accessible to ordinary clubs, squads and families — not just elite programmes. It helps more young sailors learn faster and lets more parents actually follow their kids' racing.

Without objective data, sailors and coaches rely on memory and guesswork to work out where a race was won or lost. A full GPS replay shows exactly where time was gained or lost — at the start, on laylines, or through wind shifts — so sailors learn tactics faster from objective feedback. Coaches can replay whole sessions, compare sailors side by side and run evidence-based debriefs.

Four groups benefit. Sailors get objective replays to learn from; race officials get a live full-fleet view for safety, fairer starts and finishes, and positional logs for protests; coaches get session replays and side-by-side comparisons for evidence-based debriefs; and spectators — especially parents — can finally follow every boat live from the clubhouse or their phone. Everyone connected to youth racing gets to see the whole race, from the shore.

Each dinghy carries a small waterproof tracker that reads its GPS position and broadcasts it over a LoRa radio. A gateway node on the support or committee boat picks up those signals and passes them by USB to a Raspberry Pi, which parses the packets and stores them in a database. A web server then serves that data to a live map in any browser, where boats appear as coloured markers with trails. In short, the path is boat → LoRa radio → support-boat gateway → Raspberry Pi → database → web dashboard.

The system has four main parts. First, the boat trackers — a microcontroller, GPS module, LoRa radio and battery in a waterproof box on each dinghy's mast. Second, the gateway — a LoRa receiver on the support boat that collects every boat's signal. Third, the Raspberry Pi, which acts as the brain that decodes, stores and serves the data. Fourth, the dashboard — a browser-based live map that anyone on shore can open on a phone, tablet or laptop.

The boat tracker is a self-contained waterproof unit mounted on the dinghy's mast. It contains an ESP32 microcontroller, a u-blox NEO-M8N GPS module, a LoRa radio and a lithium battery, sized to last a full race day. Its job is simple: read the boat's GPS position and broadcast it over LoRa radio every few seconds. It needs no SIM card, no phone and no internet connection of its own.

The gateway is a LoRa receiver — a TTGO LoRa32 board — that sits on the support or committee boat and listens for the GPS signals coming off every dinghy in the fleet. It is the bridge between the radio world and the digital world: it takes the tiny LoRa packets arriving over the air and hands them, by USB, to the Raspberry Pi for processing. Placing it on the support boat, with an elevated antenna, gives it a clear line of sight across the whole race course.

The Raspberry Pi 4 is the brain of the on-water setup. It receives the raw LoRa packets from the gateway over USB, decodes each boat's position, and stores it in a database with fields like boat ID, latitude, longitude, battery level and timestamp. It also runs the web server that turns that stored data into a live map. Because it is a full Linux computer, one Pi can handle collecting, storing and serving all the fleet's data at once.

Once the Raspberry Pi has decoded and stored each boat's position, a small web API on the Pi serves that data as JSON to a Leaflet.js map running in the viewer's browser. The map draws each boat as a coloured, rotating marker with a trail, updating as new fixes arrive. In the 2025 proof of concept the Pi reached the internet through a phone hotspot on the support boat, so spectators on shore could load the map on their own devices. The person watching only needs a normal web browser — no app to install.

No. The dinghies never touch the internet. Each boat only broadcasts its GPS position over LoRa radio, which is a free, licence-free band that needs no SIM card, no mobile signal and no towers. The only internet connection in the whole system is at the support boat, where the gateway and Raspberry Pi send the collected data up to the cloud so shore viewers can see it.

Because the boats talk over LoRa radio instead of cellular. LoRa is a long-range, low-power radio that works on a free ISM band (915 MHz in New Zealand), so there are no SIM cards, no data plans and no monthly fees for the trackers. This matters for youth sailing because phones are banned in dinghy racing, and commercial trackers that rely on a SIM or a paired phone simply aren't allowed on the water. It also keeps the running cost near zero.

The race course itself runs entirely on radio, not the internet. Each boat broadcasts over LoRa, and the gateway on the support boat collects every signal locally, so the whole fleet can be tracked even with no mobile coverage at all. Internet is only needed at the single point where the support boat pushes data to the cloud — typically via a phone hotspot — and even without that, the Raspberry Pi still logs every position for later replay. This was proven in the field: Day 2 of the July 2025 trials tracked boats live with no internet.

There is a slight buffered delay of roughly 30 to 60 seconds between a boat moving and its updated position showing on the dashboard. This comes from the steps the data passes through — radio transmission, gateway collection, decoding on the Pi, and pushing to the browser. For spectators, coaches and parents watching from shore this delay is completely fine, because they are following the shape of the race rather than needing millisecond-perfect positions.

It is near-live rather than instant. Positions flow continuously from the boats through the gateway and Pi to the browser, refreshing as new GPS fixes arrive, but with a small buffered delay of around 30 to 60 seconds built into the pipeline. That trade-off keeps the system simple and reliable while still giving a genuine, moving picture of the whole fleet — which is exactly what shore-based spectators and coaches want.

The Raspberry Pi runs Raspberry Pi OS in headless mode, managed over SSH. On top of that it runs a Mosquitto MQTT broker and a Python listener that catch the incoming LoRa packets, a SQLite database to store each position, and a Flask web API to serve the data as JSON. The map itself is drawn in the browser using Leaflet.js with OpenStreetMap tiles. This whole open-source stack was chosen to be lightweight, free and easy to run on a single small computer.

The 2025 proof of concept was built on Meshtastic firmware. Each dinghy ran Meshtastic and broadcast its GPS over a self-healing LoRa mesh; positions hopped across the mesh to a gateway node, which fed a Raspberry Pi running Mosquitto MQTT, a Python listener, SQLite and a Flask API. That data was then drawn on a Leaflet.js map. It proved the full boat-to-browser chain worked end-to-end, and was field-tested over three days at Royal Akarana Yacht Club in July 2025.

The 2025 flow used ready-made Meshtastic firmware and a LoRa mesh feeding a Raspberry Pi with a local SQLite database and a Flask map — perfect for proving the concept. The 2026 rebuild replaces Meshtastic with custom ESP32 firmware, adds a base node running TDMA time-slot scheduling, and sends the data up to a proper cloud backend on Cloudflare that fans live positions out over WebSockets to public and admin dashboards. At a system level, the pipeline is the same shape — boat to gateway to Pi to cloud to browser — but the rebuild makes each stage more controlled, continuous and scalable.

The proof-of-concept architecture worked end-to-end, but Meshtastic became the bottleneck. Meshtastic's message scheduling and mesh optimisation throttle how often GPS data is sent, so the position data came through sporadic and gappy rather than as a smooth, time-stamped trail. This is a software limitation, not a hardware one — the boats, radios and Pi were fine. The 2026 rebuild introduces custom firmware precisely to fix this and produce continuous, time-stamped tracks.

In 2025 each boat ran Meshtastic, which simply broadcast the current position and left the mesh to schedule delivery. In the 2026 rebuild, custom Arduino/PlatformIO firmware has each boat log its GPS with timestamps and send packaged historical fixes over a private LoRa channel, while a base node coordinates transmissions using TDMA time slots. The result is that the base can compile a complete, gap-free record of each boat's track rather than the sporadic snapshots Meshtastic produced.

In the rebuild, the Raspberry Pi gateway reads the base node over serial and POSTs each fix up to a cloud backend built on a Cloudflare Worker using the Hono framework, backed by a D1 (SQLite) database. A Durable Object called "RaceRoom" then fans those live fixes out to viewers over WebSockets. The Pi also keeps a local store with retry and dead-letter handling, so fixes aren't lost if the connection drops. This end-to-end path was verified with a real Auckland GPS fix.

In the 2026 rebuild there are two dashboards, both hosted on Cloudflare Pages. The public viewer offers a race picker, live WebSocket tracking, a replay scrubber at 2×, 5×, 15× and 30× speeds, a leg-detection leaderboard and a wind-from-course dial. A separate key-gated admin dashboard adds fleet management with TDMA slots, a click-to-drop course builder, race control, a live node-health monitor and an audit log. Together they let spectators simply watch, while officials and coaches configure and run the race.

Each boat tracker is a small waterproof package built from off-the-shelf parts: an ESP32-based microcontroller board with a built-in LoRa radio, a GPS module, a 3.7V lithium battery, and (on most boards) a tiny OLED screen for diagnostics. In the 2025 proof of concept it ran Meshtastic firmware and broadcast its GPS position every 5–10 seconds over LoRa at 915 MHz. The whole lot sits inside an IP67-rated ABS enclosure clamped to the dinghy's mast. It's designed to work with no SIM card and no internet on the boat.

Sail Race Tracker is built around the ESP32, a low-cost, widely supported microcontroller that combines processing, Wi-Fi and Bluetooth in one cheap chip. Rather than a bare ESP32, the project uses ESP32-based development boards that already have a LoRa radio (and often an OLED) integrated, which keeps wiring and cost down. The main board used in the 2025 build is the TTGO LoRa32, and the 2026 rebuild adds a Seeed XIAO ESP32-S3 as an ultra-compact option. The ESP32 was chosen because it's affordable, well documented, and works with both Meshtastic and custom Arduino/PlatformIO firmware.

The primary boat board is the TTGO LoRa32 V1.6, an ESP32 development board with a built-in 915 MHz LoRa radio and a small OLED screen, costing roughly NZ$25–30. It doesn't have onboard GPS, so an external u-blox NEO-M8N module is wired to it over UART. The Heltec HTIT tracker was also used on boats during the field trials as an all-in-one board with built-in GNSS and display. Both are cheap prototyping boards rather than a finished custom device.

I compared several ESP32/LoRa development boards early on: the TTGO LoRa32 (V1.0 and V2.1.6), the Heltec HTIT LoRa V3, the TTGO T-Beam, and the commercial SenseCAP T1000-E. He also looked at the RAK3172/WisBlock modular system and an Adafruit Feather M0 + LoRa, but rejected both — RAK had a steep learning curve and no out-of-the-box Meshtastic support, and the Feather would have needed a custom GPS and power stack. The TTGO LoRa32 ended up as the workhorse because it gave the most flexibility, the best community support, and the lowest cost.

The TTGO LoRa32 won out because it's extremely cheap (about NZ$25–30), has a built-in LoRa radio and OLED, is very widely used in the Meshtastic community, and is easy to customise through PlatformIO or Meshtastic firmware. Its main downside is no onboard GPS, which meant wiring an external NEO-M8N module over UART — but that also let me pick a more capable GPS and a better antenna than a fixed built-in one. It's used both as the boat tracker (Board #2) and as the support-boat gateway node (Board #1). It offered the best balance of flexibility, price and support of all the boards tested.

The Heltec HTIT LoRa V3 is an ESP32/LoRa development board very similar to the TTGO but with a built-in GNSS (GPS) receiver and OLED display, so it needs no external GPS wiring. I ran HTIT nodes on race boats during the July 2025 field trials, and found the built-in screen genuinely useful for on-the-spot diagnostics. Its downsides were a slightly different pin layout and firmware, some Meshtastic compatibility differences versus the TTGO, and the fact that it's less common in sailing builds. It proved a solid, easy option, just less flexible on the GPS side than the TTGO-plus-NEO-M8N combination.

The SenseCAP T1000-E is a sleek, sealed, USB-C rechargeable commercial GPS+LoRa tracker that runs Meshtastic — genuinely the best-value all-in-one device of its kind. But it's wrong for sailing on several counts: it is NOT waterproof (there's a small hole in the built-in speaker that would let water in and kill it if submerged), it has a very small battery that won't last a full race day, and its tiny internal LoRa antenna limits range. Most importantly it has no USB port to re-flash the core firmware, so you can only change the handful of settings the Meshtastic app allows — and Sail Race Tracker needs far more control than that. For those reasons it was used only as a plug-and-play proof-of-concept and demo unit, not a development or final-product board.

The TTGO T-Beam was attractive because it packs an onboard u-blox NEO-6M GPS and a built-in battery connector and charging IC, so it's an all-in-one design with fewer cables to waterproof. The catches were a higher cost (around NZ$50), a larger size, limited spare GPIO pins for future expansion, and a fixed built-in GPS that's harder to swap if you'd prefer a different module. Because the cheaper TTGO LoRa32 gave more flexibility — and the NEO-M8N is a better GPS than the T-Beam's NEO-6M — the plain LoRa32 was preferred for the main build.

Most of the boards used — the TTGO LoRa32 and the Heltec HTIT — have a small built-in OLED display. On the boat these screens are handy for diagnostics: confirming the board has powered up, got a GPS fix, and is transmitting, without needing a laptop. I found the Heltec's screen especially useful for debugging during setup. Looking further ahead, the roadmap imagines an on-device screen showing sailors things like a start countdown or recall/OCS flags.

On the TTGO LoRa32, the external u-blox NEO-M8N GPS is connected over UART (a simple serial link) using four connections. The GPS TX (transmit) goes to the ESP32's RX (receive) pin on GPIO34, the GPS RX goes to the ESP32's TX on GPIO12, and VCC and GND supply 3.3V power and ground. I had to research the correct pins and then solder header pins onto the board to make the connection. The GPS can be powered directly from the TTGO's 3.3V rail.

In the 2025 build the GPS module connects to the TTGO's UART using GPIO34 for receive (RX, taking the GPS's TX line) and GPIO12 for transmit (TX, going to the GPS's RX line), plus a 3.3V and ground connection. In the 2026 rebuild, boat 1's config was changed to run the GPS as receive-only — setting gps_tx to -1 and gps_rx to 34 — to fix a GPS reliability bug. Getting these pin settings right in the firmware config is essential, as any board with an external GPS module also needs its GPS TX/RX pins configured in software.

Yes, some assembly and soldering was required for the DIY option. The TTGO LoRa32 needed a power supply connected and the external NEO-M8N GPS module soldered on using GPIO connection pins, which meant researching the correct pins first and then soldering the headers. The all-in-one boards — the Heltec HTIT and the SenseCAP — needed no GPS wiring, just unboxing and a power supply (the HTIT), so the DIY TTGO route was the most hands-on to build. It's very much a maker-style prototype rather than a slick manufactured product.

Development boards like the TTGO LoRa32 and Heltec HTIT are cheap, readily available, and let me test and iterate quickly without designing custom hardware — perfect for a proof of concept. They do mean combining several separate parts and manually flashing each one, which adds fiddliness, but they proved the whole system works end to end. The long-term goal is a purpose-built PCB that puts the ESP32, NEO-M8 GPS and LoRa (plus optional Bluetooth, a gyro/accelerometer and a small OLED) on a single board, fabricated cheaply through a service like JLCPCB or PCBWay. That custom board would cut cost, size and weight further, but dev boards were the right choice to get to a working prototype first.

The target is to produce each boat tracker for under NZ$50 — a fraction of the roughly NZ$500–900 (or €400–500) that commercial sailing trackers cost, and with no SIM or subscription so near-zero running cost. The main parts are inexpensive: a TTGO LoRa32 at about NZ$25–30, a NEO-M8N GPS at about NZ$15–20, plus a lithium battery, an IP67 box, and a 3D-printed mast mount. A single Raspberry Pi gateway is shared across the whole fleet, so its cost spreads across many boats. A future custom PCB would push the per-unit price down even further.

The Seeed Studio XIAO ESP32-S3 is a very small ESP32-S3 board that I wanted as an ultra-compact GPS node. In the 2025 Meshtastic phase I had to reject it — it was missing a second UART, had no GPS breakout pins, and wasn't compatible with Meshtastic firmware. But the 2026 rebuild replaces Meshtastic with custom Arduino/PlatformIO firmware, which sidesteps those limitations, so the XIAO ESP32-S3 paired with a Wio-SX1262 LoRa radio is now one of the two board options being developed alongside the LilyGo/TTGO LoRa32. Its small size makes it a good candidate for a future compact tracker.

A few boards were bought or considered and then dropped. The TinyLoRa FeatherWing (Adafruit) and the ESP32-CAM were ruled out mainly because they weren't natively supported by Meshtastic — and the ESP32-CAM also isn't waterproof and lacks a practical LoRa antenna. The RAK3172/WisBlock and Adafruit Feather M0 + LoRa were passed over for a steep learning curve and the need to build a custom GPS and power stack. And the XIAO ESP32-S3 was excluded in 2025 for missing a second UART, GPS breakout pins and Meshtastic support — though it makes a comeback in the 2026 custom-firmware rebuild.

Each device in the system is given a clear label and a defined role so it's easy to tell them apart during setup and testing. Examples from my logbook include NODE-HTIT for the Heltec HTIT tracker, NODE-TTGO-GPS for the TTGO board with an external GPS, and NODE-TTGO-GATEWAY for the TTGO acting as the support-boat gateway. The SenseCAP and Raspberry Pi are labelled and tracked the same way. Labelling and role assignment matter because a working race needs each node to know its job and each boat to be reliably identified on the dashboard.

Each tracker runs off a 3.7V lithium battery — either an 18650 Li-ion cell or a LiPo pack — sized to last a full race day of 8+ hours, with USB-C recharging overnight. The 18650 cells are cheap, rechargeable and supported by the TTGO and T-Beam boards, though they need external holders and protection circuitry. During the July 2025 water trials the battery comfortably lasted a whole day and recharged overnight. Some boards, like the T-Beam, include their own battery connector and charging circuit.

Yes — the u-blox NEO-M8N used on the trackers gives around 2.5m accuracy with a fast fix, which is plenty for tactical analysis in dinghy racing. My reasoning is that relative consistency across the whole fleet matters more than absolute pinpoint accuracy: 2–5m is fine for seeing who's ahead, how starts and laylines played out, and where time was gained or lost. Centimetre-accurate RTK GPS was rejected as far too expensive (NZ$100–200+ per unit plus a base station), and the cheaper, slower NEO-6M was rejected for slower fixes and lower sensitivity in fast-moving boats. The NEO-M8N hit the sweet spot of accuracy, speed and cost (about NZ$15–20).

No — the boat trackers are a working, field-tested proof of concept built from prototyping development boards, not a commercial product. They successfully tracked boats end to end during the RAYC trials in July 2025, but they're assembled from separate off-the-shelf parts (ESP32 dev board, external GPS, battery, enclosure, 3D-printed mount) that each need flashing and configuring by hand. The 2026 rebuild is moving toward production with custom firmware and, eventually, a purpose-built PCB. For now they're deliberately maker-grade: cheap, open, and good enough to prove the whole idea works.

LoRa stands for "Long Range" radio. It is a sub-gigahertz wireless technology designed to send tiny data packets over long distances while using very little power. In New Zealand, Sail Race Tracker uses LoRa on the 915 MHz band. It is ideal for sending small GPS position updates from sailing dinghies, though it is not suited to high-bandwidth data like video.

LoRa was chosen because it needs no SIM card, no mobile towers, and no data contracts, which keeps running costs near zero. Cellular tracking was rejected because it adds ongoing SIM and data costs, and because phones are banned in dinghy racing for safety and class-rule reasons. LoRa uses the free ISM radio band, so once a tracker is built there are no monthly fees. This is a core part of how the system stays SIM-free and affordable.

Each of those alternatives falls short for on-water dinghy tracking. Wi-Fi only reaches around 50 metres, far too short for a race course. Satellite is too slow and too expensive, and Bluetooth has an even shorter range than Wi-Fi. LoRa was the only option that met every goal: long range, low power, low cost, and no SIM or subscription.

In open environments, LoRa can reach roughly 2 to 10 km. It works especially well over open water because there are very few obstacles to block the signal. This makes it well suited to sailing race courses, where boats spread out across an open bay. Raising the gateway antenna higher on the support boat improves coverage further.

The 915 MHz band is a sub-gigahertz ISM (Industrial, Scientific and Medical) radio band that is free to use and legal in New Zealand. Sail Race Tracker broadcasts its LoRa GPS updates on this band, which means no licence, no SIM, and no towers are required. Because it is a lower frequency, it also travels well over long distances and open water. Using a legal, free band keeps the system compliant and cost-free to operate.

LoRa sends only tiny data packets, but a GPS position is very small, so the low bandwidth is plenty. Each tracker only needs to send a node ID, latitude, longitude, battery level, and a timestamp. This suits LoRa perfectly, whereas the same technology would be useless for streaming video. For following a fleet of boats, small frequent position packets are exactly what is needed.

Low power draw is important because each tracker has to last a full race day of 8 or more hours on a single battery. LoRa's efficiency means the radio uses very little energy while still sending positions over long distances. Combined with a 3.7V lithium battery and USB-C charging, this lets a tracker run all day and recharge overnight. Long battery life is one of the key design requirements for the system.

A LoRa mesh network lets position packets "hop" from one node to another across the fleet, with the network self-healing if a link drops. In the 2025 proof-of-concept, each dinghy broadcast its GPS every 5 to 10 seconds, and positions hopped across the mesh until a gateway node on the support boat received them. This meant boats did not need a direct line to the gateway to be tracked. The mesh was provided by the Meshtastic firmware used at that stage.

In the 2025 proof-of-concept, each boat broadcast its GPS position roughly every 5 to 10 seconds over LoRa. On the website's tracker demo, GPS is sampled every 10 seconds. A short buffered delay of around 30 to 60 seconds is acceptable, because spectators watching from shore do not need instant updates. The goal is a smooth, followable picture of the fleet rather than split-second data.

Meshtastic is a great platform for a proof of concept, but its message scheduling and mesh optimisation throttle how often and how much GPS data can be sent. The result was sporadic, gappy position data rather than a smooth, time-stamped trail. This was a software limitation, not a fault of the LoRa hardware itself. It is the main reason the 2026 rebuild moves away from the Meshtastic mesh.

The Meshtastic mesh throttled GPS data and produced gappy tracks, so the 2026 rebuild replaces it with custom ESP32 firmware over a private LoRa channel. Instead of relying on the mesh, each boat logs time-stamped GPS and sends packaged historical fixes, letting the base compile a complete record. A base node runs TDMA (time-division multiple access) scheduling with a beacon, giving each boat its own time slot to avoid collisions. This is designed to deliver continuous, smooth, time-stamped tracks rather than sporadic points.

TDMA stands for time-division multiple access, a scheme where each boat is given its own time slot to transmit. In the 2026 rebuild, a base node runs TDMA time-slot scheduling with a beacon so that boats take turns sending over the private LoRa channel. This avoids the packet collisions and data throttling that limited the earlier Meshtastic mesh. The aim is reliable, orderly transmission that scales cleanly across a fleet.

Yes. The boats themselves need no internet and no SIM cards, because all the on-water communication happens over LoRa radio. Positions travel from boat to a gateway on the support boat entirely over LoRa. Only the gateway needs a connection to the cloud, which in the proof-of-concept came from a phone hotspot on the support boat. This is why the system can operate on race courses with no coverage.

The boat trackers keep their antennas inside the waterproof enclosure. Bench tests showed no meaningful LoRa or GPS signal loss through the clear plastic lid, so no holes had to be drilled. If an external antenna is ever needed, waterproof cable glands are available to add one. Keeping the antenna inside helps maintain the IP67 waterproof rating.

The support-boat gateway uses a vertical internal SMA LoRa antenna to maximise range. Mounting the antenna higher and more elevated on the support boat improves coverage across the race course. Because the support boat receives from the whole fleet, its antenna position matters more than any single tracker's. A better-placed gateway antenna means more boats stay in range.

LoRa itself proved reliable in field trials — during the July 2025 trials at Royal Akarana Yacht Club there were no packet collisions or data loss, and the gateway survived rain and spray. The main reliability issue was not the LoRa radio but the Meshtastic software sending too few data points, leaving gaps in the tracks. Officials from the NZIODA National Committee stressed that reliability is essential for race-official use, which is exactly why the 2026 rebuild focuses on smoother, more complete data over a custom LoRa channel. It remains a proof of concept, with the rebuild working toward the reliability needed for official use.

Sail Race Tracker uses the u-blox NEO-M8N GPS module on each boat tracker. It was chosen for its good accuracy (around 2.5m), fast fix, low cost (roughly NZ$15–20) and a 1Hz-plus update rate. The module connects to the tracker's ESP32 microcontroller (on a TTGO LoRa32 board) over a UART serial connection. It's a well-proven, affordable GNSS chip that suits a low-cost, open-source dinghy tracker.

The NEO-M8N module gives roughly 2.5m accuracy in typical conditions. For sailing tactics that's plenty — knowing a boat's position to within a couple of metres is enough to see starts, laylines, mark roundings and where time was gained or lost. Sail Race Tracker deliberately prioritises relative consistency across the fleet over pinpoint absolute accuracy, because 2–5m is more than good enough for coaching and race analysis.

In fleet racing, what matters most is where boats sit relative to each other and to the course marks, not their exact latitude and longitude to the centimetre. If every tracker uses the same GPS module and shares the same small error, the fleet map stays consistent and tactically useful. That's why Sail Race Tracker treats 2–5m accuracy as ample — the picture of the race stays true even if every boat is off by a similar small amount.

The older u-blox NEO-6M is cheaper but slower, with a slower fix and lower update rate. Sail Race Tracker chose the NEO-M8N instead because it delivers faster fixes, better accuracy (around 2.5m) and a 1Hz-plus update rate for a still-modest cost of about NZ$15–20. For a tracker that has to re-acquire position quickly after capsizes and keep up with a moving fleet, that extra performance is worth the small price difference.

No — Sail Race Tracker deliberately avoided RTK GPS. RTK (real-time kinematic) can achieve centimetre-level accuracy, but it costs NZ$100–200 or more per unit and needs a separate base station, which breaks the project's under-NZ$50-per-unit target. For youth dinghy racing, 2–5m accuracy from the NEO-M8N is plenty for tactics, so the far cheaper module was the sensible choice.

RTK GPS was rejected because it's expensive and complex for the accuracy this project actually needs. It runs NZ$100–200-plus per unit and requires a base station to work, whereas Sail Race Tracker aims to keep each tracker under NZ$50. Centimetre precision simply isn't necessary for reviewing dinghy races — relative consistency across the fleet at 2–5m matters more, so the NEO-M8N was chosen instead.

In the 2025 proof-of-concept, each boat broadcasts its GPS position every 5–10 seconds over LoRa. The on-site tracker demo on sailracetracker.live samples GPS every 10 seconds. The NEO-M8N itself can update faster (1Hz or more), but the transmit interval is kept modest to suit LoRa's low bandwidth and to conserve battery over a full race day.

The NEO-M8N connects to the ESP32 microcontroller over a UART serial link. On the proof-of-concept wiring, the GPS TX pin goes to the ESP32 RX (GPIO34) and the GPS RX pin goes to the ESP32 TX (GPIO12), with VCC on 3.3V and a shared ground. This is a standard, simple serial connection that keeps the hardware low-cost and easy to assemble.

During the July 2025 field trials at Royal Akarana Yacht Club, trackers re-acquired a GPS fix within about 30–60 seconds after a capsize. Dinghies capsize frequently, so fast reacquisition is important, and the NEO-M8N's quick fix handled it well. The trackers survived the capsizes and full submersion and kept transmitting once back upright.

Yes. The tracker sits in an off-the-shelf IP67-rated ABS enclosure with a clear lid, and it's designed to survive frequent capsizes and full submersion — routine for dinghy sailing. In the July 2025 water trials the units came through repeated capsizes and re-fixed their GPS within 30–60 seconds. Waterproofing and fast fix reacquisition were treated as essential design requirements from the start.

No meaningful loss was found. The GPS and LoRa antennas are kept inside the clear-lidded IP67 ABS box, and bench tests showed no significant signal loss through the plastic, so no holes were drilled in the case. Keeping the antennas sealed inside helps waterproofing. Waterproof cable glands are available if an external antenna is ever needed later.

Each GPS fix is a timestamped latitude and longitude, stored with the boat's ID and other data (in a SQLite database in the proof-of-concept). On the web dashboard, these positions are drawn as coloured progressive trails on a Leaflet.js map, with an SVG boat arrow rotated to the boat's heading. Played back in sequence, the fixes form the race track you see, including live positions and full race replay.

The Tracker Demo's leaderboard uses leg detection based on the boat's position relative to the course marks. A boat is counted as advancing to the next leg when it comes within about 85m of the next mark, and heading is de-jittered over an 8m threshold to avoid false readings from small GPS wobble. This lets the dashboard sort boats live and show who's ahead around the course.

The u-blox NEO-M8N supports a 1Hz-plus update rate and delivers a fast fix, which is one of the main reasons it was chosen. In practice, Sail Race Tracker transmits positions every 5–10 seconds (and samples every 10 seconds in the on-site demo) rather than at the module's full rate, because LoRa has low bandwidth and battery life over a full race day matters. The module's headroom means fixes are current and reacquire quickly when needed.

Yes — during the 2026 rebuild a GPS reading issue on one boat was traced to the serial wiring configuration. The fix was to set that boat's GPS to RX-only by configuring gps_tx to -1 while keeping gps_rx on GPIO34, so the ESP32 only listens to the GPS module rather than trying to transmit to it. After that change the GPS read correctly. It's a good example of the kind of low-level debugging behind getting reliable position data.

The support boat gateway is the piece of Sail Race Tracker that collects GPS positions from the whole fleet and forwards them to the cloud. It rides on the support or committee boat and is made up of a TTGO LoRa32 v1.6 gateway node running Meshtastic connected to a Raspberry Pi 4, housed in a waterproof utility case. Every dinghy broadcasts its position over LoRa radio, those packets hop across a self-healing mesh, and the gateway node is where they land. From there the Pi parses the data and sends it onward so spectators, coaches and race officials can watch the race live from shore.

The support or committee boat is the one boat in the fleet that carries the gateway, so it acts as the fleet's live link to the outside world. While the racing dinghies simply log and broadcast their own GPS positions, the support boat gathers everyone's data in one place and pushes it up to the cloud. This is a natural fit because a committee or support boat is already on the water at every regatta, and it means the individual boat trackers can stay small, cheap and completely SIM-free.

The support boat gateway is built from a TTGO LoRa32 v1.6 node running Meshtastic firmware, paired with a Raspberry Pi 4, both kept in a waterproof utility case. It also carries a 10,000mAh USB power bank rated at 5V/3A for all-day power, and a vertical internal SMA LoRa antenna to improve range. The TTGO node handles the LoRa radio side, receiving positions from the fleet, and the Pi does the heavy lifting of parsing, storing and forwarding the data.

The TTGO LoRa32 v1.6 is an ESP32-based development board with an onboard LoRa radio, and on the support boat it runs Meshtastic firmware as the gateway node. Its job is to listen for the GPS position packets that the racing boats broadcast over LoRa at 915 MHz and receive them off the mesh. It then passes those packets to the Raspberry Pi 4 by USB, where they are turned into usable data. The same board is used on the individual boats too, which keeps the whole system consistent and affordable at roughly NZ$25 to NZ$30 per board.

The Raspberry Pi 4 was chosen as the gateway because it is a full little Linux computer that can run the whole receiving stack in one place. On the Pi, a Mosquitto MQTT broker and a Python listener parse the LoRa packets, the data is stored in a SQLite database, and a Flask API serves it out as JSON to the web map. It runs headless over SSH with a Python virtual environment, so no screen or keyboard is needed on the boat. Because one Pi is shared across the entire fleet, its cost is spread thinly and does not affect the under-NZ$50-per-boat target for the trackers themselves.

The Raspberry Pi 4 suits the gateway role because it comfortably runs the full software stack the system needs, all on one low-cost, low-power board. It can host the Mosquitto MQTT broker, the Python packet listener, the SQLite database and the Flask API together, which a simple microcontroller could not manage. It is also easy to develop for and shared across the whole fleet, so a single Pi serves every boat at a regatta rather than needing one per tracker.

The TTGO LoRa32 gateway node connects to the Raspberry Pi 4 over a plain USB serial link. The TTGO handles the LoRa side, receiving the fleet's GPS packets over the 915 MHz radio mesh, and then streams them to the Pi through USB. On the Pi, a Mosquitto MQTT broker and a Python listener read that serial data and parse it into position records. This simple USB connection keeps the two halves of the gateway cleanly separated: radio on the TTGO, computing on the Pi.

The gateway is powered by a 10,000mAh USB power bank rated at 5V/3A, which is enough to keep the Raspberry Pi 4 and the TTGO node running all day. This external power was an important lesson from the field trials at Royal Akarana Yacht Club: on Day 3 the cloud connection ran through a coach's iPhone hotspot, and the iPhone's own battery went flat before the day was out. Having a dedicated power bank for the gateway means the system is not left relying on a phone's battery to last a full race day.

The gateway uses a vertical internal SMA LoRa antenna to receive the fleet's position broadcasts. Keeping the antenna vertical and mounting it higher or more elevated on the support boat improves coverage and range, because LoRa works best with a clear line of sight. Over open water there are very few obstacles, which already helps LoRa reach up to 2 to 10 km, and raising the antenna makes the most of that. Better antenna placement means fewer dropped packets and more reliable tracking right across a big course.

The data reaches the cloud through a phone hotspot on the support boat. Once the Raspberry Pi 4 has received and parsed the fleet's positions from the TTGO gateway node, it needs an internet connection to send that data onward, and a phone hotspot provides it. This keeps the racing dinghies themselves completely SIM-free and internet-free; only the one support boat needs connectivity. During the 2025 field trials this was done via a coach's iPhone hotspot, and it worked, though it confirmed the need for external power so the phone does not go flat mid-day.

No. Only the support boat's gateway ever touches the internet, and it does so through a phone hotspot rather than a SIM card in each tracker. The racing dinghies simply broadcast their GPS positions over LoRa radio, which uses the free 915 MHz ISM band with no towers, no contracts and no data plans. This SIM-free design is central to the project, both because it keeps running costs near zero and because phones are banned in dinghy racing, so a system that depended on a phone in every boat would never be allowed.

Yes. The TTGO LoRa32 gateway node and the Raspberry Pi 4 are housed together in a waterproof utility case so they can cope with life on a support boat. During the Day 3 field trial at Royal Akarana Yacht Club, the gateway survived rain and spray while continuing to log the fleet, which showed the enclosure does its job in real conditions. Keeping the electronics sealed matters because a committee or support boat is exposed to the same weather and spray as the racing fleet.

There is only a slight buffered delay, roughly 30 to 60 seconds, between a boat's real position and what appears on the live map. This is fine for spectators, coaches and officials watching from shore, who are following the shape of the race rather than needing split-second accuracy. The delay comes from positions hopping across the LoRa mesh to the gateway, being parsed on the Pi and then sent up through the hotspot to the cloud before the web dashboard displays them.

The gateway sits right in the middle of the data flow: boat to LoRa radio to support-boat gateway to Raspberry Pi to database to web dashboard. Each dinghy broadcasts its GPS position over LoRa every 5 to 10 seconds, those positions hop across the self-healing mesh, and the TTGO gateway node on the support boat receives them. It hands them to the Pi 4 over USB, where they are parsed by MQTT and Python, stored in SQLite, and served out by a Flask API to a Leaflet.js map. The gateway is the crucial bridge that turns dozens of separate radio broadcasts into one live picture of the whole race.

In the 2025 proof-of-concept, race data was stored in a SQLite database running on a Raspberry Pi 4 aboard the support boat. Each position record held a set of simple fields: node_id, short_name, latitude, longitude, battery_level and timestamp. In the 2026 rebuild, storage moves to the cloud using Cloudflare D1, which is itself a SQLite database, with the Pi gateway keeping a local store as a backup. Both eras deliberately use lightweight SQLite rather than a heavy database, keeping the system cheap and easy to run.

The backend has evolved through two eras. The 2025 proof-of-concept ran entirely on a Raspberry Pi 4 on the support boat: a Mosquitto MQTT broker received LoRa packets, a Python listener parsed them, a SQLite database stored the positions, and a Flask API served the data as JSON to the web map. The 2026 rebuild moves the backend to the cloud, using a Cloudflare Worker built with the Hono framework, a D1 database, and a Durable Object that streams live positions over WebSockets. The shift takes the system from a single on-boat computer to a scalable cloud service.

MQTT (Message Queuing Telemetry Transport) is a lightweight messaging system designed for small devices sending tiny bits of data, like sensor or GPS readings. It works on a publish-and-subscribe model: devices publish messages to named "topics", and other programs subscribe to those topics to receive them. In the 2025 setup, a Mosquitto MQTT broker ran on the Raspberry Pi on port 1883, receiving Meshtastic position packets on topics like meshtastic/+/position, which a Python listener then subscribed to and processed. MQTT was a natural fit because it is efficient, reliable, and built exactly for streaming lots of small position updates.

The 2025 Python listener was a small program on the Raspberry Pi that subscribed to the Mosquitto MQTT broker using the paho-mqtt library. When a boat's GPS position arrived over the LoRa mesh and was published to an MQTT topic such as meshtastic/+/position, the listener parsed the packet and pulled out the useful fields. It then wrote each fix into the SQLite database as a row containing node_id, short_name, latitude, longitude, battery_level and timestamp. In effect it was the bridge between the raw radio packets and the structured database the web map read from.

Flask is a lightweight Python web framework, and in the 2025 proof-of-concept a Flask API ran on the Raspberry Pi to serve the stored race data. It read positions out of the SQLite database and returned them as JSON, which the Leaflet.js web map fetched to draw live boat markers, trails and race replays. Because it output clean JSON, any browser on a phone, tablet or laptop could load the dashboard from shore. It was a simple, self-contained way to turn the on-boat database into a live web map.

The 2026 rebuild uses Cloudflare as its cloud backend. At its heart is a Cloudflare Worker written with the Hono framework, which handles incoming data and API requests. It is paired with a Cloudflare D1 database (a SQLite database in the cloud) for persistent storage, and a Durable Object called "RaceRoom" that fans out live position fixes to connected viewers over WebSockets. This modern serverless stack replaces the single Raspberry Pi backend of the 2025 proof-of-concept.

A Cloudflare Worker is a small program that runs on Cloudflare's global edge network rather than on one physical server, so it is fast, scalable and low-cost. In the 2026 rebuild the Worker is built with Hono, a lightweight web framework, and it handles the system's API: receiving GPS fixes, serving current race data, and managing live connections. Moving to a Worker means the backend no longer depends on a single Raspberry Pi being online, and it can serve many spectators at once. It suits the project's ethos of keeping running costs low while allowing the system to scale up.

RaceRoom is a Cloudflare Durable Object used in the 2026 rebuild to handle live race data. A Durable Object is a special kind of Cloudflare component that holds state and coordinates real-time connections, which makes it ideal for a live race. RaceRoom takes incoming GPS fixes and "fans them out" to every connected viewer over WebSockets, so everyone watching from shore sees boats move almost instantly. It is the piece that turns stored positions into a smooth, live fleet map.

WebSockets are a technology that keeps a live, two-way connection open between a browser and a server, so new data can be pushed instantly instead of the browser having to keep asking for updates. In the 2026 rebuild, the RaceRoom Durable Object uses WebSockets to stream live GPS fixes to the public viewer dashboard as boats move around the course. This gives a smooth, real-time race map rather than the periodic refreshes of the earlier setup. Viewers connect to the WebSocket endpoint at /races/:id/live to follow a specific race.

The 2026 Cloudflare Worker exposes a small set of clear endpoints. POST /ingest is where the Raspberry Pi gateway sends new GPS fixes into the system. GET /race/current returns the race that is currently active, so a viewer can quickly pick up live tracking. WS /races/:id/live is the WebSocket endpoint that streams live position updates for a particular race to the viewer dashboard.

In the 2026 rebuild, the Raspberry Pi gateway runs a Python program that reads the base LoRa node over a serial (USB) connection. As GPS fixes come in from the boats, it packages them up and POSTs them to the cloud at the Worker's /ingest endpoint. To handle patchy connectivity on the water, the gateway keeps a local store with retry and dead-letter handling, so fixes are held and resent rather than lost if the connection drops. This makes the link between boat and cloud far more robust than the earlier setup.

The local store with retry is a reliability feature in the 2026 Raspberry Pi gateway software. Because the support boat's internet can be intermittent (it often relies on a phone hotspot), the gateway first saves incoming GPS fixes locally before trying to POST them to the cloud. If a send fails, it retries, and fixes that repeatedly cannot be delivered are moved to a "dead-letter" holding area for later handling. This means the system does not silently lose position data when the connection drops out on the water.

The 2025 proof-of-concept put everything on one Raspberry Pi on the support boat, which was perfect for proving the idea but limited for a real product. Its Meshtastic-based data flow also throttled how often GPS could be sent, causing gappy tracks. The 2026 rebuild moves storage and live streaming into a scalable Cloudflare cloud backend and pairs it with custom firmware for continuous, time-stamped GPS, so the system can grow from a small training squad to a 100–200-boat regatta. In short, the architecture evolved to become more reliable, scalable and closer to a production-ready service.

Yes. The 2025 proof-of-concept used a local SQLite database on the Raspberry Pi, and the 2026 rebuild uses Cloudflare D1, which is a SQLite database offered as a cloud service. So the underlying database technology stays consistent across both eras, even though it moves from a single on-boat device to the cloud. Keeping to SQLite fits the project's aim of a simple, low-cost and reliable system.

In the 2025 proof-of-concept, the Flask API served position data as JSON from the Pi's SQLite database, and the Leaflet.js web map read it to show live markers, with a slight buffered delay of about 30–60 seconds that is fine for spectators. In the 2026 rebuild, the RaceRoom Durable Object pushes live fixes to viewers over WebSockets in real time, giving a smoother and more immediate live map. Both approaches let anyone follow the fleet from shore in an ordinary browser, but the newer one is faster and built to scale.

In the 2025 SQLite schema, each position record stored node_id (which device sent it), short_name (a friendly label for the boat), latitude and longitude (the GPS position), battery_level (so you can see a tracker's remaining charge) and timestamp (when the fix was taken). Together these fields are enough to draw live markers, colour-coded trails and full race replays on the map. The 2026 rebuild carries the same core idea forward into its Cloudflare D1 database, with the addition of time-stamped fixes designed to build smooth, gap-free tracks.

Yes. Sail Race Tracker is an open-source, community-driven project, and that ethos runs through the backend as much as the hardware. The 2025 stack was built on widely used open tools such as Mosquitto, Python, SQLite, Flask and Leaflet.js, all of which are free and openly available. The 2026 rebuild uses Cloudflare's platform for the cloud, but the project's aim remains to keep the system affordable, transparent and accessible to clubs, schools and makers.

The core tracking on the boats works with no internet at all, because positions travel over LoRa radio to a gateway rather than over cellular. In the 2025 setup the Raspberry Pi could log all the data on the boat without any connection, and a phone hotspot was only needed to push the live view to the cloud. In the 2026 rebuild the gateway POSTs fixes to the cloud when it can, but its local store with retry means it holds and resends data if the connection drops. So the system keeps recording even when the internet is patchy on the water.

You watch the race in any web browser on your phone, tablet, or laptop, from the comfort of the shore or the clubhouse. The Tracker Demo shows a map with every boat on the course, moving in near real time as GPS positions arrive from the fleet. There is a slight buffered delay of around 30 to 60 seconds, which is perfectly fine for spectators. The tagline sums it up: "See the whole race. From the shore."

No. There is no app to install and nothing to download. The Tracker Demo is a web dashboard that opens straight in your browser, so it works on a phone, tablet, or laptop without any setup. That was a deliberate design choice to keep it simple and accessible for parents, coaches, and clubs.

The Tracker Demo is built with Leaflet.js, a lightweight open-source mapping library. The on-site tracker uses Leaflet version 1.9.4 with OpenStreetMap tiles. Leaflet was chosen because it is lightweight, offline-capable, and needs no API key, unlike the alternatives.

Leaflet.js was chosen because it is lightweight, offline-capable, and requires no API key. Google Maps was ruled out on cost, and Mapbox was ruled out for its complexity. For a low-cost, open-source project that needs to work reliably from a support boat or clubhouse, a simple key-free mapping library was the right fit.

The live map shows every boat's current position with coloured markers, drawn as SVG boat arrows rotated to match each boat's heading so you can see which way they are pointing. Each boat leaves a coloured progressive trail behind it, showing where it has been. The map also shows the course marks and a live leaderboard, so you get the full picture of the race at a glance.

Each boat is shown as a coloured SVG arrow that rotates to point in the direction the boat is heading. Behind each boat, a coloured progressive trail is drawn, tracing its path across the water so you can follow its route through the race. The colours make it easy to tell boats apart in a busy fleet.

Yes. The Tracker Demo displays the course marks on the map, including the committee boat, the windward mark, the leeward mark, and a wing mark. This lets viewers see the shape of the course and understand where each boat is relative to the marks it needs to round.

The dashboard includes a wind dial rendered on a canvas element, which shows wind direction derived from the course layout. Because a windward-leeward course is set relative to the wind, the tracker can infer and display the wind direction from the positions of the course marks. It gives viewers a quick sense of the conditions the fleet is sailing in.

The Tracker Demo has a live-sorted leaderboard that uses automatic leg detection to work out each boat's progress around the course. A boat is counted as advancing to the next leg when it comes within 85 metres of the next mark, and the heading is de-jittered over 8 metres to keep the detection stable. The leaderboard re-sorts itself live as boats round marks and change places.

Yes. The Tracker Demo is a multi-race replay tool with a timeline scrubber, so you can drag through the whole race to any moment you like. This is useful for sailors reviewing their races, for coaches running debriefs, and for parents who want to rewatch from home.

The replay supports four playback speeds: 2x, 5x, 15x, and 30x. That lets you watch a race unfold gently in near real time, or fast-forward through a long race to focus on the key moments like the start, the mark roundings, and the finish.

The timeline scrubber is a slider that lets you move backwards and forwards through a recorded race. You can jump straight to the start, scrub to a mark rounding, or replay a tricky moment as many times as you like. Combined with the 2x, 5x, 15x, and 30x speed options, it makes reviewing a race quick and flexible.

Yes. The Tracker Demo is theme-aware and supports both light and dark modes. In light mode it uses OpenStreetMap tiles, and in dark mode it switches to CARTO dark tiles, so the map looks right whichever theme you prefer.

In the on-site tracker demo, GPS positions are sampled every 10 seconds. On the water, each boat's tracker broadcasts its GPS position every 5 to 10 seconds over the LoRa radio link. That rate is plenty for spectators and for reviewing tactics.

In the 2026 rebuild there are two dashboards. The public viewer is open to everyone and offers a race picker, live WebSocket tracking, the replay scrubber with 2x, 5x, 15x, and 30x speeds, the leg-detection leaderboard, and the wind-from-course dial. The admin dashboard is key-gated, meaning it is restricted to race organisers, and it handles fleet management, the course builder, race control, node-health monitoring, and an audit log.

The key-gated admin dashboard is the control side of the 2026 rebuild, intended for race organisers rather than the public. It provides fleet management with TDMA time slots, a click-to-drop course builder for setting the marks, race control, a live node-health monitor to check the boats' trackers, and an audit log. It is protected behind a key so only authorised people can run a race.

Yes, in the 2026 rebuild's admin dashboard there is a click-to-drop course builder that lets an organiser place the course marks directly on the map. This ties in with the design goal of making it simple to set and edit course marks and start a race. The public viewer then shows those marks to everyone watching.

Partly. The demo on the website is a multi-race replay, and Race 1 is a genuine on-water LoRa recording captured from Royal Akarana Yacht Club, using real RAYC race data. Races 2 and 3 in the demo are generated demo fleets, used to develop and show off the map and replay features. Because the Meshtastic proof-of-concept sent sporadic, gappy position data, the smooth demo tracks combine the real recorded LoRa data with generated race data.

The tracker is designed to last 8+ hours on a single charge, which covers a full race day. This was a core design requirement from the start, and it was confirmed during the July 2025 field trials at Royal Akarana Yacht Club, where a tracker ran all day on the water and was simply charged overnight for the next day.

Each boat tracker runs on a 3.7V lithium battery, either an 18650 Li-ion cell or a LiPo pack, sized to last a full race day. Lithium chemistry was chosen because it packs a lot of energy into a small, light form that suits a mast-mounted waterproof unit.

Both work — the tracker is built around a 3.7V lithium battery, and either an 18650 Li-ion cell or a LiPo pack fits the design. The choice comes down to your enclosure and mounting: 18650 cells are cheap, robust and easy to swap, while flat LiPo packs can be handy where space is tight.

The tracker is charged over USB-C, so it can be topped up overnight with a standard phone-style cable and charger. USB-C recharging was a deliberate design goal to keep the system simple and familiar — you just plug the units in at the end of the day and they're ready for the next race.

Yes. The tracker is designed for 8+ hours of runtime, which is enough for a full day of racing, and in the field trials the battery lasted a full day on the water before being recharged overnight. So a typical race day is well within its target.

The tracker keeps power draw low mainly through how often it transmits: it broadcasts its GPS position only every 5–10 seconds over LoRa rather than streaming constantly. Low broadcast intervals, combined with deep sleep between transmissions and LoRa's naturally low-power radio, are what stretch a small 3.7V lithium battery across a full race day.

Yes — sending GPS positions only every 5–10 seconds, instead of continuously, is one of the main reasons the tracker can run for 8+ hours on a small battery. Radio transmission is one of the biggest power users, so keeping the broadcast interval low and letting the device rest between fixes makes a real difference to all-day runtime.

The support-boat gateway — a LoRa32 node connected to a Raspberry Pi 4 — is run from a 10,000mAh USB power bank supplying 5V/3A. This external power bank was chosen specifically to keep the gateway and Pi running for a full day on the water without relying on a phone or a boat's electrical system.

The gateway and Raspberry Pi need steady all-day power, so a 10,000mAh (5V/3A) USB power bank is used to keep them running through a full race day. During the field trials the cloud connection ran through the coach's iPhone hotspot, and the iPhone's battery went flat before the end of the day — which confirmed that dedicated external power is essential for all-day live tracking.

On the full-trial day, the gateway reached the cloud via the coach's iPhone hotspot, and it worked — but the iPhone's battery went flat before the day was out. That was the key power lesson from the trials: relying on a phone for both hotspot and battery isn't enough, so external power is needed if you want live tracking to run all day.

The main field-trial lesson was that a phone alone can't power an all-day setup: the coach's iPhone hotspot went flat before the day ended. The takeaway is to plan external power for the shore-side link — such as the 10,000mAh power bank used for the gateway — so live tracking stays up for the whole regatta.

No — they're powered separately. Each boat tracker carries its own onboard 3.7V lithium battery (18650 or LiPo) recharged over USB-C, while the support-boat gateway and its Raspberry Pi run off a shared 10,000mAh USB power bank. Splitting power this way keeps each boat's unit small and self-contained, while giving the gateway the larger, steadier supply it needs for all-day operation.

Yes. Each boat tracker lives inside an off-the-shelf IP67-rated ABS plastic box with a clear lid, chosen because youth dinghies capsize often and are launched and retrieved in saltwater. In pool capsize and full-submersion testing there was no water ingress, and the tracker kept working after being recovered. Waterproofing was one of the core design requirements from the very start, alongside 8+ hour battery life and low cost.

The tracker uses a commercially available IP67-rated ABS plastic enclosure designed for electronics. It was chosen because it is rugged, water-tight, resistant to saltwater corrosion, easy to open and reseal for servicing, and cost-effective for scaling up production. It also has a clear plastic lid so you can see the components and their status lights, and spot straight away if any water is getting inside.

The clear lid lets you see inside the sealed box without opening it. That means you can check the component status lights, confirm the board is powered and, importantly, immediately notice if any water has started to enter the enclosure. It is a simple, practical touch that suits a proof-of-concept device being tested on the water.

The GPS and LoRa antennas are kept inside the sealed case. I tested this on the bench first, and found no measurable signal loss with the antennas enclosed in the plastic box — the GPS antenna acquired a fix through the plastic and the LoRa signal was not noticeably impacted. Keeping the antennas internal avoids drilling any holes, which keeps the enclosure fully water-tight.

Drilling holes for external antennas would reduce the waterproofing of the case, and bench testing showed it wasn't necessary. With all components and both aerials installed inside, there was no measurable drop in signal at benchtop range, so the decision was made to keep everything sealed. There may be some difference in LoRa range with an internal antenna over long distances, but that is something field testing would confirm rather than a reason to compromise the seal.

Yes. If long-range field testing later shows an external LoRa antenna is worthwhile, it can be added using a waterproof cable gland. A cable gland lets you pass an antenna lead out of the box while still maintaining full sealing integrity, so the enclosure stays water-tight. For now, the internal-antenna design has been kept because bench tests showed no meaningful signal loss.

The tracker is built to survive it — capsizes are treated as routine, not exceptional. In pool testing the LoRa signal from inside the enclosure dropped while submerged but resumed immediately once the unit surfaced, and there was no water ingress. A GPS fix isn't possible underwater, as expected, but the tracker reacquired its satellite fix in under 20 seconds after surfacing. In on-water trials the devices survived capsizes and re-fixed GPS within 30–60 seconds.

I ran pool capsize and submersion tests on the enclosures before taking them on the water. The cases were submerged to simulate a capsized dinghy, and the results confirmed no water ingress, LoRa recovery immediately after surfacing, and GPS reacquisition in under 20 seconds. These pool tests were then backed up by real on-water field trials at Royal Akarana Yacht Club, where the trackers survived actual capsizes.

Very quickly. GPS can't get a fix while submerged, which is expected, but in pool testing the tracker reacquired its satellite fix in under 20 seconds once it surfaced. In the on-water field trials, GPS re-fix after a capsize took roughly 30–60 seconds in real conditions. Either way, it's fast enough that a brief capsize barely interrupts a boat's track.

It attaches to the dinghy mast using a custom 3D-printed universal backplate that screws onto the waterproof box, secured with 25mm Velcro straps. The Velcro allows fast, tool-free attachment and removal, and the mount is designed to work across different fleets and classes. The backplate has a concave back surface shaped to match typical mast diameters and raised shoulder ridges that hold the enclosure flat and stop it shifting under motion or impact with the water.

The mount is a custom 3D-printed backplate, printed in black PETG filament, which was chosen for its UV and water resistance. It was printed with a 0.6mm nozzle for strong layer bonding, and attaches to the waterproof box with M3 machine screws tapped into pilot holes — a strong but reversible connection. A carbon-fibre-filament version was also printed for extra durability.

Because a lashed-on version simply wasn't secure enough. During the water trials, a tracker held on without the 3D-printed mount was not very secure, which confirmed the custom mount is essential rather than optional. The 3D-printed backplate holds the enclosure flat against the mast with shoulder ridges and Velcro straps, keeping it firmly in place under the dynamic motion and impacts of dinghy sailing.

Yes — it took several iterations. I designed the mount in CAD and printed it myself, but my 3D printer isn't a great one, so I went through a number of print runs and design trials before reaching a design and durability I was happy with. There were print and design failures along the way, including an early version with Velcro slots that failed, before the final durable design was settled.

Alongside the standard black PETG mounts, I also printed a version of the mast mount using carbon-fibre filament. Carbon-fibre-reinforced filament is stiffer and more durable, which suits a part that has to withstand the loads and impacts of being strapped to a dinghy mast. It's part of the iterative process of finding a mount design that's tough enough for regular on-water use.

Yes, it's designed as a universal backplate intended to work across different fleets. The concave back surface is shaped to match typical mast diameters and is adjustable per class, so the same basic design can be tuned for different boats. Combined with the tool-free Velcro straps, this makes it quick to fit a tracker to a range of youth dinghies such as Optimist, Starling, 29er, ILCA and iQFOiL.

Yes. The Sail Race Tracker was field-tested over three days of holiday sail training at the Royal Akarana Yacht Club (RAYC) in Auckland from 1 to 3 July 2025. The trials used four race boats carrying trackers (a mix of TTGO and Heltec HTIT nodes) plus one support boat carrying the TTGO gateway node and a Raspberry Pi 4. They were designed to validate the whole system — GPS transmission over LoRa, packet reception, logging, and the live map — under real sailing conditions rather than just on the bench.

It was tested at the Royal Akarana Yacht Club (RAYC) in Auckland, New Zealand, during a RAYC holiday sail-training programme in early July 2025. Earlier bench tests and pool capsize tests were carried out during the build phase before the on-water trials. RAYC coaches and sailors had also helped shape the design goals during earlier regattas and club events.

The three-day RAYC trials proved the complete data flow — boat, to LoRa, to support-boat gateway, to Raspberry Pi, to database, to live web dashboard — worked under real sailing conditions. Specifically, the trackers survived capsizes and re-acquired a GPS fix within 30 to 60 seconds, the battery lasted a full race day, multiple boats were tracked concurrently with no packet collisions or data loss, and coaches could follow the fleet live from shore. The system was shown to be robust and capable of scaling across a youth fleet, while confirming the one big software limitation that still needed fixing.

The trial ran across three progressive days. Day 1 was an off-water system test to confirm all four nodes powered up, got a GPS fix, transmitted, and appeared on the dashboard. Day 2 was a two-boat on-water trial run deliberately with no internet, to prove local tracking and capsize survival. Day 3 was the full trial with all four race boats plus the support boat, adding the live cloud upload via a coach's iPhone hotspot.

Day 1 was an off-water set-up test at RAYC. All four tracker nodes powered on, acquired a GPS fix, and transmitted their location; the gateway node recognised every other node in the mesh; the Raspberry Pi received and logged the data; and the map dashboard displayed four distinct markers. The 3D-printed mounting system also worked well. The key result was full end-to-end system connectivity confirmed before anyone went on the water.

Day 2 was a two-boat water trial run deliberately without any internet connection, to prove the tracking worked locally over LoRa. Two boats were launched with mounted trackers (an HTIT node and a TTGO with a NEO-M8N GPS), and I tested live tracking as they left the shore, packet delay and range, and signal recovery after capsizes. The boats survived capsizes, the battery lasted the full day (charged overnight), and data checked on the Pi at the end of the day confirmed the system had worked throughout.

Yes. Surviving capsizes is a core requirement because youth dinghies capsize routinely, and the trackers came through the on-water capsizes at RAYC without failing. The sealed IP67 enclosures kept water out, and after a capsize each unit re-acquired its GPS fix within 30 to 60 seconds. Earlier pool capsize tests had already shown no water ingress and GPS reacquisition in under 20 seconds after surfacing.

In the on-water RAYC trials the tracker re-acquired its GPS fix within about 30 to 60 seconds after a capsize. GPS is not possible underwater, which is expected, but the unit resumes fixing as soon as it surfaces. In the earlier controlled pool tests, reacquisition took under 20 seconds after surfacing.

Yes. During the Day 2 water trial the battery capacity was sufficient for a full day of racing, and the batteries were simply charged overnight for the next day. Lasting a full 8-plus-hour race day on a single charge, with easy overnight USB recharging, was one of the original design requirements, and the trials confirmed it in practice.

No. On Day 3, with all four race boats reporting at once, no packet collisions or data loss were observed. All four nodes successfully reported GPS data during the session, the SQLite database captured the records, and the dashboard visualised multiple boats concurrently. The gateway also withstood minor rain and spray without any issues.

Yes. Coaches were able to track the boats live from shore without having to chase each boat around the course, which was one of the main things the trials set out to prove. On Day 3 the support-boat gateway pushed data to the cloud via a coach's iPhone hotspot, making live positions viewable in a browser. On Day 2 the system also tracked boats locally with no internet at all, buffering the data on the Pi.

On Day 3 the live cloud upload relied on a hotspot from the coach's iPhone, and while data transmission itself worked fine, the iPhone's battery went flat before the day finished. This showed that for reliable all-day live tracking the hotspot phone needs its own power source — either an external battery pack for the phone, or a boat power supply if the support boat is large enough. The tracking system itself kept working; it was only the internet uplink that was affected.

Yes. The trials confirmed that Meshtastic was not sending through enough data points, leaving large gaps between fixes so the position trails could not be drawn smoothly or compared cleanly across boats. This is a software limitation in Meshtastic's message scheduling, not a hardware fault, and it became the main reason for the 2026 rebuild with custom ESP32 firmware. The trials were valuable precisely because they pinpointed this bottleneck under real conditions.

The feedback was positive across all three groups. Coaches were impressed by being able to track boats from shore without needing to follow each one closely; parents expressed interest in viewing live positions from the clubhouse or their phones; and the sailors were very excited and keen for future development. This real-world enthusiasm helped confirm the demand for a youth-focused, affordable, real-time race-tracking system.

Yes. Before the RAYC on-water trials, I ran bench tests and pool-based capsize and submersion tests during the build phase. The pool tests confirmed there was no water ingress into the enclosure, that the LoRa signal dropped underwater but resumed immediately on surfacing, and that the GPS reacquired a fix in under 20 seconds after surfacing. Bench tests also showed no meaningful LoRa or GPS signal loss through the plastic enclosure, which is why no antenna holes were drilled.

Yes. During the water trials, mounting the boat devices with the custom 3D-printed mast backplate was easy and reliable, whereas a lashed-on version without the printed mount was not secure. This directly proved that the 3D-printed mount is essential rather than optional. The mounting system had already been confirmed to work during the Day 1 off-water test.

I started Sail Race Tracker because I'm a competitive youth sailor myself — I race the Starling and 29er classes out of Auckland — and I had firsthand experience of how hard it is for spectators and coaches to follow youth sailing from shore. Parents and supporters often can't see the race at all, and there's no simple way to know what's happening in real time. Professional events like the America's Cup and SailGP use GPS overlays and augmented-reality maps to bring racing to life, but those systems are hugely expensive and completely unsuitable for club and school regattas. I wanted to bring that same "see the whole race" experience to youth sailing for a fraction of the cost.

I created Sail Race Tracker. I'm Jack Harker, a competitive youth sailor and Year 10 student at ACG Parnell in Auckland, New Zealand. I race the Starling and 29er classes, and I did all the physical testing, coding, assembly, and design decisions myself. The project grew out of my own frustration at how hard youth sailing is to follow from the shore.

I built it in six phases, from research through to on-water field trials. I started by researching the problem and the technology, then planned the full system architecture, built and configured the hardware, developed the software stack, ran field trials at a yacht club, and finally worked on finishing the prototype for real events. Along the way I used ChatGPT as a 24/7 research tutor and coding mentor, but every piece of hardware assembly, every line of code tested, and every design decision was mine.

The project ran through six phases: Phase 1 – Research & Concept Design; Phase 2 – System Architecture Planning; Phase 3 – Hardware Build & Setup; Phase 4 – Software Development; Phase 5 – Field Testing & Trials; and Phase 6 – Finalise Prototype for Events. Phase 1 covered researching the problem, professional systems, commercial trackers, and choosing LoRa. The later phases moved from planning the data flow through to building the trackers, writing the software, and proving it all worked on the water at Royal Akarana Yacht Club.

The core proof-of-concept was built over roughly four months, from April to July 2025. I began defining the concept and problem in early April 2025, moved through hardware and software build in May and June, and ran the on-water field trials at Royal Akarana Yacht Club on 1–3 July 2025. That gave me a working end-to-end system — boat to LoRa to gateway to Raspberry Pi to live web dashboard — inside a single sailing season.

Development of the 2025 proof-of-concept ran from April to July 2025. The initial concept and problem definition happened over 1–14 April 2025, the system architecture and hardware build took place through May, software development followed, and the field trials were held on 1–3 July 2025. A 2026 rebuild with custom firmware and a cloud backend is now continuing the work.

Extremely detailed — the project logbook runs to 224 pages and more than 49,000 words. It documents 284 build iterations across 39 different topics, covering everything from research and component selection to firmware flashing, wiring, waterproofing, software debugging, and the field trials. I kept it as a genuine engineering record, so every design decision, dead end, and fix is written down rather than just the parts that worked.

The logbook records 284 build iterations across 39 topics. That reflects how much of the project was hands-on and experimental — the prototyping boards, GPS modules, and Raspberry Pi all needed extensive testing, and I found that even tiny differences in firmware compatibility, wiring, or USB drivers could break the whole system. I learned to troubleshoot systematically rather than guessing, and every one of those iterations is documented.

Three things stood out as the hardest. The live map dashboard took many iterations to get right — getting boat trails to render cleanly in the browser was fiddly, and I ended up using Chrome because Safari didn't handle Leaflet.js as well. The 3D-printed mast mount also fought me through several print failures before I got a design durable enough to survive on the water. And the biggest technical wall was the Meshtastic limitation, which throttled how much GPS data I could send.

The dashboard was hard because turning raw GPS points into clean, readable boat trails on a live map took a lot of trial and error. I chose Leaflet.js for lightweight, API-key-free maps, but rendering progressive trails without them tangling or jittering needed many iterations. I also discovered Safari didn't handle Leaflet.js as well as Chrome, so I did my development and testing in Chrome to get the map behaving properly.

The trailing lines — the coloured trails that show each boat's path — were one of the trickiest visual problems. Getting them to draw smoothly and stay tidy as boats moved took a lot of iterations, because messy or jittery trails make a race map hard to read. It's a small detail, but it's central to the whole "see the whole race" idea, so it was worth getting right.

Meshtastic is a brilliant open-source platform and it made the proof-of-concept possible, but its message scheduling and mesh optimisation throttle how often and how much GPS data each boat can send. The result was sporadic, gappy position data instead of a smooth, continuously time-stamped trail — and that's a software limitation, not a hardware one. It was the single biggest issue confirmed in the field trials, and it's the main reason I'm doing the 2026 rebuild with custom firmware.

Yes — community consultation was a big part of it. I worked with coaches, sailors, and parents across several Auckland clubs including Royal Akarana Yacht Club, Kohimarama Yacht Club, Wakatere Boating Club, Murrays Bay Yacht Club and Maraetai Beach Boating Club, and I had support from Yachting NZ, NZIODA and High Performance Sport NZ. During the field trials I gathered direct feedback from coaches, parents and sailors on the water. That real-world input shaped what the system needed to do.

Yes. I presented the project to the NZIODA National Committee — the NZ International Optimist Dinghy Association — on 1 July 2025. There was strong interest and support, and the officials made a point I've kept front of mind: reliability is essential if a system like this is going to be used for race-official purposes. That feedback directly informs the reliability focus of the 2026 rebuild.

I learned a huge amount about systematic troubleshooting — with prototyping hardware, even small differences in firmware, wiring, or drivers can break everything, so you have to isolate problems methodically. I learned how to integrate separate modules (GPS, LoRa radio, microcontroller, power) into one reliable system rather than buying a pre-packaged solution. And through the community and the NZIODA feedback, I learned that for real-world race use, reliability matters just as much as clever features.

The field trials at Royal Akarana Yacht Club on 1–3 July 2025 were the moment the whole system had to prove itself on real water. Over three days I ran an off-water bench test, a two-boat water trial, and a full four-boat trial with a support-boat gateway — and the trackers survived capsizes, re-fixed GPS in 30–60 seconds, and lasted a full race day on battery. The dashboard showed multiple boats live from shore, which is exactly what I set out to achieve. The trials also confirmed the Meshtastic data-gap problem, which pointed straight to the next stage.

The 2026 rebuild is the next chapter — it's about turning a proven proof-of-concept into something closer to a real product. I'm replacing Meshtastic with custom ESP32 firmware so each boat logs continuous, time-stamped GPS and sends complete records over a private LoRa channel, which fixes the gappy-data problem. It also adds a proper cloud backend on Cloudflare, with a public tracker-demo viewer and a key-gated admin dashboard for race control. It continues the exact same mission — affordable, SIM-free, open-source race tracking for youth sailing — just built to be more reliable.

Not yet — and I'm honest about that. What exists today is a working, field-tested proof of concept that proved the whole idea end to end: a dinghy tracker sending GPS over LoRa to a gateway, a Raspberry Pi, a database, and a live web map viewable from shore. It's not a commercial product, and the 2025 version had real limitations like the Meshtastic data gaps. The 2026 rebuild, with custom firmware and a cloud backend, is the pathway towards making it production-ready.

Cellular tracking was rejected because it fails the two most important design goals: cost and race legality. Every SIM-based tracker needs a data plan (roughly NZ$30+ per month per unit) and relies on a phone or SIM — but phones are banned in dinghy racing for safety and class-rule reasons. LoRa (Long Range radio) uses the free 915 MHz ISM band in New Zealand, so there are no SIM cards, no towers and no monthly contracts, which keeps running costs near zero. That directly supports the goal of a SIM-free system under NZ$50 per unit.

Each alternative failed at least one core requirement, and LoRa was the only option that met all of them. Wi-Fi only reaches about 50 metres and Bluetooth is even shorter, so neither can cover a race course that spreads over kilometres of open water. Satellite links are too slow and too expensive for a low-cost youth system. LoRa delivers 2–10 km of range in open environments, sips power, and sends the tiny GPS packets a tracker needs — it works brilliantly over open water where there are few obstacles.

No — GPS position data is tiny, so LoRa's low bandwidth is a good fit rather than a limitation. Each boat only needs to send a short packet (node ID, latitude, longitude, battery, timestamp) every 5–10 seconds, which sits comfortably within LoRa's capacity. LoRa would be unsuitable for something like live video, but for coordinates it is ideal. A slight buffered delay of 30–60 seconds is perfectly acceptable for spectators watching from shore.

The NEO-M8N was chosen because it offers a much better balance of accuracy, fix speed and update rate for fast dinghy sailing, while still costing only about NZ$15–20. The older NEO-6M is cheaper but slower, with looser accuracy around 5 metres, which is less suited to quick tactical movements. The NEO-M8N gives roughly 2.5 m accuracy, a fast fix and a 1 Hz-plus update rate, which captures starts, laylines and mark roundings clearly enough for coaching and replay.

RTK GPS was deliberately left out of the current build because it clashes with the affordability goal and adds too much complexity. RTK chips cost NZ$100–200 or more, need a separate base station, and would push each unit far beyond the under-NZ$50 target. Crucially, centimetre accuracy isn't necessary: what matters for a fleet is relative consistency, not absolute precision. If every boat shares a similar 2–5 m error, you can still clearly see who crossed a line first, so RTK has been left open only for possible future iterations.

Meshtastic was the right starting point because it let a solo student get a working, self-healing LoRa mesh running quickly without building radio firmware from scratch. It handles node discovery, mesh routing and gateway forwarding out of the box, which made an end-to-end proof of concept achievable and let the field trials happen. It proved the whole concept on the water — boat to LoRa to gateway to Raspberry Pi to dashboard — and was always intended as a stepping stone rather than the final firmware.

Meshtastic became the main bottleneck once the concept was proven, so the 2026 rebuild replaces it with custom ESP32 firmware. Meshtastic's message scheduling and mesh optimisation throttle how often and how much GPS data each boat can send, producing sporadic, gappy position data instead of a smooth time-stamped trail. This is a software limitation, not a hardware one. The custom Arduino/PlatformIO firmware logs time-stamped GPS on each boat and sends packaged historical fixes over a private LoRa channel, so the base can compile a complete, continuous record.

A Raspberry Pi 4 was chosen because it's low-cost, low-power, small enough to sit in a waterproof case on a support boat, and flexible enough to run the full software stack. It connects to the TTGO LoRa gateway node over USB and runs a Mosquitto MQTT broker, a Python listener, a SQLite database and a Flask API all on one board. Being shared across the whole fleet, a single Pi supports many boats, which keeps the per-boat cost down. It also runs headless over SSH, so it needs no screen or keyboard on the water.

SQLite was chosen for the proof of concept because it's lightweight, file-based, needs no separate server process, and runs happily on a Raspberry Pi with no configuration overhead. Heavier databases like PostgreSQL or a time-series engine like InfluxDB would add complexity and resource demands that a simple GPS logging table doesn't need. A cloud-hosted option like Firebase would also reintroduce internet dependence, whereas the on-boat system has to work with no internet at all. The schema is deliberately simple — node ID, short name, latitude, longitude, battery level and timestamp.

Yes, in a modern form — the cloud backend runs on Cloudflare's D1, which is SQLite at its core, so the project stays with a database it already knows. The rebuild pairs D1 with a Cloudflare Worker built on the Hono framework and a Durable Object called "RaceRoom" that fans live fixes out to viewers over WebSockets. This keeps the familiar SQLite model while adding the real-time, multi-viewer scale a public tracker needs. It has been verified end-to-end with a real Auckland fix.

Leaflet was chosen because it's lightweight, free, works without an API key and can run offline, which matters for a low-cost, no-subscription system. Google Maps was rejected mainly on cost — its usage-based pricing and key requirements don't suit a free, open-source project. Mapbox was rejected for its added complexity. Leaflet, paired with OpenStreetMap tiles, gives coloured markers, trails and race replay in any browser without ongoing fees, and the tracker demo on the site uses Leaflet 1.9.4 with theme-aware light and dark map styles.

Development boards like the TTGO LoRa32 were used first because they let a student prototype quickly, cheaply and with no fabrication lead time. Off-the-shelf boards (around NZ$25–30) come with the ESP32, LoRa radio and often an OLED screen already wired, so they were perfect for testing the concept and running field trials. A custom PCB is on the roadmap for the production stage, where fabricating a single board with the ESP32, NEO-M8 GPS and LoRa in China would cut cost, size and weight further. It made sense to prove the system worked before committing to custom hardware.

Several ESP32-based boards were trialled to compare wiring, GPS options, waterproofing and cost. The TTGO LoRa32 V1.6 (external GPS, OLED, around NZ$25–30) became the workhorse, the Heltec HTIT tracker offered built-in GNSS and a display, and the TTGO T-Beam with onboard GPS was also considered. The sealed SenseCAP T1000-E was used for early proof-of-concept work but was ruled out for the real build because it isn't waterproof, has a small battery, can't be re-flashed over USB and runs closed firmware. The 2026 rebuild targets the LilyGo/TTGO LoRa32 and a Seeed XIAO ESP32-S3 with a Wio-SX1262 radio.

Animation Research Ltd (ARL), the Dunedin company founded by Ian Taylor, was a direct inspiration because its Virtual Eye system created the 3D real-time race visualisations that first brought the America's Cup to life for audiences. That work became a world benchmark for live sports visualisation and later spread to rally, golf, cricket and motor racing. Studying ARL prompted the founding question behind the project: why hasn't this kind of expertise been used to build an affordable tracking system for youth sailing? Sail Race Tracker aims to bring that America's-Cup-style fleet view down to club and school level.

Professional events were the starting research point because they show exactly what great race tracking looks like — real-time fleet positions, laylines, speed and direction shown on high-end overlays and AR. Reviewing SailGP and America's Cup AC75 tracking set the target for the on-shore experience: seeing the whole race live from land. The lesson, though, was that these systems are expensive, custom-engineered and broadcast-grade, and completely unsuitable for youth and club budgets. Sail Race Tracker deliberately recreates the useful spectator and coaching value at a fraction of the cost, rather than copying the elite hardware.

Commercial and elite systems including TracTrac, RaceQs, Yellowbrick, Sailmon MAX and WAIV were all reviewed to understand the market. The problem is that they cost roughly NZ$500–900 (or €400–500) per unit plus NZ$30-plus monthly data or subscription fees, and they rely on a SIM card or Bluetooth pairing to a phone. Since phones are banned in dinghy racing, and a 200-boat regatta would cost over NZ$180,000 in gear alone, none of them fit youth club sailing. That gap — no affordable, waterproof, SIM-free tracker for dinghy fleets — is exactly what Sail Race Tracker set out to fill.

Sail Race Tracker has won two major awards. In 2025 it took 1st Prize in the Years 7–10 category of Samsung Solve for Tomorrow, and it also won 1st place in the Technology category at the NIWA Auckland City Science & Technology Fair. Both awards recognised the project as a standout piece of youth innovation in New Zealand.

Samsung Solve for Tomorrow is a youth innovation competition that challenges students to use technology to solve real-world problems. In New Zealand it is run by Samsung in partnership with MOTAT and TENZ (Technology Education New Zealand). Sail Race Tracker won 1st Prize in the Years 7–10 category of the 2025 competition.

Sail Race Tracker was awarded 1st Prize in the Years 7–10 category of Samsung Solve for Tomorrow on 30 October 2025. The award was made in partnership with MOTAT and TENZ (Technology Education New Zealand).

The Samsung Solve for Tomorrow 1st Prize for Years 7–10 was a NZ$9,000 prize pool. It combined cash and Samsung technology for me, my school, and my teacher. It was awarded on 30 October 2025.

Samsung ran Solve for Tomorrow 2025 in New Zealand in partnership with MOTAT and TENZ (Technology Education New Zealand). These partners helped deliver the competition and recognise the winning student projects, including Sail Race Tracker.

Yes. Sail Race Tracker won 1st place in the Technology category at the NIWA Auckland City Science & Technology Fair 2025. The fair was held from 28 to 30 August 2025.

The NIWA Auckland City Science & Technology Fair 2025 was held from 28 to 30 August 2025. Sail Race Tracker won 1st place in the Technology category at that fair.

Yes. Sail Race Tracker was featured on RNZ (Radio New Zealand) on the Nine to Noon programme. The segment was titled "Solve for Tomorrow winners tackle race tracking and mountain bike safety," covering the Samsung Solve for Tomorrow winners.

Alongside its RNZ Nine to Noon feature, Sail Race Tracker has been covered by Samsung NZ on its winners page, by Idealog ("Young Kiwi innovators shine…"), and by MOTAT and TENZ ("Ngā Hua mō Āpōpō"). This coverage followed its 2025 Samsung Solve for Tomorrow and NIWA Auckland Science Fair wins.

Yes. Sail Race Tracker was presented to the NZIODA National Committee (the NZ International Optimist Dinghy Association) on 1 July 2025. The presentation was received with strong interest and support.

When Sail Race Tracker was presented to the NZIODA National Committee on 1 July 2025, the response was one of strong interest and support. Officials did stress that reliability is essential if the system is to be used for race-official purposes, which is a key focus of the ongoing development.

The awards show that Sail Race Tracker is a recognised piece of genuine innovation, not just a school project. Winning 1st Prize at Samsung Solve for Tomorrow 2025 and 1st in Technology at the NIWA Auckland Science Fair 2025, plus an RNZ feature and interest from the NZIODA, gave the project national visibility and credibility. That recognition supports the goal of turning a working proof of concept into an affordable, real product for youth sailing.

Commercial trackers such as RaceQs, TracTrac, Yellowbrick, Sailmon MAX and WAIV are polished, proven products — but they cost roughly NZ$500–900 (or €400–500) per unit, often with subscriptions of $30+ a month, and they rely on a SIM card or a Bluetooth-paired phone. Sail Race Tracker takes a different path: a low-cost, SIM-free, open-source GPS tracker aiming for under NZ$50 per unit to produce, with no ongoing data costs. It's built specifically for youth sailing dinghies at clubs and schools, where the commercial gear is simply too expensive to deploy at fleet scale. The honest trade-off is that Sail Race Tracker is a working proof of concept, not yet a finished commercial product.

RaceQs is an established commercial race-tracking platform, whereas Sail Race Tracker is an open-source proof of concept built by a competitive youth sailor for club and school racing. The biggest practical difference is cost and connectivity: commercial units run about NZ$500–900 each and depend on a SIM or a phone, while Sail Race Tracker targets under NZ$50 per unit and is completely SIM-free, using long-range LoRa radio instead of cellular. That SIM-free design matters in dinghy racing, where phones are banned for safety and class-rule reasons. RaceQs is more mature and feature-complete today; Sail Race Tracker's aim is affordability and access for fleets that could never justify commercial pricing.

Yes — Sail Race Tracker is being developed as a much cheaper alternative for youth and club sailing. Yellowbrick and similar commercial trackers cost roughly NZ$500–900 (or €400–500) per unit plus ongoing data or subscription fees, which makes tracking a whole dinghy fleet extremely expensive. Sail Race Tracker targets under NZ$50 per unit to produce, with no SIM, no subscription and near-zero running cost. It's worth being clear that it's currently a field-tested proof of concept rather than a shrink-wrapped product, so it trades commercial polish for openness and affordability.

Sailmon (including the Sailmon MAX) is a well-regarded commercial sailing instrument and tracker, typically in the NZ$500–900 / €400–500 per-unit bracket and reliant on a SIM or paired device. Sail Race Tracker is aimed at a different problem: affordable, SIM-free tracking for whole dinghy fleets at clubs, schools and regattas, targeting under NZ$50 per unit. Rather than cellular, it uses LoRa radio and a support-boat gateway, so it works with no internet on the race boats and no data plans. Sailmon is a finished, high-quality product; Sail Race Tracker is an open-source proof of concept built to make live fleet tracking reachable for grassroots youth sailing.

The cost gap comes from design choices, not corner-cutting. Commercial trackers bundle cellular connectivity, custom hardware and cloud services, which pushes them to roughly NZ$500–900 per unit plus $30+/month in data or subscriptions. Sail Race Tracker uses off-the-shelf, low-cost parts — an ESP32 board, a u-blox GPS module, a battery and an IP67 box — and replaces cellular with free-to-use LoRa radio on the 915 MHz ISM band, so there's no SIM and no subscription. The target is under NZ$50 per unit to produce, and a future custom PCB could cut cost, size and weight further.

Major regattas can have 100–200 dinghies on one course, and kitting that out with commercial trackers at NZ$500–900 each would cost over NZ$180,000 in equipment alone, before any ongoing data charges. Sail Race Tracker is designed to scale from a 5-boat training session up to a 100–200-boat regatta at a target of under NZ$50 per unit, with one shared Raspberry Pi gateway on the support boat and no per-unit data plans. That's the core reason the project exists: at commercial pricing, whole-fleet youth tracking is effectively unaffordable. As a proof of concept, it has been field-tested with a small fleet rather than a full 200-boat event so far.

Nearly all commercial trackers rely on a SIM card or a Bluetooth pairing to a phone to get positions off the water — but phones are banned in dinghy racing for safety, distraction and class-rule reasons. That makes SIM- and phone-dependent systems awkward or unusable in exactly the youth-racing context Sail Race Tracker is built for. By using LoRa radio instead, Sail Race Tracker sends GPS positions boat-to-boat to a support-boat gateway with no SIM, no cellular contract and no phone on board the dinghy. The result is no ongoing operating costs and a system that fits the rules of the sport.

Yes — in dinghy racing phones are generally banned on the water for safety, distraction and class-rule reasons. That's a real problem for commercial trackers, because many of them depend on a Bluetooth-paired phone or an on-board SIM to relay positions. Sail Race Tracker was designed around this constraint from the start: it carries no phone and no SIM, relaying GPS over LoRa radio to a gateway on the support or committee boat instead. This SIM-free, phone-free approach is one of the main reasons a purpose-built system was needed rather than adapting existing gear.

Professional events like the America's Cup (AC75) and SailGP use impressive GPS overlays and augmented-reality graphics, but those systems are expensive, custom-engineered and built for a handful of elite boats with big production budgets. They're simply not designed for a club regatta with 100–200 low-cost dinghies, capsizes, tight budgets and no broadcast crew. Sail Race Tracker set out to bring America's-Cup-style live fleet maps to club and school racing for a fraction of the cost. It won't match professional broadcast polish, but it targets the affordability, waterproofing and SIM-free simplicity that grassroots sailing actually needs.

Because Sail Race Tracker is open-source and community-driven, its firmware, hardware choices and software stack can be shared, inspected, improved and adapted by clubs, makers and engineers — rather than locked inside a proprietary commercial product. That openness supports the project's ethos of being affordable and accessible, and it invites contributions in firmware, web and hardware from the wider LoRa and open-source community. It also means a club isn't tied to one vendor's subscriptions or SIM contracts. The trade-off is that an open proof of concept needs more hands-on setup than a polished commercial box.

Commercial trackers like RaceQs, TracTrac, Yellowbrick, Sailmon MAX and WAIV are finished, reliable, well-supported products, and that maturity is their advantage. Sail Race Tracker is honestly still a proof of concept: its 2025 build used Meshtastic firmware, which throttled how often GPS data was sent and produced sporadic, gappy position data rather than a perfectly smooth trail. NZIODA officials rightly stressed that reliability is essential for race-official use, and commercial systems have a head start there. A 2026 rebuild with custom firmware and a cloud backend is under way to close that gap.

It's honestly a working, field-tested proof of concept — not yet a commercial product. The system has been demonstrated end-to-end, from boat to LoRa radio to a support-boat gateway to a Raspberry Pi and a live web dashboard, and it was trialled over three days at Royal Akarana Yacht Club in July 2025. But the 2025 version had a real limitation: the Meshtastic platform sent too few data points, leaving gaps between fixes. A 2026 rebuild with custom ESP32 firmware and a cloud backend is in progress to move it toward a genuine product.

No — no product currently exists offering real-time, waterproof, affordable, SIM-free GPS tracking for dinghy fleets, and there are no NZ companies offering it. The available options are overseas commercial trackers at roughly NZ$500–900 per unit that depend on a SIM or a phone, which don't fit dinghy racing's phone ban or club budgets. That gap is exactly why Sail Race Tracker was created by a young Auckland sailor. It's an early-stage, open-source answer to a genuine unmet need rather than an established commercial offering.

That depends on the club's budget, timeline and reliability needs. If a club needs a proven, supported system right now and can afford roughly NZ$500–900 per unit plus ongoing data, commercial trackers are the safer choice today — especially where officials require dependable, race-ready results. Sail Race Tracker is currently a proof of concept aimed at making whole-fleet tracking affordable at under NZ$50 per unit, SIM-free, with a 2026 rebuild under way. Clubs and schools keen to help trial prototypes or partner on testing are warmly invited to get in touch at info@sailracetracker.live.

In one sentence: Sail Race Tracker is a low-cost, SIM-free, open-source GPS race tracker built for whole youth dinghy fleets — targeting under NZ$50 per unit against roughly NZ$500–900 for commercial systems, using LoRa radio instead of a banned-on-the-water phone or SIM. The honest caveat is that it's a field-tested proof of concept rather than a finished commercial product, with a 2026 rebuild in progress to improve reliability.

Sail Race Tracker is designed to be produced for under NZ$50 per unit, compared with roughly NZ$500–900 (or €400–500) per unit for commercial sailing trackers like RaceQs, TracTrac, Yellowbrick, Sailmon MAX and WAIV. It is a low-cost, open-source system built specifically to make GPS race tracking affordable for youth sailing clubs and schools. It is currently a working proof of concept rather than a finished retail product, so there is no fixed sale price yet.

The target is under NZ$50 per boat unit to produce. That figure is built from off-the-shelf development parts: a TTGO LoRa32 board at around NZ$25–30, a u-blox NEO-M8N GPS module at around NZ$15–20, a lithium battery, an IP67-rated waterproof box, and a 3D-printed mast mount. A future custom PCB (printed and assembled cheaply in China via services like JLCPCB or PCBWay) would combine these parts onto one board and bring the cost, size and weight down even further.

Commercial sailing trackers cost roughly NZ$500–900 per unit and typically add subscriptions of NZ$30 or more per month for data. Sail Race Tracker uses inexpensive, widely available maker components (ESP32, LoRa radio, u-blox GPS) and open-source software, so there are no expensive custom parts and no proprietary licensing. It also uses LoRa radio on the free 915 MHz ISM band instead of a SIM card, which removes cellular hardware and ongoing data fees entirely.

No. Sail Race Tracker is SIM-free and uses LoRa radio on a free, licence-exempt band, so there are no cellular contracts, no data plans and no monthly subscriptions. Running costs are near zero. By contrast, commercial trackers commonly add NZ$30 or more per month per unit on top of their high purchase price.

A major regatta can have 100–200 dinghies on one course. On commercial gear at roughly NZ$500–900 per unit, tracking a 200-boat fleet would cost over NZ$180,000 in equipment alone, plus ongoing data charges. At the Sail Race Tracker target of under NZ$50 per unit, the same 200-boat fleet would cost a small fraction of that, with no subscription costs at all.

No. The gateway is shared across the whole fleet rather than being fitted to every boat. A single support or committee boat carries the gateway, which is a TTGO LoRa32 node connected to a Raspberry Pi 4. Each dinghy only needs its own low-cost tracker (under NZ$50 target), so the gateway cost is spread across every boat on the course.

Each proof-of-concept boat tracker is built from a handful of off-the-shelf parts: a TTGO LoRa32 development board (around NZ$25–30), a u-blox NEO-M8N GPS module (around NZ$15–20), a 3.7V lithium battery (18650 or LiPo) sized for a full race day with USB-C charging, an off-the-shelf IP67 waterproof ABS box, and a custom 3D-printed mast mount in PETG. These parts together are what the under-NZ$50 per-unit target is based on.

Affordability is the whole point of the project. It was created to bring America's-Cup-style live fleet tracking to club and school regattas for a fraction of commercial cost, targeting under NZ$50 per unit with no ongoing fees. Because the gateway is shared across the fleet and there are no subscriptions, clubs, schools and families can equip many boats without the tens or hundreds of thousands of dollars that commercial systems would require.

Yes, that is the plan. A future custom printed circuit board would combine the ESP32, u-blox NEO-M8 GPS and LoRa radio (plus optional extras like Bluetooth, a motion sensor or a small OLED) onto a single board. Fabricated cheaply through overseas services such as JLCPCB or PCBWay, this would cut cost, size and weight further compared with wiring separate development boards together.

Phones and SIM-based devices are banned in dinghy racing for safety, distraction and class-rule reasons, so a SIM-based tracker would not be usable anyway. Beyond that, SIM cards mean cellular contracts and monthly data fees for every unit. Sail Race Tracker uses LoRa radio on the free 915 MHz ISM band instead, which needs no SIM, no towers and no contracts, removing a major recurring cost while working well over open water.

The under-NZ$50 figure is a design target for producing each unit, and it is grounded in the real cost of the off-the-shelf parts already used in the field-tested proof of concept (TTGO board, NEO-M8N GPS, battery, IP67 box, 3D mount). The system has been proven to work end-to-end on the water, but it is not yet a finished commercial product, so a final retail price has not been set. A future custom PCB is expected to lower the build cost further.

Today, spectators and coaches often follow youth races in powerboats, which is costly, noisy, fuel-burning, risky and congests the course. Sail Race Tracker lets parents and coaches watch the whole fleet live from shore on a phone, tablet or laptop, reducing the need for chase boats. That means lower fuel use and fewer safety powerboats, on top of the low per-unit cost and the absence of any subscription or data charges.

Sail Race Tracker is built for four groups in youth sailing: sailors, coaches, race officials, and spectators (mainly parents). Sailors get full GPS replays of their races and training; coaches get fleet overlays for evidence-based debriefs; race officials get a live full-fleet view for safety and fairer racing; and parents can follow the whole race live from shore on a phone or tablet. It targets youth dinghy classes like the Optimist, Starling, 29er, ILCA and iQFOiL, of which there are thousands of sailors in New Zealand.

Coaches can replay whole training sessions and races with the full fleet overlaid on one map, then compare sailors side by side to see exactly where each one gained or lost ground. This turns debriefs into evidence-based conversations rather than relying on memory or a single vantage point from a chase boat. It lets a coach run a 5-to-20-boat squad more effectively and track each sailor's development over time, all without needing to physically follow every boat on the water.

Sailors get a full GPS replay of their races and training, so they can see objectively where time was won or lost, whether that was the start, the laylines, or a wind shift. Because the feedback is based on real recorded positions rather than gut feeling, sailors can learn tactics faster and understand their own decisions more clearly. Reviewing an actual track of the race is a much sharper learning tool than trying to remember what happened out on the water.

Yes. That is one of the core reasons Sail Race Tracker was built, with the tagline "See the whole race. From the shore." Parents and other spectators can open a live map dashboard in any web browser on a phone, tablet or laptop and watch all the boats on the course in near real time, then replay the race again at home. There is a slight buffered delay of around 30 to 60 seconds, which is fine for spectators and means far less need to follow the fleet in a chase boat.

Race officials get a live view of the entire fleet on one screen, which helps them run fairer starts and finishes and set up faster. Critically for safety, it lets them locate distressed, capsized or drifting boats quickly, so fewer safety powerboats may be needed on the course. It also produces positional logs that can support protests and redress decisions after racing. When I presented to the NZIODA National Committee in July 2025, officials stressed that reliability is essential for race-official use.

Because each boat's GPS positions are time-stamped and logged, Sail Race Tracker can provide an objective positional record of where boats were during a race. This kind of data can support race officials and juries when assessing protests or redress requests, adding evidence rather than relying solely on witness accounts. It is worth noting the 2025 system is a proof of concept, and officials have stressed that reliability is essential before positional logs are leaned on for official race decisions.

Yes. Locating distressed, capsized or drifting boats is one of the key safety benefits for race officials. Each dinghy broadcasts its GPS position regularly, so a support or committee boat can see on the live map where every boat is, including any that has capsized or drifted off the course. In field trials the trackers survived capsizes and re-acquired a GPS fix within about 30 to 60 seconds, so a boat back on its feet quickly reappears on the map.

Yes. It works for everything from a small training session to a full regatta, and it is designed to scale from a 5-boat training squad up to a 100-to-200-boat regatta. For training, coaches can replay a whole session with fleet overlays and compare sailors, while for racing, officials get a live full-fleet view and sailors get race replays. The same trackers and dashboard support both, which makes it useful day to day and not just on regatta weekends.

A post-race replay lets sailors, coaches and parents watch the race again on the map after it has finished, seeing every boat's track laid out over the course. On the website's Tracker Demo, replays include coloured progressive trails, boat arrows rotated to their heading, the course marks, a wind dial and a live-sorted leaderboard, with playback speeds of 2x, 5x, 15x and 30x and a timeline scrubber. This makes it easy to jump to the start, a key mark rounding or a decisive shift and study exactly what happened.

It gives coaches and sailors an objective record of the whole fleet to work from, so a debrief can focus on what actually happened rather than differing recollections. By replaying the session with fleet overlays and comparing sailors side by side, a coach can pinpoint where time was gained or lost at the start, on the laylines, or in the shifts. This evidence-based approach helps sailors understand their tactical decisions and improve faster.

Sail Race Tracker is aimed at youth sailing dinghy classes, specifically the Optimist, Starling, 29er, ILCA and iQFOiL. These cover a large part of the youth pathway in New Zealand, where there are thousands of youth sailors. Because the tracker is a self-contained waterproof unit mounted on the mast, it is not tied to any one boat design and can be assigned to boats across these classes.

Yes. The system is designed to bring America's-Cup-style live fleet maps to club and school regattas at a fraction of the usual cost, so both sailing clubs and schools are core intended users. Its creator, Jack Harker, is a youth sailor and Year 10 student — that's me — and I'm especially keen to hear from sailing clubs and schools willing to host on-water testing. The low target cost of under NZ$50 per unit is aimed at making fleet tracking realistic for community clubs and schools rather than only well-funded professional events.

That is exactly the scale it is designed for. Major youth regattas can have 100 to 200 dinghies on one course, and Sail Race Tracker is built to scale from a 5-boat training session up to that size. The economics are a big part of the point: outfitting a 200-boat regatta with commercial trackers would cost over NZ$180,000 in equipment alone, whereas this system targets under NZ$50 per unit with no SIM cards or subscriptions. The 2025 field trials ran with 4 race boats as a proof of concept, so large-fleet reliability is still being developed.

For those running a regatta, it offers a single live view of the whole fleet, which supports faster setup, fairer starts and finishes, and quicker location of any boat in trouble. The planned admin dashboard in the 2026 rebuild adds fleet management, a click-to-drop course builder, race control and a live node-health monitor, so organisers can manage devices and courses from one place. Reducing the number of chase and safety powerboats needed also cuts cost, noise, fuel use and congestion on the course.

Today, spectators and coaches often follow youth races in powerboats, which is costly, noisy, risky, fuel-burning and congests the race course. Sail Race Tracker lets them watch the whole fleet from shore on a phone or tablet instead, so there is less need for chase boats. That means lower fuel use, improved safety, and less crowding on the water, while still giving coaches and parents a clear view of every boat in the race.

No. The live map dashboard runs in any standard web browser, so parents only need a phone, tablet or laptop to watch from the shore or clubhouse. There is no app to install and no special hardware on the spectator's side, since the trackers on the boats and the support-boat gateway do all the work. In the field trials, parents were keen to watch from the clubhouse and their phones, and coaches were impressed at being able to track the fleet without chasing it.

Sail Race Tracker is a working, field-tested proof of concept, and the focus now is turning it into a reliable product. There are four main next steps: custom Arduino-based firmware for continuous time-stamped GPS, a custom PCB to shrink and cheapen the tracker, a full web app for race setup and management, and smarter on-device features like screens and motion sensors. A 2026 rebuild covering the firmware and cloud backend is already underway. It's honest to say this is still a work in progress rather than a finished commercial product.

No — Sail Race Tracker is a working end-to-end proof of concept that has been field-tested on the water, but it is not yet a commercial product. The 2025 system proved the whole data flow works, from boat to LoRa radio to a support-boat gateway to a live web dashboard. The project is now in a 2026 rebuild phase to move from proof of concept toward something production-ready. I'm upfront that there's still real engineering to finish before it could be sold or widely deployed.

The four next steps are: (1) custom firmware — replacing Meshtastic with Arduino-based code for continuous, time-stamped GPS; (2) a custom PCB combining the ESP32, GPS and LoRa on a single cheap board; (3) a full web app for race setup, sailor and device pairing, replay, and multi-race regatta management; and (4) smarter devices with an on-device screen and motion sensors for capsize detection and heel angle. These build directly on the lessons from the 2025 field trials. Together they address cost, reliability and usability — the things race officials said matter most.

The 2026 rebuild is the work now underway to take Sail Race Tracker from proof of concept toward production. It replaces the Meshtastic-based system with custom ESP32 firmware, adds a base node running TDMA time-slot scheduling, a Raspberry Pi gateway, and a proper cloud backend built on Cloudflare. It also introduces new viewer and admin dashboards. The rebuild has already been verified end-to-end with a real Auckland GPS fix.

The main reason is the Meshtastic bottleneck. Meshtastic was a great platform for proving the concept, but its message scheduling and mesh optimisation throttle how often GPS can be sent, producing sporadic, gappy position data rather than a smooth time-stamped trail. This was confirmed as the main issue during the July 2025 field trials. The rebuild replaces Meshtastic with custom firmware so each boat logs continuous time-stamped GPS and the base can compile a complete record.

The plan is to replace Meshtastic with custom ESP32 firmware written in Arduino/PlatformIO. Each boat logs time-stamped GPS fixes and sends packaged historical fixes over a private LoRa channel, so the base can compile a complete, smooth record rather than the gappy data Meshtastic produced. The firmware targets LilyGo/TTGO LoRa32 boards (SX1276 radio, SSD1306 OLED) and a Seeed XIAO ESP32-S3 with a Wio-SX1262 radio, with a base node running TDMA time-slot scheduling and a beacon. Per-boat configuration for sailor ID, fleet and logging mode is part of the design.

The custom PCB would combine the key parts — an ESP32, a NEO-M8 GPS module and a LoRa radio — onto a single purpose-built board, with optional extras like Bluetooth, a gyro/accelerometer and a small OLED screen. This cuts cost, size and weight compared with wiring together separate development boards. The plan is to fabricate it cheaply through a Chinese board house such as JLCPCB or PCBWay. This is a future step rather than something built yet, but it's central to hitting the under-NZ$50-per-unit target at scale.

The planned full web app covers the whole race workflow: race setup, sailor and device pairing, training modes, replay with a time slider, and a multi-race regatta dashboard. It also adds safety and fairness features like capsize alerts and rule-violation flags. In the 2026 rebuild this is split into a public viewer dashboard and a key-gated admin dashboard. The goal is that a coach or race officer could run everything from a browser without needing technical setup each time.

The rebuild introduces two Cloudflare Pages dashboards. The public viewer has a race picker, live WebSocket tracking, a replay scrubber at 2×, 5×, 15× and 30× speeds, a leg-detection leaderboard and a wind-from-course dial. The key-gated admin dashboard adds fleet management with TDMA slot assignment, a click-to-drop course builder, race control, a live node-health monitor and an audit log. Together they give spectators a clean live view and officials the controls they need to run a race.

The 2026 rebuild uses a Cloudflare-based backend. A Cloudflare Worker built with the Hono framework handles requests, backed by a D1 (SQLite) database, and a Durable Object called "RaceRoom" fans out live GPS fixes to viewers over WebSockets. Endpoints include POST /ingest for incoming fixes, GET /race/current, and a WebSocket at /races/:id/live. This replaces the earlier proof-of-concept stack of a local Flask API and SQLite on the Raspberry Pi.

Capsize alerts are a planned feature, not yet a finished one. The idea is to use on-device motion sensors — a gyro and accelerometer — to detect when a boat has capsized and flag it automatically, so race officials can quickly locate a boat in trouble. This ties directly to safety, which officials stressed is essential for race-official use. During the 2025 trials the trackers already survived capsizes and re-acquired GPS within 30–60 seconds, so the hardware handles the conditions; the automatic detection is the next layer to add.

Yes, that's part of the "smarter devices" step on the roadmap. By adding motion sensors to the tracker, the system could measure heel angle and tacking efficiency, giving sailors and coaches richer analytics than position alone. This turns objective on-water data into coaching feedback about technique, not just where boats are. It's a planned enhancement rather than something in the current proof of concept.

Multi-race regatta management is a core part of the planned full web app and the 2026 rebuild. The viewer dashboard already includes a race picker to switch between races, and the admin side is designed for fleet management and race control across an event. The aim is to scale from a 5-boat training session up to a 100–200-boat regatta. This directly addresses the big regattas where following the racing from shore is hardest today.

A production version would pair a compact, cheap custom PCB tracker — ESP32, GPS and LoRa on one board, possibly with motion sensors and a small screen — running custom firmware that streams continuous time-stamped GPS. On the software side it would offer a full web app for race setup, device pairing, replay, multi-race regatta dashboards, capsize alerts and rule-violation flags. It would keep the core promises: waterproof, SIM-free, a full race day of battery, and an under-NZ$50-per-unit target. The 2026 rebuild is the first serious step toward that picture.

There isn't a fixed launch date — Sail Race Tracker is honestly still a work in progress. The 2025 proof of concept works end to end and has been field-tested, and the 2026 rebuild of the firmware and cloud backend is already underway and verified in early testing. But turning it into a polished, reliable product still involves finishing the custom firmware, designing a custom PCB, and building out the full web app. Reliability matters especially for race-official use, so the priority is getting it right rather than rushing.

The planned on-device screen would show sailing-relevant information directly on the tracker, such as a start countdown and recall or OCS (on-course-side) flags. This means a sailor could get race signals without a phone, which is important because phones are banned in dinghy racing. It's part of the "smarter devices" step of the roadmap. Some of the target boards already include an OLED display, so the hardware groundwork is there.

In the rebuilt architecture, each boat's custom firmware sends time-stamped GPS fixes over a private LoRa channel to a base node that uses TDMA scheduling. A Raspberry Pi gateway reads the base over a serial connection and POSTs the fixes to the cloud, with a local store plus retry and dead-letter handling so nothing is lost if the connection drops. The Cloudflare Worker ingests the fixes and a Durable Object streams them live to dashboards over WebSockets. This is a cleaner, more reliable pipeline than the 2025 MQTT-and-Flask proof of concept.

The roadmap is deliberately staged and grounded in what's already been proven on the water, rather than being a wish list. The 2025 field trials at Royal Akarana Yacht Club validated the whole concept, and the 2026 rebuild has already been verified end-to-end with a real Auckland GPS fix, so the pathway is concrete. I'm a Year 10 competitive sailor who has done the coding, assembly, testing and design myself, using ChatGPT as a research and coding tutor. The honest framing is that each step — firmware, PCB, web app, smarter devices — is real engineering that takes time, and the project is progressing steadily rather than claiming to be finished.

Not just yet — the Sail Race Tracker is a working, field-tested proof of concept, not a finished commercial product, so there's nothing for sale off the shelf right now. That said, I genuinely welcome interest from anyone keen to trial or eventually buy a unit, and a 2026 rebuild with custom firmware and a cloud backend is currently underway. If you'd like to register your interest, email me — Jack Harker — at info@sailracetracker.live and let me know a bit about your fleet and timeframe.

To be honest and upfront: no, it isn't for sale as a commercial product yet. It's an open-source proof of concept that has been tested end-to-end on the water at Royal Akarana Yacht Club, and I'm actively rebuilding it in 2026 to move it closer to production. If you're interested in what happens next, get in touch at info@sailracetracker.live and I'll keep you in the loop.

The best way is to email me — Jack Harker — directly at info@sailracetracker.live — that address is already public on the project site. When you reach out, it helps to include your fleet size, the class you sail (Optimist, Starling, 29er, ILCA, iQFOiL or similar), your club or school, and the timeframe you have in mind. I'm especially keen to hear from people who want to help with further on-water testing.

Yes — I'm especially keen to hear from sailing clubs and schools willing to host on-water testing, since real regatta and training conditions are exactly what the project needs next. The system has already been trialled over three days at Royal Akarana Yacht Club with four race boats and a support-boat gateway. To arrange a trial, email info@sailracetracker.live with your club name, fleet size, the classes you run, and a rough timeframe.

Clubs and schools can host testing during regular training days or regattas — the 2025 field trials ran alongside RAYC holiday sail training, tracking boats live as they left the shore, surviving capsizes, and lasting a full race day on battery. Hosting typically means providing a handful of boats to carry trackers plus a support or committee boat for the gateway. If your club or school would like to get involved, contact me at info@sailracetracker.live with details of your fleet and available dates.

On-water testing is one of the most valuable ways to help, and I'm actively looking for clubs, schools and coaches willing to run trackers during training or racing. Real-world feedback from coaches, sailors and parents directly shaped the project during the RAYC trials. To put your hand up, email info@sailracetracker.live and mention your class, fleet size, club and when you could test.

I warmly welcome potential sponsors and supporters who share the goal of affordable, accessible race tracking for youth sailing. Because the project is open-source and community-driven, support of any kind — funding, hardware, hosting, or connections — helps move it from proof of concept toward a real product that clubs can afford. If you'd like to sponsor or support the project, please email me — Jack Harker — at info@sailracetracker.live.

Absolutely — the project is open-source and I'm keen to hear from makers and engineers who want to contribute to the firmware, web app or hardware. The 2026 rebuild involves custom ESP32 firmware (Arduino/PlatformIO), a Cloudflare Worker cloud backend, and dashboards, so there's plenty of scope to help. If you'd like to get involved, email info@sailracetracker.live and let me know where your skills fit.

The rebuild uses custom ESP32 firmware in Arduino/PlatformIO, a Cloudflare Worker (Hono) backend with a D1 database, and Leaflet-based dashboards, so developers who know embedded C++, LoRa, Python, or web front-ends can all contribute meaningfully. Anyone from the LoRa or open-source community is especially welcome. Reach out to me at info@sailracetracker.live to talk about where you could help.

Yes — I welcome hardware contributions, whether that's help with the tracker enclosure, 3D-printed mast mount, GPS and LoRa boards, or the future custom PCB that would cut cost, size and weight. The current build uses off-the-shelf parts like the TTGO LoRa32, a u-blox NEO-M8N GPS, and an IP67 case, all with an under-NZ$50-per-unit target. If hardware is your thing, email info@sailracetracker.live to get involved.

I'm very keen to work with youth sailing bodies and associations — the project was presented to the NZIODA National Committee on 1 July 2025, where it drew strong interest and support, with officials noting that reliability is essential for race-official use. Building relationships with organisations like these helps make sure the tracker meets real racing needs. If you represent a sailing body and would like to talk, email me at info@sailracetracker.live.

The simplest way to reach me, Jack Harker, is by email at jackharker000@gmail.com — that address is public on the project site and is the right place for anything to do with trials, buying interest, sponsorship, contributing, partnerships, media or speaking requests. I'm a Year 10 competitive youth sailor in Auckland, New Zealand, and I welcome friendly enquiries. Just include a bit of context about who you are and what you're after, and I'll get back to you.

To help me respond usefully, include the essentials: your fleet size, the class or classes you sail, your club or school, and the timeframe you're working to. If you're interested in testing or buying, that context lets me gauge how the system would fit your situation; if you're offering to contribute or sponsor, a quick note on how you'd like to help is perfect. Send it all to info@sailracetracker.live.

Yes — open-source is central to the project's ethos, which is deliberately community-driven and built to be affordable and accessible. The proof of concept ran on open tools like Meshtastic, Flask, SQLite and Leaflet.js, and the 2026 rebuild continues in that spirit. If you'd like to contribute to the open-source effort or learn more, email me at info@sailracetracker.live.

Media and press are very welcome — the project has already been featured on RNZ's Nine to Noon and covered by Samsung NZ, Idealog, MOTAT and TENZ following its Samsung Solve for Tomorrow 2025 first prize. For interviews, background, imagery or the project film, email me — Jack Harker — at jackharker000@gmail.com. There's also a Samsung Solve for Tomorrow film on YouTube and a podcast interview available as reference.

Yes — I'm happy to consider speaking and demo requests, having already presented the project to the NZIODA National Committee and shared it through the Samsung Solve for Tomorrow and NIWA science fair events. A talk can cover the problem, how the LoRa-based system works, the on-water trials, and the honest journey of building a proof of concept as a student. To request a speaking slot or demonstration, email info@sailracetracker.live with your event details and timeframe.

Sail Race Tracker is a working end-to-end proof of concept, not a finished commercial product. Its main limitation is the Meshtastic firmware used in the 2025 build: Meshtastic's message scheduling and mesh optimisation throttle how often GPS data is sent, producing sporadic, gappy position data rather than a smooth time-stamped trail. This is a software limitation rather than a hardware one, and it is exactly what the 2026 rebuild with custom ESP32 firmware is designed to fix. Other honest limits include a buffered delay of 30–60 seconds, dependence on a support-boat hotspot for live cloud updates, and GPS accuracy of roughly 2.5 metres.

No. It is a field-tested proof of concept I built — I'm youth sailor Jack Harker — and it has been proven to work end-to-end from boat to shore dashboard. It is not yet a commercial product, and a 2026 rebuild with custom firmware and a cloud backend is currently underway to move it towards production. If you are interested in trialling or supporting the project at this stage, you can reach me at info@sailracetracker.live.

The 2025 proof of concept runs on Meshtastic firmware, which is excellent for getting a mesh network going quickly but throttles how often and how much GPS data each boat can send. The result is sporadic, gappy position data instead of a continuous, smoothly time-stamped trail. This is a known software bottleneck, not a fault in the hardware. The 2026 rebuild replaces Meshtastic with custom ESP32 firmware that logs time-stamped GPS on each boat and sends packaged historical fixes, so the base can compile a complete record.

That is the honest open question the project is working to answer. When Sail Race Tracker was presented to the NZIODA National Committee on 1 July 2025, officials showed strong interest and support but stressed that reliability is essential for any race-official use. The current Meshtastic-based proof of concept has gaps in its data that make it better suited to spectating and coaching than to official decisions, which is a key reason for the 2026 rebuild aimed at continuous, complete position records. Until that reliability is proven, it should be treated as a supplementary tool rather than an authoritative source for race management.

No. Sail Race Tracker is not a safety-of-life device and is not a replacement for proper on-water rescue cover, safety powerboats, or standard race-safety procedures. It is a race-tracking and spectating tool, and while a live full-fleet view could in future help officials locate distressed, capsized, or drifting boats, that is an aspiration rather than a certified safety function. It should always be used alongside — never instead of — the normal safety arrangements for a regatta.

The trackers use a u-blox NEO-M8N GPS module with accuracy of roughly 2.5 metres, which is plenty for sailing tactics such as reviewing starts, laylines, and shifts. Higher-precision RTK GPS with centimetre accuracy was considered but rejected for now because it costs NZ$100–200 or more per unit and needs a base station. For fleet racing, relative consistency across all the boats matters more than absolute precision, so 2–5 metre accuracy is more than adequate for the intended use.

The system uses LoRa (long-range radio) on the 915 MHz ISM band, which can reach up to 2–10 km in open environments and works especially well over open water where there are few obstacles. Range is not fixed, though — it depends on conditions and particularly on antenna elevation, since a higher, elevated antenna on the support boat noticeably improves coverage. As with any radio system, range and reliability can vary with the environment, so real-world coverage should be confirmed on the water for each venue.

The boats themselves need no internet and no SIM cards — positions travel over LoRa radio to a gateway on the support boat. However, for live tracking to reach the cloud dashboard, the gateway relies on a phone hotspot on the support boat. This introduces a dependency: during the July 2025 field trials the cloud link worked via a coach's iPhone hotspot, but the iPhone battery went flat before the end of the day, which confirmed that an external power source is needed for reliable all-day live tracking.

Sail Race Tracker uses a slight buffered delay of around 30–60 seconds between what happens on the water and what appears on the dashboard. This is a deliberate design choice and is perfectly fine for spectators, coaches, and parents following the race from shore. It does mean the tracker is not intended for split-second, real-time official decisions, which is another reason it is positioned as a spectating and coaching tool rather than a live race-management system.

Capsizes were a core design requirement, since youth dinghies capsize frequently. The trackers are housed in IP67-rated waterproof enclosures built to survive frequent capsizes and full submersion, and during the July 2025 water trials the units survived capsizes and re-acquired a GPS fix within about 30–60 seconds afterwards. There will naturally be a short gap in the data while the boat is over and the GPS re-fixes, so a capsize is one situation where a brief interruption in tracking is expected rather than a fault.

Each boat tracker uses a 3.7V lithium battery (18650 Li-ion or LiPo) sized to last a full race day of 8-plus hours, with easy overnight USB-C recharging, and this was confirmed on the water during the field trials. The bigger power limitation is on the support boat: the gateway's cloud link runs off a phone hotspot, and a flat phone battery will cut live updates. For dependable all-day live tracking the support-boat setup needs external power, such as the 10,000mAh USB power bank used in the gateway kit.

Sail Race Tracker is not a certified commercial product, not a safety-of-life device, and not a replacement for proper rescue cover or standard race-safety procedures. It is also not currently a fully reliable source for official race decisions, because the 2025 Meshtastic-based build produces gappy data and carries a 30–60 second buffered delay — limitations the 2026 rebuild is addressing. What it is: an affordable, SIM-free, open-source proof of concept that brings live, America's-Cup-style fleet tracking to youth sailing for spectators, coaches, and sailors, with an honest roadmap toward becoming reliable enough for official use.

Yes, and I'm open about it — I used ChatGPT as a 24/7 research tutor and coding mentor throughout the project. It helped me plan the roadmap, research options, set up my MacBook and Raspberry Pi, and work through things like MQTT, SQLite, Flask and Leaflet. But all the physical testing, coding, assembly and design decisions were made by me, so I retain full ownership of the work.

No. The best way to think about it is a student working with an expert tutor who is available around the clock. AI answered questions and helped me debug, but I still had to understand the concepts, write and flash the code, wire the hardware, 3D-print the mounts, and take everything out on the water to test it. The learning, the decisions and the hands-on work were all mine.

ChatGPT acted like a personal mentor I could ask anything, any time. It supported me with the project roadmap, background research, setting up my development machines, and getting to grips with tools like the Mosquitto MQTT broker, SQLite, the Flask API and the Leaflet map. When something wasn't working, it helped me reason through the debugging — but I was the one applying the fixes and confirming them in real-world tests.

My approach shows how AI can support learning without replacing the student's own work. Rather than having AI do the project for me, I used it as a tutor to learn faster and go deeper than I could alone — while still doing all the building, testing and decision-making myself. Being transparent about that, and keeping ownership of the actual work, is what makes it a genuine learning story.

On the software side, I worked in VS Code with PlatformIO for firmware, Python for the backend, Flask to serve the data, and Leaflet.js for the live web map. Meshtastic firmware ran on the boat trackers in the proof-of-concept, and the site and dashboards have been hosted and tested via services like Vercel and Cloudflare. It's a deliberately affordable, open toolset rather than expensive commercial software.

Quite a lot — and that was part of the point. He learned to flash microcontroller firmware with PlatformIO and the Meshtastic CLI, run a headless Raspberry Pi over SSH, parse radio packets with an MQTT broker and Python, store positions in a SQLite database, and serve them to a Leaflet map through a Flask API. Each layer was a new skill picked up during the build.

Yes — open source is a core part of the ethos. Sail Race Tracker is described as a low-cost, SIM-free, open-source GPS race-tracking system, built to be affordable, community-driven and accessible. The idea is that clubs, schools and makers should be able to use and build on it rather than being locked into expensive proprietary trackers.

Because the whole problem I set out to solve was cost and accessibility. Commercial trackers run to hundreds of dollars per unit plus monthly subscriptions, which puts fleet tracking out of reach for youth and club sailing. Keeping Sail Race Tracker open source and low-cost means the technology can spread through the sailing community instead of sitting behind a price tag.

It fits the project's mission of being genuinely affordable. Leaflet.js was chosen over Google Maps and Mapbox partly to avoid cost and API keys, LoRa radio needs no SIM or subscription, and the development boards and GPS modules are all inexpensive. Using open, free-tier and low-cost tools keeps the running costs near zero and makes the whole system something a club could actually afford.

A lot of the sailing community got behind it. I thank the coaches, sailors and parents at Royal Akarana, Kohimarama, Wakatere, Murrays Bay and Maraetai Beach clubs, along with Yachting NZ, NZIODA and High Performance Sport NZ. My friend Clemens helped with web hosting on Vercel, and my family supported me throughout.

My friend Clemens helped with the web hosting side, including getting the site up on Vercel. It's one example of how the project came together with support from friends and the wider community, alongside my own work on the firmware, hardware and dashboards.

That you can take on a genuinely ambitious, real-world project as a student by pairing curiosity with the right support. I used AI as a tutor to learn quickly, leaned on the sailing community and friends for help and testing, and chose open-source, low-cost tools — but I did the hands-on building, testing and problem-solving myself. The takeaway is that AI and open tools can accelerate your learning without doing the work for you, as long as you stay honest about it and keep ownership of what you create.

The trackers run on the ANZ region so the LoRa radios operate in the 915 MHz ISM band, which is the licence-free frequency legally allowed for this kind of use in New Zealand. The region setting controls the frequency range, duty-cycle limits and channel plan that the firmware is permitted to use, so it has to match the country you are in. Getting this right is not just a technical detail — using the correct 915 MHz NZ band means no SIM cards, no towers and no radio-licence contracts. Every node in the fleet must be set to the same region or they simply will not hear each other.

In the 2025 proof-of-concept each boat's Meshtastic node broadcasts its GPS position roughly every 5 to 10 seconds. This is set through the position broadcast interval (the `positionBroadcastSecs` value in Meshtastic's position configuration), which trades responsiveness against airtime and battery. A shorter interval gives a smoother track but uses more radio airtime and power; because LoRa packets are tiny and the band is shared, you cannot simply set it to broadcast every second for a whole fleet without swamping the channel.

Both. Simpler settings can be changed through the Meshtastic mobile app over Bluetooth, but for repeatable, scriptable configuration the project uses the Meshtastic CLI on the MacBook and Raspberry Pi. Commands take the form `meshtastic --set <setting> <value>` — for example setting the region, the position broadcast interval, or the device role. The CLI is preferred for the fleet because you can apply identical settings to every node and script the process rather than tapping through an app for each device.

Yes. For the nodes to form one network and exchange position data they must share the same LoRa channel settings, including the channel name and the pre-shared key (PSK) that Meshtastic uses to encrypt traffic on that channel. If two nodes are on different channels or have mismatched PSKs, they will not decode each other's packets even though they are on the same 915 MHz frequency. Keeping a single shared channel across the fleet is what lets the gateway on the support boat receive every boat's positions.

In the 2025 setup every boat carries a standard Meshtastic node that broadcasts its own GPS and relays others' packets, while one node on the support or committee boat is designated as the gateway. The gateway node is the one wired by USB into the Raspberry Pi, where it hands packets off to the MQTT broker and Python listener. The role influences how a node behaves in the mesh — the boat nodes are position beacons and relays, and the gateway is the bridge that gets data off the water and into the database.

On the TTGO LoRa32, which has no onboard GPS, the u-blox NEO-M8N connects over UART: the GPS TX pin goes to the ESP32 RX on GPIO34, and the GPS RX goes to the ESP32 TX on GPIO12, with VCC on 3.3V and a shared GND. That gives a two-wire serial link plus power. GPS modules and the ESP32 both talk serial, so the "TX to RX, RX to TX" crossover is essential — wiring TX to TX would mean neither side ever hears the other.

During the 2026 rebuild a GPS bug on boat 1 was traced to the serial TX line, and the fix was to run the GPS link receive-only: `gps_tx` was set to -1 and `gps_rx` was set to 34. Since the ESP32 only ever needs to read the stream of position sentences coming out of the GPS, it does not actually need to transmit back to the module for basic tracking, so dropping the TX pin removed the source of the fault. This is a good example of how a tiny pin-level configuration change can resolve a stubborn hardware bug.

Meshtastic is built for off-grid messaging, so its message scheduling and mesh-optimisation logic deliberately throttle how often and how much data each node sends to keep the shared radio channel from congesting. For race tracking that means position updates arrive sporadically, leaving gaps in the trail rather than a smooth, evenly time-stamped track. Importantly this is a software limitation of Meshtastic's design, not a limit of the LoRa radios or GPS hardware — which is exactly why the 2026 rebuild replaces Meshtastic with custom firmware.

The 2026 rebuild replaces Meshtastic with custom ESP32 firmware written in Arduino/PlatformIO. Instead of broadcasting single positions at intervals, each boat logs time-stamped GPS fixes locally and sends packaged batches of historical fixes over a private LoRa channel, and the base node compiles them into one complete record. This approach fills the gaps that Meshtastic left, because no fix is lost simply because the channel was busy at the moment it was recorded — the boat can send it a little later as part of a batch.

TDMA (time-division multiple access) means each boat is given its own time-slot in which to transmit, coordinated by a beacon from the base node. In the 2026 firmware the base node runs the TDMA scheduling and broadcasts the beacon that keeps every boat's clock and slot aligned. This prevents two boats transmitting at the same instant and colliding on the shared 915 MHz channel — a disciplined schedule scales far more reliably to a large fleet than everyone talking whenever they like.

Yes. The custom firmware supports per-boat configuration including a sailor ID and fleet, so each device is tied to a specific boat and sailor rather than just an anonymous radio ID. In the 2025 Meshtastic setup each node already had a short name and node ID stored with its positions in the database. The 2026 admin dashboard extends this with fleet management that assigns each boat its TDMA slot alongside its identity, so the leaderboard and replay can label every track correctly.

The 2025 proof-of-concept used Meshtastic's self-healing mesh, where boats could relay one another's packets to reach the gateway. The 2026 rebuild moves toward a more structured point-to-point / TDMA arrangement on a private LoRa channel: boats transmit in scheduled slots to the base node rather than relying on ad-hoc mesh hopping. Over open water, where there are few obstacles between the boats and an elevated antenna on the support boat, a scheduled point-to-point scheme gives more predictable, gap-free data than mesh relaying.

Meshtastic firmware is flashed through the official web flasher at flasher.meshtastic.org, which runs in the browser and talks to the board over USB. This has to be done in Google Chrome — Safari does not support the Web Serial connection the flasher relies on, so it will not work. For the custom 2026 firmware the boards are built and uploaded from PlatformIO on the MacBook instead, which is the standard Arduino/ESP32 development toolchain.

They are two different LoRa transceiver chips used on different boards. The LilyGo/TTGO LoRa32 board used in the 2026 build carries an SX1276 radio (paired with an SSD1306 OLED display), while the Seeed XIAO ESP32-S3 build pairs with a Wio-SX1262 radio module. Both operate on the same 915 MHz band and do the same job of sending and receiving the tiny LoRa packets; the difference is which board and radio combination the firmware is compiled for, so the firmware has to target the correct radio chip for each board.

The base node's beacon is the heartbeat that keeps the TDMA schedule synchronised, telling every boat when the transmission cycle starts so each one knows exactly when its slot comes around. Because the boats send historical batches of time-stamped fixes rather than only live positions, a boat that briefly loses the beacon or its slot does not permanently lose data — it can send the buffered fixes once it re-syncs. This buffered, batch-and-catch-up design is the core reason the custom firmware produces a complete race record where Meshtastic left gaps.

LoRa in Sail Race Tracker runs on 915 MHz, which sits in the sub-GHz ISM (Industrial, Scientific and Medical) band that is licence-free in New Zealand. Using an ISM band means there are no network contracts, no SIM cards, and no ongoing spectrum fees — you can transmit legally without a radio operator's licence. This was one of the deciding factors in choosing LoRa: the radio side of the system carries near-zero running cost, which is essential for a fleet of 100–200 boats.

Open water is close to an ideal radio environment because there are very few obstacles — no buildings, hills, or trees to block or scatter the signal between a boat and the support-boat gateway. Sub-GHz frequencies like 915 MHz also travel further and bend around minor obstructions better than higher-frequency bands such as Wi-Fi's 2.4 GHz. The brief notes LoRa "works brilliantly over open water" for exactly this reason, which is why it beat Wi-Fi (roughly 50m range) so decisively for on-the-water use.

The 2–10 km figure is the theoretical open-environment range for LoRa, and it assumes clear line-of-sight with well-positioned antennas. Sail Race Tracker's own design target was more modest and realistic — reliably covering distances of roughly 500 m to 2 km, which is the typical spread of a youth dinghy course. During the July 2025 RAYC field trials the system tracked four boats plus the support boat concurrently with no packet collisions or data loss, so the working range comfortably covered the trial course, even if it did not attempt the full 10 km theoretical maximum.

Radio range over water depends heavily on antenna height because it extends the effective line-of-sight horizon — the higher the antenna, the further it can "see" past the curve of the water surface and any wave chop. The support-boat gateway therefore uses a vertical, elevated SMA LoRa antenna specifically to improve coverage across the fleet. Raising the gateway antenna is one of the simplest ways to boost how many boats stay in reliable contact.

SMA is a common screw-on connector standard for small radio antennas, and the support-boat gateway uses a vertical internal SMA LoRa antenna mounted for height and range. The SMA connection makes it easy to swap or upgrade antennas without soldering. On the boat trackers the antennas are kept inside the sealed case rather than on external SMA connectors, but waterproof cable glands are available if an external SMA antenna is ever needed.

The boat trackers keep both the LoRa and GPS antennas inside the sealed IP67 ABS enclosure, and no holes are drilled through the case. This decision was based on bench testing during the design phase, which showed no meaningful LoRa or GPS signal loss through the plastic. Keeping the antennas internal preserves full waterproofing — a critical requirement given the trackers must survive frequent capsizes and full submersion — with waterproof cable glands held in reserve should an external antenna ever prove necessary.

LoRa deliberately trades bandwidth for range and low power — it is designed to send tiny packets of data over long distances using very little battery. A GPS fix is just a handful of numbers (node ID, latitude, longitude, battery level, timestamp), which fits easily within LoRa's limited bandwidth. Anything data-heavy like photos or video is far too large to stream over LoRa, so any camera-based protest footage envisioned for future devices would need to be stored on the device rather than transmitted live over the radio.

In the 2025 proof-of-concept, positions hop across a self-healing LoRa mesh: each boat can relay another boat's data if that boat is out of direct range of the gateway, and the network reroutes automatically if a node drops out. This mesh behaviour came from the Meshtastic firmware the trackers originally ran. The 2026 rebuild moves away from that model toward a private point-to-point channel with a base node running TDMA (time-division) scheduling, trading the mesh's automatic relaying for tighter control over exactly when each boat transmits.

Packet collisions are a genuine concern when lots of boats broadcast on one channel, but during the 3-day RAYC field trials with four boats plus the support boat there were no packet collisions or data loss observed. The bigger issue that surfaced was not collisions but Meshtastic's own message scheduling throttling how often GPS data was sent, producing gappy tracks. To manage transmissions cleanly at larger fleet sizes, the 2026 rebuild introduces TDMA time-slot scheduling, where a base node assigns each boat its own slot so their transmissions don't overlap.

LoRaWAN is a full networking standard built on top of LoRa radio, typically involving managed gateways and network servers. Sail Race Tracker does not use LoRaWAN — the 2025 system used Meshtastic's LoRa mesh, and the 2026 rebuild uses raw LoRa on a private channel with custom ESP32 firmware controlling transmissions directly. Working closer to the raw radio gives me full control over packet timing and format, which is exactly what was needed to fix the gappy-data problem that a higher-level stack was causing.

Because 915 MHz is a shared ISM band, other unlicensed devices can in principle use the same frequencies, but open water has far fewer competing transmitters than a built-up area, which helps in practice. Operating within the licence-free ISM band means no radio licence or spectrum fee is required in New Zealand. The main real-world reliability challenge observed in trials was not outside interference but the firmware's own data-rate limits, which the custom rebuild addresses.

The brief sets a design goal of scaling from a 5-boat training session up to a 100–200-boat regatta, but the 2025 proof-of-concept was only field-tested with four boats at once. The limiting factor on a single channel is airtime — how the available transmit time is shared among boats — which is precisely why the 2026 rebuild adds TDMA time-slot scheduling to give each boat a defined slot. Supporting a full regatta-scale fleet on one channel is a target the custom firmware is being built toward, not something yet proven on the water.

Each alternative failed at least one core requirement: cellular needs SIM cards (which carry cost and are effectively banned by dinghy phone rules) and is power-hungry; Wi-Fi reaches only about 50 m; satellite is too slow and expensive for real-time fleet tracking; and Bluetooth is far too short-range. LoRa was the only option meeting every goal at once — long range, very low power for all-day battery life, no SIM or ongoing data fees, and low unit cost. That combination is why it became the backbone of the whole system.

No — the boats themselves need no internet, no SIM cards, and no mobile coverage at all. They simply broadcast GPS positions over LoRa radio to the support-boat gateway, which works even in areas with no cellular signal. Internet only enters the picture at the gateway, where a phone hotspot on the support boat pushes the collected data up to the cloud; the entire on-water radio link is completely independent of any mobile network.

In the 2025 proof-of-concept each boat broadcast its GPS position roughly every 5–10 seconds over LoRa, and the tracker demo samples positions every 10 seconds. Broadcasting more frequently would consume more battery and more of the shared channel's airtime, raising the risk of congestion as the fleet grows, so the interval balances responsiveness against power and bandwidth. A slight buffered delay of 30–60 seconds before positions reach spectators is perfectly acceptable, since racing runs all day and spectators don't need split-second live data.

The boat tracker uses a u-blox NEO-M8N GPS module, connected to the TTGO LoRa32 board over UART. It was chosen for its roughly 2.5m accuracy, fast fix time, high refresh rate (1Hz or better) and low price (around NZ$15–20), while still being well supported in the DIY LoRa and Meshtastic community. It hit the sweet spot of being accurate and quick enough for fast-moving dinghies without pushing the per-unit cost past the under-NZ$50 target.

The NEO-M8N delivers position accuracy of about 2.5m under good conditions. For dinghy racing that is more than enough, because the system relies on relative consistency across the fleet rather than survey-grade absolute accuracy. Being able to see who crossed a line first, and how boats moved relative to each other, is what matters for tactics and replay.

If every boat has a similar 2–3m GPS error and that error is consistent, you can still clearly see who was ahead, who crossed the start line first, and how the fleet spread out. Absolute position (exactly where a boat sits on the planet) matters far less than how boats compare to one another on the same course at the same moment. This insight is what justified using an affordable sub-NZ$20 GPS chip instead of an expensive centimetre-grade one.

Yes. The project's research concluded that even 5–10m accuracy is highly valuable for training and tactical replay, so the NEO-M8N's ~2.5m is comfortably within useful range. At that resolution you can review starts, laylines, wind shifts and mark roundings well enough to learn where time was gained or lost. Youth sailors and coaches don't need centimetre precision to have an evidence-based debrief.

The NEO-6M is a common, cheaper (~NZ$10) module used in many budget LoRa builds, but it has slower fix times and lower sensitivity, with accuracy around 5m. That makes it less suitable for rapid repositioning in fast-moving dinghies. The NEO-M8N was chosen instead because its faster fix and ~2.5m accuracy suit the quick, dynamic movement of racing boats.

RTK (Real-Time Kinematic) GPS can achieve centimetre-level accuracy, but it was rejected for now because it is expensive (roughly NZ$100–200+ per unit) and requires a fixed base station to work. That cost and complexity clashes directly with the under-NZ$50-per-unit goal and the aim of keeping the system simple to deploy across a whole fleet. The project has deliberately left RTK open as a possible upgrade for future iterations.

It's a possibility for future iterations rather than a near-term plan. RTK would give centimetre accuracy, which could be interesting for very precise start-line or mark-rounding analysis, but it needs a base station and adds significant cost per boat. For the current goal of affordable, fleet-wide youth tracking, ~2.5m from the NEO-M8N is the right trade-off, so RTK stays on the "future" list.

Each boat broadcasts its GPS position roughly every 5–10 seconds over LoRa. The demo tracks on the website use GPS sampled every 10 seconds. This interval balances having enough points to draw a smooth, useful trail against conserving battery and keeping LoRa's low-bandwidth radio traffic manageable across a whole fleet.

LoRa is a low-bandwidth, long-range radio designed for small packets, so sending a position every few seconds fits the technology well while leaving room for many boats on the same channel. Sampling every 5–10s also conserves battery, which is essential for lasting a full 8+ hour race day. For spectating, coaching and tactical replay, a fix every few seconds captures the important moves without needing a constant stream.

Fix time depends on whether the receiver is starting cold or warm. A cold start (the module has no recent satellite data, such as after being off overnight or moved a long way) takes longer, while a warm start reacquires much faster because it still has recent almanac and position data. The NEO-M8N was specifically chosen for its fast fix time, which matters when getting a whole fleet ready before a race.

During the July 2025 field trials at Royal Akarana Yacht Club, the trackers survived capsizes and re-acquired a GPS fix within about 30–60 seconds of the boat coming back upright. A capsize briefly blocks the antenna's view of the sky (and can submerge the unit), so the receiver loses fix momentarily, but because it's effectively a warm re-acquisition it recovers quickly. For race replay, a short 30–60s gap after a capsize is acceptable.

No meaningful interference was found. The tracker uses an off-the-shelf IP67-rated ABS box with a clear lid, and bench tests showed no significant GPS or LoRa signal loss through the plastic. Because of that, the antennas are kept inside the sealed case and no holes were drilled, which keeps the enclosure fully waterproof. Waterproof cable glands are available if an external antenna is ever needed later.

The tracker mounts on the boat's mast using a custom 3D-printed universal mast backplate (printed in black PETG). Mounting up on the mast gives the GPS module a clear, elevated view of the sky, which helps satellite reception, and it also lifts the LoRa antenna higher for better radio range. The 3D-printed mount proved essential during trials, as an early lashed-on version wasn't secure enough.

GPS modules need line of sight to multiple satellites to calculate an accurate position, so anything blocking the sky (a capsized hull, a body, or obstructions) degrades the fix. Sailing has a natural advantage here: open water means an unobstructed sky and, being over water, LoRa also travels well with few obstacles. Mounting the tracker high on the mast maximises this open sky access for the best possible reception.

The NEO-M8N connects to the ESP32-based TTGO LoRa32 board over a UART serial link, with the GPS powered from the board's 3.3V rail alongside a ground connection. In the original wiring the GPS TX went to the ESP32 RX and GPS RX to the ESP32 TX. In the 2026 rebuild the first boat was set to RX-only (gps_tx set to -1, gps_rx on GPIO34) to resolve a GPS bug, so the ESP32 simply reads the standard NMEA position data the module streams.

The Raspberry Pi 4 was chosen because it runs a full Linux system, which lets me install everything the gateway needs in one place: the Mosquitto MQTT broker, Python, Git, and other development tools. It has USB ports for the serial link to the TTGO LoRa32, built-in Wi-Fi and Ethernet for cloud upload, and enough processing power to also host the Flask web server and dashboard on the same device. It is small, affordable, and can run from a battery pack, which makes it ideal for deployment on a coach or committee boat.

Headless means the Pi runs with no monitor, keyboard, or mouse attached — it is controlled entirely over the network via SSH from my MacBook. Raspberry Pi OS is set up in headless mode so that on a support boat the Pi just needs power and can be reached wirelessly, without carrying a screen out on the water. This keeps the gateway compact and rugged, which matters inside a waterproof utility case where there is no room or tolerance for peripherals.

The gateway runs Raspberry Pi OS, the Debian-based Linux distribution made for the Pi. It was installed in a headless configuration with SSH enabled so the Pi could be managed remotely. Running a full Linux OS is precisely what makes the Pi suitable as a gateway — it supports the standard toolchain of Mosquitto, Python, and Git that the data pipeline depends on.

A Python virtual environment isolates the gateway's packages — such as paho-mqtt and Flask — from the system-wide Python, so dependencies for this project do not clash with anything else on the Pi. It keeps the project self-contained and reproducible, which is good practice when a device may be re-flashed or rebuilt for field trials. I created and activated the venv inside a dedicated project folder as part of the Pi setup during the 12–18 May build phase.

Mosquitto is the MQTT broker installed on the Pi — MQTT is a lightweight publish/subscribe messaging protocol well suited to small, frequent messages like GPS coordinates. The Meshtastic gateway node publishes incoming position data as MQTT messages, and the Python listener subscribes to receive them, so the broker acts as the middle layer that decouples the radio side from the logging side. This is a clean, well-supported way to move packets from the LoRa mesh into software that can store and serve them.

The Mosquitto broker runs on port 1883, the standard MQTT port. Position data arrives on Meshtastic topics such as `meshtastic/+/position`, where the `+` is a single-level wildcard that matches any node's identifier — so one subscription captures position messages from every boat in the fleet. The listener script subscribes to these topics to pull GPS fixes out of the message stream.

The Python listener subscribes to the Meshtastic MQTT topics, parses the incoming GPS position messages, and writes each fix into the local SQLite database. In the 2025 proof-of-concept it saved records with fields including node_id, short_name, latitude, longitude, battery_level, and timestamp. It is the software glue between the radio packets coming off the LoRa mesh and the stored data that the Flask API later serves to the map.

The TTGO LoRa32 gateway node connects to the Raspberry Pi 4 by USB, where it presents as a serial (USB serial) device. The Pi reads the Meshtastic packets over that serial link, and the data is handed on via MQTT to the Python listener. This USB serial bridge is exactly why the Pi was a good fit — it has the USB ports and Linux serial support needed to talk to the LoRa board directly.

The gateway is powered by a 10,000mAh USB power bank rated 5V/3A, chosen to keep the Pi and its TTGO node running across a full race day. This addresses a real problem found during the July 2025 trials: on Day 3 the cloud link ran off a coach's iPhone hotspot, but the iPhone battery went flat before the day's end, showing that all-day live tracking needs dedicated external power rather than relying on a phone. The dedicated power bank keeps the gateway itself alive independently of whatever is providing the internet uplink.

The Pi gateway reaches the cloud via a phone hotspot on the support boat — during the Day 3 field trial this was a coach's iPhone hotspot, and it worked. The boat trackers themselves never touch the internet; only the single gateway needs a connection, and only to upload buffered data. This is why the system is described as SIM-free at the fleet level: one shared uplink serves the whole fleet instead of a SIM in every boat.

For unattended field use the gateway software is intended to start automatically when the Pi powers on, so that switching on the power bank is enough to bring the whole pipeline up — broker, listener, and logging — without a laptop or manual commands on the boat. This matters because the Pi runs headless inside a sealed case, where there is no convenient way to log in and launch scripts by hand mid-regatta.

In the 2025 proof-of-concept the Pi ran Mosquitto plus a Python listener that logged Meshtastic MQTT data to SQLite and served it with Flask. In the 2026 rebuild the Pi's job is refocused: a Python program reads the custom base node over serial and POSTs the GPS fixes up to the cloud backend, rather than hosting the map itself. This shift matches the move away from Meshtastic to custom firmware and a Cloudflare-based cloud backend for storage and live fan-out.

The 2026 Pi gateway keeps a local store of fixes and uses retry-with-dead-letter logic so that data is not lost when the uplink drops. If a POST to the cloud fails — for example when the support-boat hotspot briefly loses signal — the fix is retried, and anything that still cannot be delivered is set aside in a dead-letter store rather than discarded. This directly hardens the system against the kind of connectivity gap that flattened the hotspot phone during the 2025 trials.

An Arduino or ESP32 is low-power and can handle serial, but it cannot practically run a full MQTT broker and data-logging stack, so it was ruled out as too limited for the gateway role. The gateway needs to run a real operating system with Mosquitto, Python, and a database, which is squarely a Raspberry Pi job. The ESP32 boards are used on the boats and as the LoRa nodes instead — they are the radios, and the Pi is the hub they feed into.

A MacBook or laptop can run Python and MQTT easily, but it is impractical on a boat: it is bulky, hard to keep dry, and draws too much power for all-day battery use. An Android phone with a USB OTG adapter is lightweight but would need custom app support and is not Meshtastic-native, so it does not fit the pipeline. The Pi hits the balance the others miss — enough power and Linux flexibility to run the full stack, while staying small, cheap, and able to run from a power bank inside a waterproof case.

Each position record in the SQLite database stores six fields: node_id, short_name, latitude, longitude, battery_level, and timestamp. The node_id identifies which physical tracker sent the fix, while short_name is the human-readable boat label, and the timestamp lets the system reconstruct movement over time. Together these fields are enough to plot a boat on the map, draw its trail, sort a leaderboard, and monitor its battery — without storing anything unnecessary.

The node_id is the unique hardware identifier that each tracker broadcasts over LoRa, so it never changes and is guaranteed unique across the fleet. The short_name is a friendly label (like a sail number or sailor name) that officials and spectators can actually recognise on the map. Keeping both means the raw data stays reliably keyed to hardware, while the dashboard can still show something meaningful to a parent watching from shore.

Every GPS fix carries the sending device's battery level, so battery health is tracked as time-series data right beside position. This matters because the trackers need to survive a full race day of 8+ hours, and an official needs to know if a boat's device is about to die mid-race. In the 2026 rebuild the admin dashboard includes a live node-health monitor, which draws on exactly this kind of per-device status data.

MQTT is a lightweight publish/subscribe messaging protocol that suits small, frequent packets — a perfect match for GPS coordinates arriving from a LoRa mesh. In the proof-of-concept, the TTGO gateway node connects by USB to the Raspberry Pi, where a Mosquitto MQTT broker and a Python listener parse the incoming packets. MQTT's low overhead and simple topic model made it far more appropriate than heavier protocols built for high-bandwidth data.

In a publish/subscribe model, senders publish messages to named "topics" and a broker delivers them to whoever has subscribed to those topics, so the two sides never talk directly. In this system the Meshtastic bridge publishes position packets to topics like meshtastic/+/position on the Mosquitto broker running on port 1883, and the Python listener subscribes to them. This decoupling means the listener simply receives fixes as they arrive, without needing to poll each boat.

Mosquitto is the MQTT broker installed on the Raspberry Pi, and it acts as the central post office for all position messages. The Meshtastic gateway feeds packets in, the broker sorts them by topic, and the Python subscriber script pulls them out to write into the database. Running the broker locally on the Pi means the whole message-handling pipeline works even when there is no internet on the race boats.

GPS fixes are tiny — just a handful of numbers per boat every few seconds — which is exactly the kind of small, frequent payload MQTT was designed to move efficiently. LoRa itself is a very low-bandwidth link (great for coordinates, useless for video), so the whole stack is built around minimising data. MQTT's minimal per-message overhead means the Pi can comfortably handle a fleet's worth of position updates without straining the connection.

Position data from different boats can arrive at slightly different times as it hops across the LoRa mesh to the gateway, so a short buffer is applied — around 30 to 60 seconds — to hold fixes until they can be aligned in time. This ensures every boat is shown at the same moment on the map, rather than some boats appearing "ahead" simply because their packets arrived first. It is a deliberate trade of a little latency for a coherent, time-synchronised fleet view.

No — for spectators the small delay is not a problem at all. Sailing races run most of the day, with typically three to five races a day and regattas often spanning several days, so a parent watching from the clubhouse doesn't need sub-second immediacy. Seeing the whole fleet correctly aligned in time is far more valuable than shaving off half a minute of lag.

SQLite is a simple, lightweight, file-based database that runs directly on the Raspberry Pi with no extra hosting or setup, which made it ideal for early testing and small-scale trials. It let position messages be stored and queried with minimal effort during the proof-of-concept and field trials. The honest trade-off is that a local file isn't shareable across many devices, which is why cloud options were researched for scaling up.

Several platforms were compared for the scaling phase. PostgreSQL was a strong candidate as a powerful, widely-used relational database that works well with Flask and historical queries; InfluxDB stood out as a purpose-built time-series database optimised for timestamped data like GPS; and Supabase (Postgres plus auth) was noted as a modern open-source backend. Firebase and other NoSQL options such as MongoDB and DynamoDB were considered but judged less suitable — harder to run the time-based location queries this project needs, or too complex for a small fleet.

Firebase offers real-time sync and is mobile-friendly, but it makes complex queries harder and is overkill for the fairly structured job of storing GPS points. Similarly, NoSQL stores like MongoDB and DynamoDB aren't ideal for the time-based sorting of location data that race replay depends on. Since this system's core need is efficiently querying positions by boat and by time, relational and time-series databases were the better match.

The 2026 rebuild moves the cloud backend to a Cloudflare Worker (using the Hono framework) backed by a D1 database, which is itself SQLite-based. Alongside it sits a Durable Object called "RaceRoom" that fans out live fixes to viewers over WebSockets, with endpoints including POST /ingest, GET /race/current, and WS /races/:id/live. This gives a scalable, low-cost cloud home for the data while keeping the familiar SQLite model that the project started with.

Because every fix is stored with a timestamp, node_id, and short_name, the data can be filtered by boat and by time window to reconstruct any part of a race. In the proof-of-concept a Flask API served endpoints such as /api/latest for current positions and /api/history filtered by device ID and a start/end time. This is what powers race replay — the dashboard requests a boat's fixes over a chosen period and animates them along a timeline scrubber.

Each fix is just a few small fields, and GPS is sampled roughly every 5 to 10 seconds per boat (the on-site demo tracker samples every 10 seconds). Even across a large fleet this stays modest, because LoRa's low bandwidth deliberately keeps packets tiny — it carries coordinates, not photos or video. Storing that as time-series rows in SQLite or Cloudflare D1 is comfortably within the capacity of a Raspberry Pi and a lightweight cloud backend, which is central to keeping the system low-cost and SIM-free.

The on-site Tracker Demo (tracker.html) is built on Leaflet.js, specifically version 1.9.4. Leaflet is a lightweight, open-source JavaScript mapping library that renders the interactive map, the boat markers, the course marks and the coloured trails. The whole tracker is self-contained, so it runs directly in the browser without a heavy front-end framework behind it.

Leaflet was chosen because it is lightweight, offline-capable and needs no API key, which suited a low-cost, open-source project. Google Maps was ruled out largely on cost, and Mapbox on complexity. Leaflet gives full control over custom markers, trails and course marks without tying the project to a paid or key-gated commercial service.

Each boat is drawn as an SVG arrow marker rather than a plain dot. The arrow is rotated to match the boat's heading, so at a glance you can see not just where a boat is but which direction it is travelling. This makes the fleet map read much more like a real race picture than a scatter of points.

As each boat moves, the tracker leaves a coloured trail marking the path it has taken. The trail is progressive, meaning it builds up over time along the boat's route and is colour-coded so different boats can be told apart on a crowded course. This is what lets sailors and coaches see the actual line a boat sailed, including starts, laylines and where ground was gained or lost.

The Tracker Demo shows the key marks that define a sailing course: the committee (start) boat, the windward mark, the leeward mark and a wing mark. Placing these on the map gives the boat positions and trails proper context, so you can see how each boat is progressing around the course rather than just drifting dots on open water.

The tracker includes a canvas-rendered wind dial that indicates wind direction. It works on a "wind-from-course" basis, meaning the wind direction is inferred from the geometry of the course marks rather than read from a separate wind sensor. It is drawn using the HTML canvas element, giving a compact visual reference for which way the breeze is coming from during the replay.

The tracker shows a live-sorted leaderboard that automatically works out each boat's progress using leg detection. It tracks which leg of the course a boat is on and advances a boat to the next leg once it comes within 85 metres of the next mark. This lets the leaderboard order the fleet by race progress automatically, without anyone having to score legs by hand.

It is the rule the leaderboard uses to know when a boat has rounded a mark and moved on to the next leg of the course. When a boat comes within 85 metres of the next mark it is treated as having reached it, so its leg count advances and its position in the leaderboard updates. This automatic leg detection is what keeps the running order live throughout the race.

GPS positions jump around slightly even for a stationary or slow-moving boat, which would make the heading (and therefore the rotated boat arrow) flicker. To smooth this out, the tracker de-jitters heading over 8 metres, meaning it only updates the calculated heading once the boat has actually moved a meaningful distance. The result is stable boat arrows and cleaner leg detection instead of twitchy, noisy readings.

Yes. The Tracker Demo includes a timeline scrubber that lets you move back and forward through the recorded race, so you can review any moment rather than only watching live. This replay is a core feature for sailors and coaches wanting to study starts, shifts and mark roundings after the fact.

The replay can be run at 2×, 5×, 15× and 30× speed. That range lets you crawl through a tight, tactical moment such as a start at 2×, or fast-forward through a long, uneventful leg at 30× to reach the next bit of action. The scrubber and the speed controls work together so you can navigate a whole race quickly.

Yes, the Tracker Demo is theme-aware and adapts its map tiles to suit. In light mode it uses OpenStreetMap (OSM) tiles, and in dark mode it switches to CARTO dark tiles. This keeps the map readable and comfortable whether you are viewing in bright daylight on the shore or on a dimmer screen.

The demo tracker data is sampled every 10 seconds, driven from a tracker-data.js file. In the 2025 proof-of-concept, boats broadcast their GPS roughly every 5–10 seconds over LoRa, so a 10-second sample cadence reflects that. A short buffered delay of around 30–60 seconds is perfectly acceptable for spectators watching from shore.

The 2026 rebuild splits the dashboard in two. The public viewer offers a race picker, live WebSocket tracking, the replay scrubber at 2×/5×/15×/30×, the leg-detection leaderboard and the wind-from-course dial. The admin is key-gated and adds control tools: fleet CRUD with TDMA slot assignment, a click-to-drop course builder, race control and a live node-health monitor with an audit log.

In the 2026 rebuild, live fixes are pushed to the dashboard over WebSockets, fanned out by a Cloudflare Durable Object called "RaceRoom" so viewers see boats update in real time. Because the whole dashboard is a browser-based web app, it runs on any browser across phone, tablet or laptop with nothing to install. That means a parent on the shore, a coach on a support boat or a race official can all open the same live map from their own device.

The original 2025 proof-of-concept ran a Flask API and a SQLite database on the Raspberry Pi itself, which was perfect for proving the idea worked end-to-end but ties the whole system to one small on-boat computer. The 2026 rebuild keeps a Pi at the support boat only as a lightweight gateway, and moves the database, API, and live fan-out into a cloud backend. This makes the system easier to scale to a full regatta, more resilient, and viewable by many spectators at once without leaning on a single Pi.

The cloud backend is a Cloudflare Worker written with the Hono framework, backed by a Cloudflare D1 database and a Durable Object called "RaceRoom" that fans out live fixes over WebSockets. This is serverless, so there is no always-on server to maintain, and it scales automatically with demand. It replaces the Pi-hosted Flask/SQLite combination from the proof-of-concept.

Hono is the web framework used to write the Cloudflare Worker that handles Sail Race Tracker's cloud API. It defines the HTTP routes — such as POST /ingest and GET /race/current — that the gateway and dashboards talk to. Using a lightweight framework designed for Cloudflare Workers keeps the API code clean and fast at the edge.

Cloudflare D1 is the cloud database used in the 2026 rebuild, and it is itself a SQLite database — the same engine used on the Pi in 2025, but now hosted serverlessly in the cloud. It stores the race and position data that the Worker writes and reads. Keeping SQLite semantics means the data model stays familiar while gaining cloud hosting.

"RaceRoom" is a Cloudflare Durable Object whose job is to fan out live GPS fixes to connected clients over WebSockets. When a new fix arrives, the RaceRoom pushes it out to every viewer watching that race live, so all spectators see updates in near real time. Durable Objects are well suited to this because they give a single coordination point for a race's live connections.

POST /ingest is the endpoint the Pi gateway calls to send GPS fixes up to the cloud. The gateway reads fixes from the base node over serial and POSTs them to /ingest, where the Worker stores them in D1 and hands them to the RaceRoom for live fan-out. It is the single entry point for all boat position data coming into the cloud.

GET /race/current is a read endpoint that returns the currently active race, so a dashboard or viewer can discover which race is live without being told manually. It complements the live WebSocket feed by giving clients a way to load the current race context on start-up. It is one of the core endpoints exposed by the Cloudflare Worker.

WS /races/:id/live is a WebSocket endpoint that a viewer connects to for a specific race by its ID, receiving live position fixes as they arrive. Behind it sits the RaceRoom Durable Object, which fans out each new fix to all connected WebSocket clients. This is what lets many spectators watch the same race update live from shore.

Yes, the rebuild's backend includes a /health endpoint and a /tracks endpoint alongside the ingest, current-race, and live-WebSocket routes. A /health route is the standard way to check that the service is up, and /tracks relates to the race track data the system serves. Together with /ingest, /race/current, and WS /races/:id/live, they make up the Worker's endpoint surface.

The Pi gateway authenticates to the cloud using a Bearer key when it POSTs fixes to the ingest endpoint. This means only an authorised gateway carrying the correct key can push position data into a race, keeping random requests from injecting fake fixes. It is a simple, standard token-based scheme suited to a single trusted gateway.

Both dashboards run on Cloudflare Pages. The public viewer offers a race picker, live WebSocket tracking, a replay scrubber at 2×/5×/15×/30× speeds, a leg-detection leaderboard, and a wind-from-course dial — everything a spectator or coach needs to watch. The admin dashboard is key-gated and adds control features: fleet CRUD with TDMA slots, a click-to-drop course builder, race control, a live node-health monitor, and an audit log.

TDMA (time-division multiple access) gives each boat its own time slot to transmit on the private LoRa channel, so transmissions do not collide. In the admin dashboard, TDMA slots are assigned as part of fleet management (fleet CRUD with TDMA slots), and a base node runs the TDMA scheduling plus a beacon. Setting the slot map per boat is what lets a whole fleet share the radio channel cleanly.

Arming a race is part of the race control features in the key-gated admin dashboard — it is how an official sets up and starts a race so the system begins capturing and serving live data for it. Once a race is the current, live one, GET /race/current returns it and viewers can connect to its live WebSocket feed. Race control lives in admin because starting and managing a race is an official's job, not a spectator's.

The admin dashboard includes a live node-health monitor that shows the status of the trackers and base node during a race. This matters because NZIODA officials stressed that reliability is essential for race-official use, so being able to see at a glance which nodes are reporting healthily helps catch problems on the water early. It turns the fleet from a black box into something an official can actively supervise.

The core fix is in the firmware: custom ESP32 code replaces Meshtastic so each boat logs time-stamped GPS and sends packaged historical fixes over a private LoRa channel, producing a complete, smooth record instead of the sporadic, gappy data Meshtastic throttled it to. The cloud side then ingests, stores, and fans out that richer data at scale. Because the Cloudflare stack is serverless — Workers, D1, Durable Objects, and Pages — there is no always-on server to pay for or maintain, so it scales up for a 200-boat regatta and back down again while staying cheap, in keeping with the project's near-zero running-cost, SIM-free ethos.

The tracker uses a commercially available IP67-rated ABS plastic box designed for electronics, chosen so the project could stay low-cost and easy to scale. These boxes are rugged, water-tight, resistant to saltwater corrosion, and can be opened and resealed for servicing components between regattas. Using an off-the-shelf case avoided the cost and complexity of custom tooling at the prototype stage while still meeting the requirement to survive frequent capsizes and full submersion.

The clear plastic lid lets you see what is happening inside the sealed unit without opening it. That means you can check component status lights at a glance, and — critically — spot immediately if any water is starting to enter the case. For a device that spends its day getting capsized and submerged, being able to visually confirm the seal is still holding is a genuinely useful safety feature.

Both antennas are kept inside the sealed enclosure. My goal was to make the unit as waterproof as possible, and mounting antennas externally would have meant drilling holes in the case — which would reduce its waterproofness. Keeping the aerials internal preserves the full IP67 seal with no penetrations to fail.

Bench-top testing showed no measurable signal loss with the antennas enclosed. The LoRa signal did not appear to be impacted, and the GPS antenna worked fine through the plastic box. I noted there may be some difference in LoRa range that only full on-water field testing could confirm, but the results were strong enough that I decided to proceed with internal antenna placement and not drill any holes.

Yes. If a build ever needs an external LoRa antenna for extra range, waterproof cable glands can pass the antenna lead out through the case while maintaining full sealing integrity. This keeps the option open for the future without compromising the IP67 rating, but the current design doesn't use it because internal antennas tested well enough on the bench.

No — it was pool-tested first. I ran a pool capsize simulation on both enclosures before the on-water field trials, submerging the sealed units to check water tightness. This let me validate the seal in a controlled setting (and, as the logbook notes, meant testing waterproof enclosures in the family pool) before trusting the devices in a real regatta environment.

During submersion, the LoRa signal from inside the enclosure dropped, then resumed immediately after the unit surfaced. A GPS fix was not possible underwater, which is expected since water blocks the satellite signal. The key finding was that both functions recovered on their own once the device came back up — exactly the behaviour needed for a fleet where boats capsize routinely.

In the pool submersion testing, GPS reacquisition took under 20 seconds after the unit surfaced. On the water during the July field trials, GPS re-fix after a capsize was observed at 30 to 60 seconds. Either way, the recovery is fast enough that only a short segment of a boat's track is lost during a capsize.

No — there was no water ingression during the pool capsize testing. Combined with the fast signal and GPS recovery, this confirmed the tracker could survive immersion and still function after recovery. That reliability is essential for a youth fleet where capsizes are a routine part of racing, not a rare event.

The 3D-printed mount proved essential because a lashed-on version simply wasn't secure enough. During the two-boat water trial, the custom mount held the unit firmly to the mast under dynamic motion and impact with the water, whereas improvised lashing couldn't be trusted to keep the tracker in place. A secure, repeatable mounting solution was one of the core design criteria, since a tracker that shifts or falls off mid-race is useless.

It is a universal backplate that screws directly onto the waterproof enclosure and then straps to the mast. It was designed in CAD to work across different fleets, with a concave back surface shaped to match typical mast diameters (adjustable per class), slots for Velcro straps on either side for fast tool-free attachment, and raised shoulder ridges that hold the enclosure flat and stop it shifting. The idea is one mount design that fits many classes of dinghy.

The mount is printed in black PETG, chosen for its UV and water resistance — important for a part that lives outdoors in sun and spray. It's printed with a 0.6 mm nozzle for strong layer bonding, giving the part the durability to survive rough marine handling. I also printed a version in carbon-fibre filament as part of exploring more robust options.

The mount attaches to the enclosure with M3 machine screws tapped into pilot holes, creating a connection that is strong but still reversible so components can be serviced. On the mast side, 25 mm Velcro straps thread through slots on either side of the backplate, allowing fast, tool-free attachment and removal on the water. The concave back surface sits against the mast so the strap tension holds the unit flat and stable.

There were several print and design failures before I reached a version I was happy with. My 3D printer wasn't a high-end machine, so I had to do a number of print runs and trials to get both the design and the durability right. An early Version 1 with Velcro slots failed, and the design was iterated through to a final working version.

I printed a carbon-fibre-filament version alongside the black PETG mount as part of iterating toward a durable, robust design that could withstand the demanding marine environment. Carbon-fibre-reinforced filament offers greater stiffness and strength, which is attractive for a part that has to hold the tracker securely on a mast through capsizes and knocks. It sits within the broader design process of trialling materials and print runs until the mount was strong enough to trust in real racing conditions.

The boat tracker runs on a 3.7V lithium battery, sized to last a full race day of 8+ hours. During development I evaluated three options: 18650 Li-ion cells, LiPo flat packs, and USB power banks. The design goal is a battery large enough to cover a full day of racing with simple overnight recharging, ideally over USB-C.

18650 Li-ion cells are cheap, rechargeable, and directly supported by boards like the TTGO LoRa32 and T-Beam, which include battery connectors and charging circuitry. Their main drawback is that they need external holders and protection circuitry, which adds a little complexity to the enclosure and layout. For a full-day-capacity, low-cost tracker they're a strong, proven option.

LiPo flat packs are lighter and smaller than 18650 cells, which helps keep the tracker compact and low on the mast. The downside is that they're less durable and more complicated to waterproof safely, which matters a lot in a device designed to survive frequent capsizes and full submersion. So while LiPo packs are attractive for size, 18650 cells offer more robustness for the marine environment.

USB power banks were extremely handy for testing early prototypes on the bench, since you can just plug in and go. However, they aren't practical for in-hull deployment inside a sealed, mast-mounted tracker — they're bulky and awkward to fit in a compact IP67 enclosure. Power banks stayed a prototyping and gateway tool rather than part of the on-boat battery design.

The core design requirement is at least eight hours of operation — long enough for a full day of racing — with easy overnight recharging. Battery selection had to guarantee that runtime in all weather, so a 3.7V lithium cell is paired with power-saving firmware behaviour to stretch endurance. In the July 2025 field trials the tracker battery lasted a full day on the water and was simply recharged overnight for the next day.

Overnight USB-C charging is the intended method — it's a universal, convenient connector that lets you top up a unit at the clubhouse or at home ready for the next day. During the RAYC field trials, trackers that ran all day were charged overnight and were ready to go again the following morning. USB-C is called out as the ideal charging approach in the design requirements.

The tracker broadcasts its GPS position roughly every 5–10 seconds over LoRa. This interval is a deliberate balance: broadcasting more frequently gives smoother, more responsive tracking, while a longer interval saves battery power. Choosing a low broadcast interval in the range of every 5 seconds up to about a minute is one of the main levers for trading responsiveness against all-day endurance.

Yes — the more often the device wakes its GPS and fires the LoRa radio to transmit, the more power it uses. That's why the broadcast interval is tuned to something like every 5–10 seconds rather than continuously: it keeps tracking smooth enough for tactics and spectating while conserving energy over a long day. For spectator use a slightly less frequent update is perfectly acceptable, so responsiveness can be traded for endurance where needed.

The firmware is designed to support smart GPS, deep sleep, and screen timeout to conserve energy between transmissions. Deep sleep powers down the device between broadcasts, smart GPS avoids keeping the receiver on unnecessarily, and screen timeout switches off any OLED display when it isn't needed. Optimising power management this way — including deep sleep and smart GPS — is an explicit item on the project roadmap for finalising the prototype.

Yes. Devices without always-on screens or blinking status LEDs have a significant battery-life advantage, since displays and indicators are a constant drain. This was one of the observations noted about the sealed SenseCAP unit, which lacked a screen. It's also why the production firmware includes a screen-timeout feature to switch off the OLED on boards that have one.

The gateway kit — a TTGO LoRa32 node connected to a Raspberry Pi 4 — is run from a 10,000mAh USB power bank rated at 5V/3A, which provides all-day power on the support or committee boat. Because the gateway does the heavy lifting of receiving every boat's packets and forwarding them to the Pi, it needs a dependable, high-capacity supply rather than a small internal cell. The power bank sits with the Pi inside the waterproof utility case.

The gateway runs a full Raspberry Pi 4, which is far more power-hungry than a boat tracker, so it needs a substantial supply to last a whole day on the water. A 10,000mAh, 5V/3A bank gives that headroom for the Pi plus the attached LoRa node. This keeps the gateway independent of the phone that's providing the internet hotspot, which is important because that phone has its own separate power problem.

On Day 3 of the July 2025 trials the gateway reached the cloud through the coach's iPhone hotspot, and it worked — but the iPhone's battery went flat before the end of the day. The clear finding was that for all-day live streaming you need external power for the phone providing the hotspot, not just the gateway itself. In other words, every link in the chain that runs all day — tracker, gateway, and the hotspot phone — needs its own dependable power source.

The long-term goal is a single custom PCB that combines the ESP32, NEO-M8 GPS, and LoRa radio (with optional extras like Bluetooth, a gyro/accelerometer, and a small OLED), fabricated cheaply by a manufacturer such as JLCPCB or PCBWay. Integrating everything onto one purpose-built board would let power management be designed in from the start rather than bolted on, cutting size, weight, and wasted draw. Combined with firmware deep sleep and smart GPS, a custom PCB is the path to a smaller, more power-efficient production tracker.

The field trials ran over three days, from 1 to 3 July 2025, at the Royal Akarana Yacht Club (RAYC) in Auckland, held during RAYC's holiday sail training programme. The setup used four race boats fitted with tracker nodes (a mix of TTGO LoRa32 and Heltec HTIT boards) plus one support boat carrying the TTGO gateway node and a Raspberry Pi 4. Running the trial alongside real holiday training meant the system was tested with actual youth sailors on a real course rather than in a staged demo.

Day 1 was an off-water system test to prove the full chain worked before anything went afloat. All four boat nodes were powered up, each obtained a GPS fix and transmitted its position; the gateway node saw all four nodes on the mesh; the Raspberry Pi logged the incoming data; and the dashboard correctly displayed four markers. The mounting arrangement was also checked and worked. Getting every stage confirmed on land first meant that any problems on the water could be narrowed down to on-water factors rather than basic setup faults.

Doing a dry run on Day 1 let each stage of the pipeline be verified independently — GPS fix, LoRa transmit, gateway reception, Pi logging, and dashboard display — without the complications of water, movement, and range. Because the system is a chain of separate parts (boat node, LoRa mesh, gateway, Pi, database, web map), confirming all four nodes reached the dashboard as four markers on land meant that if something later failed on the water, the cause could be isolated far more quickly. It is a sensible engineering habit: prove the baseline before adding variables.

Day 2 was the first on-water test, run deliberately with no internet connection, using two boats so any issues would be easy to track. As the boats left the shore, live tracking worked and their positions updated on the dashboard. The day focused on the harsher realities of dinghy sailing — capsizes, battery endurance over a full day, and whether the mount would actually stay put — rather than on scale.

Yes. During the Day 2 water trial the tracker devices survived capsizes, which was a key requirement given that youth dinghies capsize frequently and the enclosure must handle full submersion. The IP67-rated waterproof case with the antennas kept inside (no holes drilled) held up in real conditions. This on-water confirmation was important because bench and pool tests can only simulate so much.

After a capsize the GPS module re-acquired its fix in about 30 to 60 seconds. That short re-fix time was possible thanks to the chosen u-blox NEO-M8N module, which offers fast fix times and roughly 2.5m accuracy. A brief gap in tracking while a boat is righted and the fix re-locks is acceptable for spectating and coaching, since the buffered dashboard already tolerates a similar delay.

Yes. During the Day 2 trial the tracker battery lasted a full day on the water, and the device was simply recharged overnight — meeting the design goal of at least eight hours of operation with easy overnight USB recharging. This confirmed that the 3.7V lithium battery sizing was appropriate for a real training day. All-day endurance is essential because regattas typically run three to five races a day across the daylight hours.

Day 2 confirmed that the custom 3D-printed mast backplate was essential and that a simple lashed-on version was not secure enough. The 3D mount — black PETG, concave to match the mast diameter, with M3 screws and 25mm Velcro straps — held the tracker firmly through sailing and capsizes, whereas lashing risked the device shifting or coming loose. This was a genuine field finding: several print iterations had already failed before a durable design was reached, and the water trial validated that the effort was worthwhile.

Day 3 was the full trial with all four boats plus the support boat operating together. Every one of the four boats reported GPS, the data was logged to the SQLite database, and the dashboard displayed multiple boats concurrently. This was the first test of the system handling a whole small fleet at once rather than one or two boats, moving it from a point-to-point demo to a genuine fleet-tracking scenario.

No. During the Day 3 full-fleet trial there were no packet collisions and no data loss, even with all four boats broadcasting their positions over the shared LoRa mesh at the same time. This is a meaningful result because it showed the self-healing Meshtastic mesh could handle a small fleet without boats' transmissions clobbering one another. It gave confidence that the radio side scales to more than a couple of nodes, even though the data-rate limitation remained the headline concern.

The gateway — a TTGO LoRa32 node connected to a Raspberry Pi 4, housed in a waterproof utility case — survived rain and spray during the Day 3 trial on the support boat. Keeping the Pi and gateway node sealed in a waterproof case with an internal antenna meant the electronics stayed dry in real marine conditions. Since the support boat is exposed all day, gateway weatherproofing is just as important as sealing the boat trackers themselves.

On Day 3 the Raspberry Pi gateway reached the cloud using a coach's iPhone as a mobile hotspot on the support boat, and the uplink worked — proving the system can push live data online without any SIM cards on the boats themselves. The one snag was power: the iPhone's own battery went flat before the end of the day. The lesson was clear — for all-day live streaming, the phone providing the hotspot needs to be run from external power rather than its internal battery.

Feedback across all three groups was positive. Coaches were impressed that they could follow the fleet from shore without having to chase boats in a powerboat; parents were keen to watch races live from the clubhouse or on their phones; and the sailors were excited and wanted to do more. This real-world enthusiasm from the exact users the system is built for — and from an audience that included people familiar with expensive professional tracking — was strong validation of the concept.

The main issue confirmed on the water was that Meshtastic sends too few data points, producing large gaps between GPS fixes rather than a smooth, continuously time-stamped trail. This is a software limitation of Meshtastic's message scheduling and mesh optimisation, not a fault in the hardware — the boards, GPS, radios, and mount all performed. Meshtastic remains an excellent proof-of-concept platform, but the gappy data showed it could not deliver the smooth tracks needed for a polished product.

The trials proved the end-to-end concept works in real conditions — waterproofing, all-day battery, fast GPS re-fix after capsize, a secure 3D-printed mount, a fleet tracked with no collisions or data loss, a weatherproof gateway, and a SIM-free cloud uplink via phone hotspot. Two concrete changes emerged: the hotspot phone needs external power so it lasts the full day, and, most importantly, Meshtastic must be replaced with custom ESP32 firmware that logs and transmits continuous time-stamped GPS to close the gaps between fixes. That firmware replacement is the central goal of the 2026 rebuild.

The design target is under NZ$50 per unit to produce. This figure is a goal set at the start of the project rather than a finished retail price, and it drives almost every hardware decision — from choosing a sub-NZ$20 GPS module over a NZ$100–200+ RTK chip, to keeping antennas inside an off-the-shelf case instead of engineering custom parts. It's best read as an indicative target for a bill of materials, not a fixed sticker price.

Indicatively, one boat tracker is built from a TTGO LoRa32 development board (~NZ$25–30), a u-blox NEO-M8N GPS module (~NZ$15–20), a 3.7V lithium battery (18650 Li-ion or LiPo), an off-the-shelf IP67-rated ABS enclosure with a clear lid, and a custom 3D-printed mast mount printed in PETG. The brief gives firm indicative figures only for the board and GPS; the battery, case and printed mount are low-cost commodity or self-made parts, so an exact all-in total isn't stated. Together these components are what the under-NZ$50 target is measured against.

They're the two components with meaningful, quoted unit prices in the project research, so they anchor the bill of materials. The TTGO LoRa32 V1.6 comes in at roughly NZ$25–30 and provides the ESP32 microcontroller, LoRa radio and an OLED screen in one board, while the NEO-M8N adds ~2.5m GPS accuracy for about NZ$15–20. The remaining parts — battery, IP67 box, printed mount, screws and Velcro — are inexpensive by comparison, which is why the two "chips" dominate the indicative cost.

Very little, because the Raspberry Pi 4 gateway is shared across the whole fleet rather than fitted to each boat. One gateway (a TTGO LoRa32 plus a Raspberry Pi 4, a 10,000mAh power bank and a waterproof case) sits on the support or committee boat and receives every boat's data. Its cost is a one-off spread across however many trackers are in use, so on a 20- or 50-boat fleet the per-boat share of the gateway becomes almost negligible.

Commercial trackers such as RaceQs, TracTrac, Yellowbrick, Sailmon MAX and WAIV cost roughly NZ$500–900 (or €400–500) per unit, plus subscriptions and data fees of NZ$30+ per month. The Sail Race Tracker aims to produce a comparable-purpose device for an indicative target of under NZ$50 per unit — roughly a tenth or less of the commercial hardware cost. The saving comes from open-source firmware, inexpensive development boards, and using the free LoRa ISM band instead of cellular.

Because the system is SIM-free and subscription-free by design. Boats transmit over LoRa on the free 915 MHz ISM band in New Zealand, so there are no cellular contracts, no per-device SIM cards and no monthly data plans — the very costs that make commercial fleets expensive to run. The only recurring inputs are overnight battery charging and a phone hotspot on the support boat to reach the cloud, which avoids the NZ$30+ per month per unit that commercial systems typically charge.

On commercial gear, a 200-boat regatta would cost over NZ$180,000 in equipment alone, before adding ongoing data and subscription fees. Against the Sail Race Tracker's indicative under-NZ$50-per-unit target, the equivalent hardware bill would be an order of magnitude lower, plus one shared gateway and no per-boat data plans. Exact totals depend on final production costs, so this is best framed as an indicative comparison rather than a fixed quote.

The LoRa ESP32 development boards and supporting modules were sourced from AliExpress, which the project identified as the best route to buy a small number of boards to test between options. Ordering direct from China kept the per-board cost low (delivery took around 2–3 weeks), which is central to hitting the under-NZ$50 target. The Raspberry Pi was bought locally from PB Tech, and the MacBook used for development was already owned.

The SenseCAP T1000-E is the best-value ready-made Meshtastic all-in-one device tested, but it was used for proof-of-concept only because it isn't waterproof, has a small battery unsuited to a full race day, has a small internal antenna, and has no USB port to re-flash custom firmware. It's also the most expensive of the boat-device options considered (~NZ$60–70). Combining separate cheaper modules keeps the unit cost down and, crucially, keeps the firmware and hardware open to the customisation the project needs.

Generally yes — the more parts are combined rather than bought as a finished product, the cheaper the overall system, but the harder it is to make everything talk to each other. Each module has to be manually wired and flashed with the right code or config, and some LoRa modules aren't natively supported by Meshtastic, which adds complex integration work. The project found the TTGO-plus-NEO-M8N combination struck the right balance between low cost and buildability for the prototype stage.

A future custom PCB — a single board carrying the ESP32, NEO-M8 GPS and LoRa radio (and optionally Bluetooth, a gyro/accelerometer and a small OLED) — would cut cost, size and weight further at volume. Fabricating one board through a service like JLCPCB or PCBWay in China replaces several separately purchased modules and reduces hand-assembly, which is where much of the per-unit cost and effort currently sits. This is on the roadmap as a step from proof-of-concept toward a production product, not something in the current prototypes.

Volume helps in two ways: bulk board and component orders lower each part's price, and a custom PCB removes the manual wiring and per-module flashing that make hand-built prototypes labour-intensive. A single fabricated board through JLCPCB or PCBWay consolidates the ESP32, GPS and LoRa into one manufacturing step, cutting both parts cost and assembly time. The current figures are indicative prototype costs, so a volume-produced PCB would be expected to come in below them.

Indicatively, a club would need one tracker per boat (targeted at under NZ$50 each to produce) plus a single shared support-boat gateway (a TTGO LoRa32, a Raspberry Pi 4, a power bank and a waterproof case) that serves the whole fleet. With no SIMs, subscriptions or data plans, there's effectively no ongoing running cost beyond charging batteries. Because the project is a field-tested proof of concept rather than a finished product, these are indicative figures — a firm per-fleet quote would depend on final production costs.

It's both the founding motivation and a knock-on benefit. The project was started because no affordable, waterproof, SIM-free tracker existed for youth and club dinghy racing, where commercial systems priced at NZ$500–900 per unit plus data are simply out of reach — a 200-boat regatta would exceed NZ$180,000 in gear alone. Hitting the under-NZ$50 target also unlocks wider benefits raised by the NZIODA committee: making the sport more engaging for spectators and enabling better training and post-regatta analysis without ongoing data costs for a whole fleet.

Because every boat's position is logged with a time-stamp, a full replay lets you see exactly where you were on the start line at the gun and how you were placed relative to the rest of the fleet. Starts are one of the specific moments the system is built to reveal — you can see whether you were early, buried in a pack, or sitting in clear air. Reviewing this objectively, rather than from memory, is how sailors learn to time and position starts faster.

Yes — laylines are one of the exact situations the tracker is designed to expose. With coloured trails showing each boat's track around the course, you can see whether you overstood or understood the layline to a mark, and compare your approach to sailors who did it better. Seeing where distance was gained or lost on the approach is far more instructive than trying to reconstruct it from feel alone.

The system gives you objective GPS trails for the whole fleet, and wind shifts are specifically called out as something replay helps sailors learn from. When one part of the fleet suddenly gains on another, the tracks make the shift visible after the fact, so you can see which side paid and whether you were on the right side of it. The on-site Tracker Demo also includes a wind dial derived from the course, giving extra context to what the boats were doing.

Yes. The replay shows your track through each rounding alongside the rest of the fleet, so you can see whether you rounded tight and held your lane or lost boats through a slow, wide turn. The tracker even detects legs automatically — the leaderboard advances a boat once it comes within 85m of the next mark — so roundings are clearly delineated in the data you review.

Because the replay captures the whole fleet's positions over time, you can look back and see how a given tack played out relative to the boats around you — whether crossing when you did gained or lost you distance. The 2026 rebuild also envisions on-device motion sensors that could measure tacking efficiency directly, but even the current position replay lets you learn which tactical crosses paid off.

The system keeps a time-stamped positional log of every boat, and one of its stated benefits for race officials is fairer starts and finishes plus positional logs that can support protests and redress. A full-fleet view at the gun gives an objective record of where boats were relative to the line. It is worth remembering this is a proof of concept rather than a certified race-management tool, and NZIODA officials stressed that reliability is essential before it is leaned on for official decisions.

That is one of the intended uses for race officials — positional logs for protests and redress are listed among the benefits the system offers. Because each boat's latitude, longitude and timestamp are recorded, the data can help reconstruct an incident. However, the current version is a field-tested proof of concept, not a finished or certified product, so it should be treated as supporting evidence rather than a definitive ruling tool.

The target classes are Optimist, Starling, 29er, ILCA and iQFOiL — the core youth and pathway dinghy and board classes. I built the system and race Starling and 29er myself, so it is designed around real youth racing rather than professional keelboats. There are thousands of youth sailors across these classes in New Zealand alone.

Yes — a key design requirement is that it scales from a 5-boat training session right up to a 100–200-boat regatta. Coaches specifically use it to run squads of roughly 5 to 20 boats more effectively, comparing sailors side by side. The same live map and replay tools serve both the small squad and the full fleet.

The system is aimed squarely at major youth regattas, which can put 100–200 dinghies on a single course. Field trials in July 2025 ran with 4 race boats and a support boat, with no packet collisions or data loss observed, which proved the concept. Scaling to full regatta size is part of the ongoing 2026 rebuild rather than something demonstrated at 200 boats yet.

Phones are banned in dinghy racing for reasons of safety, distraction and class rules, so any tracker relying on a SIM card or a Bluetooth pairing to a phone is a non-starter on the water. Commercial trackers such as RaceQs, TracTrac, Yellowbrick, Sailmon MAX and WAIV all depend on a SIM or a phone connection. Sail Race Tracker is deliberately SIM-free and phone-free, sending positions over a LoRa radio mesh instead.

A coach can replay a whole session with all the boats overlaid, then compare sailors side by side to see who gained and lost where. Because the feedback is objective GPS data rather than opinion, debriefs become evidence-based — you can point to the exact moment on the start line or at a mark rather than debating what happened. Coaches at the July 2025 trials were impressed that they could follow the fleet from shore without chasing it in a powerboat.

A live full-fleet view lets race officials locate distressed, capsized or drifting boats quickly, which is a genuine safety benefit on a crowded course. On the fairness side, it supports cleaner starts and finishes and keeps positional logs for protests and redress. It can also mean fewer safety powerboats are needed, since officials no longer have to physically chase the fleet to keep eyes on every boat.

Yes — full GPS replay of races and training is the headline benefit for sailors. The on-site Tracker Demo offers a timeline scrubber and playback at 2×, 5×, 15× and 30× speeds, with boat arrows rotated to heading and progressive coloured trails, so you can step through a race and study the decisive moments. Replaying objectively is how sailors pick up tactics faster than they would from memory alone.

For tactics, what counts is where you are compared with the other boats, not your exact coordinate to the centimetre. That is why the system uses the u-blox NEO-M8N module with around 2.5m accuracy rather than expensive RTK gear that reaches centimetre precision — relative consistency across the fleet matters more, and 2–5m is plenty for reading starts, laylines and shifts. Keeping every boat on the same consistent standard is what makes the fleet comparison meaningful.

A pilot would likely mirror the July 2025 field trials at Royal Akarana Yacht Club: a small set of boat trackers, one gateway on a support or committee boat, and a live web dashboard viewable from shore. A club would typically host a training day or regatta where a handful of dinghies carry trackers, coaches and parents watch positions live, and everyone gives feedback afterwards. The aim of a pilot is to prove reliability in real conditions and gather input from sailors, coaches and race officials — not to sell finished units. Clubs or schools keen to host a trial are welcome to email me at info@sailracetracker.live.

The 2025 trials ran with 4 race boats plus 1 support boat carrying the gateway and Raspberry Pi, which is a realistic size for an initial pilot. From there the system is intended to scale from a 5-boat training squad up toward 100–200-boat regattas, so a club could start small and grow. A pilot deliberately keeps the fleet modest so issues can be spotted and fixed before larger events. The exact kit for any given pilot would be worked out with the host club depending on their boats and courses.

The ethos is open-source, community-driven and built to be affordable, so the firmware is intended to be open and the hardware offered at or near cost. The production target is under NZ$50 per unit to build, compared with roughly NZ$500–900 (or €400–500) for commercial trackers, and there is no SIM, subscription or data plan, so running costs are near zero. Any pricing or licensing model is still to be worked out and should be treated as an intention rather than a firm commitment. Anyone wanting to discuss commercial arrangements can reach me at info@sailracetracker.live.

Because the firmware is intended to be open-source and the current hardware uses off-the-shelf parts (an ESP32 board, a u-blox NEO-M8N GPS, a LoRa radio, a battery, an IP67 box and a 3D-printed mount), a technically capable club could in principle self-build. Others would likely prefer pre-assembled units so they can simply mount and go. Both paths are possibilities the project is open to, though nothing is finalised while the 2026 rebuild is still underway. Clubs can email info@sailracetracker.live to talk through what would suit them.

Yes, that is a planned roadmap step. The intention is to design a single custom PCB combining the ESP32, NEO-M8 GPS and LoRa radio — with optional extras like Bluetooth, a gyro/accelerometer and a small OLED — and to have it fabricated cheaply through a service such as JLCPCB or PCBWay. A custom board would cut cost, size and weight further than the current dev-board approach. This is a future step, not something in production today.

Sail Race Tracker was designed and built by me, Jack Harker, a Year 10 student at ACG Parnell in Auckland, and I retain full ownership of the project. AI tools such as ChatGPT were used as a research tutor and coding mentor, but all the physical testing, coding, assembly and design decisions were made by me. The project is guided by an open-source, community-driven ethos, so the intention is to share firmware and design openly rather than lock it away. Questions about IP or collaboration can go to info@sailracetracker.live.

Yes — potential sponsors are among the groups I'm especially keen to hear from. Sponsorship could help fund further on-water testing, hardware for pilots, and the move toward a custom PCB and production run. The project has already been recognised through the Samsung Solve for Tomorrow 2025 award (a NZ$9,000 prize pool), which shows there is appetite to back it. Sponsors or grant-makers interested in supporting the work are welcome to email info@sailracetracker.live.

Grant funding is a plausible path given the project's educational, safety and community focus, and it has already attracted support-in-kind through the Samsung Solve for Tomorrow programme run with MOTAT and TENZ. Because the goal is to keep units affordable and near cost, external funding could help bridge development and manufacturing without pushing prices up for clubs. Any specific grant plans are still to be developed. Anyone who can point toward suitable grants or wishes to help is encouraged to contact info@sailracetracker.live.

A partnership could involve a club or class association hosting on-water testing, providing boats and sailors for pilots, and helping shape features that matter to race officials and coaches. Sail Race Tracker was presented to the NZIODA National Committee on 1 July 2025 and drew strong interest and support, with officials stressing that reliability is essential for race-official use. The project has also acknowledged help from people at several Auckland clubs and from Yachting NZ and NZIODA. Class associations, clubs or national bodies keen to partner can reach me at info@sailracetracker.live.

Yes, at an early and informal level. The project was presented to the NZIODA National Committee on 1 July 2025 and received strong interest and support, and Yachting NZ and NZIODA are both thanked among those who helped along the way. High Performance Sport NZ is also acknowledged. These are supportive relationships rather than formal commercial arrangements, and deeper involvement would be a welcome next step. National bodies wanting to explore this can email info@sailracetracker.live.

When Sail Race Tracker was presented to the NZIODA National Committee, officials made clear that reliability is essential if the system is ever to be trusted for race-official use such as start/finish decisions or protest evidence. That feedback directly drives the 2026 rebuild, which replaces the Meshtastic proof-of-concept firmware with custom firmware to deliver smooth, continuous, time-stamped GPS instead of gappy data. Proving that reliability in repeated real-world pilots is a key milestone before the system could be considered sellable or official-grade. Race officials with reliability requirements are welcome to share them via info@sailracetracker.live.

The project is based in New Zealand and its trials, awards and partnerships to date have been local, so international interest is best described as an open possibility rather than something already established. The underlying need — affordable, SIM-free tracking for youth dinghy fleets — is not unique to New Zealand, since commercial trackers are expensive worldwide and phones are banned in dinghy racing generally. The open-source ethos means the design could in principle be adopted elsewhere. Anyone overseas who is interested is warmly invited to get in touch at info@sailracetracker.live.

The system is designed to be low-maintenance: trackers charge overnight via USB-C, are housed in IP67-rated waterproof boxes, and use a 3D-printed mast mount proven durable in trials. There are no SIM cards, subscriptions or data plans to manage, which keeps ongoing overhead low. As a proof of concept moving toward production, support arrangements for things like firmware updates, spare parts and troubleshooting would be worked out with each pilot club rather than being a fixed service today. Clubs can discuss their support needs by emailing info@sailracetracker.live.

The headline milestone is finishing the 2026 rebuild: custom ESP32 firmware plus a cloud backend that together deliver smooth, reliable, time-stamped tracking instead of the gappy data the Meshtastic proof of concept produced. Beyond that, the roadmap points to a custom PCB for cheaper volume manufacturing, a fuller web app for race setup and replay, and smarter on-device features like start countdowns and capsize detection. Repeated, reliable pilots at clubs and schools would be needed to prove it is regatta-ready. It is honestly still a proof of concept, not a finished product — and people who want to help move it forward can email info@sailracetracker.live.

The simplest first step is to email me directly at info@sailracetracker.live, which is already listed publicly on sailracetracker.live. I'm especially keen to hear from sailing clubs and schools willing to host testing, youth sailing bodies, makers and engineers, potential sponsors, and anyone in the LoRa or open-source community. A conversation can then work out whether a pilot, a partnership, sponsorship or a contribution to firmware, web or hardware is the best fit. There is no formal application process — an email is genuinely the place to start.

You need three things: a waterproof tracker for each boat you want to follow (ESP32 + LoRa radio + GPS + battery in an IP67 box), a support or committee boat to carry the gateway, and the gateway itself — a TTGO LoRa32 node wired by USB to a Raspberry Pi 4 in a waterproof utility case. To get the live map off the water and into the cloud you also need a phone hotspot on the support boat and a USB power bank to keep the gateway running. That is the full field kit proven across the RAYC trials, from a 5-boat training session up toward a 100–200-boat regatta.

Each tracker carries a node ID and short name that the system logs alongside its GPS fixes, so a device maps cleanly to one boat on the dashboard. In the 2026 rebuild the key-gated admin dashboard adds proper fleet management (fleet CRUD) with per-boat configuration, so you register each boat, give it a sailor ID and fleet, and set its logging mode from one place. That means before racing you simply pair each physical tracker to the boat and sailor it will ride on, and the map labels every marker correctly.

Each tracker clips to a custom 3D-printed universal mast backplate printed in black PETG (chosen for its UV and water resistance) with a concave face shaped to match the mast diameter, and it is held on with 25mm Velcro straps. The RAYC water trial proved this mount is essential: an earlier lashed-on version was not secure, whereas the 3D backplate held firmly through sailing and capsizes. A carbon-fibre-filament version was also printed. Mounting on the mast keeps the antenna and GPS high and clear for the best signal.

The 2026 admin dashboard includes a click-to-drop course builder, so you literally click on the map to place your marks — committee boat, windward, leeward and wing — and adjust them as the course changes. Those marks then drive the viewer's features, including the leg-detection leaderboard (which advances a boat within 85m of the next mark) and the wind-from-course dial. So course setup is a quick map-based task rather than typing coordinates by hand.

In the 2026 rebuild a base node runs TDMA (time-division) scheduling with a beacon, giving each boat its own time slot to transmit so their packets do not collide on the LoRa channel. When you set up the fleet in the admin dashboard you assign each boat a TDMA slot as part of its config, then use race control to start (arm) the race. This orderly scheduling is what lets many boats report cleanly at once, and even in the earlier trials with four boats there were no packet collisions or data loss.

The trackers use a 3.7V lithium battery (an 18650 Li-ion or LiPo) sized to last a full race day of 8+ hours, and they recharge over USB-C, so overnight charging is as simple as plugging each unit into a USB charger. In the RAYC trial the batteries lasted a full day on the water and were charged overnight ready for the next day. Plan a charging station so every tracker in the fleet is topped up before racing.

They open the live map dashboard in any web browser on a phone, tablet or laptop — no app to install and no login needed for the public viewer. The viewer shows all boats as coloured arrows on the map with progressive trails, plus a race picker, live WebSocket tracking, a leg-detection leaderboard and a wind dial. Parents can follow from the clubhouse or the shore, and coaches get the full-fleet view they cannot get from a chase boat.

The trackers are built to survive frequent capsizes and even full submersion in their IP67 enclosure, and the RAYC water trial confirmed they kept working through capsizes. After a capsize the GPS typically re-acquires its fix within about 30–60 seconds, so the boat rejoins the live map shortly after righting. For race officials this is a safety win: the live full-fleet view helps locate a capsized, distressed or drifting boat quickly.

The boat trackers sit in off-the-shelf IP67-rated ABS boxes with the antennas kept inside the plastic, which bench tests showed caused no meaningful LoRa or GPS loss, so no holes were drilled that could let water in. On the support boat the gateway rides in a waterproof utility case, and during the RAYC full trial it survived rain and spray without issue. So a wet, splashy race day is exactly what the hardware was designed for.

The Raspberry Pi 4 gateway runs off a 10,000mAh USB power bank (5V/3A) for all-day power, so plan to bring that charged and connected. The RAYC trial exposed the real risk here: the cloud link ran through a coach's iPhone hotspot, and the iPhone battery went flat before the day's end. The lesson is to give both the gateway Pi and the hotspot phone their own external power so the live feed lasts the full day.

No. The boats broadcast their positions over LoRa (915 MHz) with no SIM cards and no internet at all, and the gateway on the support boat collects everything locally. The Day 2 RAYC trial ran live tracking with no internet on the water. Internet only comes in via the support boat's phone hotspot to push data up to the cloud dashboard for shore viewers, and a slight buffered delay of 30–60 seconds is perfectly fine for spectators.

Mount the LoRa antenna as high and as vertical as you can. The gateway uses a vertical internal SMA LoRa antenna, and a higher, elevated antenna improves coverage — which matters because LoRa works brilliantly over open water where there are few obstacles, giving range in the order of 2–10 km in open conditions. Putting the support boat with its raised antenna near the middle of the course area helps it hear the whole fleet.

Yes. The viewer dashboard includes a replay scrubber with a timeline and speed options of 2×, 5×, 15× and 30×, so sailors and parents can replay a whole race at home. This replay is one of the core reasons the system exists: sailors get full GPS replay to see where time was gained or lost at starts, laylines and shifts, and coaches can run evidence-based debriefs by replaying whole sessions with fleet overlays.

Every fix is stored, so the data persists for later review — in the proof of concept the gateway logged positions into a SQLite database with fields for node ID, short name, latitude, longitude, battery level and timestamp. The 2026 rebuild moves this into a cloud backend (a Cloudflare D1 database) with the fixes served to the viewer for replay, and the admin side keeps an audit log of race activity. Real recordings have already been captured and reused this way — Race 1 on the tracker demo is a genuine on-water LoRa recording from RAYC.

Recover each tracker from its mast (the Velcro straps release it from the 3D backplate quickly), then bring in the support-boat gateway kit — the TTGO node, the Raspberry Pi 4 and the power bank in their waterproof case. Put every tracker on to charge overnight so the fleet is ready for the next day, as was done during the multi-day RAYC trial. Because the data has already been logged through the gateway, nothing is lost once the units are switched off and stowed.

RaceQs is an established GPS race-tracking and replay platform, but a RaceQs-style commercial tracker costs roughly NZ$500–900 (or €400–500) per unit and typically leans on a smartphone or SIM/data connection to upload positions. That model doesn't suit youth dinghy racing, where phones are banned for safety, distraction and class-rule reasons, and where a 200-boat regatta would run past NZ$180,000 in gear alone. Sail Race Tracker targets under NZ$50 per unit, is SIM-free (using a 915 MHz LoRa radio mesh instead of cellular), and is waterproof enough to survive repeated capsizes. It gives up broadcast polish and some maturity in exchange for being affordable at fleet scale.

TracTrac is a professional-grade tracking system used at major regattas and events, delivering high-quality live coverage — but it sits in the same expensive, subscription- and data-dependent bracket as other commercial trackers (roughly NZ$500–900 per unit plus ongoing data). It's built for organised, well-funded events rather than a club coach running a 5–20 boat squad on a shoestring. Sail Race Tracker is deliberately the opposite: an under-NZ$50, SIM-free, open-source unit that a school or club can deploy across a whole fleet without a per-boat data contract. The trade-off is that TracTrac offers commercial reliability and event-grade production, while Sail Race Tracker is still a field-tested proof of concept.

Yellowbrick is well known for long-distance and offshore tracking, using satellite and cellular links to report positions from anywhere on the water. That connectivity is powerful for ocean racing but expensive, and it depends on SIM or satellite airtime that adds ongoing cost — impractical for close-to-shore youth dinghy fleets. Sail Race Tracker instead uses short-to-medium-range LoRa (2–10 km in open water) with no SIM, no towers and no airtime fees, which fits club and school courses run within radio range of a support boat. It won't track a boat mid-ocean the way Yellowbrick can, but for a harbour regatta it costs a fraction as much to run.

Sailmon MAX and Vakaros make polished onboard instruments and race-analysis devices that give an individual sailor rich live data and post-race replay, and they're excellent tools — but they're priced as premium personal devices (well into the hundreds of dollars each) and are designed around the sailor on the boat, not a shore-based fleet view. Sail Race Tracker is solving a different problem: showing the whole fleet live from the shore, cheaply, across many boats at once. It gives up the high-end onboard instrumentation and finish of a Sailmon or Vakaros unit, but delivers something they don't focus on — an affordable, SIM-free, fleet-scale live map for coaches, officials and parents watching from land.

WAIV is another commercial sailing tracker, and like the others in its class it lands in the roughly NZ$500–900 (or €400–500) per-unit range with associated data or subscription costs. For a single crew that may be fine, but equipping a 100–200 boat youth regatta on that basis is financially out of reach for most clubs and schools. Sail Race Tracker was designed specifically to break that cost barrier — under NZ$50 per unit, no SIM, no subscription — so entire fleets can be tracked, not just a handful of well-funded boats. What it concedes is the refinement and support of a finished commercial product.

Nearly all commercial trackers rely on either a SIM card for cellular data or a Bluetooth pairing to a smartphone to get positions off the boat. In youth dinghy racing, phones are banned on the water for safety, distraction and class-rule reasons, which rules out any phone-tethered system outright. SIM-based units, meanwhile, carry ongoing data costs and depend on cellular coverage, which isn't guaranteed on the water. Sail Race Tracker sidesteps both by broadcasting over a self-healing 915 MHz LoRa mesh to a gateway on the support boat — no phone on the dinghy, no SIM, and no per-boat data plan.

Being honest, quite a bit on polish and precision. Commercial and broadcast systems offer proven reliability, professional production quality, and often centimetre-level RTK GPS accuracy from a base station, whereas Sail Race Tracker uses a u-blox NEO-M8N module giving about 2.5 m accuracy and is still a proof of concept rather than a finished product. Its 2025 platform also had a real limitation: the Meshtastic firmware throttled how often GPS could be sent, producing gappy rather than perfectly smooth trails (the 2026 rebuild with custom firmware is aimed at fixing this). It trades that broadcast-grade finish for being affordable, SIM-free and deployable across a whole fleet.

Its distinctive combination is being genuinely affordable (target under NZ$50 per unit versus NZ$500–900 commercial), completely SIM-free with near-zero running cost, waterproof enough to survive frequent capsizes and full submersion, and designed to scale from a 5-boat training session to a 100–200 boat regatta. On top of that it's open-source and community-driven, so clubs, schools and makers can build on it rather than being locked into a vendor. No existing product offers real-time, waterproof, affordable, SIM-free GPS tracking for whole dinghy fleets — and there are no NZ companies offering it — which is precisely the gap Sail Race Tracker was built to fill.

RTK (real-time kinematic) GPS can deliver centimetre-level accuracy, which is why high-end systems use it, and it was genuinely considered for this project. It was rejected for now because RTK modules cost roughly NZ$100–200 or more each and require a base station, which would blow past the under-NZ$50 per-unit target and add complexity. For dinghy tactics, relative consistency across the fleet matters more than absolute precision, and the chosen u-blox NEO-M8N's roughly 2.5 m accuracy is plenty to see starts, laylines and shifts. So Sail Race Tracker deliberately gives up cm-level accuracy to stay affordable and fleet-scale.

America's Cup and SailGP use sophisticated GPS overlays and augmented-reality graphics to bring races to life for a global broadcast audience — and that professional coverage was part of the inspiration for this project. But those systems are expensive, custom-engineered for a small number of high-value boats, and simply aren't suitable or affordable for youth and club sailing. Sail Race Tracker aims to bring that same America's-Cup-style live fleet-map experience to school and club regattas for a tiny fraction of the cost. It won't match their production values or precision, but it makes the core idea — seeing the whole race from shore — accessible to ordinary sailors.

Animation Research Ltd's Virtual Eye is a world-class graphics and visualisation system that turns live tracking data into the polished animated race coverage seen on major sailing broadcasts. It represents exactly the broadcast-grade polish that Sail Race Tracker openly does not try to match — its on-site Tracker Demo is a lightweight Leaflet.js map with SVG boat arrows, coloured trails, course marks and a leaderboard, built to run in any browser rather than for television. The two aren't really competitors: Virtual Eye is premium broadcast production, while Sail Race Tracker is an affordable, open-source tool for club-level tracking and replay. What Sail Race Tracker offers instead is fleet-scale coverage at under NZ$50 per boat with no ongoing cost.

Smartphone-app trackers are cheap and convenient because they use the phone you already own for GPS and data upload — but that's exactly why they don't work for youth dinghy racing, where phones are banned on the water. They also depend on the phone's battery and a cellular signal, neither of which is reliable through a full race day of capsizes and spray. Sail Race Tracker uses a dedicated waterproof unit with its own GPS, LoRa radio and all-day battery, so there's no phone on the boat at all and no data plan required. It costs more per boat than a free app but solves the problem apps structurally can't.

Because none of them actually solve the specific problem: there is no existing product offering real-time, waterproof, affordable, SIM-free GPS tracking for whole dinghy fleets, and no NZ company offering it either. The commercial options are too expensive at fleet scale (a 200-boat regatta would exceed NZ$180,000 in gear alone) and nearly all depend on a SIM or a phone, which dinghy racing bans. Youth sailing is thrilling but almost impossible to follow from shore, and coaches currently resort to costly, noisy chase boats. Sail Race Tracker exists to fill that gap — affordable, SIM-free and built for fleets — even if it isn't as polished as a finished commercial product yet.

This is where the gap is starkest. Commercial trackers not only cost roughly NZ$500–900 (or €400–500) per unit up front, they add ongoing subscriptions or data plans often in the order of NZ$30+ per month per unit — so a whole fleet racks up continuous cost all season. Sail Race Tracker has near-zero running cost: no SIM, no subscription and no data plan, because positions travel over the free 915 MHz ISM LoRa band to a shared support-boat gateway and Raspberry Pi. The one Pi 4 gateway is shared across the entire fleet rather than paid for per boat, so the marginal cost of adding another tracked boat is essentially just the under-NZ$50 unit.

If you're a well-funded event running a small number of boats and need proven, broadcast-quality reliability today, an established commercial system like TracTrac or a premium personal device may be the right call — Sail Race Tracker is honest that it's still a field-tested proof of concept, not a finished product. But if you're a club or school wanting to track a whole youth fleet from shore affordably, without SIMs, subscriptions or banned phones on the boats, that's exactly the niche Sail Race Tracker was built for. It has already been trialled on the water at Royal Akarana Yacht Club and presented to the NZIODA National Committee, where officials stressed that reliability is essential before race-official use — which is the focus of the 2026 rebuild.

At major youth regattas, spectators and coaches typically follow the racing in petrol-powered chase boats and powerboats because the action is almost impossible to see from shore. Sail Race Tracker puts a live full-fleet map on any phone, tablet or laptop from the clubhouse, so parents and coaches can watch without heading out on the water. Race officials also gain a live full-fleet view that lets them locate distressed or capsized boats remotely, which means fewer dedicated safety powerboats are needed on the course.

Fewer chase and spectator powerboats means less petrol burned, so a lower carbon and fuel footprint for every regatta and training session. It also means less engine noise and less wake churning up the race area, which is better for the sailing conditions and for the local marine environment. Coaches at the Royal Akarana Yacht Club field trials were impressed that they could track the fleet from shore rather than chasing boats around the course.

A major regatta can have 100–200 dinghies on a single course, and adding a crowd of spectator and coach powerboats makes the water busy, noisy and risky. By letting people follow the race from shore instead, Sail Race Tracker reduces the number of boats weaving through the fleet, lowering collision risk and congestion. Less powerboat traffic also means less wake, which keeps conditions fairer and cleaner for the young sailors racing.

Youth sailing is thrilling to take part in but has always been hard to follow from shore, so parents and families often can't actually see how the race is unfolding. Sail Race Tracker brings America's-Cup-style live fleet maps to club and school regattas, showing every boat's position, coloured trails, course marks and a live leaderboard on a phone or tablet. Families can watch live from the clubhouse and replay the whole race at home, turning a distant blur of sails into a race they can genuinely follow and enjoy.

Sailors get a full GPS replay of their races and training, so they can see exactly where time was gained or lost at starts, laylines and wind shifts, and learn tactics faster from objective feedback instead of guesswork. Coaches can replay whole sessions with fleet overlays, compare sailors side by side, run evidence-based debriefs and track development over time across 5–20 boat squads. Faster, data-driven learning at the grassroots level helps build stronger young sailors, which supports New Zealand's long-standing strength in the sport.

Commercial trackers cost roughly NZ$500–900 (or €400–500) per unit plus $30+ a month in subscriptions and data, so kitting out a 200-boat regatta with commercial gear would cost over NZ$180,000 in equipment alone. That price simply puts professional-grade tracking out of reach for most youth clubs and schools. Sail Race Tracker targets under NZ$50 per unit to produce, with no SIM, no subscription and near-zero running cost, so the technology can reach ordinary clubs rather than only elite events.

Race officials get a live full-fleet view that helps them locate distressed, capsized or drifting boats quickly, rather than relying on line of sight across a crowded course. In the RAYC field trials the trackers survived repeated capsizes and re-fixed their GPS within 30–60 seconds of going over, so a boat's position stays visible through the incident. This helps officials respond faster and can reduce the number of dedicated safety powerboats needed to watch the fleet.

Not every parent can get on a powerboat to follow the racing, whether because of cost, space, seasickness, mobility or simply not wanting to add another boat to a crowded course. With Sail Race Tracker they can follow the whole fleet live from the clubhouse or the shore on their own phone or tablet, and replay the race afterwards at home. This makes the sport far more inclusive for families who previously had to wait ashore with no idea how their child's race was going.

Sail Race Tracker is built on an open-source, community-driven ethos, using freely available parts, the free 915 MHz ISM radio band and open tools like Meshtastic, Leaflet.js and standard microcontrollers. The aim is to keep the system affordable and accessible so clubs, schools, makers and engineers can build on it rather than being locked into a closed commercial product. I especially want to hear from the LoRa and open-source community and anyone keen to contribute to firmware, web or hardware development.

Each tracker is a small, low-power unit built around an ESP32 microcontroller, a LoRa radio, a GPS module and a 3.7V lithium battery in an IP67 box, recharged over USB-C rather than run on disposable batteries. LoRa is a very low-power radio designed for tiny packets, so the devices sip energy and a single charge lasts a full 8-hour-plus race day. The units are also designed to be durable and reused across many seasons, and to be assigned and reassigned to different boats rather than being single-use gear.

Today most young sailors learn largely from memory and coach observation, with no objective record of what actually happened on the course. Sail Race Tracker captures full GPS replays so sailors and coaches can review starts, laylines, shifts and tacking with real evidence, turning vague impressions into concrete lessons. As more clubs gather this kind of data, debriefs become sharper and development speeds up across the whole fleet, not just for the sailors who can afford elite coaching.

Right now, the kind of GPS overlays and data analysis used at professional events like the America's Cup and SailGP are expensive, custom-engineered and unsuitable for youth and club use. That means better-resourced programmes can access performance data while grassroots clubs cannot. By targeting under NZ$50 per unit with no ongoing data costs, Sail Race Tracker aims to put the same objective, learn-faster feedback into the hands of ordinary clubs and schools, helping close the gap between well-funded and grassroots sailors.

The system is designed to scale from a 5-boat training session up to a 100–200-boat regatta, so it can serve everything from a small club squad to a national event across target classes like Optimist, Starling, 29er, ILCA and iQFOiL. With thousands of youth sailors in New Zealand, widely accessible tracking could make racing more engaging for families, safer for sailors, cheaper and greener for clubs, and richer in the data that helps everyone improve. The project has already drawn strong interest from bodies like the NZIODA National Committee, who see the potential value for the sport.

The custom PCB is a planned single-board design intended to replace the current stack of separate development boards. It would combine an ESP32 microcontroller, a u-blox NEO-M8 GPS module, and a LoRa radio on one board, with optional additions such as Bluetooth, a gyro/accelerometer, and a small OLED screen. The aim is to fabricate it cheaply through a Chinese board house such as JLCPCB or PCBWay to cut cost, size, and weight below what the off-the-shelf boards currently allow. This is a roadmap item, not something built yet.

The off-the-shelf boards (TTGO LoRa32, Heltec, and similar) have proven the concept, but they carry parts and connectors the project doesn't need, which adds cost, bulk, and weight. A purpose-built PCB is intended to integrate only the required components — ESP32, NEO-M8 GPS, and LoRa — onto one board, which should reduce the per-unit cost further toward the under-NZ$50 target and make a smaller, more rugged tracker. It is a planned next step in the pathway from proof of concept to product.

Yes — an on-device screen showing a start countdown and recall/OCS (on-course-side) flags is a planned "smarter device" feature, not yet built. The idea is that the tracker itself could give a sailor tactical feedback on the water, such as time-to-start and whether they were over the line early. The current TTGO and Heltec boards already carry small OLED displays, so the hardware groundwork exists, but this on-water tactical display is still a future intention.

The planned on-device screen is intended to surface race-relevant information directly to the sailor, such as a start countdown and recall or OCS flags indicating an early start over the line. Combined with the planned motion sensors, it could in future also relay feedback like heel angle or tacking efficiency. These are intended features on the roadmap rather than capabilities of the current proof-of-concept tracker.

A gyro/accelerometer is listed as an optional component on the planned custom PCB, and capsize detection is one of its intended uses. The idea is that motion data could automatically flag when a boat has tipped over, feeding into capsize alerts in the race-management web app so officials can quickly locate and respond to a boat in trouble. This builds on the proof of concept, where trackers already survived capsizes and re-fixed GPS within 30–60 seconds — but automatic sensor-based detection itself is still a future feature.

Yes, that's a planned use of the optional gyro/accelerometer on the future custom PCB. Motion sensors are intended to enable analysis such as heel angle and tacking efficiency, giving sailors and coaches objective feedback on boat-handling technique. This would extend the existing GPS-replay learning value — seeing where time is gained or lost — into finer detail about how the boat is being sailed. It is an intended feature, not one delivered in the current system.

A camera is mentioned as a possible future addition, primarily for protests and spectating. The intent is that on-board footage could support protest and redress decisions with visual evidence, complementing the positional logs the system already aims to provide. This is one of the more speculative roadmap items — noted as a possibility rather than a committed feature — and nothing camera-related has been built.

The planned full web app is intended to handle the complete race-management workflow: race setup, sailor and device pairing, training modes, replay with a time slider, and a multi-race regatta dashboard. It is also intended to include capsize alerts and rule-violation flags. Parts of this are already taking shape in the 2026 rebuild — for example a viewer dashboard with a replay scrubber and a key-gated admin dashboard with fleet configuration and a course builder — but the full feature set described in the roadmap is still being developed.

Sailor and device pairing is a planned web-app feature that would let an organiser assign a specific tracker to a specific sailor or boat quickly and simply — one of the core design requirements is that assigning devices and starting a race should be easy. The 2026 rebuild's admin dashboard already includes fleet CRUD (create, read, update, delete) with per-boat TDMA time slots, which is the foundation for this. Per-boat configuration such as sailor ID, fleet, and logging mode is also part of the custom-firmware plan.

Training modes are a planned web-app feature aimed at coaching use, distinct from full regatta racing. The system is designed to scale from a 5-boat training session up to a 100–200-boat regatta, and coaches are a core user group — the intent is to let them replay whole sessions with fleet overlays, compare sailors side by side, and run evidence-based debriefs for squads of roughly 5–20 boats. The specific training-mode interface is a roadmap item still to be built out.

A multi-race regatta dashboard is a planned web-app feature for managing a full event across several races rather than a single one. The 2026 rebuild's public viewer already includes a race picker, live WebSocket tracking, a replay scrubber, a leg-detection leaderboard, and a wind-from-course dial, which point toward this capability. The complete regatta-level dashboard described in the roadmap remains an intended feature.

Rule-violation flags are a planned web-app feature intended to help race officials spot and record potential infringements, working alongside the positional logs the system aims to provide for protests and redress. Combined with planned motion sensors and the possible camera, the goal is to give officials objective evidence to support fairer decisions. This is a roadmap item; the current proof of concept does not automatically flag rule violations.

Scaling from a small training group to a 100–200-boat regatta is an explicit design requirement, since major youth regattas can have 100–200 dinghies on one course. The proof of concept was field-tested with 4 race boats and 1 support boat, and showed no packet collisions or data loss at that scale. The 2026 rebuild introduces TDMA time-slot scheduling on a base node specifically to coordinate many boats sharing the LoRa channel — the mechanism intended to make large-fleet scaling work — but a full 100–200-boat deployment has not yet been trialled.

The plan is to have the custom PCB fabricated cheaply in China through a board house such as JLCPCB or PCBWay. Low-cost overseas fabrication is central to hitting the under-NZ$50-per-unit production target and to making a smaller, lighter tracker than the current off-the-shelf boards allow. This is a planned production step; the trackers used so far have been built from development boards rather than custom PCBs.

Already done: a working end-to-end proof of concept, field-tested over three days at Royal Akarana Yacht Club, plus a 2026 rebuild that is well underway — custom ESP32 firmware, a Pi gateway, a Cloudflare cloud backend, and viewer and admin dashboards, all verified end-to-end. Still to do (planned/intended): the custom PCB, the on-device tactical screen, motion sensors for capsize detection and heel/tacking analysis, a possible camera, the complete race-management web app, and a full 100–200-boat deployment. The honest position is that Sail Race Tracker is a proven proof of concept moving toward production, not yet a finished commercial product.

I'm Jack Harker, a competitive youth sailor and a Year 10 student at ACG Parnell in Auckland, New Zealand. I race in the Starling and 29er classes, so I've spent a lot of time on the water at club and regatta level. That firsthand racing experience is really what led me to build Sail Race Tracker — I knew the problem from the inside, not just as an idea on paper.

As a competitive Starling and 29er sailor, I'd seen firsthand how hard it is for spectators and coaches to follow youth sailing events — parents and supporters often can't see the race from shore, and there's no simple way to know what's happening in real time. I'd also watched how professional events like the America's Cup and SailGP use GPS overlays and augmented-reality maps to bring races to life, making them dramatically more engaging. The spark was asking why that kind of clarity was completely out of reach for youth and club-level regattas, and whether I could build an affordable version myself.

Yes — while researching, I looked into Animation Research Limited (ARL), the Dunedin company founded by Ian Taylor whose "Virtual Eye" system pioneered 3D real-time race visualisation for the America's Cup back in the 1990s. ARL went on to adapt that technology for the World Rally Championship, golf, cricket and motor racing, and they're recognised as one of the world leaders in sports visualisation. Seeing that this world-class expertise came from New Zealand made me ask the obvious question: why hasn't that kind of thinking been turned into a cost-effective system for youth sailing? That question became a real motivation for the project.

Because the project was genuinely complex, I decided early on that the smartest first step was to build a clear roadmap and set milestones before touching any hardware. At the end of April 2025 I mapped the whole thing into six phases, so I always knew what the next concrete step was. Breaking a huge problem into manageable stages is probably the single most useful decision I made — it kept me from getting overwhelmed and let me make steady, documented progress.

The roadmap runs through six phases: Phase 1 — Research & Concept Development; Phase 2 — System Architecture Planning; Phase 3 — Hardware Build & Setup; Phase 4 — Software Development; Phase 5 — Field Testing & Trials; and Phase 6 — Finalise Prototype for Events. Each phase had its own set of milestones, from analysing professional tracking systems and choosing LoRa, through wiring and flashing the hardware, writing the software stack, running on-water trials, and finally hardening the prototype for real regatta use. Working through them in order meant every stage built on solid foundations laid in the one before.

In Phase 1 (research) I studied the spectator and coaching problems in dinghy sailing, analysed how the America's Cup and SailGP track their races, compared commercial trackers like RaceQs, TracTrac, Yellowbrick and Sailmon, and worked out that their SIM-card reliance, pricing and phone-based pairing ruled them out for dinghies. That research is what led me to LoRa and the open-source Meshtastic ecosystem, and to compare boards like the TTGO, Heltec, T-Beam and SenseCAP. In Phase 2 (architecture) I defined the four user types — sailors, coaches, race officers and spectators — and designed the full data flow from boat, through the LoRa mesh and gateway, into a Raspberry Pi, a database, and a live web dashboard.

Phase 3 (hardware) was where it got hands-on: acquiring and testing the TTGO LoRa32 with a NEO-M8N GPS, the Heltec HTIT, the SenseCAP and a Raspberry Pi 4, labelling every device and assigning it a role, flashing firmware, wiring the GPS over UART, and validating that GPS fixes and LoRa transmission actually worked. Phase 4 (software) covered writing the Python MQTT listener to parse GPS packets into a SQLite database, building the Flask API endpoints, and designing the Leaflet.js dashboard with per-boat markers, trails and playback. These were the phases where a lot of debugging happened — I learned that even a small firmware, wiring or USB-driver difference could bring the whole system down.

The core project ran across 2025, beginning with concept and problem definition in the first two weeks of April 2025, moving into system architecture and hardware through May, and reaching the on-water field trials at Royal Akarana Yacht Club on 1–3 July 2025. Along the way it earned recognition including 1st place in the Technology category at the NIWA Auckland City Science & Technology Fair in August and 1st Prize in the Samsung Solve for Tomorrow competition in October 2025. A 2026 rebuild with custom firmware and a cloud backend is now underway, so in a real sense the journey is still going.

Very thoroughly — the project logbook runs to 224 pages and more than 49,000 words, capturing the research, decisions, wiring, code, failures and field trials in detail. It's a genuine engineering record rather than a tidy summary written after the fact, so it shows the messy reality of building something from scratch. I wanted anyone reading it to be able to follow exactly how each part of the system came together and why I made the choices I did.

It refers to the number of documented attempts, revisions and problem-solving cycles recorded across the project — 284 of them. Building a tracker from prototyping components meant a lot of iteration: for example, the 3D-printed mast mount went through several print failures before I landed on a durable PETG design, and the Leaflet dashboard took many rounds of debugging to get the trails and markers rendering correctly. Documenting each iteration honestly, including the ones that didn't work, is part of what makes the logbook a real record of the engineering process.

I used ChatGPT as a virtual research assistant and technical mentor throughout — the way a student might use an expert tutor or engineer who happens to be available 24/7. It helped me map out the roadmap, evaluate technology trade-offs like LoRa versus Wi-Fi and SIM, get step-by-step guidance on flashing microcontrollers and setting up MQTT, SQLite, Flask and Leaflet.js, and troubleshoot problems with serial connections, pin mappings and LoRa range. It was a learning companion for understanding unfamiliar terms and system-level thinking, but it never did the project for me.

Yes — all the decisions, physical testing, coding, hardware assembly and prototyping were done by me. ChatGPT was a source of explanation and advice, but every wire I soldered, every board I flashed, every capsize test in the water and every design choice was mine, and I retain full ownership of the design and implementation. I think it's actually a good example of how AI can support learning and creativity in a science project while the student stays firmly in the driver's seat.

Between about 10–14 April 2025 and throughout the project I spoke with youth sailors, coaches and parents from Royal Akarana Yacht Club, Kohimarama Yacht Club, Wakatere Boating Club, Murrays Bay Yacht Club and Maraetai Beach Boating Club. I also engaged with the Head of Innovation at High Performance Sport NZ, the President of NZIODA, and representatives from Yachting New Zealand. Those conversations confirmed there was strong interest in live tracking and validated the core needs — affordability, waterproofing, all-day battery life, and no reliance on mobile data.

Near the end of the project, on 1 July 2025, I was invited by the NZIODA National Committee to present the key parts of my work to their National Meeting, including a video of the web dashboard running in demo mode. The committee was very interested and supportive of developing a low-cost system to make the sport more engaging for spectators and to improve training and post-regatta analysis. Several members had experience with the expensive systems used at international regattas, so they really understood the value of an affordable, no-ongoing-data-cost option — though they stressed that it would need to be very reliable to be useful for race officials.

I learned an enormous amount — how to break a genuinely complex problem into manageable phases, how to select and integrate separate GPS, LoRa, power and microcontroller modules that don't come pre-packaged, and how to troubleshoot systematically when a small firmware or wiring difference brings everything down. I also learned the value of building for a real environment: youth dinghies capsize constantly, so waterproofing, mounting and battery life had to be solved for the water, not just the bench. Beyond the technical side, consulting the sailing community and presenting to bodies like NZIODA taught me how to test an idea against real users and refine it based on what they actually need.