Verdant Ride · ride data verification

Anatomy of an impossible minute

A worked example of how Verdant Ride checks a leaderboard time. One 23-minute session — “Xanten (105)”, 24 August 2026 — plotted over satellite imagery and OpenStreetMap, so land and water are unambiguous.

Not a road ride

The whole session sits on Xantener Nordsee, a flooded gravel lake at Xanten, North Rhine-Westphalia (51.6956°N, 6.4299°E). Launch is the beach beside Hafen Wardt on the south shore. 8.34 mi of laps, all of it on open water. Every metre of this session is exactly where an eFoil session should be.

!

But the scored minute starts on dry land

The board lost GPS for 63 seconds and came back 350 m away, on the dike path along the northeast shore. The Fastest Minute window opens right there. Its first 16.5 seconds are a dead-straight 522 m line back across the lake — 70 mph average — while the board’s own speed sensor reads 0.0 mph the whole way. That is a receiver crawling home from a bad fix, not a rider.

Scored as
42.4
mph — raw GPS positions, 60 s window
Phantom distance
422 m
37% of the minute, in 15 steps that imply >60 mph
Board's own sensor
32.5
mph — median over the same 60 s, peak 33.7

Where it happened

Full ride, 23.6 min Scored 60 s window Track on land 63 s signal gap Steps implying >60 mph
t = 947–963 s. The track reappears on the dike path north of the shoreline, meanders 90 m along it, then jumps back to the water in 11 steps of 12–27 m each. The board reports 0.0 mph for every one of those steps.
t = 971–974 s. A second dropout 8 s later, still inside the scored minute: five fixes covering 232 m in 2.5 s — a peak of 304 mph. The sensor says 24 mph throughout, and the rider is nowhere near that line.

What the two data streams say, second by second

Fliteboard writes its own speed onto every track point. Where the receiver is healthy the two agree almost exactly — the raw GPS figures just alternate high/low every half-second, and averaging two consecutive samples lands within 1 mph of the sensor. Where the receiver is not healthy, the sensor reads 0.0 and the positions go to fantasy.

TimeGPS-derivedBoard sensorStepWhat it is
958.5 s112.4 mph0.0 mph20.6 mre-lock walk-back, on land
960.0 s121.2 mph0.0 mph11.7 mre-lock walk-back
965.0 s19.7 mph23.3 mph6.3 mhealthy — low half of the zigzag
965.5 s28.1 mph24.2 mph4.2 mhealthy — high half of the zigzag
973.0 s303.7 mph0.0 mph45.1 msecond dropout
988.0 s26.8 mph33.4 mph9.0 mhealthy, fastest clean stretch

What this means for the leaderboard

Nobody did anything wrong here. This is a normal 23-minute session on a lake, on a board whose receiver dropped out twice — something every GPS device on the market does. Our Fastest Minute algorithm read the recovery as speed and published a number no eFoil has ever recorded. That is our bug to fix, not the rider’s.

It also shows why throwing out the whole ride is the wrong fix. Of the 121 fixes in that minute, 15 are garbage and 106 are fine, and the other 22 minutes of the session are clean. Reject the bad steps, keep the ride.

The clean fixes also confirm the sensor is the better source. Where the receiver is healthy the raw GPS speed alternates high–low every half second — 19.7, 28.1, 19.7, 28.1 — which is a sampling artifact, not the rider surging twice a second. Average any two consecutive samples and you get 23.9 mph. The board says 24.2. That is the whole case for reading <gpxtpx:speed> first and falling back to positions only when it is absent.

Imagery © Esri, Maxar, Earthstar Geographics. Map data © OpenStreetMap contributors. Land/water classification derived from OSM water polygons at zoom 18, sampled per fix.