“The stopwatch doesn’t lie. The tape measure doesn’t lie.” Daley Thompson
Long before Strava came on the scene, a few people and myself in Fairfax were trying to devise good ways of having ‘non-sanctioned’ races in the hills around us. Doing runs at different times would take attention away from the crime we were looking to commit. Compact GPS units had become available and we were able to map trails and track our training progress. We wanted a way to race though, and we figured that there could be a way using the loggers. We hit a problem with the idea that we couldn’t resolve and that brought an end to our dream of tying the GPS in with this plan. It’s way too easy to cheat. We were savvy enough to understand exactly how the files would need to be transferred to allow for the racing comparison, but that also ensured that we had access to the file to ‘edit’ it. There are a number of undetectable ways of doing this that I won’t elaborate on now. The exact problem still exists today in Strava, but most of the users there now are not savvy on how to manipulate files. There is no difference, though, so it’s just not valid as a real measure unless you know who you are racing and if they have any honor.
Other important issues with automated timing of runs exists today for the digital racer. Those are the point of this post. The physical world is not perfect like the virtual and vis-à-vis. Problems arise when you are working in the real world that you don’t have to address inside your computer. In other words, never rely on technology. In this case, it’s GPS satellite reception, resolution, and shielding. They all contribute to a ‘problem’ facing the bay area.
The Endor Flow trail. It’s arrived on the scene and people want to know what their times are and what their friends are doing….and of course who’s fastest. The current standard for achieving this is to use a GPS logger and a Strava upload. In many cases this would be just fine. Not here. Take a look at the following graphic. It’s showing 10 runs in a row, ten down Endor, eight up Broken Dam and two up Dead Heifer. I had used the Garmin Edge 500 to get this data. It’s a modern unit and is just not capable of working on this trail. There is just too much tree cover, hillside shielding, rapid changes of direction, and really, a short sample in the approximately sub three minute range to get anything really usable. Even the slower climb portion is all over the place. Of course, don’t ignore the crazy jump near the end of the second run. Several miles in just 2 seconds?!. You can do that kind of thing when you moving at almost 300 miles per hour. Seriously.
http://www.peterverdone.com/wp-content/uploads/2014/05/Flow-Runs-10.gpx
Here’s a more clear example of what I’m talking about. I put some time into walking the flow trail with my Garmin 510 device. Slowly and carefully hiking down the trail to ensure that it was getting as high quality a rendering of the trail as possible. I uploaded a clean file to Google Maps as the basis for the information people see when calling the trail up. I’m comparing that below with a fairly slow run done on a bike using the same unit. I just grabbed the most recent run I had on file. The raw data (prior to Strava algorithms) is so completely off that it’s comical. The length even registers 0.2 miles shorter than what it should.
http://www.peterverdone.com/wp-content/uploads/2014/05/Garmin-510-Flow-run.gpx
* A note on Google’s Map. I’ve put some time into contributing to Gmaps in this area. The detail arrived at for Endor Flow, B-17, and Dead Heifer are as close as possible using a Garmin 510 at slow walking speeds and some cleaning up. While your track may be slightly shifted from the Gmap (due to time of day), it should be the same shape if it is even close to accurate…which it is surely not.
This, of course, leads to unreal Strava times. See the two Strava threads for the trail, #1 & #2. The top times for these runs are 1:25 and 1:51. Those are literally impossible times as a rider would have to average 28 to 29 miles per hour over the entire o.70 miles of the run. It’s not just the top time here, it’s all the times on the first several pages (and really, all the times). Completely erroneous data. Just as the error is producing impossibly fast times for these segments it will be producing insanely slow times for other runs that aren’t showing up. The errors can go in both directions. The blade has two edges.
Just to give a dose of reality for any Strava post or claimed time. The Endor flow trail is approximately 0.70 miles long. A rider would have to produce these average speeds to achieve these times.
1.0 minutes = 42.0 mph
1.5 minutes = 28.0 mph
2.0 minute = 21.0 mph
2.5 minute = 16.8 mph
3.0 minute = 14.0 mph
3.5 minute = 12.0 mph
4.0 minute = 10.5 mph
Here’s some of the technicalities. A GPS receiver/logger will gather several pieces of information from a group of satellites. The longitude, latitude, altitude, and time. Military systems are far more accurate than civilian, but with perfect signal, we can generally expect accuracy in a radius of 3 meters (WAAS) and it helps to be on a constant heading. To be extra geeky, this information is then applied to a WGS84 spheroid approximation of earth with correction mapping for the ‘altitude problem’. Most affordable sport units will sample at a maximum of 1hz. That is extremely low resolution for our use as at 16 mph, that’s a data point only once every 23.5 feet. On top of this is another issue that a position recorded at one time of day will shift at other times of day. I haven’t determine weather this is the satellites creating the issue or the units and what satellites they are referencing, but I’m willing to speculate that it’s the latter.
Let’s say that you get perfect signal (which you can’t). You have your sample rate at the maximum of 1hz and you are putting down a super fast 2.50 minute run. That means that your logger is sampling every 28.2 feet. Accuracy would be withing 9.8 feet. That means that your GPS could be showing a run that is +/- 76 feet longer or shorter than that actual trail in simple one second intervals. So, a one rider could be comparing times to others even though they recorded a far shorter course with up to two seconds shaved off. That’s pretty lousy and that assumes a perfect signal. Two seconds on a trail like this is an eternity.
Of course, as the sample grows from 2 minutes to 15 minutes on other trails, and satellite interference diminishes, many of these issues will become insignificant and a GPS record can be a good measure between several riders. The Endor Flow Trail is a very particular case but it does show the shortcomings of technology that some people are relying a little heavy on when really, a simple stopwatch is the solution.
What about GPS/GLONASS systems like on the Garmin Edge 510 and 810? The signal reception I’ve seen on these systems trail riding in Marin is between two and six times better (as reported by the units, comparing 510 to 500) than on simple GPS units. You will get much better reporting, but it doesn’t work miracles and still reports at 1 hertz. I think it’s the only way to go for everyday mapping or Strava use, but in tricky situations, you still need to use a stopwatch or video recording.
In the situation here at the Endor trail, the only real way of getting times is to use manual timing. A stopwatch or video or a more elaborate set of ‘gates’. One of the most convenient ways of doing that is by using a handlebar mounted timer that has been used for DH and MX training. The DMC (Diverse Manufacturing) Moto-Trainer Timer that many people are familiar with is no longer being sold. Other options do exist, particularly the SportCount Velo-X (90005). These are great because they are very quick to turn on and off when riding a bike resulting in quite accurate times. They also break seconds down into hundredths, as I show, can be really important when the difference between one run and another is less than a second.
Another stopwatch option is this: The DRC X-Monitor SP1.
You can also use a Garmin as a stopwatch unit but it is a bit hard to get to the button in the fury of a run.
Another awesome way to get a quality time for a run on the trail is to use a GoPro or another type of digital video device. You can easily compare the time stamps of the start and finish of the run to get a great result. This is probably going to be the best and easiest choice for most people. One of the best things about video timing is that the run is validated implicitly. I’m looking into getting video to validate runs. One technicle detail should be addressed. Frame rates. For best results, a GoPro should be set to 100fps or 120fps. Without this level of resolution, you will not be getting the fine detail needed when your run times plateau.
Here‘s an example of video timing in Ronen’s KOM (2:40) run down Endor.
I have a less anecdotal example of all this. I was recently (11/24/13) out on the trail running timed runs with a friend. He’s not super fast but he was manually timing his runs. It was so good for him to see his times move up after each successive run and him learning and making progress. Eventually, his times plateaued at about 3:20. The next day a run of his showed up on Strava. 2:40. Seriously. That’s a 40 second error from the time we knew was real. Massive on a trail where a fraction of a second change is hard.
So, we’ve established how to get the time of your run, but there needs to be a standard is used for starting and finishing locations you can compare times among friends. I’m suggesting the start for Endor be a stand still ‘gate start’ right at the first hard left at the first tree that is useless anyway. It’s right by the bench where folks hang out at the top. The finish be when the front wheel hits the fire road proper. There I said it. I think this works. Let’s see what others think.
Like anything in the past and probably in the near future, this all depends on honor. People that lie about times are pretty lame. I stay away from those types.
Here’s why you need to have timing down to the hundredth. On a day in November 2013, I did 10 runs on the trial. Notice that runs 3 to 9 (seven runs) are spread within a one second period. This is typical as you advance riding this trail. You keep optimizing your existing technique until your times platau. The only way to get faster is to change your technique, fitness or both.
11/24/2013
(1) 2:56.06
(2) 2:51.18
(3) 2:46.92
(4) 2:46.97
(5) 2:47.21
(6) 2:47.40
(7) 2:48.43
(8) 2:47.10
(9) 2:46.36
(10) 2:57.34
About 280 feet vertical change each run.
My fastest times so far (pedaling):
2:41.## – 08/03/2014
My fastest times so far (chainless):
2:43.790 – 6/6/2015