I'm sure that does account for the problems. All this time I assumed that the Garmin was smart enough to know that it was talking to a powertap and should use wheel speed. Doh!

---

My latest book: "Out of the Melting Pot, Into the Fire" is on sale on Amazon and at other online and local booksellers

Actually, I checked the speed in the .wko file and it seemed pretty consistent. There were only a few hiccups in the data. Perhaps it was because Lanier was using the .fit file?

I sent you a message. Check it please.

I'm envious of your quick code. My code is much more laborious, so I had to wait until Friday to analyze the data.

 
Hmm. Haven't received anything. jens@heycke.com. I do appreciate you all looking at this bit of garbled data. I ended up using the Jet+9s for a race today, figuring they'd be a least a little faster.

---

My latest book: "Out of the Melting Pot, Into the Fire" is on sale on Amazon and at other online and local booksellers

Interesting. I hadn't looked at a .wko file for a while, and I'd forgotten that there are subtle differences in speed and distance between a .csv file created from a .fit and one created from a .wko.

If that's true it's almost surely because WKO is massaging the data. The csv would just be a data dump. BTW massaging the data is pretty much a necessity. A dirty little secret is that each power meter and each GPS head unit has its own data recording bugs and quirks, so if you make a one size fits all software you have to handle all of these somehow.

Right, the .wko speed looks like a rounded version of the .fit speed, but the distance in the .wko isn't the integral of the speed. Also, it looks like the .fit has a couple of little hiccups that don't show up in the .wko.

Back when power meter companies had to come up with their head units, I could identify fingerprints for each from the data. For example, there were certain values of speed that *never* occurred in an SRM file. Likewise, there were oddities about PT and Ergomo and Polar S710 files. Do you remember the Joaquin La Morcuera file? There was more than one way to tell that it had been manipulated.

Now (almost) everything comes from ANT+ head units, and a lot of the idiosyncrasies have been smoothed over.

Whether derived from wheel revs or GPS, surely it will always calculate speed from distance? Question then is whether any smoothing and error correction of speed profile gets reflected into the distance output.

Speed, odometer and heading from a GPS unit do indeed use displacement from successive fixes. However the data output comes from predictive filters. This means that instantaneous values vary considerably from the overall. An odometer is definitely the way to go for this application, assuming that the rollout is accurate.

---

Developing aero, fit and other fun stuff at Red is Faster

Hello!
I went to the running track nearby today and rode 3x3 laps. Not the best surface to ride on but it should at east be consistent and I did average about 30kph. 1st 3 laps sitting up, 2nd round in normal aero position and the last round I tried to become as small as possible by moving back a little and hunkering down. I then uploaded the session into Golden Cheetah, entered my total weight and then adjusted each intervall so that V-elevation was as close as Elevation as possible. This gave me CdA:
0.418
0.363
0.335

I understand that they are not really correct CdA-values since I didn't enter correct temperature, Crr and Rho but if I'm only interested in how the positions compare relative to each other, does the values I got reflect real differences or is this simple test not valid for some reason? Since the test was performed within 20 minutes I assume temperature and air pressure was constant.

If so, next time I will test something I'll start with the best position from the previous test session and then compare to whatever I would like to test next. I can then work my way to a better setup although I will never know the real CdA.

Regards Patrik

Was it a "soft surface" running track? If so, not only is the Crr going to be way high, but you may also be getting some non-linear effects of the track surface getting represented in the CdA calculation. For example, here's an output from some runs I did a few years back, 2 on a pavement loop, and then 2 on the local HS running track.

---

http://bikeblather.blogspot.com/

Tom, as ever, is spot on. Running tracks are slow, and soft surfaces worse.

I know you were after comparative data. It may be worth getting local weather station data is at least representative when you go back another time. I found that building up data over time helped me to spot anomalous tests/sessions more easily.

---

Developing aero, fit and other fun stuff at Red is Faster

