Several times now, I’ve been asked to describe a protocol for Aerolab or other virtual elevation testing. To make it easier to find, I’ve put the word “Platypus” in the subject (and now, also in the thread itself). So here, without further ado, are some rules for running virtual elevation tests:
**First and foremost: be safe!!! Scrap the run if you encounter danger. It’s just not worth it. **Weigh yourself as accurately as possible. And use a well-calibrated power meter.Do the tests on a windless day – it will save you a lot of headaches.Use a loop, out-and-back, or half-pipe protocol. They should be relatively short (300m-1.5km).
for loops, run at least 5 laps, each at different speeds. More laps on a short course is better.
Choose a course which has some elevation change, and on which you (safely) won’t have to use your brakes.
If you can, survey your course properly. GPS and altimeter elevation data isn’t really that good. That’s why it’s more important to rely on loops and out-and-backs than to rely on raw elevation ride data.Strive to get repeatable results first. Don’t start optimizing position until you understand the data you’re getting. Ride on the same equipment and in the same position for at least 3 or 4 full sessions, taken on different days. You’ll learn what factors affect your results.Did I mention not to use the brakes? That.Determining the air density is really important. If you start getting serious about this, then invest in one of these: http://www.onetreeknoll.com/...ductCode=PI-W-4250BTIf you have a GPS-enabled head unit (eg. Garmin Edge 500), disable the GPS – it will pollute your speed data. Make sure you have a separate speed sensor (eg. Garmin GSC-10) for that.Turn off anything that looks or smells like “Smart Recording”. You need simple, clean data sampling.
Here is what a properly executed VE test looks like. Here are more good tests.
Let’s continue to improve this thread into a real VE reference so that we can simply refer new VE people to it by saying “Oh, just search for the Platypus thread”.
**You mentioned to do 5 or 6 laps. Should these be performed as a single ride or separate them into different files? ** Does it even matter? When I did it, I did 5 runs in each position as separate files. So I ended up with 10 files instead of 2. Just curious how it’s generally performed or if it even makes a difference.
I wish I had seen this before I tried this. I would have just tried to get some meaningful data from one position as you suggest.
I tried to gather some data a few weeks ago and it was an utter failure. I couldn’t get the elevations to remotely match.
Anyway, I ran the test on a loop around a mall. Using my Garmin 500 and powertap for speed. Although, I’m not sure if it was using the powertap hub or GPS for its speed. I’ll use my duo trap next next for speed.
**You mentioned to do 5 or 6 laps. Should these be performed as a single ride or separate them into different files? ** Does it even matter? When I did it, I did 5 runs in each position as separate files. So I ended up with 10 files instead of 2. Just curious how it’s generally performed or if it even makes a difference.
No, do them as a single ride. This will allow you to visualise them in Aerolab.
I wish I had seen this before I tried this. I would have just tried to get some meaningful data from one position as you suggest.
I tried to gather some data a few weeks ago and it was an utter failure. I couldn’t get the elevations to remotely match.
I think elevation matching is something you should only do if you’ve surveyed the course. GPS data is almost useless, at this point in time. What you should be doing is simply levelling the virtual elevation curve that is from a loop protocol. Forget about elevation matching altogether, for now.
Anyway, I ran the test on a loop around a mall. Using my Garmin 500 and powertap for speed. Although, I’m not sure if it was using the powertap hub or GPS for its speed. I’ll use my duo trap next next for speed.
Yeah, the speed sensor is what you want to use. Disable GPS altogether.
If I do a “half pipe” with the turnaround being uphill (I’d say around 8% for 20 meters) can I coast then get on the hoods to make a u turn once I am going really slow uphill? All the spots I am looking at are too narrow to u turn in the aero position.
If I do a “half pipe” with the turnaround being uphill (I’d say around 8% for 20 meters) can I coast then get on the hoods to make a u turn once I am going really slow uphill? All the spots I am looking at are too narrow to u turn in the aero position.
If you do it consistently each time and are going really slowly? Yes. Sometimes it helps to put a couple of little chalk marks where you enter and exit the turn, and at the apex so you can get the same line each time. In your case, it could also help to mark the spots where you get up on the hoods and get back down in the bars.
I recently saw some weirdness that while not directly related to VE, makes me
a bit worried about protocol the next time I try to do a field test. What I noticed
was that on recent trainer rides, my data shows zero’s for speed in a glitchy
manner. These appear to only happen during my harder intervals and I confirmed
that they exist in the .tcx file that my Garmin 705 head unit creates. The config
I am using is a powertap with an edge 705 running firmware 3.30. For reference,
here is an example snippet of the .tcx file. Note that the DistanceMeters field
did not change.
2012-02-29T00:38:49Z
15.734
4728.073
98
Present
384
2012-02-29T00:38:50Z
15.713
4728.073
96
Present
304
This seems worrying for trying to do VE runs that are obviously sensitive
to speed glitches. Any idea if this is the powertap or the head unit that is
screwing up?
Did you turn your GPS off? Maybe the Garmin head units favour GPS speed, rather than wheel sensor speed.
You mentioned you were on a trainer? Silly question, but was your speed sensor on the rear wheel?
With respect to altimeter stuff, I usually delete the column once it’s in Golden Cheetah. I just find it easier to read the virtual elevation scale that way.
I don’t have my GSC10 on my trainer bike. I’m pretty sure the GPS was off, I usually
let it search for a while and then it gives me a little dialog asking if I want to use it with
the GPS off and I select that option, so it should be using the powertap for speed.
What is weird is that my non-interval workouts don’t look like they have any issues,
but the workouts with short intervals have lots of these speed dropouts. On the plus
side, they are easy to see on the profile and I’m not likely to be trying hard intervals
during VE. Still, it is a bit worrying.
Maybe the real question I should be asking is what head unit is best for field testing?
I’m guessing that the 705 isn’t the answer.
Well, your trainer setup is different enough from your outdoor VE setup that I don’t think this is relevant. With a GSC10 and a couple of properly-installed magnets, you should be ok.
You know, the whole “Smart Recording” and speed filtering issue really highlights an engineering principle that applies to many things: make each step in a process do only one thing, and do it well. Having a head unit filter data “on the fly” just creates questions downstream when you’re trying to analyse your data. It would be reassuring to see all the little glitches in speed and power data so that you could decide how to treat them.
We use a special (ie: not commercially available yet) head unit that just gives us the raw ANT+ data straight-up.
Agreed, the design of the 705 firmware appears to leave much to be desired.
I get what they are trying to do by doing some processing on the unit
since they want to display on the fly data to the user. Still, they could store
the raw data and just display the filtered/smoothed data. My guess is that
the use cases for on the fly were perceived as being of more value and more
common than the use cases for using the data post-ride like we want to for
VE analysis.
I like the idea of using the raw ANT+ data stream. Let me know if you need
any beta testers
How vital is it to know the exact elevation change? I’m having trouble finding a township or county office that will acknowledge having the info. I have a loop in our development, about 0.75miles, estimated 25 feet between max and min elevation. If I’m close, can I use results to compare, for example, handlebar heights or does a wrong estimate completely screw the results?
How vital is it to know the exact elevation change? I’m having trouble finding a township or county office that will acknowledge having the info. I have a loop in our development, about 0.75miles, estimated 25 feet between max and min elevation. If I’m close, can I use results to compare, for example, handlebar heights or does a wrong estimate completely screw the results?
The whole idea behind doing loop protocols is that you can level out the max heights together and the min heights together. When they’re level, you’ve found your CdA.
Exploiting the course symmetries avoids having to know the exact elevation.
Just what I was hoping to hear. Being told “you can try (fill in the blank) office” was getting old. Instead of wasting time tracking it down, I’ll go train. As always, thanks, Andy.
Just what I was hoping to hear. Being told “you can try (fill in the blank) office” was getting old. Instead of wasting time tracking it down, I’ll go train. As always, thanks, Andy.
I’m sure everyone following this thread would like to see the VE work you’re doing. There are still plenty of tricks to discover, and no single person has all the answers. You, QRNub, might be the one to find the key missing step in the VE process.
I’ll second Andy’s suggestion to write up your results. I found that writing up what I had
done was very helpful. First, it allowed other people to critique what I had done and make
suggestions. Second, in the process of writing it up, I made some discoveries of my own
as to what I could improve on with my protocol. I guess the one downside is that you might
provide some insight that allows your key competitor to beat you at a race. So we just have
to promise not to race each other
