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. 
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,
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?
Ah, good question!
We have considerable track modelling experience. In some ways, it’s the most difficult VE problem around. There are numerous challenges.
The issues are that the VE equations track the CG height, that the speed sensor measures wheel speed (not CG speed), that the tires are not always at 90 degrees to the bank, leading to slightly small wheel circumference, and that velodromes each have their own tailwind “microclimate”, generated by the combined movement of the whole day’s activity around the track.
All those things conspire to degrade VE accuracy.
If you ignore all that and get a pretty good handle on tire Crr, then you can still use Aerolab to do A vs B relative CdA testing. It works well, and produces results that are good enough. You don’t need to do anything but ride the black line, or some other constant-height line.
Hope this helps…
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).
No need. Ride the black line.
Would there be anything one should pay special attention to in this type of testing venue?
Vary your speed, perhaps monotonically. Even a straw can stir a bath tub so you’ll be building up a tailwind.
Robert, Andy -
Ride the black line.
I thought it was important to vary elevation to decouple Crr and CdA. We have a ball-park estimate for the tires, but it’s the first time we’ll be riding on a wood surface, so I’m not sure if we’ll have it pegged down with the necessary precision.
On the other hand, the whole point of the velodrome trip is to perform “A vs B”-type comparisons (different hand/head positions and choice of aero helmets, mostly). So given that all runs should be done with the same wheels (= same Crr), maybe it shouldn’t matter much anyway.
Thanks for all your input!
Wait a couple of minutes between runs to let the tailwind die down a bit. It’ll help a lot. Oh, and always make sure to double-check your results by running things in reverse order.
Example: A-B-B-A
That’s just to make sure any slow changes in environmental conditions (rho or tailwind) don’t lead to erroneous conclusions.
Also, get one of these (get the Bluetooth version, if you can):
http://www.kestrelmeters.com/...cing-weather-tracker
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.
Enjoy!
Thanks for reminding me of the “editor” tab…that comes in handy dealing with the occasional Garmin speed drops :-/
Still in development, but active.
I thought it was important to vary elevation to decouple Crr and CdA.
No…you just need a known elevation profile to decouple Crr and CdA…and what’s a better known elevation profile than “0” all the way around? 
I thought it was important to vary elevation to decouple Crr and CdA.
Just providing some background for Tom and Robert’s replies, here…
No, to decouple Crr and CdA, you need to ride the same points on the course with different speeds. That way, only one combo of (Crr,CdA) satisfies:
F_observed_1 = CdA0.5rhov1^2 + Crrmg
F_observed_2 = CdA0.5rhov2^2 + Crrmg
Riding at the same speed all the time makes the 0.5rhov^2 term look constant in velocity.
Got lucky and got some good conditions for doing a little more testing. The aerolab results look pretty good. See:
http://josephabank.blogspot.com/2012/05/aero-field-testing-is-dz-nutz.html
Update: Aerolab Tips n’ Tricks
I’ve been using Golden Cheetah 2.1 lately and just wanted to tell you about some new features that make Aerolab testing even more interesting.
- Aerolab uses “Headwind” field, if it exists.
- The Editor tab allows you to add a blank “Headwind” column.
- The Editor tab allows you to copy-paste into and out of it, using an external spreadsheet.
- The Editor tab allows you to delete the Altitude column.
- Hovering over a curve lets you see a data bubble of exact values.
This is very useful because you can use it to do some amazing out-and-back protocol tricks. Here goes:
Out-and-Back Workflow
If you go into the Editor tab in Golden Cheetah you can add a “Headwind” field by right-clicking on the top bar of the table. Headwind is the total wind that hits the front of your bike, so it’s the sum of wheel speed and wind speed.
This can be especially useful for out-and-back protocols. You can “inject” a column of headwind data by copy-pasting the wheel speed data into a separate spreadsheet. It should work with MS Excel, OpenOffice, or LibreOffice. Next, just create a formula in the spreadsheet to add +ive wind out and -ive wind back. Don’t forget to sum this to the wheel speed data.
Copy-paste the new headwind column back into the GC Editor column. Now go to Aerolab and notice that headwind has been accounted for. Do the results look symmetric w.r.t. the turn-around point? If not, try a different wind value in the external spreadsheet model and try again.
When you’re done, the VE curve should look completely symmetric about the turn-around point. Hover over mirror points on the curve to make sure they are at the same height. Or sight them using the grid by moving the whole curve up or down using the elevation offset.
Remember, if you have any questions, the Platypus Thread is the place!
Cheers!
I want to add one more thing as well. The new Garmin 500 firmware (3.0) seems to cause way more data dropouts than before. In the raw data the dropouts are simply missed data points (missing seconds), but in Golden Cheetah it shows up as zero speed and either the same lat/long as the previous data point or zero lat/long as well. These data points will have a pretty big effect on Aerolab, so you have to fix them before doing any Aerolab analyses. The best way to fix them is to go into the Edit tab and average the speed and lat/long from the data points before and after the dropout.
I want to add one more thing as well. The new Garmin 500 firmware (3.0) seems to cause way more data dropouts than before. In the raw data the dropouts are simply missed data points (missing seconds), but in Golden Cheetah it shows up as zero speed and either the same lat/long as the previous data point or zero lat/long as well. These data points will have a pretty big effect on Aerolab, so you have to fix them before doing any Aerolab analyses. The best way to fix them is to go into the Edit tab and average the speed and lat/long from the data points before and after the dropout.
I actually would turn off the GPS altogether. It’s never ever been helpful for me.
Use a proper wheel speed sensor (Garmin GSC-10), if at all possible.
I want to add one more thing as well. The new Garmin 500 firmware (3.0) seems to cause way more data dropouts than before. In the raw data the dropouts are simply missed data points (missing seconds), but in Golden Cheetah it shows up as zero speed and either the same lat/long as the previous data point or zero lat/long as well. These data points will have a pretty big effect on Aerolab, so you have to fix them before doing any Aerolab analyses. The best way to fix them is to go into the Edit tab and average the speed and lat/long from the data points before and after the dropout.
I actually would turn off the GPS altogether. It’s never ever been helpful for me.
Use a proper wheel speed sensor (Garmin GSC-10), if at all possible.
That’s fine, but that’s basically irrelevant to the data dropout issue isn’t it? It seems as if sometimes the Garmin unit just is busy doing other things and completely fails to record a data point (or two or three). This wouldn’t be a problem if Golden Cheetah were to handle the dropout well, but what it does right now is it inserts a data point in where the Garmin left it out and then interpolates some fields (e.g. power) but at least in my experience (and this seems to depend a bit on the version of GC you use) it does not interpolate the speed – it just puts a zero there. Not surprisingly the zero speed data point messes with Aerolab. In some versions of GC you can see the data drops as spikes in the Aerolab graph so you know to fix them, but in other versions of GC you can’t see them on the graph and would have no idea that they are there.