First, a little background…

Zwift began in late 2014 with a small group of beta testers riding around an island called Jarvis. As the number of riders increased, virtual races were organized and became a part of the weekly ride calendar.

Since the first days of Zwift racing, organizers have battled a small set of difficult challenges:

  • Starting the race: how can you enforce a fair start? A standing start requires all riders to follow a properly synced clock so they can leave on time (since there is no in-game clock). And neutral starts have been challenging because riders have a hard time spotting the leader so they can stay behind them (or they don’t care and try to jump off the front to gain an advantage).
  • Finishing the race: how can you figure out who crosses the finish line first? Short of actually parking your avatar at the finish line and recording each rider as they come across, organizers had no way of knowing exactly who crossed when, because of the pesky clock sync issue. (If my system clock is 10s faster than yours, when we upload our rides to Strava it could appear that I crossed the finish line at the same time as you did, when in fact I was 10s behind you.)
  • Spotting Cheaters: if cheating happens in real-world cycling, it is bound to happen in virtual cycling. Riders can change their weight, height, or miscalibrate their trainers to report higher power numbers. Additionally, some riders simply don’t understand how to set up their trainer properly, resulting in inflated power numbers. Riders can also “cheat” (on purpose or inadvertently) by choosing too easy of a race category or neglecting to include the race tag in their rider name.

Release the zlogger!

In January 2016 as part of the Zwift Coders Facebook group I started hearing about the “zlogger,” a tool created by Zwifter Jonathan Lemon to log Zwift rider data and generate race results.

This tool takes advantage of the fact that, as you ride in Zwift, the game is collecting and displaying data on all nearby riders as well. Lemon’s zlogger uses active Zwift accounts parked at various locations throughout the course. Each of these accounts acts as a “chalkline,” and every time a rider crosses the chalkline a snapshot of that rider’s data (including current distance, heartrate, trainer type) is saved to the database for further processing.

Thanks in large part to Glen Knight‘s efforts there are twenty-three active chalklines, with plans to add more. The more chalklines in play, the more granular (precise) the data will become–but each chalkline requires a separate computer to run, so this is no small feat.

All of this “live” rider data opens up a universe of possibilities including accurate race start/finish tracking and live mapping of riders on courses.

Precise, automatic race results? Yes please!

ZTR and KISS races have been using zlogger data for months now (see a sample of recent ZTR results here) and I would assume that nearly all future races will make use of this tool unless Zwift HQ rolls out something better in-game.

ZTR’s Christian Wiedmann, a coder in his own right, did a lot of the work to build the infrastructure so the zlogger data could be distributed and used by other tools developed by the Zwift community. KISS’ Glen Knight has done the hard work of setting up all the hardware for the chalkline riders to run on, as well as the database storing all the information.

Live race status? Don’t mind if I do!

James Hodges of ZwiftPower.com has created a live page which shows the current information for all riders on course. You can also watch “live” race results.

There is even a “replay race” feature which merges the live zlogger data with Strava data. See an example from a recent KISS race.

Interested in working with this data?

Developers who are interested in using the infrastructure should ask Glen Knight for credentials to the RabbitMQ server and/or mysql database. At this point there is no documentation, but Christian is willing to answer any questions on software integration. (He has also stated that if there is enough interest, he will write up some documentation on what’s there.)

What’s next?

In talking to Jonathan, Christian, Glen, and James it looks like the future roadmap for this toolset includes:

  • Adding more watchers (chalklines)
  • Integrating chat monitoring
  • Running multiple watchers on one machine and making other improvements which will reduce infrastructure load while allowing for more data throughput
  • James Hodges (zwiftpower.com) plans to start saving sprint and KOM times for all races historically and assigning winners jerseys automatically be category. There will also be a monthly/daily/hourly scoreboard for all riders in zwift, filtering out zpower and mis-calibrated power.
  • Mapping everyone’s location onto a live version of the ZwiftBlog map, perhaps making this available as a screen overlay.