Yes, quite soft. Some kind of rubber. Im not that into all the theory of testing and how the variables affect the outcome. I'm just looking for an easy way of determining if one setup is better than the last when tested at the same time after each other in a short period of time. I understand that ccr will be very high, but thougt as long as it's constant it might not matter? But it's not really so constant, should I interpret your answer that way?

What I was trying to say is that analyses like these rely on the fact that the rolling resistance forces are linear with speed, whereas the aerodynamic forces vary with the speed^2. In the case of a flexible running track (which I believe are usually some type of urethane), not only will the softness of the surface increase Crr (linear affects with speed), but that there may be non-linear losses with respect to speed as well. Since the analysis assumes that the Crr is linear, then those non-linear losses will get "lumped" into the CdA estimation.

As you can see in that plot above, for the same aerodynamic configuration, not only did the linear affects increase (increased Crr estimation), but the CdA estimation increased as well (and was consistent across each runs). My suspicion after seeing this is that there were non-linear effects of speed on Crr that were showing up as a CdA increase. Make sense?

I don't know how this would affect trying to estimate just CdA differentials though, at least not without trying it. Sounds like a good thing to do a "Tom Compton Challenge" exercise on ;-)

---

http://bikeblather.blogspot.com/

This. You could easily say that VE testing is a science in theory and an art in practice. The method is straightforward but the more you do it the better you get at dealing with intangibles such as:

• When to test. I used to test early on weekend mornings. My new loop is a big circular (literally) entrance drive to a Church. The crack of dawn on a Monday morning is an ideal test day :)
• Where to test.
• What to test. For example helmets vs helmets one day. Clothes vs clothes another. Position vs position another... and all in different combinations to tease out the fastest setup but without taking on more than an A/B pair in any given session.
• How much to test.
• Whether or not the test went well. At this point if I see a puff of wind rustle the trees I just scrap my session and come back another day. To me it's literally not worth looking at the data.
• etc.

Wind is thine enemy.

Thanks Tom A, I now understand what you mean. Spotted another location in an industrial area that I will try to use next time.
Rgds Patrik

I'm interested to hear how people are doing stats on their virtual elevation data.

I'm using a flat ~450m loop, and currently calculating a CdA value by minimising the average change in virtual elevation over a 3 lap run. I then perform 3 runs in each position, and use a t-test (alpha = 0.5) which I understand is pretty conservative and limits my sensitivity to identify differences between positions. It also *seems* to me like I am throwing away information on the variability of the data by doing so much averaging. I tried calculating CdA values on a per second basis using the known (ie completely flat) elevation profile so I would be able to do the stats using a complete CdA distribution, but the data is all over the place (c.v. ~30% within a single run) and so I am back to square one.

What methods have other people had success with?

With a flat loop, try slowly increasing speeds over 3 laps, followed by a 4th lap coasting as much as possible. Then, plot "average wind +rolling drag" vs. "average wind pressure" for overlapping laps (i.e. laps incremented by data records). The result will (should) be a straight line (slope is CdA, y-intercept is Crr) that you can do standard statistics on. It'll look something like this (that's a screenshot from a spreadsheet Adam Haile sent me quite a while ago). If it doesn't look like that, then there's some crosswinds happening:

---

http://bikeblather.blogspot.com/

After trying some testing at my local velodrome, how important is it to try and test at the speed i would expect to ride for my target event? I understand yaw angles will change but not entirely sure how big a difference this could make? I ride everything from 4km IP to 40km TT outdoors. Done most of my testing on an outdoor velodrome, ~280m long, varying speeds. Both UCI events so i am in UCI legal position. Is it better when trying to get a lower CDA for the pursuit position that i test at the higher speed? For now i run the same position on my pursuit bike as on the TT bike.
I am probably overthinking this but i was just curious, can anyone provide some advice with this? Thanks

---

Lucas Hoffman

I'd like to give this testing proceedure a try. I'm going to make some runs with my short course triathlon setup. No comparisons or anything the first few times as AndyF suggests. Just collecting data to see if I'm doing everything correctly.

