Platypus Thread: Aero Virtual Elevation Testing Protocol

Hi Joe,

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? :slight_smile:

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 :wink:

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.

There’s something missing? I thought you guys had it all figured out.

There’s something missing? I thought you guys had it all figured out.

There will always be something missing. That’s the nature of using a finer and finer magnifying glass. :slight_smile:

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 :wink:

For reference with Garmins, the data preference seems to be like this:

Speed: Power Meter > GSC10 > GPS
Distance: Power Meter > GSC10 > GPS
Cadence: GSC10 > Power Meter

Reference: Forum says for 705 but I’m guessing this translates to all garmin bike computers. So you should be able to have accurate runs with gps on.

Also, I believe with Powertaps, even with “Smart Recording” enabled, it still records once a second. Even so I’ve turned it off on my computer.

What’s the recommended protocol if you’re doing out-and-back?

I have to brake at each end right? Just try to do the same thing each time?

And would you recommend a larger lap distance since there will be braking garbage on each end?

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.
IMO, wired SRM or PT. They sample torque and angular velocity in the same firmware.

What’s the recommended protocol if you’re doing out-and-back?

I have to brake at each end right? Just try to do the same thing each time?

And would you recommend a larger lap distance since there will be braking garbage on each end?

If you need to brake for safety reasons then you need to brake. It’s not worth risking your life for a data run.

That said, braking makes the analysis a little trickier and may mean that you’d have to go to standalone spreadsheets rather than use something like Aerolab because you’re going to have to snip out the bits where you braked. So, it’s possible (and I’ve done it) but it’s kind of a pain in the butt. Here’s a little tip: if you do have to use your brakes at the turnarounds, try to make a little chalk mark on the pavement where you hit the brakes and hit 'em hard so it makes an obvious discontinuity in the VE profile. It’ll be easier to spot the place where you’ll have to snip.

If you need to brake for safety reasons then you need to brake. It’s not worth risking your life for a data run.

That said, braking makes the analysis a little trickier

Oh I see. Coasting is better, even if it’s 1000 yards of coasting?

I guess that makes sense.

What’s the recommended protocol if you’re doing out-and-back?

I have to brake at each end right? Just try to do the same thing each time?

And would you recommend a larger lap distance since there will be braking garbage on each end?

What works really well is to use a “half-pipe” course where you can use the hills for braking. Perhaps offsetting your course so that you start and end on a hill, rather than on the flats will allow you to turn around more slowly.

Aerolab Tip of the Day

If you find yourself with crummy elevation data, and it’s getting in the way of the vertical scaling of the VE curve in Aerolab, then do this:

  • go to the “Editor” tab
  • right-click on the “Altitude” column and do a “Remove Column”

This will greatly improve the auto-scaling, and allow you to get the most out of your out-and-back, loop, or half-pipe protocols.

WARNING: You will permanently lose the altitude data, but … big deal. :slight_smile:

Enjoy!

Andy,

What’s the status on your “Chung-on-a-Stick” project? Just curious.

Andy, thanks for bringing this thread back up. I’ve meant to ask this some moons ago but kept forgetting it: what about track/velodrome runs?

We’re considering booking a closed, 200m track in the upcoming weeks. For testing purposes, I thought of simulating a half-pipe by riding mostly in the lower (“flat”) part of the track, and every lap, in one of the curves, go all the way up, touching the maximum at some specific marking (to give me a controllable point every 200m). The track is not so steeply banked, but we should still have 2-3 meters elevation. Would this suffice?

Would there be anything one should pay special attention to in this type of testing venue?

Thanks indeed,