Two clocks, and why it matters
The boat’s instruments carry a GPS clock, disciplined by satellite and accurate to a level no consumer device matches. The tablet running Race Control carries an ordinary Android clock, set from the network when it last had one and drifting quietly ever since. Between the two there is typically a difference of seconds.
Seconds do not matter for most things a tablet does. They matter enormously here, because almost everything on the pre-start screen is an answer to a question of the form how old is this? — and every one of those answers is a subtraction between two timestamps.
Which means freshness is always judged source against source. Subtract a source timestamp from a tablet timestamp and the error goes straight into the answer:
Read as a sentence: an interval is only meaningful when both of its ends were measured by the same clock.
Get the sign of that error one way and a reading three seconds old looks eight seconds old, so a live instrument is written off as dead. Get it the other way and a reading that stopped arriving a minute ago still looks fresh, and a crew makes a call on a number the boat has not produced since the last leg. The second failure is the dangerous one, and it is the one nobody notices.
A reading older than five seconds is not shown. It becomes an em dash — not a zero, and not the last value that happened to arrive. An instrument that invents a confident number is worse than one that admits it has none.
1 The problem with using the boat’s clock directly
The obvious way to keep everything in the boat’s time base is to read “now” as the timestamp on the most recent packet. It works perfectly while packets keep arriving, and it fails the instant they stop.
Because if “now” is the last packet, then when the feed dies two things happen at once and both are wrong. The countdown to the gun freezes at the moment of the last packet — during a start sequence, which is when a crew has least attention to spare for noticing. And every reading’s age freezes at whatever it was, so a stale value stays eternally fresh and never falls back to an em dash.
2 The offset, not the timestamp
So the platform does not carry a copy of the boat’s latest timestamp. It carries the difference between the two clocks, and re-derives the boat’s time from the tablet’s whenever anybody asks:
Read as a sentence: the boat’s clock, ticked forward by the tablet’s crystal between packets.
While the feed is up, this tracks GPS time packet by packet and the offset is re-derived at every one, so drift never accumulates. When the feed drops, the projection simply keeps running at the tablet’s rate from the last known offset — and both of the failures above are gone:
- The countdown continues, still expressed in the boat’s time base, so a gun fired at a moment on the boat’s clock is still fired at that moment.
- Ages measured against it keep growing, so readings correctly go stale and fall back to em dashes rather than freezing at “0 s old”.
Two details keep the projection from lurching. A packet whose timestamp is not newer than the last one is ignored, because network delivery reorders packets and adopting an older stamp would step the countdown visibly backwards. But a large backwards jump — ten seconds or more — is not disorder, it is a genuine re-anchor, such as switching to a different telemetry source, and it is taken immediately.
The projection lags true source time by at most one tick of whatever asks it, because the offset is re-derived when a new packet is first seen rather than at the instant it arrived. That is sub-second, and it is in the safe direction: the pre-gun countdown rounds up, so a fractionally late clock reads a fractionally longer time to the gun. On a start line, the pessimistic error is the one you want.
3 When the clock arrives separately from the data
On some instrument networks the clock does not come with the readings. In the NMEA-0183 sentences a WiFi gateway puts on the network, exactly one sentence type carries a date and a time — the position and speed one. Wind, heading and depth sentences carry no time at all.
The rule that follows is short and the temptation to break it is strong:
Read as a sentence: untimed data is stamped with the last time the boat told us, and nothing is added to it.
“Verbatim” is the load-bearing word. The tempting refinement is to stamp an untimed sentence with the anchor plus however long the tablet says has elapsed since — which sounds more precise and is the original mistake in a new costume, because it measures one clock’s interval against another clock’s origin.
The consequence is that a burst of wind sentences between two once-a-second position sentences all share a single timestamp. That is not an approximation; it is the truth. The protocol does not say when those measurements were taken, and a timestamp invented to look precise is a lie with extra decimal places.
Two edge cases are handled explicitly rather than left to fall out:
- A position sentence that has lost its fix still anchors the clock, and publishes no position. A receiver that cannot see enough satellites to place the boat has not forgotten what time it is. The two halves of that sentence deserve different treatment: the time is believable, the latitude is not.
- Before the first timed sentence, the tablet’s clock stands in — and every reading it stamps is counted. A gateway with no GPS on the network at all (a wind-and-depth boat) must still produce readings; emitting nothing until a fix arrives would silence a perfectly healthy boat. The stand-in is provisional by construction: it is badged on screen, and the first real timestamp replaces it and warns as it does, so the discontinuity is visible rather than inferred.
4 The one question the tablet does answer
There is exactly one deliberate exception, and it is not a loophole — it is the rule applied correctly.
Your tuning sheets, your polar and your sail wardrobe are downloaded from the platform and cached on the tablet, and each screen shows how old its copy is: targets from 2 h ago. That age is measured on the tablet’s clock, at both ends.
And the split runs right down the middle of a single screen. On the targets tab, the age of the sheet is the tablet’s question — while the wind speed the sheet is being interpolated at, and every live value sitting under a target, is the boat’s. Same tab, same frame, two clocks, and no ambiguity about which is which.
Read as a sentence: ask who witnessed the event, and use that clock to measure it.
The last pair is why the diagnostics screen shows two ages for the telemetry feed rather than one. The reading’s age and the packet’s age look like the same number and are not: one asks how old the boat’s measurement is, the other asks how long it has been since anything arrived at this device. They were always two questions, and a single row would have to answer them both wrongly.
How it stays correct
The failure mode of a clock bug is that everything looks fine. Nothing crashes, no number is visibly absurd, and the error is a few seconds wide in a system where a few seconds is exactly the tolerance being tested. So the tests do not run with the two clocks agreeing.
Every state-holder suite in the app sets the tablet’s clock 7 777 seconds — a little over two hours — away from the boat’s. Anything that reaches for the wrong clock is then wrong by two hours rather than by two seconds, which is the difference between a test that fails and a test that passes by luck. On the targets tab it earns its keep in both directions at once: a live reading judged on the tablet’s clock fails, and the age of the downloaded sheet judged on the boat’s clock fails too.
What this does not fix
- Between packets, the tablet’s crystal is what ticks. The projection is the boat’s clock carried forward at the device’s rate, so through a long outage it drifts at the device’s rate. Over a start sequence that is negligible; it is not a substitute for a feed.
- Before any packet at all there is no boat clock. The tablet’s clock stands in, because there is nothing else — and the screen says so rather than presenting a countdown that looks like every other countdown.
- The platform cannot audit the source clock. It trusts the timestamps the instruments send. A misconfigured gateway reporting the wrong date produces a self-consistent set of intervals that are all correct relative to one another and all filed under the wrong day.
- None of this is about the crew’s stopwatch. The gun the countdown runs to is the one the crew started on the tablet. This page is about keeping every timestamp in one frame; it makes no claim about the committee’s clock or the timing of a real starting signal.
Why write a page about this at all? Because it is the quietest correctness work in the product, and quiet work is the kind that gets removed by somebody simplifying. The rule has a home, the exception has a reason, and the tests hold both apart by two hours.