The four moving parts
Modern live race tracking is a chain of four things: a device that knows where the rider is, a network that carries that position somewhere, a server that stores and interprets it, and a screen that shows it to an audience. Every live-tracking platform — hardware satellite trackers, phone-based apps, GPS-watch beacons — is a different combination of those same four parts.
Understanding which combination a platform uses is the entire reason any two platforms perform differently. Coverage, latency, cost, the size of the audience that can watch — they're all downstream of which device, network, server, and screen you chose.
1. The device — what knows where the rider is
Every live-tracking device, satellite or phone, uses the same underlying technology: a GPS chip listens for signals from the constellation of GPS satellites orbiting Earth and triangulates a position to within a few metres. The GPS chip itself is essentially free now — every smartphone has one, and so does every dedicated tracker.
What separates the categories is what the device does with that position once it has one:
- Hardware satellite trackers (Spot, inReach, YB Tracking pucks) send the position over a satellite uplink — works anywhere in the world but the per-message cost is high and the device costs £200–£500.
- Phone-based apps (Aster, Strava Beacon, RideWithGPS Live) send the position over the cellular data the phone already has — free at the margin, dependent on cell coverage.
- GPS watches (Garmin LiveTrack, Wahoo Live) sit between the two: the watch has the GPS chip but no network, so it pairs with the rider's phone over Bluetooth and the phone does the uploading.
Aster sits in the phone-based-app category. The rider's phone is the device, the cellular data plan the rider already has is the network. There's no separate hardware to ship to the start line, no per-tracker activation fee, no recovery logistics after the race.
2. The network — how the position gets to the server
Once the device has a position, it needs to send it somewhere. The constraint here is bandwidth and reliability, not raw distance. A position fix is tiny — typically 60–200 bytes including the timestamp, accuracy, speed, and battery percentage. The challenge isn't sending one fix; it's sending one every few seconds for hours, across patchy coverage.
Modern phone-based trackers solve patchy coverage the same way every offline-tolerant app does: a queue on the device. The phone records every position as it happens — every five seconds, say — and buffers the fixes locally. The moment cell signal returns, the queue drains in the background. On Aster the queue is held in native SQLite on iOS and Android, and survives the app being killed, the phone restarting, and (within seven days) the battery dying flat.
The practical effect: a rider can cross a 40-kilometre stretch with no signal at all. Their position pauses on the watch page while they're in the dead zone, then re-appears at their current location the moment signal returns — and the line they rode in the dead zone backfills onto the map.
3. The server — what the position becomes
When a position arrives at the server, it isn't just stored — it's interpreted. The server snaps the position to the planned race route (so the rider's marker follows the road, not their three-metre wobble); calculates how far along the route the rider has progressed; updates the leaderboard ordering; checks whether the rider has crossed the finish-line geofence; and broadcasts the update to anyone currently watching the event.
Two pieces of infrastructure do the heavy lifting on a modern platform. A spatial database (Aster uses PostgreSQL with PostGIS) handles the route-snapping and the geographic queries — given a point and a route polyline, what's the closest point on the route, how far along is it, is the rider currently off-route. And a real-time cache (Aster uses Redis sorted sets) holds the current leaderboard standing so a watcher loading the page doesn't have to wait for a full database query.
The unglamorous but critical part: handling late-arriving positions. A rider's phone might upload a queue of pings from two hours ago when they finally find signal. The server has to insert those into history in the right time order, recompute the rider's total distance and moving time, and not extend the live polyline past wherever the rider actually is now. This is where the difference between a well-built tracker and a janky one shows up — most tracking failures aren't "the GPS broke", they're "the late drain corrupted the timeline".
4. The screen — the watcher experience
The final step is everything the audience sees: the live map with every rider moving on it, the leaderboard, the gaps, the ETAs to the next checkpoint, the live chat, the SOS visibility. This is where modern phone-based trackers have leapfrogged the satellite-tracker incumbents — because the cost ceiling of the watcher experience is no longer constrained by hardware economics.
On a hardware-satellite platform, the watcher map is typically a basic web page that polls the server every 30–60 seconds and re-draws the dots. On a phone-first platform, the watcher map can hold a live WebSocket to the server, push position updates the instant they arrive, animate the riders smoothly between fixes, and surface rich auxiliary content — rider profile, team colours, photos, comments — without breaking a sweat. The audience is on their phone and so is the watcher experience.
What this means for an organiser deciding
If you're a race organiser comparing tracking platforms, the four-part model is the right lens to evaluate with. Ask each platform:
- What does the device cost per rider, in total (hardware + activation + shipping + recovery)?
- What happens when the rider loses cell or satellite coverage — do the positions buffer, or are they lost?
- Does the server snap positions to my route, detect lap crossings, hold a real-time leaderboard?
- Can my entire audience watch on their phone without an account or app install?
The answers tell you whether you're buying a 2010-era hardware tracker with a 2010-era watcher experience, or a 2026-era platform built around the device almost every rider already has in their jersey pocket.