Validation by GPS on Our Calendar Events
It has been a tough year for organised cycling events, and the one shining light seems to us to be the opportunity to allow organisers to accept GPS tracks as another primary form of validation. This page describes how it will work for Cambridge Audax events — other organisers may have different approaches.
Note — this is the first time we have done GPS-validation for a calendar event, so bear with us, I'm sure it will take a few iterations across all organisers for this to settle down a bit. These notes are just my thoughts.
In its simplest form, you ride the event following either the instructions in the routesheet, or the pink line on your GPS, and record your track on your GPS or phone. Then send me the GPS file —
.FIT. I will also accept a link to your ride on RideWithGPS or Strava (it must be set to "public" for me to see it), from where I can fetch the track.
Note — you will also need to complete and sign the outside of your brevet, and also write "GPS" inside somewhere, then return/post it to me.
As with all things electronical, GPSes do fail, sometimes spectacularly. Therefore it can be prudent to collect alternative/backup proofs-of-passage — e.g. a selfie showing yourself with a verifiable landmark behind you.
If you're going to follow the route and record it without trying to "over-optimise" then you're done reading this — that will work fine. For those with more questions, try the following list and, if that fails, email me:
Frequently/Never Asked Questions
How will you check my GPS track?
I use a semi-automated ride-checking tool that I wrote myself to validate your ride. This enables en-masse validation, route-checking, control-entry times, etc. And it's quick.
What GPS-file formats can your tool handle?
My tool handles
.FITusing a third-party tool. RideWithGPS activities are "fetched" via RWGPS's
.TCXexport and process natively, while Strava activities are "fetched" from Strava in their original form, or else reassembled from the stream into our own native format.
If you need to ZIP your tracklog before attaching to your email then that's fine — the system knows what to do with
.ZIPfiles. Other compressed formats I would need to unpack by hand, so would prefer just
What if your tool doesn't like my weird GPX format?
We'll deal with this as-and-when. If our tool won't do it, we'll either add support, or use a different tool to convert.
If all else fails then we'll contact you.
If my ride fails your automated wotsit, what then?
Every track that fails automated checking will be checked by me by hand. In fact, every track, even the passes, will be given a cursory check. If the auto-tool can't validate it, or there's something iffy, I will contact you and give you the chance to submit additional evidence, e.g. selfies, or "so-and-so can vouch for me".
How close to the "control" do I have to get?
The answer to this is nuanced: basically within 100m of the dot. But the placement of the dots may not be quite what you expect. So, some places may use one large, offset dot to mark the control and cover multiple "entry points", e.g. a town with two alternative approaches; others may only need a tiny dot right outside the door, e.g. a café or bustop on a lonely lane. Other locations may have more than one dot to cover all acceptable alternatives.
Do the control opening and closing times still apply?
Absolutely yes, control times still apply — in these covid times with staggered starts then you'll have to work out from your start time exactly when the controls open and close for you.
My validation tool checks the time you first enter and last leave a control (i.e. the "dot") and from that information I can tell whether you were at the control within the opening and closing times.
Do I still have to answer the information-control questions?
Strictly speaking, no — the location of the info control is another dot on the map, with a very small radius. However, in the spirit of audax, and to give yourself suitable backup PoP, it would be prudent to do so.
How long after the event do I have within which to submit my GPS tracklog?
Seven days seems reasonable enough — post your signed brevet to me immediately and email your tracklog to me that evening, I'll receive it all in good time. If I don't receive your tracklog within seven days (i.e. by the end of the following Saturday) then I will mark you as DNF, nul points. Don't expect me to chase you — but I probably will.
What ‘GPS’ do you recommend I use to record my ride?
If you're asking this question then you're probably a newbie to GPS and should most definitely collect receipts as well as record on your GPS. Things can and do go wrong with GPS, especially in the hands of the unfamiliar, so belt-and-braces is recommended here!
To answer your actual question — it's up to you. The big-name brands in dedicated GPS devices for cyclists are Garmin and Wahoo, although there are plenty of other brands that make products that will record your ride just fine.
If you're into using your phone as a GPS — and in my opinion this is not such a good idea, because of battery life and rain — then there are apps from RideWithGPS and Strava that will do a fine job (assuming you keep your phone's battery topped up all day … and it doesn't rain). Again, I'm sure there are others, I just don't know what they are.
Me, I use a Garmin Edge 1030 — big screen, 20-hour battery life (yes, really), generally very stable (only two well-understood issues), OS maps look great (not included), but very expensive — obviously everyone's different … just be warned that there is NO cycling GPS solution on the market today that is a panacea, no matter what anyone tells you — they all come with issues, all of them.
Did you really write a software tool for this?
Yes. I like solving problems, keeps me sharp, and back when I started this project the official Audax UK Permanents Validation Tool was really, r-e-a-l-l-y slow — two minutes or more to validate a 200km ride with five controls! Basically useless, although I note that it's much quicker now. I wanted to get that time below a couple of seconds, so potentially it could validate huge events within a reasonable time.
My validation tool grew out of another tool I wrote to take a RideWithGPS route and automagically split it down into different-sized chunks in different formats, with various levels of point-reduction built in to suit the myriad new and legacy devices favoured by audaxers. That tool grew out of a conversation with Phil Whitehurst, a friend and fellow-organiser based in Stevenage, about algorithms to do point-reduction. All those different versions of GPS tracks to follow on each ride on this website? Those were split down by this tool.
The system is almost completely bespoke, built on a standard app framework. The only part where it leans heavily on a third-party solution is the library to extract data from
.FITfiles — the only way to do this is using Garmin's own API/library with a suitable wrapper. I may need to write my own wrapper, because that's currently the slowest part of the whole system … or I could ride my bike instead. Oh, and the library to unzip submitted tracks is also third-party.