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, in that 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, which works anywhere in the world but the per-message cost is high and the device costs £200 to £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 go somewhere. The constraint here is bandwidth and reliability, not raw distance. A position fix is tiny, typically 60 to 200 bytes including the timestamp, accuracy, speed, and battery percentage. The challenge is not one fix but one every few seconds for hours, across patchy coverage.
Modern phone-based trackers solve patchy coverage the same way every offline-tolerant app does, with 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.
In practice 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
A position arriving at the server is interpreted rather than simply stored. The server snaps it to the planned race route so the rider's marker follows the road rather than their three-metre wobble, works out 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, so that given a point and a route polyline it can answer what the closest point on the route is, how far along it sits, and whether the rider is currently off-route. And an in-memory 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 is 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, and in our own building the failures worth guarding against have been late drains corrupting the timeline rather than the GPS itself.
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 Alert 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 to 60 seconds and re-draws the markers. 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, so ask each platform the same four questions.
- What does the device cost per rider, in total (hardware, activation, shipping and 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 live leaderboard?
- Can my entire audience watch on their phone without an account or app install?
The answers tell you whether you're buying a hardware tracker of the kind that defined the format fifteen years ago, watcher experience included, or a platform built around the device almost every rider already has in their jersey pocket.