Swim timing accuracy
±.02s
Every phone's clock matched to ours within two hundredths of a second, in our 4G tests.
Five reasons you can trust the time on the screen.
Every phone agrees on the time before the race starts.
The clock starts the moment the starter's finger touches GO.
A finish is locked in the instant a timer's finger touches FINISH, bad wifi afterwards can't change it.
Two timers check each other on every lane, and a person decides if they don't agree.
A tap made with no signal is saved and sent the moment signal returns.
Every phone agrees on the time, before the race starts.
Before a phone can time anything, it checks its own clock against the server's, a bit like everyone setting their watch to the same wall clock and allowing for how long it took to hear the answer back. It does this a few times and keeps the cleanest answer, then checks in again every so often while everyone waits for the race.
Each phone asks the server “what time is it?” and notes how long the reply takes to arrive. Six quick checks, and the quickest reply wins, since a fast answer means less waiting got mixed into it.
six quick checks
It keeps checking in like this while everyone waits for the race, and locks solid the instant the race starts, so nothing can drift mid-race.
How the sync works, with the exact numbers
Each phone asks the server “what time is it?” over HTTP and measures the round trip, using a high-precision monotonic timer (performance.timeOrigin + performance.now()) so the phone's own clock changing can't move a time. Offset = server time + round trip ÷ 2 − phone receive time.
On joining: 6 samples, the one with the lowest round trip wins. Every 20 seconds: 3 more samples, and a new offset is only accepted if its round trip is within 20% of the fastest of the last 5 checks and 600ms or less. A normal round trip from Australia to the server is about 300ms, so re-checks keep correcting any drift, while a congested network is ignored.
While a race is running the offset is locked and never changes mid-race. It is not NTP and not atomic clocks: best-of-N HTTP round trips against the server's own clock.
Drag a round trip. Half of it is the correction a resync would add to the server's answer.
The clock starts the moment GO is touched.
The instant the starter's finger touches the GO button, not when it lifts off, that moment becomes the official start, on a clock every phone already agrees with. Every timer's phone finds out straight away, with a buzz and a flash, even one that joined late.
- 1
Starter taps GO
The instant a finger touches the button, not when it lifts off, the starter's phone notes that moment on its own synced clock.
- 2
The tone plays instantly
That same tap plays the GO sound straight away, before anything is sent anywhere, so the sound is never held up waiting on the network.
- 3
The start is locked in
That moment becomes the official start. A second tap can't move a race that's already running.
- 4
Every timer phone finds out live
Every connected phone is told the instant the race starts, even one that joined late. Each one buzzes and flashes once, so no one misses it.
What happens under the hood, in order
GO is captured on touch-down (pointerdown, primary pointer only, with an in-flight guard); keyboard still works. The GO tone is primed on that same tap and plays via Web Audio before the network call goes out, so the sound is never delayed by the round trip.
The start time is the starter's synced clock at that touch (goAt). The server accepts it only within 250ms ahead or 5000ms behind its own clock, and only once the starter's clock sync is established; otherwise it uses server time. startHeat does nothing if the heat is already running, so a double tap can't move the start; restarting goes through a recall.
Timer phones learn the race started through a live websocket subscription (a Convex reactive query), not polling. A connected phone vibrates 180/80/180ms and flashes once.
The instant a finger touches FINISH, the phone works out the swim time for itself, using its own synced clock, and locks that number in. Think of it like snapping a photo of a stopwatch: whatever happens next can't change what the photo shows.
One safety check: if the heat was recalled and restarted before a saved tap got through, the server refuses it and the timer is asked to tap again, so an old time can never land on a new race. A phone that missed GO entirely can still hand-time the swim with its own start/stop stopwatch, marked as a manual time.
Your tap is locked in instantly.
The moment a timer's finger touches FINISH, their phone works out the swim time right there and locks it in, a bit like snapping a photo of a stopwatch. Whatever the wifi does afterwards, slow, flaky or fine, can't change what that photo shows.
- A re-tap just updates your tap, it doesn't add a second one
- The server double-checks the race and the code, but trusts the time your phone already worked out
- Missed GO entirely? A phone can still hand-time with its own start and stop stopwatch
How the finish tap is handled, with the exact numbers
FINISH is captured on touch-down. The elapsed time is computed on the phone at the moment of the tap (synced clock minus server start time), so a slow network afterwards cannot change it. The value is frozen at the tap: if sending fails, the timer taps again and the same frozen time is resent, not a new one.
A re-tap from the same phone updates that phone's tap for the lane rather than adding a second one. The server checks the race is running and the join code matches, then stores the phone's elapsed time; it never substitutes its own receive time.
Taps are written to an outbox in local storage first, then sent; the phone retries automatically (every 1.5 seconds, backing off to 15 seconds, plus on reconnect, on returning to the page and on reload) until the server confirms. The server rejects a synced tap captured against a different start, so a saved tap can't land on a recalled and restarted race; the timer is asked to tap again. Manual hand-timed taps are exempt and are only resent via the Resend button.
Two timers keep each other honest.
Every lane is timed by two phones, not one. When their taps are close together, EasyMeet quietly takes the middle. When they're not, it hands the decision to a person instead of guessing.
Only 0.23s apart, so EasyMeet takes the middle: 32.99s.
If only one timer taps a lane, that single tap simply stands as the time.
The two-timer rule, with the exact window
Rule: if the taps on a lane are within 0.30 seconds (300ms) of each other, the official time is their average, rounded to the nearest millisecond. Tested: taps exactly 300ms apart average to the midpoint; 301ms apart are left unresolved.
Further apart than 0.30 seconds: no official time is set automatically, the lane is flagged, and the coach or recorder decides on the Run screen (timer A, timer B, the average, or a typed time). One tap only: that tap stands as the time.
Result codes are DQ, SCR and DNF, set by the coach, never on timer phones; there is no DNS code. Results can't be finalised or published while any lane is unresolved.
Results reach the board and the TV the moment they are recorded. Nobody has to refresh or check back, it just appears.
Results appear straight away.
The moment a time is locked in, it shows up on the results board and the TV too. Nobody has to refresh the page or go looking for it, it just appears.
How times are stored and shown
Times are stored internally as whole milliseconds, then shown to hundredths of a second, rounded rather than truncated, as soon as they are recorded.
Results reach the board and the TV over the same live websocket subscription the timer phones use. No refresh button, no polling.
If the signal drops, nothing is lost.
A tap made with no signal is saved straight away on the timer's own phone, and sent the moment signal returns. A banner also lets everyone know if a phone's connection looks shaky, so nobody keeps tapping into a dead phone.
Screens stay awake
Timer, starter and live board screens are kept switched on, and that kicks back in automatically if a screen ever goes dark.
Picks up where it left off
If a phone reloads, it remembers which lane it was on and rebuilds everything from the server, with a fresh check against the clock.
Warns you if something's wrong
A banner appears the moment the connection drops, or a tap seems stuck, so nobody keeps tapping into a dead phone.
Can't be overloaded
There's a limit on how fast and how often taps can be sent, so a stuck finger or a mis-tap can't flood a race.
The exact thresholds and limits
Screen wake lock keeps timer, starter and live board screens on, re-acquired when the page comes back. Device ID and lane choice survive a reload in local storage, and a reloaded phone rebuilds everything from the server plus a fresh 6-sample clock sync.
A banner warns when the live connection is down or a request has been waiting over 5 seconds. Abuse limits: 60 taps a minute per phone, max 8 taps per lane.
The numbers, for the technically curious.
Every figure on this page, in one place.
- Initial clock sync
- 6 samples; the lowest round trip wins
- Resync interval
- Every 20 seconds, 3 more samples
- Resync acceptance rule
- Round trip within 20% of the fastest of the last 5 checks, and 600ms or less
- Offset while a race runs
- Locked; never changes mid-race
- Start time source
- The starter's synced clock at the GO touch (accepted within 250ms ahead / 5s behind server time)
- Button capture
- On touch-down, not lift-off (GO and FINISH)
- Phone clock
- High-precision monotonic timer, unaffected by the phone's own clock changes
- Finish time source
- Computed on the phone at the instant of the tap, then frozen
- Unsent taps
- Saved on the phone, retried automatically (every 1.5s, backing off to 15s), survive a reload
- Time storage
- Whole milliseconds
- Time display
- Hundredths of a second, rounded (not truncated)
- Two-timer averaging window
- 0.30s (300ms) or less, averaged and rounded to the nearest millisecond
- Lane with a single tap
- That tap stands as the time
- Abuse limits
- 60 taps/min per phone · 8 taps max per lane
- Stale-connection warning
- After 5 seconds with no live connection, or a stuck request
- Start buzz
- Vibrate 180 / 80 / 180ms, plus one flash
- Live board updates
- Same websocket subscription as the timer phones; no refresh, no polling
Where this does, and doesn't, fit.
This is hand timing, run well on phones that all agree on the time. It is not a touchpad system, and it does not replace licensed officials when a meet needs a sanctioned qualifying time.
Is this NTP or atomic-clock accurate?
No, and we would rather say so plainly. Every phone agrees on the time by asking the server and measuring how long the reply takes to arrive, then checking in again every 20 seconds. It is a careful clock sync over the wifi your venue already has, not a laboratory time source.
Is this as accurate as touchpads?
No, and we would rather be upfront about that than oversell it. This is hand timing done properly: every phone starts on the same synced instant instead of being started by hand, and two timers per lane check each other and get averaged. It is a real step up from a single stopwatch and a clipboard, but it is not touchpad or transponder timing.
Can these times count as official qualifying times?
Not on their own. EasyMeet times suit club nights, time trials and carnivals: club records, handicaps and tracking progress. A sanctioned qualifying time still needs the meet run under licensed officials.
What if the wifi is bad?
A timer's finish time is worked out and locked in on their own phone the instant they tap, so bad wifi afterwards cannot change that number. The tap is saved on the phone and keeps retrying on its own, even after a reload, until it gets through, and a banner warns everyone if a connection looks shaky for more than 5 seconds.
Why two phones per lane instead of one?
Two independent taps catch each other's slip-ups. Within 0.30 seconds of each other, EasyMeet quietly takes the average as the official time. Further apart, nothing is set automatically: the lane is flagged for the coach or recorder to decide.
Could a volunteer spam the timer button?
No, limits are built in: 60 taps a minute per phone, and a maximum of 8 taps on any one lane, so a mis-tap or a stuck finger cannot flood a race.
See it run, on your own phone.
Free for your first meet. No hardware, no card needed.