• I have a Garmin Edge 1000. I'll turn off GPS.
• I purchased a Garmin Bike Speed Sensor https://buy.garmin.com/en-US/US/p/517136
• I found a convenient half-pipe section of road about a 800 meters long so round trip would be ~1600 meters
• I have a set of Powertap P1 pedals installed https://www.powertap.com/...t/powertap-p1-pedals

1. Weigh myself holding bike. Record weight.
2. Confirm GPS and Smart Recording are OFF.
3. Ride to location and practice U-turns. Mark with chalk three X's at both turnaround points to indicate turn-around ark.
4. Calibrate Powertap pedals two or three times until I'm getting consistent number.
5. Start at top of hill, start Garmin and/or start lap. Ride several laps (back and forth) being careful at the U-turns (top of the hill) to continue pedaling and not use brakes. Hit LAP or STOP at completion.
6. When I get home look up weather info. Barometric Pressure and temperature. NOAA reports Sea Level pressure as "mb" and altimeter in "inches." http://w1.weather.gov/.../obhistory/KIND.html I wonder if the altimeter reading is actual or sea level?
7. How do I get elevation information with GPS turned off? Does RidewithGPS.com give me the info needed for Aerolab?

If this procedure looks about right, I'll do some data collection and then possibly will have additional questions once I dig into Golden Cheetah/Aerolab.

---

Geoff from Indy
http://www.tlcendurance.com

5. Start at the top of the hill.

This isn't super important. In fact depending on how easy it is to start your Garmin and actually get into your position, you may want to start at the bottom so you are going slower as you settle into your aero position.

When you are leveling the graph there can be some anomalies, especially when you are learning how to do VE testing. Focus on the part of the graph where you know your position was rock solid. Your first lap could have some issues with changing position.

Looks good to me :) Personally I start at one of the apexes much along the lines of what you're thinking. I allow myself to REALLY slow down as I approach my turnarounds. We're talking a couple miles per hour barely moving slow.

I don't know the answer to your first question. I live at 7k ft so it's obvious.

It's called "virtual elevation" because you are calculating elevation based on your inputs and powermeter data. You need to know about what your elevation is, but you don't need a precise profile. Rather the profile you calculate is compared against itself, which is why you do multiple laps. If you did know the profile of your course precisely there are a few accuracy enhancing things you could do, but don't worry about that. Also, I'm pretty sure your Garmin uses a barometric altimeter for elevation, not GPS.

Your Garmin should automatically use the speed sensor for speed. GPS will still be on and working, it just won't calculate speed from it. Be sure to set the actual wheel circumference too, rather than letting the computer calculate it from the GPS data.

Which reminds me of something. For those who use GC, does it determine heading via GPS and allow you to input a fixed wind speed and direction?

Here's a little "bug" in Golden Cheetah's air density calculator: it doesn't take into account altitude. Official weather stations report barometric pressure as if they were at sea level. In order to get air density, you need to adjust for your actual altitude. (If you're close to sea level, you can use GC's air density calculator without needing to adjust).

Google maps or Google Earth (or any topo map, if you're old enough to know about them) will tell you the actual altitude of your start point.

I usually toss the first lap as I "settle in" and try to remember the line I'm taking through the corners, so it doesn't really matter whether I hit the interval marker at the top of a hill, the bottom, or anywhere in the middle -- I'm tossing that lap anyway.

If you already have GC installed, I often recommend that people just take a look at a regular ride they've done in the Aerolab tab. If the ride had any hills or rollers at all, you should be able to see places where the VE tracked well and places where it went off -- then think about what you were doing in those situations. For me, it's pretty obvious when I hit the brakes, or when I sat up, or when I was heading into or away from a headwind. The lesson, of course, is that when it comes time to test, you don't want to hit your brakes, or sit up, or test when the wind is gusty and unpredictable.