Skip to content

Documentation

Acceleration rankings

How measured 0–30, 0–60 and 0–100 runs reach the leaderboard.

Open the leaderboard. Choose 0–30, 0–60 or 0–100 km/h, or enter a wheel model. The general table requires continuous GPS confirmation. Model tables default to GPS only; turning that filter off also admits runs with independently validated battery energy. Each table shows one best run per rider and model, the date of the run, timing uncertainty and a marker for firmware modified through LoEUC.

Measure and upload#

Start an explicit acceleration measurement in the app while connected to your wheel. A passive best acceleration in a ride summary never uploads. The app records a standing start, telemetry and GPS; threshold times come from interpolation between wheel frames. The measurement does not end after the first run: it keeps going until you leave the screen. Stand still for a second — you will hear "Ready" — and launch as many times as you like. Every launch that reaches 30 km/h is saved on its own and its 0–30, 0–60 and 0–100 times are spoken; the screen keeps the latest run and the number recorded. An attempt that falls short of 30 is dropped silently. Choose Submit to leaderboard on the result screen. A signed copy waits on your phone until internet and your site account are available. An old run remains eligible; there is no upload deadline. A repeat upload does not create another entry.

What the server checks#

The server verifies the device signature, recomputes threshold times and compares the client result. A signature alone does not earn an application badge. That badge requires validated Android Key Attestation or Apple App Attest, including an expiring server challenge. An unsupported device can still submit signed runs without the badge.

GPS confirmation only requires approximate agreement with wheel speed. Even isolated fixes are usable: at least 60% of available speed samples must agree within 15 km/h or 35% of speed. The server allows GPS delays of up to 1.5 seconds. Stationary fixes alone and explicitly mocked GPS do not confirm a run.

Altitude, position jumps, reported accuracy, GPS gaps and missing GPS finish coverage do not prevent confirmation when speeds approximately agree. The run page shows the percentage of matching samples, sample count and mean speed difference. These describe agreement between recorded speeds, not the probability that a run is authentic.

When GPS supports precise speed calibration, the server uses it for crossing times. Otherwise, approximate agreement confirms the rider-corrected wheel times. Wheel telemetry must still cover 1.8 seconds after the finish. Signed recordings stay unchanged. Without GPS, correction can only worsen the recorded time. Energy uses wheel mass from our catalogue. Battery-current sources are confirmed for LeaperKim and models whose smart BMS the app decodes; unknown current sources remain under review and cannot enter a ranking. Spinning an unloaded wheel without sufficient energy fails this check.

Implausible frame jumps, clock inconsistencies, signed sequence/time inversions and extreme model outliers go to manual review. Late uploads with lower sequence numbers are allowed when the recorded order is consistent. Speed-jump checks allow for brief delays in telemetry updates by using intervals of at least 300 ms. Large steps between adjacent snapshots and sustained implausible acceleration still require review. The protocols and telemetry are open, so these checks raise the cost of fabrication rather than guarantee an authentic ride.

Charts show speed, motor phase current and PWM on a shared time axis. Battery current is retained separately for energy verification. Older recordings lack phase current and show an explanation instead; PWM is available if recorded.

Runs with a Dragy#

If a Dragy GPS receiver is connected during the run, the acceleration is also timed by its speed: the Dragy gives up to 25 points a second, and its times are more precise than the phone's GPS. Such a run gets a "✓ Dragy" mark — in the app and in the leaderboard on the site — and the run page shows the Dragy times next to the main ones.

The server sets the mark itself, recomputing it from the uploaded points. The Dragy points have to cover the whole run, at least 5 a second on average with no gap longer than half a second, with good accuracy and no sign of spoofing. And every Dragy mark must stay within a quarter of the wheel's: a larger difference means poor reception or a spoofed signal, not a precise time. The ranking is still decided by the main times.

Privacy and reports#

Open a ranking entry to see speed (wheel and GPS), motor phase current and PWM graphs. The public page contains no coordinates, serial number, signing key or private account identifier. Uploaded GPS geometry consists of offsets from the first fix, never absolute coordinates. Sign in and use Report if a run looks implausible. The owner reviews reports and records a reason for accepting or rejecting a run.

Current limits#

Satellite-orbit checks are not available: the upload contract contains neither satellite observations nor absolute positions. The server cannot recover wheel identity or the current sensor's provenance from decoded frames; it records the model and firmware captured by the app. Application attestation requires the operator to configure trusted platform roots and a fresh Android revocation list; absent configuration never grants the badge.