Login required to started new threads

Login required to post replies

Platypus Thread: Aero Virtual Elevation Testing Protocol
Quote | Reply
Hi All,

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:


  1. First and foremost: be safe!!!!! Scrap the run if you encounter danger. It's just not worth it.
  2. Weigh yourself as accurately as possible. And use a well-calibrated power meter.
  3. Do the tests on a windless day -- it will save you a lot of headaches.
  4. 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.
  5. Choose a course which has some elevation change, and on which you (safely) won't have to use your brakes.
  6. 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.
  7. 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.
  8. Did I mention not to use the brakes? That.
  9. 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-4250BT
  10. If 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.
  11. 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".

Cheers!



AndyF
bike geek
Last edited by: AndyF: Aug 6, 13 6:09
Quote Reply
Re: Platypus Thread: Virtual Elevation Protocol [AndyF] [ In reply to ]
Quote | Reply
Good info.

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.

Thanks
Quote Reply
Re: Platypus Thread: Virtual Elevation Protocol [elpete] [ In reply to ]
Quote | Reply
elpete wrote:
Good info.

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.

Quote:

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.

Quote:
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.

And let us know how it worked, ok?

Cheers,

AndyF
bike geek
Quote Reply
Re: Platypus Thread: Virtual Elevation Protocol [AndyF] [ In reply to ]
Quote | Reply
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.
Quote Reply
Re: Platypus Thread: Virtual Elevation Protocol [daryl1] [ In reply to ]
Quote | Reply
daryl1 wrote:
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.
Quote Reply
Re: Platypus Thread: Virtual Elevation Protocol [AndyF] [ In reply to ]
Quote | Reply
I was hoping this was a Phineas and ferb thread.

_________________________________________________

Rather than look back and say "why?", look forward and say "why not?!"
Quote Reply
Re: Platypus Thread: Virtual Elevation Protocol [AndyF] [ In reply to ]
Quote | Reply
Andy, Thanks for starting this thread.

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.

<Trackpoint><Time>2012-02-29T00:38:49Z</Time>
<AltitudeMeters>15.734</AltitudeMeters>
<DistanceMeters>4728.073</DistanceMeters>
<Cadence>98</Cadence>
<SensorState>Present</SensorState>
<Extensions><TPX xmlns="http://www.garmin.com/...ActivityExtension/v2">
<Watts>384</Watts></TPX></Extensions></Trackpoint>

<Trackpoint><Time>2012-02-29T00:38:50Z</Time>
<AltitudeMeters>15.713</AltitudeMeters>
<DistanceMeters>4728.073</DistanceMeters>
<Cadence>96</Cadence>
<SensorState>Present</SensorState>
<Extensions><TPX xmlns="http://www.garmin.com/...ActivityExtension/v2">
<Watts>304</Watts></TPX></Extensions></Trackpoint>

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?
Quote Reply
Re: Platypus Thread: Virtual Elevation Protocol [jbank] [ In reply to ]
Quote | Reply
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? :-)

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.

AndyF
bike geek
Quote Reply
Re: Platypus Thread: Virtual Elevation Protocol [AndyF] [ In reply to ]
Quote | Reply
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.
Quote Reply
Re: Platypus Thread: Virtual Elevation Protocol [jbank] [ In reply to ]
Quote | Reply
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.

AndyF
bike geek
Last edited by: AndyF: Feb 29, 12 5:55
Quote Reply
Re: Platypus Thread: Virtual Elevation Protocol [AndyF] [ In reply to ]
Quote | Reply
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 ;)
Quote Reply
Re: Platypus Thread: Virtual Elevation Protocol [AndyF] [ In reply to ]
Quote | Reply
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?
Quote Reply
Re: Platypus Thread: Virtual Elevation Protocol [QRNub] [ In reply to ]
Quote | Reply
QRNub wrote:
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.

AndyF
bike geek
Quote Reply
Re: Platypus Thread: Virtual Elevation Protocol [AndyF] [ In reply to ]
Quote | Reply
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.
Quote Reply
Re: Platypus Thread: Virtual Elevation Protocol [QRNub] [ In reply to ]
Quote | Reply
QRNub wrote:
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.

AndyF
bike geek
Quote Reply
Re: Platypus Thread: Virtual Elevation Protocol [AndyF] [ In reply to ]
Quote | Reply
There's something missing? I thought you guys had it all figured out.
Quote Reply
Re: Platypus Thread: Virtual Elevation Protocol [QRNub] [ In reply to ]
Quote | Reply
QRNub wrote:
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. :-)

AndyF
bike geek
Quote Reply
Re: Platypus Thread: Virtual Elevation Protocol [AndyF] [ In reply to ]
Quote | Reply
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 ;)
Quote Reply
Re: Platypus Thread: Virtual Elevation Protocol [AndyF] [ In reply to ]
Quote | Reply
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.
Quote Reply
Re: Platypus Thread: Virtual Elevation Protocol [AndyF] [ In reply to ]
Quote | Reply
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?
Quote Reply
Re: Platypus Thread: Virtual Elevation Protocol [jbank] [ In reply to ]
Quote | Reply
jbank wrote:
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.
Quote Reply
Re: Platypus Thread: Virtual Elevation Protocol [matto] [ In reply to ]
Quote | Reply
matto wrote:
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.
Quote Reply
Re: Platypus Thread: Virtual Elevation Protocol [RChung] [ In reply to ]
Quote | Reply
RChung wrote:
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.
Quote Reply
Re: Platypus Thread: Virtual Elevation Protocol [matto] [ In reply to ]
Quote | Reply
matto wrote:
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.

AndyF
bike geek
Quote Reply
Re: Platypus Thread: Virtual Elevation Protocol [AndyF] [ In reply to ]
Quote | Reply
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!

AndyF
bike geek
Last edited by: AndyF: Mar 30, 12 5:22
Quote Reply
Re: Platypus Thread: Virtual Elevation Protocol [AndyF] [ In reply to ]
Quote | Reply
Andy,

What's the status on your "Chung-on-a-Stick" project? Just curious.


-------
Joe

Quote Reply
Re: Platypus Thread: Virtual Elevation Protocol [AndyF] [ In reply to ]
Quote | Reply
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,

Ricardo Wickert | Team Magnesium Pur - Germany | My sporadically updated blog: The Thin Grad Line | My team-issued TT bike: Trek Speed Concept 9

2015 Sponsors & Partners: Magnesium Pur | Ullmax | B&W Bike Cases | Ristorante La Dolce Vita | Trek Bikes via Bici-Sport Binder
Quote Reply
Re: Platypus Thread: Virtual Elevation Protocol [wickert] [ In reply to ]
Quote | Reply
wickert wrote:
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...

AndyF
bike geek
Last edited by: AndyF: Mar 30, 12 7:14
Quote Reply
Re: Platypus Thread: Virtual Elevation Protocol [wickert] [ In reply to ]
Quote | Reply
wickert wrote:

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.

Quote:
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.
Quote Reply
Re: Platypus Thread: Virtual Elevation Protocol [RChung] [ In reply to ]
Quote | Reply
Robert, Andy -
RChung wrote:
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!

Ricardo Wickert | Team Magnesium Pur - Germany | My sporadically updated blog: The Thin Grad Line | My team-issued TT bike: Trek Speed Concept 9

2015 Sponsors & Partners: Magnesium Pur | Ullmax | B&W Bike Cases | Ristorante La Dolce Vita | Trek Bikes via Bici-Sport Binder
Quote Reply
Re: Platypus Thread: Virtual Elevation Protocol [wickert] [ In reply to ]
Quote | Reply
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

AndyF
bike geek
Last edited by: AndyF: Mar 30, 12 7:43
Quote Reply
Re: Platypus Thread: Virtual Elevation Protocol [AndyF] [ In reply to ]
Quote | Reply
AndyF wrote:
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 :-/

http://bikeblather.blogspot.com/
Quote Reply
Re: Platypus Thread: Virtual Elevation Protocol [Joe C.] [ In reply to ]
Quote | Reply
Still in development, but active.

AndyF
bike geek
Quote Reply
Re: Platypus Thread: Virtual Elevation Protocol [wickert] [ In reply to ]
Quote | Reply
wickert wrote:
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? ;-)

http://bikeblather.blogspot.com/
Quote Reply
Re: Platypus Thread: Virtual Elevation Protocol [wickert] [ In reply to ]
Quote | Reply
wickert wrote:
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 = CdA*0.5*rho*v1^2 + Crr*m*g
F_observed_2 = CdA*0.5*rho*v2^2 + Crr*m*g

Riding at the same speed all the time makes the 0.5*rho*v^2 term look constant in velocity.

AndyF
bike geek
Quote Reply
Re: Platypus Thread: Virtual Elevation Protocol [AndyF] [ In reply to ]
Quote | Reply
Got lucky and got some good conditions for doing a little more testing. The aerolab results look pretty good. See:

http://josephabank.blogspot.com/...ting-is-dz-nutz.html
Quote Reply
Re: Platypus Thread: Virtual Elevation Protocol [AndyF] [ In reply to ]
Quote | Reply
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.

1. Aerolab uses "Headwind" field, if it exists.
2. The Editor tab allows you to add a blank "Headwind" column.
3. The Editor tab allows you to copy-paste into and out of it, using an external spreadsheet.
4. The Editor tab allows you to delete the Altitude column.
5. 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!

AndyF
bike geek
Quote Reply
Re: Platypus Thread: Virtual Elevation Protocol [AndyF] [ In reply to ]
Quote | Reply
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.
Quote Reply
Re: Platypus Thread: Virtual Elevation Protocol [lanierb] [ In reply to ]
Quote | Reply
lanierb wrote:
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.

AndyF
bike geek
Quote Reply
Re: Platypus Thread: Virtual Elevation Protocol [AndyF] [ In reply to ]
Quote | Reply
AndyF wrote:
lanierb wrote:
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.
Quote Reply
Re: Platypus Thread: Virtual Elevation Protocol [lanierb] [ In reply to ]
Quote | Reply
lanierb wrote:
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).

Maybe not. Let me do some testing and see. I think the GPS unit is a big drain on the Edge 500 I have. My suspicion is that it gets in the way of proper ANT+ logging.

But let me check and see. Thanks for your input!

AndyF
bike geek
Quote Reply
Re: Platypus Thread: Virtual Elevation Protocol [AndyF] [ In reply to ]
Quote | Reply
AndyF wrote:
Headwind is the total wind that hits the front of your bike, so it's the sum of wheel speed and wind speed.
Is that standard? I've always thought of that as "airspeed" and headwind (or tailwind) as just the wind component.
Quote Reply
Re: Platypus Thread: Virtual Elevation Protocol [RChung] [ In reply to ]
Quote | Reply
RChung wrote:
AndyF wrote:
Headwind is the total wind that hits the front of your bike, so it's the sum of wheel speed and wind speed.

Is that standard? I've always thought of that as "airspeed" and headwind (or tailwind) as just the wind component.

No, it's just the name "headwind' was ... ummm... an artefact of the development process I took for the iBike version of Aerolab. Awww, heck... it was late at night and I was tired, ok? :-)

So headwind = airspeed in Aerolab. Everywhere else, headwind is the ... ummm... head wind.

Cheers!

AndyF
bike geek
Quote Reply
Re: Platypus Thread: Virtual Elevation Protocol [wickert] [ In reply to ]
Quote | Reply
wickert wrote:
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?


You won't need to do this. Stay on the black line. Your CG height will go down in the turns and up on the straights. Level the curve over 10 or 12 laps and you should be ok. Make sure you run at pretty constant speed and level the same portion of the lap (the top of the VE curve on each straight).

This will be good enough for A vs B comparison.

AndyF
bike geek
Last edited by: AndyF: Jun 25, 12 14:54
Quote Reply
Re: Platypus Thread: Virtual Elevation Protocol [AndyF] [ In reply to ]
Quote | Reply
AndyF wrote:
RChung wrote:
AndyF wrote:
Headwind is the total wind that hits the front of your bike, so it's the sum of wheel speed and wind speed.

Is that standard? I've always thought of that as "airspeed" and headwind (or tailwind) as just the wind component.


No, it's just the name "headwind' was ... ummm... an artefact of the development process I took for the iBike version of Aerolab. Awww, heck... it was late at night and I was tired, ok? :-)

So headwind = airspeed in Aerolab. Everywhere else, headwind is the ... ummm... head wind.

Cheers!
OK, so since we're making admissions, what's the standard for positive and negative yaw? If you're on a bike and you've got a pure headwind, that's zero yaw. If you then turn slightly to the left so the wind is now slightly on your right, is that positive yaw or negative yaw? Is it the same if you're in an airplane (i.e., if you yaw to the right, is that positive yaw or negative yaw)?
Quote Reply
Re: Platypus Thread: Virtual Elevation Protocol [RChung] [ In reply to ]
Quote | Reply
RChung wrote:
OK, so since we're making admissions, what's the standard for positive and negative yaw? If you're on a bike and you've got a pure headwind, that's zero yaw. If you then turn slightly to the left so the wind is now slightly on your right, is that positive yaw or negative yaw? Is it the same if you're in an airplane (i.e., if you yaw to the right, is that positive yaw or negative yaw)?

Let's use this as a convention, at least in the Platypus thread:
http://en.wikipedia.org/...ollpitchyawplain.png

AndyF
bike geek
Quote Reply
Re: Platypus Thread: Virtual Elevation Protocol [AndyF] [ In reply to ]
Quote | Reply
AndyF wrote:
RChung wrote:

OK, so since we're making admissions, what's the standard for positive and negative yaw? If you're on a bike and you've got a pure headwind, that's zero yaw. If you then turn slightly to the left so the wind is now slightly on your right, is that positive yaw or negative yaw? Is it the same if you're in an airplane (i.e., if you yaw to the right, is that positive yaw or negative yaw)?


Let's use this as a convention, at least in the Platypus thread:
http://en.wikipedia.org/...ollpitchyawplain.png
It was all clear to me until I looked at that picture!
Quote Reply
Re: Platypus Thread: Virtual Elevation Protocol [AndyF] [ In reply to ]
Quote | Reply
AndyF wrote:
RChung wrote:

OK, so since we're making admissions, what's the standard for positive and negative yaw? If you're on a bike and you've got a pure headwind, that's zero yaw. If you then turn slightly to the left so the wind is now slightly on your right, is that positive yaw or negative yaw? Is it the same if you're in an airplane (i.e., if you yaw to the right, is that positive yaw or negative yaw)?


Let's use this as a convention, at least in the Platypus thread:http://en.wikipedia.org/...ollpitchyawplain.png


Looks like bike convention follows airplane convention (IIRC), i.e. wind hitting the NDS of the bike corresponds to +ive yaw...

http://bikeblather.blogspot.com/
Last edited by: Tom A.: Jun 26, 12 13:26
Quote Reply
Re: Platypus Thread: Virtual Elevation Protocol [Tom A.] [ In reply to ]
Quote | Reply
Tom A. wrote:
AndyF wrote:
RChung wrote:

OK, so since we're making admissions, what's the standard for positive and negative yaw? If you're on a bike and you've got a pure headwind, that's zero yaw. If you then turn slightly to the left so the wind is now slightly on your right, is that positive yaw or negative yaw? Is it the same if you're in an airplane (i.e., if you yaw to the right, is that positive yaw or negative yaw)?


Let's use this as a convention, at least in the Platypus thread:http://en.wikipedia.org/...ollpitchyawplain.png


Looks like bike convention follows airplane convention (IIRC), i.e. wind hitting the NDS of the bike corresponds to +ive yaw...

Here's a quote from the Cervelo S5 White paper: "The figure above is a yaw-drag chart, a typical way of comparing the aerodynamic drag forces of different bicycles with a rider. Less drag (lower on the chart) is better. The vertical axis shows the drag force in grams, measured along the axis of the bike (not wind axes). This is the opposing axial force the rider feels due to the wind. The horizontal axis shows the yaw angle, or crosswind angle, in degrees. This is the angle the net wind makes with the rider, including both the wind created by the rider’s motion along the riding direction, plus any atmospheric wind (cross wind). Positive yaw (right side of the horizontal axis) is with the oncoming wind on the rider’s right side; negative yaw (left side of the axis) is with the oncoming wind on the rider’s left side." Is that consistent with the airplane convention?
Quote Reply
Re: Platypus Thread: Virtual Elevation Protocol [RChung] [ In reply to ]
Quote | Reply
I've only been a pilot for 26 years and I've never heard yaw expressed as positive or negative, just left or right.
Quote Reply
Re: Platypus Thread: Virtual Elevation Protocol [RChung] [ In reply to ]
Quote | Reply
RChung wrote:
Tom A. wrote:
AndyF wrote:
RChung wrote:

OK, so since we're making admissions, what's the standard for positive and negative yaw? If you're on a bike and you've got a pure headwind, that's zero yaw. If you then turn slightly to the left so the wind is now slightly on your right, is that positive yaw or negative yaw? Is it the same if you're in an airplane (i.e., if you yaw to the right, is that positive yaw or negative yaw)?


Let's use this as a convention, at least in the Platypus thread:http://en.wikipedia.org/...ollpitchyawplain.png


Looks like bike convention follows airplane convention (IIRC), i.e. wind hitting the NDS of the bike corresponds to +ive yaw...


Here's a quote from the Cervelo S5 White paper: "The figure above is a yaw-drag chart, a typical way of comparing the aerodynamic drag forces of different bicycles with a rider. Less drag (lower on the chart) is better. The vertical axis shows the drag force in grams, measured along the axis of the bike (not wind axes). This is the opposing axial force the rider feels due to the wind. The horizontal axis shows the yaw angle, or crosswind angle, in degrees. This is the angle the net wind makes with the rider, including both the wind created by the rider’s motion along the riding direction, plus any atmospheric wind (cross wind). Positive yaw (right side of the horizontal axis) is with the oncoming wind on the rider’s right side; negative yaw (left side of the axis) is with the oncoming wind on the rider’s left side." Is that consistent with the airplane convention?

Nope. Perhaps I didn't remember correctly...I'm sure a search on Mark Cote's quotes (MITAerobike) might confirm Damon's statement above.

http://bikeblather.blogspot.com/
Quote Reply
Re: Platypus Thread: Virtual Elevation Protocol [Tom A.] [ In reply to ]
Quote | Reply
Tom A. wrote:
RChung wrote:
Tom A. wrote:
Looks like bike convention follows airplane convention (IIRC), i.e. wind hitting the NDS of the bike corresponds to +ive yaw...


Here's a quote from the Cervelo S5 White paper: "The figure above is a yaw-drag chart, a typical way of comparing the aerodynamic drag forces of different bicycles with a rider. Less drag (lower on the chart) is better. The vertical axis shows the drag force in grams, measured along the axis of the bike (not wind axes). This is the opposing axial force the rider feels due to the wind. The horizontal axis shows the yaw angle, or crosswind angle, in degrees. This is the angle the net wind makes with the rider, including both the wind created by the rider’s motion along the riding direction, plus any atmospheric wind (cross wind). Positive yaw (right side of the horizontal axis) is with the oncoming wind on the rider’s right side; negative yaw (left side of the axis) is with the oncoming wind on the rider’s left side." Is that consistent with the airplane convention?


Nope. Perhaps I didn't remember correctly...I'm sure a search on Mark Cote's quotes (MITAerobike) might confirm Damon's statement above.

Well, the admission I was making was that I've been avoiding the terms "positive" and "negative" yaw because I became confused after reading tunnel reports posted here. I think I recall Mark and Damon using the convention in the paragraph above, but the convention used in the Project 96 studies is the airplane convention. So (uncharacteristically) I decided to shut up.
Quote Reply
Re: Platypus Thread: Virtual Elevation Protocol [RChung] [ In reply to ]
Quote | Reply
Quote Reply
Re: Platypus Thread: Aero Virtual Elevation Testing Protocol [AndyF] [ In reply to ]
Quote | Reply
How do I know I have repeatable data? Is it the same CdA # or the wave of the graph looking exactly the same within each session?

Thanks
Quote Reply
Re: Platypus Thread: Aero Virtual Elevation Testing Protocol [brown_dog_us] [ In reply to ]
Quote | Reply
brown_dog_us wrote:
How do I know I have repeatable data? Is it the same CdA # or the wave of the graph looking exactly the same within each session?

Thanks

Well, if you do things right, no matter what the CdA, all the curves will look like the real elevation. Repeatability should be measured by how consistently the same set-up will yield the same CdA.

AndyF
bike geek
Quote Reply
Re: Platypus Thread: Aero Virtual Elevation Testing Protocol [AndyF] [ In reply to ]
Quote | Reply
AndyF wrote:

Well, if you do things right, no matter what the CdA, all the curves will look like the real elevation.

This is what has me worried. I'm doing a half pipe and I can see the peaks on both sides, but the peaks are not at the exact same elevation each time. If it helps here is a screen shot of my graph:



Thanks for all the help.
Quote Reply
Re: Platypus Thread: Aero Virtual Elevation Testing Protocol [brown_dog_us] [ In reply to ]
Quote | Reply
You're off by, what, 20cms per 1km? .2% There must've been practically no wind that day. Very nice!

AndyF
bike geek
Quote Reply
Re: Platypus Thread: Aero Virtual Elevation Testing Protocol [AndyF] [ In reply to ]
Quote | Reply
lol. You mean all I had to do was use the scale on the left side of the graph to get some perspective?

Thanks again.
Quote Reply
Re: Platypus Thread: Aero Virtual Elevation Testing Protocol [brown_dog_us] [ In reply to ]
Quote | Reply
Ummm, yeah. :-)

Congrats on an excellent VE test, BDU.

AndyF
bike geek
Quote Reply
Re: Platypus Thread: Aero Virtual Elevation Testing Protocol [AndyF] [ In reply to ]
Quote | Reply
AndyF wrote:
You're off by, what, 20cms per 1km? .2% There must've been practically no wind that day. Very nice!
Yeah, but it looks like the first 3-1/4 laps may have had very (very) slightly higher CdA than the last 2 laps. Anything change?
Quote Reply
Re: Platypus Thread: Aero Virtual Elevation Testing Protocol [RChung] [ In reply to ]
Quote | Reply
I didn't change anything in my setup. What are some of the variables that could change this? Wind, not following the exact same line, or different speeds at the turn around?
Quote Reply
Re: Platypus Thread: Aero Virtual Elevation Testing Protocol [AndyF] [ In reply to ]
Quote | Reply
I'd like to add a sub-point to the "Don't use your brakes". Make sure your brake isn't rubbing! I did some testing where I switched from my H3 to a disc to try to test the difference. The results with the disc were really bad, which was confusing (roughly from .23=>.27). I then noticed that when I spun the wheel freely in my bike stand that it was very slightly rubbing at one point. It was subtle enough that I didn't notice when installing the wheel or while riding (perhaps I shouldn't listen to music while testing). Another day of testing bites the dust :(
Quote Reply
Re: Platypus Thread: Aero Virtual Elevation Testing Protocol [jbank] [ In reply to ]
Quote | Reply
jbank wrote:
I'd like to add a sub-point to the "Don't use your brakes". Make sure your brake isn't rubbing! I did some testing where I switched from my H3 to a disc to try to test the difference. The results with the disc were really bad, which was confusing (roughly from .23=>.27). I then noticed that when I spun the wheel freely in my bike stand that it was very slightly rubbing at one point. It was subtle enough that I didn't notice when installing the wheel or while riding (perhaps I shouldn't listen to music while testing). Another day of testing bites the dust :(
OTOH, it shows that the method can pick up pretty small effects.
Quote Reply
Post deleted by IJ [ In reply to ]
Re: Platypus Thread: Aero Virtual Elevation Testing Protocol [AndyF] [ In reply to ]
Quote | Reply
I've got a bit of a mystery that I'm curious to get some feedback about. I did some field testing today and got some results I don't believe. I'm looking for potential holes in what I did as well as a question of plausibility. My goal was to try to identify whether my desoto liftfoil trisuit or my new cycling team skinsuit was faster. I was expecting that they would be very close and guessed that maybe the trisuit would be a touch faster. I warmed up by doing some testing of two different helmets with so so results, it was hard to distinguish them, but I felt ok about my test setup. I had my race setup, except I was using my powertap rear wheel which has slow tires (it was on the trainer before). I was getting speed and power from the powertap, turning off the gps for speed on my 705 (I have had trouble in the past with my gsc10 sensor and quarq). I did three runs where each run went about two minutes from home to the start of my halfpipe, did two laps of the halfpipe and then went home. I didn't turn off the garmin at home, just put down the bike, changed trisuit for skinsuit, and did the next lap. The results in aerolab look very clean. I was just looking for deltas in CdA, not absolutes, so I just left Crr as 0.005, although I did put in reasonable values for mass and rho.

-) Run 1 and 3: matching CdA of ~.217 in trisuit
-) Run 2: CdA of .192 in skinsuit

I stupidly didn't do a 4th pass in the skinsuit, so I assumed that there must have been some error. After lunch, I decided to give it another shot. This time I got:

-) Run4: CdA of .193 in skinsuit
-) Run5: CdA of .215 in trisuit

The runs also look great in aerolab and match the first runs closely. So is it plausible that there is that big a difference between the skinsuit and my trisuit. Is there some other error that might manifest itself in such a way that my runs match each other so closely? For reference, the skinsuit is the one I'm wearing here. I didn't think it was supposed to be exceptionally fast, it was just the one the cycling team I joined had in stock.

Quote Reply
Re: Platypus Thread: Aero Virtual Elevation Testing Protocol [jbank] [ In reply to ]
Quote | Reply
My first instinct is to ask whether you've adjusted your air density according to the time of day. Although they track each other fairly well over the course of the runs (skinsuit vs trisuit relative difference). The absolute CdA you're quoting is probably a ways off, though.

As far as the delta between skinsuit and not...we'll have to let some of the more experienced guys come in. 0.022-0.025 change in CdA is huge, though.

The question of who is right and who is wrong has seemed to me always too small to be worth a moment's thought, while the question of what is right and what is wrong has seemed all-important.

-Albert J. Nock
Quote Reply
Re: Platypus Thread: Aero Virtual Elevation Testing Protocol [Derf] [ In reply to ]
Quote | Reply
Just to be clear, runs 1, 2 and 3 were done over a total duration of 35 minutes, with 31 of those riding (just about 2 minutes per change of clothes).
Run 4 and 5 were done two+ hours later where the temperature had indeed risen by a few degrees, but they were also done within a 23 minute window (21 of those riding).
I'm sure the absolute CdA is inacruate which is why I mentioned that I was just looking for relative results. I also agree that >0.02 CdA change doesn't seem right which is why I redid the test assuming a bug and then decided to ask here after my second test confirmed the results.

I realize I should also have put a picture of the trisuit. This is a slightly older picture of what that looks like. I certainly wouldn't have thought it was a dog. The only thing that comes to mind is that the stitching is pretty raised on it. Otherwise it is nice and tight, etc.

Quote Reply
Re: Platypus Thread: Aero Virtual Elevation Testing Protocol [jbank] [ In reply to ]
Quote | Reply
FWIW, when I visited the wind tunnel last year we did some skinsuit comparisons. There were several riders and one brought a team suit that had raised stitching in a creative diagonal pattern that looks similar to your tri suit. It was a full skinsuit but the stitching was similar. It was clearly the highest drag skinsuit of all tested that day and added more than 200 grams of drag relative to faster suits and IIRC nearly 300 grams of drag relative to the Castelli bodypaint suit. The best guess of the testing folks was that those raised seams were in all the wrong places in terms of tripping the air flow and though they look kinda nice they may not be the best thing from an aero standpoint.

BTW, what are you assuming for Crr in your Chung testing? Are you basing it of roller testing or regression testing done in another session or just swagging it?

-Dave
Quote Reply
Re: Platypus Thread: Aero Virtual Elevation Testing Protocol [Dave_Ryan] [ In reply to ]
Quote | Reply
The Crr is just a swag. My front wheel is a Jet9 with a GP4000s and latex. The rear is an American Classic 420 with a powertap and some cheap "strada-k" tire with butyl that I use on my trainer. I've got a Jet disc that I'll use racing, but I was hoping the PT would give nice even results for the field testing.

If I remember my rules of thumb, its 50 grams of drag = 5 watts = .005m^2 CdA @ 30mph. So 200-300 grams would be .02 to .03m^2 CdA. So what you are saying is that it is not on the face of it absurd that there might really be that big a difference between my skinsuit and trisuit?

If my data is right I am sad since I really like my DeSoto stuff and would be sad that it is slow. I've certainly tested it in the pool and it is pretty fast there. I was just assuming it would be fast on the bike too :(
Quote Reply
Re: Platypus Thread: Aero Virtual Elevation Testing Protocol [jbank] [ In reply to ]
Quote | Reply
jbank wrote:
If my data is right I am sad since I really like my DeSoto stuff and would be sad that it is slow. I've certainly tested it in the pool and it is pretty fast there. I was just assuming it would be fast on the bike too :(

How high does the zipper go on the front of the skinsuit and the trisuit? Is the area around the neck equally tight?

I've never tested a sleeveless trisuit so I don't really know but a difference of .02 m^2 is bigger than I would have thought.
Quote Reply
Re: Platypus Thread: Aero Virtual Elevation Testing Protocol [jbank] [ In reply to ]
Quote | Reply
The short answer is: absolutely. We've seen this happen a couple of times. To quote Paul Harder of Trek, "Skin is slow". :-)

AndyF
bike geek
Quote Reply
Re: Platypus Thread: Aero Virtual Elevation Testing Protocol [jbank] [ In reply to ]
Quote | Reply
I know that the TriTalk podcast did some roll down aero testing of a few tri suits a while back and that of the 3 or 4 tested (not a huge sample or a controlled test, I know) the DeSoto LiftFoil tested the best. I always assumed it was a little faster than other tri suits because the stitching all runs parallel to the direction of the wind coming over the back and there is no pocket sitting perpendicular to the airflow on the low back to trip it up.

So, as far as tri suits go, I think you could do a lot worse than the LiftFoil.


__________________________________________________
The plural of anecdote is not data. :-)
- Andrew Coggan
Quote Reply
Re: Platypus Thread: Aero Virtual Elevation Testing Protocol [RChung] [ In reply to ]
Quote | Reply
RChung wrote:
jbank wrote:

If my data is right I am sad since I really like my DeSoto stuff and would be sad that it is slow. I've certainly tested it in the pool and it is pretty fast there. I was just assuming it would be fast on the bike too :(


How high does the zipper go on the front of the skinsuit and the trisuit? Is the area around the neck equally tight?

I've never tested a sleeveless trisuit so I don't really know but a difference of .02 m^2 is bigger than I would have thought.

The zipper on the trisuit is not as high and the neck is probably not quite as tight. So I guess it could be a combo of the neck tightness/coverage, the seams and less coverage (skin is slow).

Slightly off topic, but I haven't tried out a skinsuit under a wetsuit before. Any reason to think that won't work well? I don't have to run afterward; I just swim and bike.
Quote Reply
Re: Platypus Thread: Aero Virtual Elevation Testing Protocol [jbank] [ In reply to ]
Quote | Reply
Apologies if I sounded overly critical about your protocol--it looks solid.

Your testing makes me wonder about my own clothing selections! I have a baggy team one-piece, a tightly fitting Kiwami, and a new voler skinsuit that requires a second person to put on. Historically, I've just done TT's in bibs + a long sleeve nike pro compression shirt.

What's the pocket situation on your suits? I'm inclined to think that makes a pretty big difference, too.

Seems like it's time for me to test and see where everything shakes out. Hopefully not as big a difference as you've seen. :/ Unless my team suit is fast, then I'm okay :)

The question of who is right and who is wrong has seemed to me always too small to be worth a moment's thought, while the question of what is right and what is wrong has seemed all-important.

-Albert J. Nock
Quote Reply
Re: Platypus Thread: Aero Virtual Elevation Testing Protocol [Derf] [ In reply to ]
Quote | Reply
No problem about being critical. That is what I'm looking for! I was assuming I'd made some dumb mistake but couldn't figure out what it might be. I was hoping someone might poke holes and figure out what I did wrong. On the other hand, if my testing is correct, I ought to be able to get a bunch of PRs since I used the trisuit in all my races last year including TTs.

Neither one of the suits I tested have pockets, so that isn't the issue. As an aside, what does the second person do when putting on a skinsuit ;)
Quote Reply
Re: Platypus Thread: Aero Virtual Elevation Testing Protocol [jbank] [ In reply to ]
Quote | Reply
Second person helps get the skinsuit over the shoulders. I have to put both arms on at the same time, hike the sleeves up really high (so there's enough fabric to get over my shoulders) and then readjust everything afterwards. :) I believe it was "Carl Spacker" who said that nothing motivates a diet like putting on a skinsuit...

Bummer, I was hoping you'd say, "well, there's a couple big, handy pockets in the back of the Desoto"... crazy the difference!

Looks like you've got a good season ahead of you!

The question of who is right and who is wrong has seemed to me always too small to be worth a moment's thought, while the question of what is right and what is wrong has seemed all-important.

-Albert J. Nock
Quote Reply
Re: Platypus Thread: Aero Virtual Elevation Testing Protocol [jbank] [ In reply to ]
Quote | Reply
Geez, you really need a better handlebar setup. Something that allows you to angle the extensions.

Did you ever test the stacked hands versus high extensions positions?
Quote Reply
Re: Platypus Thread: Aero Virtual Elevation Testing Protocol [jbank] [ In reply to ]
Quote | Reply
Hey
If you want, you can send me your data, I have a code that corrects for change in temperature (if the powertap or your computer measures this), among other things.

And I dont know why theres not much actually done in skinsuits commercially but the gains can be huge! I dont know your skinsuit but maybe youre lucky. And congrats on your overal air resistance, I wish mine would be that low...
Quote Reply
Re: Platypus Thread: Aero Virtual Elevation Testing Protocol [AndyF] [ In reply to ]
Quote | Reply
Hi, I'm keen on giving this a try. I live in a some what busy area, so I could use some tips for course selection. I have access at certain times to an empty parking lot, though there is a flag nearby and evidently it's typically pretty windy there. I can also go a little further to a parking garage, which one would also expect to be empty. It's not totally enclosed, but it has half height walls so the wind could be less there. I could probably put up cones to block it off without anyone complaining. Any other tips? Do you suppose a power tap and a joule 2.0 is sufficient for the data collection?

Thanks!
Quote Reply
Re: Platypus Thread: Aero Virtual Elevation Testing Protocol [corneliused] [ In reply to ]
Quote | Reply
corneliused wrote:
Hi, I'm keen on giving this a try. I live in a some what busy area, so I could use some tips for course selection. I have access at certain times to an empty parking lot, though there is a flag nearby and evidently it's typically pretty windy there. I can also go a little further to a parking garage, which one would also expect to be empty. It's not totally enclosed, but it has half height walls so the wind could be less there. I could probably put up cones to block it off without anyone complaining. Any other tips? Do you suppose a power tap and a joule 2.0 is sufficient for the data collection?

Thanks!

Alright, let's get this going.

If there is a prevailing wind direction, I would align an out-and back course about 400-600m in total distance (out and back) with the wind. Then make sure you have a good handle on the air density at the time you test.

Once you have the data, we can have a look at it, ok? Have you read the protocols in the previous thread posts? Have you looked at jbanks' website?

If so, then you're ready to go.

G'luck!

AndyF
bike geek
Quote Reply
Re: Platypus Thread: Aero Virtual Elevation Testing Protocol [AndyF] [ In reply to ]
Quote | Reply
I have been working a bit with the Aerolab function in Golden Cheetah, but I am finding it really hard to get good repeatable "loop" data. I do, however, have a really nice hill outside my front door. So I did some runs up a 600 m stretch with 20 m of elevation gain.

What I had hoped to do was to use the "Crr and CdA on constrained elevation gain" method give in on slide 43 of 112 in the R. Chung presentation/aero bible presentation. I coded everything in R and I think my data and estimated elevations are pretty good, but I notice that my graph doesn't look like the one in the presentation. The big difference is that I calculate a zero-intercept, but the graphs on slide 43 are not constrained. Can you enlighten me?

Thanks

P.S. I can send R code and data files. I also implemented some optimization routines the find "best fitting" Crr and CdA values and I have fund that "best" is a relative term.
Quote Reply
Re: Platypus Thread: Aero Virtual Elevation Testing Protocol [grumpier.mike] [ In reply to ]
Quote | Reply
grumpier.mike wrote:
I have been working a bit with the Aerolab function in Golden Cheetah, but I am finding it really hard to get good repeatable "loop" data. I do, however, have a really nice hill outside my front door. So I did some runs up a 600 m stretch with 20 m of elevation gain.

What I had hoped to do was to use the "Crr and CdA on constrained elevation gain" method give in on slide 43 of 112 in the R. Chung presentation/aero bible presentation. I coded everything in R and I think my data and estimated elevations are pretty good, but I notice that my graph doesn't look like the one in the presentation. The big difference is that I calculate a zero-intercept, but the graphs on slide 43 are not constrained. Can you enlighten me?

Thanks

P.S. I can send R code and data files. I also implemented some optimization routines the find "best fitting" Crr and CdA values and I have fund that "best" is a relative term.


Ah. The actual runs start at km=0 and elevation=0. I just snipped off the first 1.75 km and the first 100m of elevation gain for that slide.

I'd be interested in seeing your R code. I've tried some black box optimization but I still find that I learn more from looking at the VE profiles as diagnostics.
Last edited by: RChung: Aug 17, 13 18:33
Quote Reply
Re: Platypus Thread: Aero Virtual Elevation Testing Protocol [RChung] [ In reply to ]
Quote | Reply
RChung wrote:
grumpier.mike wrote:
I have been working a bit with the Aerolab function in Golden Cheetah, but I am finding it really hard to get good repeatable "loop" data. I do, however, have a really nice hill outside my front door. So I did some runs up a 600 m stretch with 20 m of elevation gain.

What I had hoped to do was to use the "Crr and CdA on constrained elevation gain" method give in on slide 43 of 112 in the R. Chung presentation/aero bible presentation. I coded everything in R and I think my data and estimated elevations are pretty good, but I notice that my graph doesn't look like the one in the presentation. The big difference is that I calculate a zero-intercept, but the graphs on slide 43 are not constrained. Can you enlighten me?

Thanks

P.S. I can send R code and data files. I also implemented some optimization routines the find "best fitting" Crr and CdA values and I have fund that "best" is a relative term.


Ah. The actual runs start at km=0 and elevation=0. I just snipped off the first 1.75 km and the first 100m of elevation gain for that slide.

I'd be interested in seeing your R code. I've tried some black box optimization but I still find that I learn more from looking at the VE profiles as diagnostics.

Ah, that would explain the different intercepts.

I will document the code a bit and send you a PM for an email address. I also GPSed the end points of the ride. Assuming the GPS data are accurate (I don't know much about GPS accuracy, but I just updated my iPhone GPS location until it stopped changing elevation values) my estimated elevation profiles are with about .5%.
Quote Reply
Re: Platypus Thread: Aero Virtual Elevation Testing Protocol [grumpier.mike] [ In reply to ]
Quote | Reply
grumpier.mike wrote:
I will document the code a bit and send you a PM for an email address. I also GPSed the end points of the ride. Assuming the GPS data are accurate (I don't know much about GPS accuracy, but I just updated my iPhone GPS location until it stopped changing elevation values) my estimated elevation profiles are with about .5%.
Thanks. I think my email address might be on the front page of that document. GPS altitude can be a little coarse for this kind of thing -- but you should try it to be sure. For that slide the hill happened to have topographic surveyor's benchmarks right near the start and end so I was pretty sure what the elevation change was.
Quote Reply
Re: Platypus Thread: Aero Virtual Elevation Testing Protocol [RChung] [ In reply to ]
Quote | Reply
So I'm trying to get familiar with the Aerolab tool, and I'm in need of some help from the collective wisdom, as the GC help pages are a bit thin to say the least.

I did some baseline data gathering, varying the speed (pushing harder) for the middle lap of 3 laps to have data to tease out Crr from CdA. But when I'm looking at the data in Aerolab, the Crr and Cd control sliders seem to affect the VE curve in exactly the same way and my middle lap has a larger elevation change no matter what pair I choose. Am I not setting up the tool correctly, or did I do something wrong in the data collection that could be causing this?
Quote Reply
Re: Platypus Thread: Aero Virtual Elevation Testing Protocol [tgoguely] [ In reply to ]
Quote | Reply
From memory, if you want to address both Crr and CdA then you need to add elevation to the equation.

Ironman Certified Coach

Currently accepting limited number of new athletes
Quote Reply
Re: Platypus Thread: Aero Virtual Elevation Testing Protocol [corneliused] [ In reply to ]
Quote | Reply
Anyone in Orange County, CA doing VE testing? This is the land of coastal wind, stoplights, and road medians... Any tips on a good testing site are welcome. Thanks!
Quote Reply
Re: Platypus Thread: Aero Virtual Elevation Testing Protocol [jbank] [ In reply to ]
Quote | Reply
i'm curious to know. if .005 = 5 watts @ 30mph, what is .005 at 25mph or 28mph? is there a chart? and how does that equate to time saved (or added) per kilometer or mile?
Quote Reply
Re: Platypus Thread: Aero Virtual Elevation Testing Protocol [mcnnr27] [ In reply to ]
Quote | Reply
i've been playing with this at various industrial parks on the weekend, there seems to be good data collecting but still questioning my settings and analysis for accurate #'s.
Quote Reply
Re: Platypus Thread: Aero Virtual Elevation Testing Protocol [sna_b] [ In reply to ]
Quote | Reply
sna_b wrote:
i'm curious to know. if .005 = 5 watts @ 30mph, what is .005 at 25mph or 28mph? is there a chart? and how does that equate to time saved (or added) per kilometer or mile?

It's a rule of thumb, but it's a pretty good one, so it's pretty close at 25, 28, or 30 mph. If you really need to know the exact number you'll have to calculate.
Quote Reply
Re: Platypus Thread: Aero Virtual Elevation Testing Protocol [sna_b] [ In reply to ]
Quote | Reply
for me.................4.3/6.0/7.4w at 25/28/30mph for .005CdA +/-
Quote Reply
Re: Platypus Thread: Aero Virtual Elevation Testing Protocol [AndyF] [ In reply to ]
Quote | Reply
I’m in the midst of trying to hone in on using Aerolab properly. I’ve read the string a few times and studied the PDF doc as well that explains Chung’s Aero testing and VE. I’ll try to keep it short; here’s what I’ve done:
· Testing TT position, standard hold on extensions to find a baseline cda#
· Terrain – outdoor industrial park that has no stop signs and limited to no traffic on weekends
· Winds very light but increase throughout the day
· Used some apps to retrieve data on humidity, temp, Rho, Air density, etc
· Rode 3 loops on a .9mile loop (egg shaped) and started lap 1 at 250W, lap 2 at 270 and lap 3 at 290, essentially 1 shift harder per lap….i wasn’t shooting for specific power targets but they came out close to this
· Garmin 500 capturing data at 1sec intervals and speed sensor is connected and Quarq PM is calibrated prior to each run

Once completed, I uploaded file into GC and looked at the Aerolab. I slide the number bars to reflect the CRR, Mass & Rho…I left CRR at 5, because that seems right and I figured if I compare with the same wheels on the same day with the same tire pressure then that shouldn’t affect the faster v slower…maybe not the most accurate cda # but on a comparison, I’ll find the fastest position…fill me in if this is incorrect.

Now to my real question – when sliding the cda bar, am I supposed to use the constant altitude box checked or unchecked or does it matter?

Also, the 2 charts below show the difference with the box checked and unchecked. I like the straight bar to connect the start and finish points clearer but is this correct? OR is the difference of .0007 so minor that I’m splitting hairs? (i can't seem to upload my images)

Lastly, as a confirmation, am I doing conducting the field testing correctly?

https://drive.google.com/...1ETHc&authuser=0



https://drive.google.com/open?id=0Bybxljl8xw55VVBuVGg1bVNfdXM&authuser=0


Thank you.

Last edited by: sna_b: Dec 31, 14 9:48
Quote Reply
Re: Platypus Thread: Aero Virtual Elevation Testing Protocol [sna_b] [ In reply to ]
Quote | Reply
There's poor fit between the VE and the altimeter. Something's off.
Quote Reply
Re: Platypus Thread: Aero Virtual Elevation Testing Protocol [RChung] [ In reply to ]
Quote | Reply
Thanks RChung - any suggestions? i'm not sure what's off?
Quote Reply
Re: Platypus Thread: Aero Virtual Elevation Testing Protocol [sna_b] [ In reply to ]
Quote | Reply
How did you get the data off the Garmin 500 and into GC? Did you download it directly?
Quote Reply
Re: Platypus Thread: Aero Virtual Elevation Testing Protocol [RChung] [ In reply to ]
Quote | Reply
i took the Garmin fit file and uploaded to TrainingPeaks and and did an elevation correction. From there I sent to WKO+ and GC.
Quote Reply
Re: Platypus Thread: Aero Virtual Elevation Testing Protocol [sna_b] [ In reply to ]
Quote | Reply
Is the .fit file still on the Garmin? Drag it to GC directly, without going through TP or correcting elevation. I'm not saying that's the problem, I'm trying to eliminate possibilities.
Quote Reply
Re: Platypus Thread: Aero Virtual Elevation Testing Protocol [RChung] [ In reply to ]
Quote | Reply
i've already deleted the .fit file. I'll re-run my testing soon and try dropping the .fit file directly to GC w/o doing anything in TP. Is my field testing protocol correct?
thank you very much.
Quote Reply
Re: Platypus Thread: Aero Virtual Elevation Testing Protocol [sna_b] [ In reply to ]
Quote | Reply
Yes, looks reasonable.

Do you still have any rides whatsoever on your Garmin? Drag any .fit file into GC and look at it with Aerolab. For this, you're not trying to guess your CdA, you're just trying to see whether you can get the data into GC without any intervening step that may have altered the data.

[Edited to add:] What I'm seeing from your screenshot is that your outdoor industrial park has a series of relatively steep ups-and-downs. Your altimeter trace suggests that you climb ~20m in the first 400m, that there are sudden and sharp changes in elevation, and that there is a steep descent (around 15m in 100m) back to the start of the loop. I'm wondering if this could be an artifact of the "elevation correction" algorithm in TP. The VE profile, on the other hand, seems to show a much flatter industrial park loop. Perhaps you can say which of these two seems to more accurately describe the industrial park even though you no longer have the .fit file.
Last edited by: RChung: Jan 1, 15 7:46
Quote Reply
Re: Platypus Thread: Aero Virtual Elevation Testing Protocol [RChung] [ In reply to ]
Quote | Reply
Good catch, I definitely did not climb that much. This loop does have a false flat but nothing close to a climb. I do have an old file (same loop, more laps) i pulled from the 500 and directly put into GC, it looks better...but i'd love to hear what your expert eye sees. The 2 shots below are the same loop just with "constant alt" checked and unchecked. So, if i was using this file, would i match up the VE with the V and level the start/finish points of the VE to give me the cda#? does the .2453 look correct?


https://drive.google.com/open?id=0Bybxljl8xw55cllHWnB0YVFuUkU&authuser=0
https://drive.google.com/open?id=0Bybxljl8xw55QzREbkxyMDlkQW8&authuser=0


I really appreciate the feedback.
Quote Reply
Re: Platypus Thread: Aero Virtual Elevation Testing Protocol [sna_b] [ In reply to ]
Quote | Reply
sna_b wrote:
I’m in the midst of trying to hone in on using Aerolab properly. I’ve read the string a few times and studied the PDF doc as well that explains Chung’s Aero testing and VE. I’ll try to keep it short; here’s what I’ve done:
· Testing TT position, standard hold on extensions to find a baseline cda#
· Terrain – outdoor industrial park that has no stop signs and limited to no traffic on weekends
· Winds very light but increase throughout the day
· Used some apps to retrieve data on humidity, temp, Rho, Air density, etc
· Rode 3 loops on a .9mile loop (egg shaped) and started lap 1 at 250W, lap 2 at 270 and lap 3 at 290, essentially 1 shift harder per lap….i wasn’t shooting for specific power targets but they came out close to this
· Garmin 500 capturing data at 1sec intervals and speed sensor is connected and Quarq PM is calibrated prior to each run

Just to be absolutely sure here: is the GPS on your Garmin 500 really off? That's the only way you'll be able to make use of the speed sensor, I think. And GPS speed is notoriously crappy.

AndyF
bike geek
Quote Reply
Re: Platypus Thread: Aero Virtual Elevation Testing Protocol [AndyF] [ In reply to ]
Quote | Reply
Hi Andy- the Garmin GPS was 'ON'. I enabled the speedsensor, but It sounds like i need to disable the GPS and that might tighten things up.
Quote Reply
Re: Platypus Thread: Aero Virtual Elevation Testing Protocol [sna_b] [ In reply to ]
Quote | Reply
sna_b wrote:
Hi Andy- the Garmin GPS was 'ON'. I enabled the speedsensor, but It sounds like i need to disable the GPS and that might tighten things up.

I think so. Garmin doesn't make it very easy to turn the GPS off permanently, unfortunately, so you have to do it every time. And then make sure the Edge 500 is properly paired with the speed sensor.

RChung, is it possible that the poor data consistency between VE and E is attributable to crummy GPS speed?

AndyF
bike geek
Quote Reply
Re: Platypus Thread: Aero Virtual Elevation Testing Protocol [sna_b] [ In reply to ]
Quote | Reply
sna_b wrote:
Good catch, I definitely did not climb that much. This loop does have a false flat but nothing close to a climb. I do have an old file (same loop, more laps) i pulled from the 500 and directly put into GC, it looks better...but i'd love to hear what your expert eye sees.
Ah, yes, that looks more reasonable. OK, I'm thinking that passing it through an "altitude correction" caused the problem. You may still be able to upload to TP and then on to GC (though I prefer to go directly to GC) but don't do that altitude correction thing. It's also possible that some of that is due to GPS speed rather than a wheel speed sensor, but a large part of it seems like that altitude correction wasn't correcting right.

Quote:
The 2 shots below are the same loop just with "constant alt" checked and unchecked. So, if i was using this file, would i match up the VE with the V and level the start/finish points of the VE to give me the cda#? does the .2453 look correct?

I only use the "constant altitude" checkbox when I know it's absolutely constant altitude, like on a velodrome. Otherwise, I leave it unchecked.

I think .24 is probably in the right ballpark, though the exact CdA will depend on getting the exact Crr correct. There are protocols you can use that might make it easier to "pry apart" the CdA and Crr, but they require that you really do have everything else carefully measured (for example, you want to make sure you have a separate speed sensor and aren't using GPS for speed, and you'll want to make sure you're using the correct wheel diameter, etc.). For now, I'd suggest just getting some experience with the data collection, and after a few trips out to the industrial park you'll have a much better idea of how sensitive the method is and how careful you need to be in collecting data. I found out that I need to hit the corners at the same spot each lap, so I sometimes use a little piece of chalk to mark X's at the "entrance" and "exit" for turns. I vary the speed at different points around the laps (including coasting sometimes), and I toss the first run of the day (as I mentioned somewhere in the thread up above). I used to use a little 3x5 index card with a checklist of things to do for the tests (like, check the tire pressure and zero the torque and so on) but now I use my phone to take a photo of my setup and to make little voice notes on the runs. These are some of the little tricks I've come up with over time. If you come up with others, please post them to this thread.

I should mention that since you're using a Quarq, you should set your eta slightly below 1.0 (maybe .97 or so -- that means 3% loss in the drivetrain). You only have eta set at 1 if you're using a PT.
Last edited by: RChung: Jan 1, 15 9:30
Quote Reply
Re: Platypus Thread: Aero Virtual Elevation Testing Protocol [RChung] [ In reply to ]
Quote | Reply
Very helpful insight. i'll keep collecting data to fine tune. Much appreciated! HNY
Quote Reply
Re: Platypus Thread: Aero Virtual Elevation Testing Protocol [sna_b] [ In reply to ]
Quote | Reply
Happy new year to you, too. Keep us informed.

The moral of the story thus far: GPS elevation and speed isn't good enough for this purpose.
Quote Reply
Re: Platypus Thread: Aero Virtual Elevation Testing Protocol [AndyF] [ In reply to ]
Quote | Reply
Wait--I have an edge 500--I thought that once you hard-code the rolling circumference of the tire (on a powertap) it will use that as its distance/speed measure rather than GPS (while simultaneously logging gps coordinates). Doing so has eliminated the "speed/distance" bounce you get with the Garmin when you're sitting still.

The question of who is right and who is wrong has seemed to me always too small to be worth a moment's thought, while the question of what is right and what is wrong has seemed all-important.

-Albert J. Nock
Quote Reply
Re: Platypus Thread: Aero Virtual Elevation Testing Protocol [Derf] [ In reply to ]
Quote | Reply
Derf wrote:
Wait--I have an edge 500--I thought that once you hard-code the rolling circumference of the tire (on a powertap) it will use that as its distance/speed measure rather than GPS (while simultaneously logging gps coordinates). Doing so has eliminated the "speed/distance" bounce you get with the Garmin when you're sitting still.

Ok, perhaps my bad here. I can remember that I have been bitten in the butt by GPS speed on an Edge 500 before, though.

AndyF
bike geek
Quote Reply
Re: Platypus Thread: Aero Virtual Elevation Testing Protocol [AndyF] [ In reply to ]
Quote | Reply
I don't want to insinuate that I'm correct either. I thought that was the case, but now I'm doubting my previous confidence in this matter.

I know for a fact that you're correct when you use the "auto-circumference" mode, just not sure when you hard-code that value.

Edit: everything I'm reading says that (at least the Edge 500) will prioritize Speed = Powertap rotations * circumference over GPS.

The question of who is right and who is wrong has seemed to me always too small to be worth a moment's thought, while the question of what is right and what is wrong has seemed all-important.

-Albert J. Nock
Last edited by: Derf: Jan 1, 15 13:26
Quote Reply
Re: Platypus Thread: Aero Virtual Elevation Testing Protocol [Derf] [ In reply to ]
Quote | Reply
Yeah, DCRainmaker has this in one of his reviews (for the new Garmin speed sensor).

Here's the overview of order of preference for GPS units:


Cadence:
1. Power meter sending torque and cadence (e.g. Vector, SRM, Quarq)
2. Cadence sensor
3. Power meter sending power values and cadence (e.g. Power2Max, Rotor)


Speed:
1. Power meter sending torque and speed (e.g. PowerTap). In this case wheel speed is needed to compute power.
2. Speed sensor
3. GPS
Quote Reply
Re: Platypus Thread: Aero Virtual Elevation Testing Protocol [Zenmaster28] [ In reply to ]
Quote | Reply
Thanks!

The question of who is right and who is wrong has seemed to me always too small to be worth a moment's thought, while the question of what is right and what is wrong has seemed all-important.

-Albert J. Nock
Quote Reply
Re: Platypus Thread: Aero Virtual Elevation Testing Protocol [RChung] [ In reply to ]
Quote | Reply
RChung wrote:
The moral of the story thus far: GPS elevation and speed isn't good enough for this purpose.

OK, in my admittedly limited understanding, while clearly speed accuracy is very important, is the robustness of the actual elevation that important to VE testing if you're just trying to compare different setups and not trying to pry apart exact Crr? It's my understanding I'm trying to level the VE trace rather than match it to the actual elevation trace. In my case I've been using barometric elevation but it's a bit flakey on my Garmin and not necessarily much better than GPS altitude.

Thanks for developing such a cool tool, BTW.
Quote Reply
Re: Platypus Thread: Aero Virtual Elevation Testing Protocol [tttiltheend] [ In reply to ]
Quote | Reply
tttiltheend wrote:
RChung wrote:
The moral of the story thus far: GPS elevation and speed isn't good enough for this purpose.


OK, in my admittedly limited understanding, while clearly speed accuracy is very important, is the robustness of the actual elevation that important to VE testing if you're just trying to compare different setups and not trying to pry apart exact Crr? It's my understanding I'm trying to level the VE trace rather than match it to the actual elevation trace. In my case I've been using barometric elevation but it's a bit flakey on my Garmin and not necessarily much better than GPS altitude.

Thanks for developing such a cool tool, BTW.

No, you're right. The actual elevation doesn't matter much -- except when you get fooled into thinking that it's accurate when it's not. Then you can end up chasing rainbows, trying to match up to something that's wrong. If it's right (and you know it's right) then it can help you identify the Crr and CdA exactly.

And you have to thank Andy F. and the GC guys for developing Aerolab.
Quote Reply
Re: Platypus Thread: Aero Virtual Elevation Testing Protocol [RChung] [ In reply to ]
Quote | Reply
Thanks for clarifying.

Fixed my post: Thanks for developing such a cool concept and to Andy and the GC team for developing the aerolab tool.
Quote Reply
Re: Platypus Thread: Aero Virtual Elevation Testing Protocol [AndyF] [ In reply to ]
Quote | Reply
AndyF wrote:
Ok, perhaps my bad here. I can remember that I have been bitten in the butt by GPS speed on an Edge 500 before, though.
The Edge 500's GPS reception can be pretty bad. Whenever I've offered to aerolab someone's TT for them, and they've sent me a file from an Edge 500, I've always thought "never again" after having to go through the whole file by hand fixing all the issues with the speed data.

OTOH The Edge 1000 produces pretty nice data (GPS+GLONASS), e.g. a 10 mile TT I rode with headwind out / tailwind back without a speed sensor:


I haven't used a speed sensor since getting the Edge 1000, as its GPS+GLONASS speed data seems to be very close in quality to speed sensor data, and it has the advantage of not needing to calibrate the rollout.
Quote Reply
Re: Platypus Thread: Aero Virtual Elevation Testing Protocol [Steve Irwin] [ In reply to ]
Quote | Reply
Steve Irwin wrote:
OTOH The Edge 1000 produces pretty nice data (GPS+GLONASS), e.g. a 10 mile TT I rode with headwind out / tailwind back without a speed sensor:


I haven't used a speed sensor since getting the Edge 1000, as its GPS+GLONASS speed data seems to be very close in quality to speed sensor data, and it has the advantage of not needing to calibrate the rollout.

Woah. That's nice.
Quote Reply
Re: Platypus Thread: Aero Virtual Elevation Testing Protocol [Steve Irwin] [ In reply to ]
Quote | Reply
Quote Reply
Re: Platypus Thread: Aero Virtual Elevation Testing Protocol [Steve Irwin] [ In reply to ]
Quote | Reply
Doesnt the 510 use the same system?
Quote Reply
Re: Platypus Thread: Aero Virtual Elevation Testing Protocol [neilridley] [ In reply to ]
Quote | Reply
yes
Quote Reply
Re: Platypus Thread: Aero Virtual Elevation Testing Protocol [neilridley] [ In reply to ]
Quote | Reply
The 510 also has GLONASS. I haven't used a 510, but my experience with 705, 500 and 800 before the 1000 is that the larger devices tend to have better GPS reception. A clubmate once told me he did a calculation of the optimal antenna size for a GPS signal, and found it to be a bit larger than any of the Garmin cycling devices, so the larger devices would be closer to the optimal antenna size if his calculation was correct.
Quote Reply
Re: Platypus Thread: Aero Virtual Elevation Testing Protocol [Steve Irwin] [ In reply to ]
Quote | Reply
Steve do you a weather station to collect data or pick it up later from the web? Seen a few apps on itunes that are supposed to pick up the airdensity from your nearest station . Being stuck on an island stuck in the english channel im really struggling to find a suitable test circuit, ( small island so no big industrial estates or carparks and windy!)
Quote Reply
Re: Platypus Thread: Aero Virtual Elevation Testing Protocol [neilridley] [ In reply to ]
Quote | Reply
Air pressure from airport weather data, temperature from airport weather data combined with Garmin data.
Quote Reply
Re: Platypus Thread: Aero Virtual Elevation Testing Protocol [Steve Irwin] [ In reply to ]
Quote | Reply
do you use sea level air pressure or correct it for the height of the test circuit?
Quote Reply
Re: Platypus Thread: Aero Virtual Elevation Testing Protocol [neilridley] [ In reply to ]
Quote | Reply
I've never tested anywhere that isn't essentially at sea level. But looking at an example of a TT course I ride, the highest elevation is 40m above the lowest elevation, and if the mean elevation were 20m above sea level, perhaps I should be accounting for the 0.26% reduction in pressure. It doesn't really matter, because I never compare CdA values across different courses or test venues anyway, as there are other reasons why they won't be comparable, e.g. unknown differences in Crr due to different surfaces. So as I'm only comparing against CdA for other rides on the same course, a constant adjustment for the course always being a certain amount above sea level would make no difference, the main concern is to correct for the air pressure difference between the two rides.
Quote Reply
Re: Platypus Thread: Aero Virtual Elevation Testing Protocol [neilridley] [ In reply to ]
Quote | Reply
If you're getting air pressure from an official weather station it's usually standardized to sea level. If you're getting air pressure from a local source it can sometimes be "station pressure" so it's not.

If you're on an island in the Channel you probably don't have to worry too much about the difference.
Quote Reply
Re: Platypus Thread: Aero Virtual Elevation Testing Protocol [RChung] [ In reply to ]
Quote | Reply
General Questions
  • How do you calculate the air density from this data? http://w1.weather.gov/.../obhistory/KSAV.html
  • When using a loop course how do you accurately determine the beg and end of the loop in the Aerolab interface so that you know the actual elevation is the same?

Quote Reply
Re: Platypus Thread: Aero Virtual Elevation Testing Protocol [pyrahna] [ In reply to ]
Quote | Reply
pyrahna wrote:
General Questions
  • How do you calculate the air density from this data? http://w1.weather.gov/.../obhistory/KSAV.html
  • When using a loop course how do you accurately determine the beg and end of the loop in the Aerolab interface so that you know the actual elevation is the same?

Ah, there's a "missing" variable in the air density calculator. The issue is that "official" weather stations like the one you're pointing to, typically give the barometric pressure at sea level. There's also "station" air pressure, which gives the air pressure at whatever altitude the station is at. If you're close to sea level and you have an official weather station, just use the air density calculator in GC. If you're at altitude and you're using "station baro pressure" just use the air density calculator in GC. If you're at altitude but you're using an official station's baro pressure, you need to make an altitude adjustment (which is the missing variable from the current calculator). That said, if you're looking at the *difference* between two setups (rather than the exact values of CdA and Crr) then you can pretty much ignore the altitude adjustment.

I don't usually "mark" the beginning and end of the loop -- usually, I just know the length of the loop. If the loop is, say, 1213 meters long, then I know that every 1213 meters is exactly one loop, so has to be the same elevation. It helps to run the same line through the corners. If the loop is new to you, try doing a couple of "high speed" test runs with a piece of chalk and mark the entry and exit points for your turns. If you mark the entries and exits at high speed then you'll know you can hit the same marks at low speed (that doesn't always work quite so well in the other order).
Quote Reply
Re: Platypus Thread: Aero Virtual Elevation Testing Protocol [RChung] [ In reply to ]
Quote | Reply
Thanks for pointing me towards the Air Density Estimator tool...I hadn't discovered it yet. Thankfully since I am in Savannah I am going to assume that I am at sea level. If we were any closer we would be under water.

Marking the corners isn't going to be needed per say. This is the loop I am using https://www.google.com/...0065,-81.2100071,17z. I was using the big loop to try and negate the slight wind that was going on, but it is a little long at ~1.1 miles. I just wish there was a little easier way to figure out my start and end point for the interval.

Along the lines of Intervals. Is there a way in Golden Cheetah to get rid of intervals that I have 'selected'?
Quote Reply
Re: Platypus Thread: Aero Virtual Elevation Testing Protocol [pyrahna] [ In reply to ]
Quote | Reply
pyrahna wrote:
Along the lines of Intervals. Is there a way in Golden Cheetah to get rid of intervals that I have 'selected'?

Do you mean to delete the intervals or to unselect an interval? To delete an interval, you can right-click on it -- but I'm not sure why you'd want to delete an interval. Currently, flipping between intervals or unselecting an interval is kinda funky. If you're "zoomed-in" on an interval you can right-click on the left interval window and choose "zoom out" to display the entire ride again -- but that interval might still be selected. I can't remember how to unselect any interval -- sometimes I just click on the previous day's ride and click back on today's ride. As you can tell, I'm sorta confused about that.
Quote Reply
Re: Platypus Thread: Aero Virtual Elevation Testing Protocol [pyrahna] [ In reply to ]
Quote | Reply
I'm incredibly jealous of your testing loop.
Quote Reply
Re: Platypus Thread: Aero Virtual Elevation Testing Protocol [GreenPlease] [ In reply to ]
Quote | Reply
Public road, fairly well lit at night, really limited traffic.....not a bad deal at all. The side cover is a little inconsistent and there can be some weird winds if we are being really nitpicky, but overall it's pretty good for a lot of things.

We actually hold our spring/summer crit series on the upper half of the loop. Two corner crit.
Quote Reply
Re: Platypus Thread: Aero Virtual Elevation Testing Protocol [pyrahna] [ In reply to ]
Quote | Reply
Have you tried this loop out yet? Just hit the interval timer when you start, do two or three (or more) laps at varying speed and power, then hit the interval marker at the end. Usually there are little bumps or dips that you can use to line up the laps. I could spot the dip caused by a storm drain at the side of an otherwise flat road. I've spotted a little low spot on an otherwise flat road that I hadn't noticed, but it was in a consistent spot so I went out there after a rainy day and found a light coating of mud on the road right where it was indicated.
Quote Reply
Re: Platypus Thread: Aero Virtual Elevation Testing Protocol [RChung] [ In reply to ]
Quote | Reply
I'm pretty familiar with it and tried a couple single lap loops the other day...mostly just goofing around. I'm pretty sure my joule gps is reading GPS for speed or my powertap has miserable speed trace data cause it is just not that clean. I asked Saris and they claim that if the powertap is connected it will use that for speed and not GPS but I am not terribly convinced. I want to try using a garmin speed/cadence sensor I have and see if that works better.

I'm just trying to figure out what I don't know and how consistent I can be.

I will def look for high spots. I usually start/stop at the intersection on the bottom of the loop. There should be a high spot from the road crown at the intersection. I will see when I get some better speed trace data.
Quote Reply
Re: Platypus Thread: Aero Virtual Elevation Testing Protocol [pyrahna] [ In reply to ]
Quote | Reply
Here's a test to make sure: hold up the rear of the bike, spin the wheel to wake up the hub, then turn on the Joule. If you do this indoors and immediately get a speed signal you know it's not coming from GPS. Make sure your rollout is correct.

A lot of people new to the test protocol think they have to hold their speed constant. You don't need to do that. In fact, on a flat course like yours, start out slow then ramp up your speed to maybe racing speed (all while holding your position) then coast (while soft pedaling) back down to maybe jogging speed, then repeat. That will get you a wide range of speed and power, and the coasting bits will help you determine how fast you decelerate under zero power.
Quote Reply
Re: Platypus Thread: Aero Virtual Elevation Testing Protocol [AndyF] [ In reply to ]
Quote | Reply
Hi guys,

Brilliant thread, great work! I just want to ask something in case someone can help me.

The protocol recommends a course with elevation changes and changes in speed, and one of the posts was regarding testing in a velodrome when the answer was actually to do not change the line nor go up the banking, and also to keep a steady speed.

I'm confused because I've near my place a 600m outdoor track, that has only one of the corners with a banking. Because it's outdoor and quite long, I think it's more like a road loop than actually a velodrome. My question is.. should I ride up the banking (keeping the same line every lap) to change the speed/elevation, or just stick to the black line? (tho I don't know how I'd be able later to align the VE this way.. any tips?)

Cheers!!
Quote Reply
Re: Platypus Thread: Aero Virtual Elevation Testing Protocol [kikopi77] [ In reply to ]
Quote | Reply
I would think sticking to the black line would yield more consistent results than trying to ride the same banked line every time, unless you perhaps marked the curve out.
Quote Reply
Re: Platypus Thread: Aero Virtual Elevation Testing Protocol [RChung] [ In reply to ]
Quote | Reply
I'm planning to have a go at this soon and am trying to decide where the best location will be for testing. I have a few "halfpipe" options in neighborhoods that I could use, but I feel like it would be hard to hold mynaero position while make a sharp turn at low speed. I think my best location will be here: http://goo.gl/maps/UDHkq. It's ~half a mile and almost perfectly flat, and has almost no traffic on an early Sunday morning. My only concern is if the constant turn of the short loop would affect the data at all? If that loop is too tight I have another good option (directly northwest on that map) that is about .9 miles, but there is a stop sign I would have to run each lap, and being in a neighborhood I would think it hard to get a lot of consecutive runs without being passed by a car screwing up my data. Also the longer loop means it takes a lot more time to get each test completed. Any feedback would be appreciated. Thank you.

Powertap / Cycleops / Saris
Quote Reply
Re: Platypus Thread: Aero Virtual Elevation Testing Protocol [kikopi77] [ In reply to ]
Quote | Reply
kikopi77 wrote:
Hi guys,

Brilliant thread, great work! I just want to ask something in case someone can help me.

The protocol recommends a course with elevation changes and changes in speed, and one of the posts was regarding testing in a velodrome when the answer was actually to do not change the line nor go up the banking, and also to keep a steady speed.

I'm confused because I've near my place a 600m outdoor track, that has only one of the corners with a banking. Because it's outdoor and quite long, I think it's more like a road loop than actually a velodrome. My question is.. should I ride up the banking (keeping the same line every lap) to change the speed/elevation, or just stick to the black line? (tho I don't know how I'd be able later to align the VE this way.. any tips?)

Cheers!!

Stick to the black line, though vary your speed.
Quote Reply
Re: Platypus Thread: Aero Virtual Elevation Testing Protocol [Tulkas] [ In reply to ]
Quote | Reply
Tulkas wrote:
I'm planning to have a go at this soon and am trying to decide where the best location will be for testing. I have a few "halfpipe" options in neighborhoods that I could use, but I feel like it would be hard to hold mynaero position while make a sharp turn at low speed. I think my best location will be here: http://goo.gl/maps/UDHkq. It's ~half a mile and almost perfectly flat, and has almost no traffic on an early Sunday morning. My only concern is if the constant turn of the short loop would affect the data at all? If that loop is too tight I have another good option (directly northwest on that map) that is about .9 miles, but there is a stop sign I would have to run each lap, and being in a neighborhood I would think it hard to get a lot of consecutive runs without being passed by a car screwing up my data. Also the longer loop means it takes a lot more time to get each test completed. Any feedback would be appreciated. Thank you.

Holding your position and finding a venue without traffic that is protected from the wind trumps everything else. A halfpipe lets you vary speed easily, so you'll just have to vary the speed intentionally. The turn won't affect the data as long as you can hold your position.
Quote Reply
Re: Platypus Thread: Aero Virtual Elevation Testing Protocol [AndyF] [ In reply to ]
Quote | Reply
Hi guys,

Just 2 quick questions.. I've just started playing with the Aerolab so I'm still struggling with a few things.

1. How can you analyse different segments on the same ride, so I can select the laps that I had a different setup to get the CdA and then compare? Or do I need to reset the Garmin every time I change the setup?

2. I did a test ride with the GPS on, but later on GC I deleted the altitude profile. But now when I try to align the bottom of the VE moving the slider, the whole thing moves up/down, tho it doesn't change at all the alignment of the VE line. Is it because I had the GPS on or am I doing something else wrong? This is the printscreen of the segment of the ride where I took the bike to a outdoor track (that has a + - 1.5% gradient on each side).
Quote Reply
Re: Platypus Thread: Aero Virtual Elevation Testing Protocol [kikopi77] [ In reply to ]
Quote | Reply
kikopi77 wrote:
Just 2 quick questions.. I've just started playing with the Aerolab so I'm still struggling with a few things.

1. How can you analyse different segments on the same ride, so I can select the laps that I had a different setup to get the CdA and then compare? Or do I need to reset the Garmin every time I change the setup?

You don't need to reset the Garmin each time, but you should do more than one lap in the same position. Maybe 3 or 4. Don't change position on every lap.

But for every unique position, try to match the elevation curve of successive laps. Do each position one at a time.

Quote:
2. I did a test ride with the GPS on, but later on GC I deleted the altitude profile. But now when I try to align the bottom of the VE moving the slider, the whole thing moves up/down, tho it doesn't change at all the alignment of the VE line. Is it because I had the GPS on or am I doing something else wrong? This is the printscreen of the segment of the ride where I took the bike to a outdoor track (that has a + - 1.5% gradient on each side).

Move the CdA slider and it will tilt the elevation profile. If you're doing loops, you're trying to match the start elevation of the loop with the end elevation. When you've matched them, you've found the right CdA. Is that what you're doing?

AndyF
bike geek
Quote Reply
Re: Platypus Thread: Aero Virtual Elevation Testing Protocol [AndyF] [ In reply to ]
Quote | Reply
Quote:
You don't need to reset the Garmin each time, but you should do more than one lap in the same position. Maybe 3 or 4. Don't change position on every lap.
But for every unique position, try to match the elevation curve of successive laps. Do each position one at a time.

I was planning on holding each position for 4 laps, so it should be fine, thanks! But how can I analyse the CdA for each 4 laps only? It seems that on GC the CdA is for the whole ride, how can I isolate only the laps that I want for the analysis?

Quote:
Move the CdA slider and it will tilt the elevation profile. If you're doing loops, you're trying to match the start elevation of the loop with the end elevation. When you've matched them, you've found the right CdA. Is that what you're doing?
I was trying to do it, but when moving the CdA slider the VE is not tilting, it's going up or down but keeping the same shape, so the difference between the bottoms/tops doesn't change at all. Not sure if I explained it well?

Many thanks again for your help!
Btw, nice website ;)
Quote Reply
Re: Platypus Thread: Aero Virtual Elevation Testing Protocol [RChung] [ In reply to ]
Quote | Reply
RChung wrote:
Here's a test to make sure: hold up the rear of the bike, spin the wheel to wake up the hub, then turn on the Joule. If you do this indoors and immediately get a speed signal you know it's not coming from GPS. Make sure your rollout is correct.

A lot of people new to the test protocol think they have to hold their speed constant. You don't need to do that. In fact, on a flat course like yours, start out slow then ramp up your speed to maybe racing speed (all while holding your position) then coast (while soft pedaling) back down to maybe jogging speed, then repeat. That will get you a wide range of speed and power, and the coasting bits will help you determine how fast you decelerate under zero power.

Rather than cycling speed within a loop interval, would it be better to "Shen" (so to speak) by slowly ramping up one's nominal power over several laps? I can't decide which would tease apart Cda/Crr better.

The question of who is right and who is wrong has seemed to me always too small to be worth a moment's thought, while the question of what is right and what is wrong has seemed all-important.

-Albert J. Nock
Quote Reply
Re: Platypus Thread: Aero Virtual Elevation Testing Protocol [Derf] [ In reply to ]
Quote | Reply
Derf wrote:
RChung wrote:
Here's a test to make sure: hold up the rear of the bike, spin the wheel to wake up the hub, then turn on the Joule. If you do this indoors and immediately get a speed signal you know it's not coming from GPS. Make sure your rollout is correct.

A lot of people new to the test protocol think they have to hold their speed constant. You don't need to do that. In fact, on a flat course like yours, start out slow then ramp up your speed to maybe racing speed (all while holding your position) then coast (while soft pedaling) back down to maybe jogging speed, then repeat. That will get you a wide range of speed and power, and the coasting bits will help you determine how fast you decelerate under zero power.


Rather than cycling speed within a loop interval, would it be better to "Shen" (so to speak) by slowly ramping up one's nominal power over several laps? I can't decide which would tease apart Cda/Crr better.

That will work, too. Both are ways to widen the range of speeds. Andy Shen's method is (to my mind) a little harder to do on the road but makes the analysis a little easier. Ramping and coasting is (to my mind) a little easier to do on the road but makes the analysis a little harder. I actually use both, at different times, depending on the venue I'm using. Use whichever makes the most sense for you.
Quote Reply
Re: Platypus Thread: Aero Virtual Elevation Testing Protocol [RChung] [ In reply to ]
Quote | Reply
Sounds fair; thanks!

The question of who is right and who is wrong has seemed to me always too small to be worth a moment's thought, while the question of what is right and what is wrong has seemed all-important.

-Albert J. Nock
Quote Reply
Re: Platypus Thread: Aero Virtual Elevation Testing Protocol [kikopi77] [ In reply to ]
Quote | Reply
Can you post the ride file somewhere? Perhaps there is something we can do in previous versions.

AndyF
bike geek
Quote Reply
Re: Platypus Thread: Aero Virtual Elevation Testing Protocol [kikopi77] [ In reply to ]
Quote | Reply
"It seems that on GC the CdA is for the whole ride, how can I isolate only the laps that I want for the analysis?"

I use the Split Ride tool (under the Activity menu) to split out the laps into separate files for VE analysis. I also keep a simple spreadsheet for tracking my various tests where I capture the pertinent data for each test, such as RHO, Crr, Mass, resultant CdA, etc.

As for why the VE curve isn't changing when you move the CdA slider, I have no clue. That sounds like it may be a bug in your install of GC.
Quote Reply
Re: Platypus Thread: Aero Virtual Elevation Testing Protocol [Tulkas] [ In reply to ]
Quote | Reply
Tulkas wrote:
I'm planning to have a go at this soon and am trying to decide where the best location will be for testing. I have a few "halfpipe" options in neighborhoods that I could use, but I feel like it would be hard to hold mynaero position while make a sharp turn at low speed.

Aahh...but that's one of the "beauties" of a halfpipe course, in that since you ARE going at a very slow speed, staying in an aero position is FAR less critical at the turnarounds. In fact, once I'm going very slow near the turn, I sit up a little and turn my head to look back and confirm that it's safe to make the turn, make the turn (I go slow enough that braking is unnecessary), then settle back in to the position and star pedaling again. You'll never detect the effects of that "sit up and look over your shoulder" move in the plots...as long as you're going slow enough, that is. For me, it's just barely fast enough to stay upright without doing a track stand ;-)

http://bikeblather.blogspot.com/
Quote Reply
Re: Platypus Thread: Aero Virtual Elevation Testing Protocol [tttiltheend] [ In reply to ]
Quote | Reply
Thanks v. much guys, I went back to the track today and later on I could tilt the VE using the slider, perfect!

I just forgot to press the 'laps' when riding so I couldn't split the ride on GC, but next time I'll get it all right!

Cheers
Quote Reply
Re: Platypus Thread: Aero Virtual Elevation Testing Protocol [Tom A.] [ In reply to ]
Quote | Reply
Ok, thanks for the feedback. The loops are still easier (closer to my house, less chance of traffic), but the ones around here are almost perfectly flat so I'm not sure I will be able to see where each lap starts and ends on the VE profile. I'll have to play with it and see.

Powertap / Cycleops / Saris
Quote Reply
Re: Platypus Thread: Aero Virtual Elevation Testing Protocol [kikopi77] [ In reply to ]
Quote | Reply
kikopi77 wrote:
Thanks v. much guys, I went back to the track today and later on I could tilt the VE using the slider, perfect!

I just forgot to press the 'laps' when riding so I couldn't split the ride on GC, but next time I'll get it all right!

Cheers

You can of course add laps to your file after the fact very easily and then split the file, of course that doesn't help you if it isn't apparent from the file where you want the laps to start end end.
Quote Reply
Re: Platypus Thread: Aero Virtual Elevation Testing Protocol [tttiltheend] [ In reply to ]
Quote | Reply
How can I add the laps?? I know exactly where they start!
Quote Reply
Re: Platypus Thread: Aero Virtual Elevation Testing Protocol [kikopi77] [ In reply to ]
Quote | Reply
Easy peasy. Just drag over the desired part of your ride to make a selection, and then Activity>Save Ride.
Quote Reply
Re: Platypus Thread: Aero Virtual Elevation Testing Protocol [tttiltheend] [ In reply to ]
Quote | Reply
Quote:
Easy peasy. Just drag over the desired part of your ride to make a selection, and then Activity>Save Ride.

Brilliant, worked perfectly!!
Quote Reply
Re: Platypus Thread: Aero Virtual Elevation Testing Protocol [AndyF] [ In reply to ]
Quote | Reply
So if I understand correctly you need to have the true elevation profile to compare to the VE line if you want to tease out the CRR from the CDA. What I can't figure out is how you get the true elevation line into the graph. I'm using GC version 3.1, but none of my graphs have ever had the elevation (green line) do anything. If I turn on constant elevation it will give me a straight line at 0 feet, but other than that I can't figure out how to make it track anything other than VE. I have tried doing runs with the GPS on and off for my test runs, when GPS is on there are lat/long coordinates at each data point but no elevation data. Interestingly, all the group rides I've done on my road bike (only 3 sadly) have altitude data, despite the fact that they use the same Powertap and Garmin 310 head unit with identical settings. The only thing I could think that is different is that I don't have a Garmin speed/cadence sensor on my road bike, so somehow when that is present then altitude data is not recorded? However that hasn't held up either, as I have one ride on my Tri bike without the GSC10 and it still doesn't have altitude (GPS on, lat/long data present); however that ride was recorded as the middle leg of a multi-sport activity so maybe it flushes that data out in the upload??

Any input on this would be appreciated, I know there must be a way to input altitude data after the fact since I see that data in all the screen shots and everyone says they turn GPS off to get clean data. Also, is google earth elevation data reliable or should I be able to find some other source that is usable for this purpose?

Powertap / Cycleops / Saris
Quote Reply
Re: Platypus Thread: Aero Virtual Elevation Testing Protocol [Tulkas] [ In reply to ]
Quote | Reply
Tulkas wrote:
So if I understand correctly you need to have the true elevation profile to compare to the VE line if you want to tease out the CRR from the CDA.

Not exactly, but that's the easiest way. (The harder way involves many tests over the same course where you vary speed over sub-segments of the course). In fact, all you really need is the elevation difference between known points on the course: if you happen to pass by topographic benchmarks with known altitude, you can use that to match the overall profile
Quote:

What I can't figure out is how you get the true elevation line into the graph. [..] Interestingly, all the group rides I've done on my road bike (only 3 sadly) have altitude data, despite the fact that they use the same Powertap and Garmin 310 head unit with identical settings.

That is interesting. However, the 310 doesn't have a barometric altimeter -- it uses GPS to estimate altitude, so the elevation trace you get from it probably won't work for you anyway even if you had it.

If you really, really, want to separate CdA and Crr, you'll either have to do the multiple replicate tests, or you can look up known elevations at a couple or few points of your course.

Or, you could blow that off, assume a reasonable value for Crr, and just look at changes in CdA. That's what many (most?) people do.
Last edited by: RChung: May 2, 15 10:12
Quote Reply
Re: Platypus Thread: Aero Virtual Elevation Testing Protocol [RChung] [ In reply to ]
Quote | Reply
I can understand wanting to estimate CdA and Crr simultaneously. I tend to run different front wheels with different tires and thought I should add that to my testing protocol. I wrote some custom code to implement the VE formulas and tried adding a fancy solver. It appears the equations don't necessarily have a unique solution, so the resulting VE profiles were crazy.

I never had much luck finding the combination a good testing course and decent elevation data, so I would also suggest using the available Crr estimates and just focusing on CdA. If you get really good at estimating CdA, then you might consider adding Crr. I just found it too much to do all at once.
Quote Reply
Re: Platypus Thread: Aero Virtual Elevation Testing Protocol [grumpier.mike] [ In reply to ]
Quote | Reply
grumpier.mike wrote:
I can understand wanting to estimate CdA and Crr simultaneously. I tend to run different front wheels with different tires and thought I should add that to my testing protocol. I wrote some custom code to implement the VE formulas and tried adding a fancy solver. It appears the equations don't necessarily have a unique solution, so the resulting VE profiles were crazy.

I never had much luck finding the combination a good testing course and decent elevation data, so I would also suggest using the available Crr estimates and just focusing on CdA. If you get really good at estimating CdA, then you might consider adding Crr. I just found it too much to do all at once.

If performing comparisons between sets up involves a wheel change, make sure speed measurement of each is taken from the unchanged wheel.

As Robert says, the analysis readily determines which set up provides for the lowest total resistance forces, but not necessarily answers the question as to why. To do that with these methods require more data (i.e. more time spent collecting it for each set up).

There are other reliably repeatable means to measure relative differences in Crr (e.g. roller test protocols), you can use those to adjust for any possible differences from field testing to tease out actual relative contribution of Crr and CdA changes.

http://www.cyclecoach.com
http://www.aerocoach.com.au
Quote Reply
Re: Platypus Thread: Aero Virtual Elevation Testing Protocol [AndyF] [ In reply to ]
Quote | Reply
Been a little while since I did field testing, but I decided recently to give it another go over the weekend with a slightly new setup and had a couple of minor questions for others doing this stuff. In the past, I was either doing the tests with a powertap, which gave both power and built in speed via wheel rotations (definitely don't want GPS!), or with a quarq and using a GSC-10. I hate the GSC-10. I don't normally ride with it on my bike, it is finicky to setup (lots of weird random drops destroying runs, etc). The setup I used over the weekend was a quarq for power and a new garmin hub mounted speed sensor. The new speed sensor was really great: super easy to mount even when I don't want to ride with it all the time, gave good data, etc.

Ok, so now comes the question part. I did a series of halfpipe A/B/A/B runs, using my head unit's "lap" function for identifying each run. I then loaded the ride into goldencheetah 3.1.0 and brought up aerolab. What I found was that trying to determine the CdA for each lap was a bit annoying and labor intensive. The "Estimate CdA and Crr" wants to do it for the whole ride (I think). I could click on a lap and zoom to the lap and then adjust things till it looked right, but that took a lot of time and was a bit error prone and subject to some user bias/interpretation. I even ended up removing the altitude data to get a horizontal line I could use as a guide. Here is an example of doing that below. Is there some better way to do this? Should I split each run into its own ride?


Quote Reply
Re: Platypus Thread: Aero Virtual Elevation Testing Protocol [AndyF] [ In reply to ]
Quote | Reply
I am having an elevation problem with Aerolab. The runs I am doing are at 6,000 feet and the elevation line show that but the VE line is at 2,800 feet. What this is doing is making the graph have too large of an elevation range, as a result the 80 feet hills that I am climbing on my laps can not be seen, the VE line looks flat. Is there a way to get the VE line closer to the actual evaluation so I can match up the hills. Below is a chart where I did like 12 loops as you see none are discernible using the CdA slider.

[URL=http://s48.photobucket.com/...dia/aerolab.jpg.html][/url]

BoulderCyclingCoach.com
Quote Reply
Re: Platypus Thread: Aero Virtual Elevation Testing Protocol [rockdude] [ In reply to ]
Quote | Reply
Have you tried unchecking the "eoffset auto" box and using the slider to set the elevation offset?
Quote Reply
Re: Platypus Thread: Aero Virtual Elevation Testing Protocol [rockdude] [ In reply to ]
Quote | Reply
You might also just clear all the elevation data from your ride. I've found that to help in the past when I had wonky elevation data from my garmin.
Quote Reply
Re: Platypus Thread: Aero Virtual Elevation Testing Protocol [jbank] [ In reply to ]
Quote | Reply
jbank wrote:
You might also just clear all the elevation data from your ride. I've found that to help in the past when I had wonky elevation data from my garmin.

Yeah, sometimes you have to do that. But sometimes unchecking the box and manually setting the elevation offset will work, and sometimes you can scan through the Altitude column in the "Edit" view to see if there are one or two anomalous values and just fix them directly. If there are a whole bunch of bad values, yeah, you might have to clear the entire altitude column.

I wonder whether part of this could be a mismatch between metric and imperial measurements. Rockdude mentioned he rides at 6000 feet, but that Aerolab screenshot looks like the distance is in km and the elevation is in meters.
Last edited by: RChung: Oct 13, 15 8:59
Quote Reply
Re: Platypus Thread: Aero Virtual Elevation Testing Protocol [rockdude] [ In reply to ]
Quote | Reply
Yeah, what jbank said -- clear the elevation. Edit tab, right-click on the altitude column and delete it. Then go back to Aerolab and enjoy. :-)

AndyF
bike geek
Quote Reply
Re: Platypus Thread: Aero Virtual Elevation Testing Protocol [RChung] [ In reply to ]
Quote | Reply
[/quote] I wonder whether part of this could be a mismatch between metric and imperial measurements. Rockdude mentioned he rides at 6000 feet, but that Aerolab screenshot looks like the distance is in km and the elevation is in meters.[/quote]



I think this is the issue. I am pretty sure my altitude data is good. The eoffset auto box does nothing. The elevation line is is pretty close and it shown in feet, The VE line is the line that is off and I think its being shown in meters. I will play around and see if my head unit will record in meters and also try to delete my altitude data. FYI- have had the same issue with two different head units, Joule 2 and the Garmin 910.

BoulderCyclingCoach.com
Last edited by: rockdude: Oct 13, 15 16:15
Quote Reply
Re: Platypus Thread: Aero Virtual Elevation Testing Protocol [rockdude] [ In reply to ]
Quote | Reply
rockdude wrote:
I think this is the issue. [..] The elevation line is is pretty close and it shown in feet, The VE line is the line that is off and I think its being shown in meters.
Yeah, the distance is in Km, the VE line is in meters, but the y-axis is in feet.
Quote Reply
Re: Platypus Thread: Aero Virtual Elevation Testing Protocol [RChung] [ In reply to ]
Quote | Reply
RChung wrote:
rockdude wrote:

I think this is the issue. [..] The elevation line is is pretty close and it shown in feet, The VE line is the line that is off and I think its being shown in meters.

Yeah, the distance is in Km, the VE line is in meters, but the y-axis is in feet.

I deleted the altitude from the files and VE lines now show the hills. I believe I can work with this and start doing some valid testing.
Cheers.

BoulderCyclingCoach.com
Quote Reply
Re: Platypus Thread: Aero Virtual Elevation Testing Protocol [RChung] [ In reply to ]
Quote | Reply
A quick question. I think I've seen the answer around but I can't seem to find it now. Is it ok to stop pedaling for a short period around a corner? I thought I had seen something that mentions you should always try to soft-pedal even when going slow.

I found a decent loop but one of the corners is about 110 degrees and slight down hill. I can do it but if I carry just bit too much speed I can't pedal as I have to lean too much. Sad thing is I banged my nice shiny new P1 pedals yesterday trying it :( Any coasting would be for only about 40 feet per lap of a 0.4 mile loop. I would probably do 3 loops per test.

On minor cool note, I was able to easily notice the difference between riding aero versus on the bars when I plugged into Aero Lab in a quick test "proof of concept" test. I know that may not easily apply to minor changes but I just wanted to make sure I could at least make some sense of the data doing something very simple.
Quote Reply
Re: Platypus Thread: Aero Virtual Elevation Testing Protocol [Burhed] [ In reply to ]
Quote | Reply
I had found issues with my quarq when I didn't soft pedal. The problem I had was that the quarq would keep registering the last power for a while if it didn't see the magnet tripped by an extra crank rotation. So in particular if you went fairly hard and suddenly stopped pedaling you could get weird results. If you aren't using a quarq (and maybe with new firmware this is fixed as well) I wouldn't worry. If you are using a quarq, at least try to make sure there is no big change where you suddenly go from high power to not pedaling.
Quote Reply
Re: Platypus Thread: Aero Virtual Elevation Testing Protocol [Burhed] [ In reply to ]
Quote | Reply
Burhed wrote:
A quick question. I think I've seen the answer around but I can't seem to find it now. Is it ok to stop pedaling for a short period around a corner? I thought I had seen something that mentions you should always try to soft-pedal even when going slow.

The physics doesn't care if you are pedalling or not, it's really only braking that's the problem as there is no allowance made for it in the equations. So theoretically there is no problem.

However....

The issue with not pedalling is how your power meter and head unit combination reports power when you stop and restart pedalling. Examine the power file closely around the points where you stop pedalling and restart pedalling. How accurate is the power data at those times? In some cases it is fiction, and as a result it can introduce an error as the data departs from reality.

Whether it's an error of consequence depends on how bad the data is, how often the error occurs/accumulates, how fine a difference you are attempting to parse out of the data.

http://www.cyclecoach.com
http://www.aerocoach.com.au
Quote Reply
Re: Platypus Thread: Aero Virtual Elevation Testing Protocol [AlexS] [ In reply to ]
Quote | Reply
AlexS wrote:
Burhed wrote:
A quick question. I think I've seen the answer around but I can't seem to find it now. Is it ok to stop pedaling for a short period around a corner? I thought I had seen something that mentions you should always try to soft-pedal even when going slow.


The physics doesn't care if you are pedalling or not, it's really only braking that's the problem as there is no allowance made for it in the equations. So theoretically there is no problem.

However....

The issue with not pedalling is how your power meter and head unit combination reports power when you stop and restart pedalling. Examine the power file closely around the points where you stop pedalling and restart pedalling. How accurate is the power data at those times? In some cases it is fiction, and as a result it can introduce an error as the data departs from reality.

Whether it's an error of consequence depends on how bad the data is, how often the error occurs/accumulates, how fine a difference you are attempting to parse out of the data.

Right, the issue is that some power meters (and head units) don't handle sudden stops and starts all that well. If you're doing a test that lasts, say, 3 or 4 minutes and you lose 3 seconds because your power meter doesn't handle starts and stops well that's probably not a big deal. If your test is only 30 seconds long it could be. So you look at your data to see if your power meter and head unit is susceptible to this or not. If so, make sure you don't do 30 second long tests.

(There's a secondary issue that your CdA can vary a tiny bit if you're coasting with your legs at 9 o'clock and 3 o'clock vs. if your legs are at 12 o'clock and 6 o'clock. I can never remember to be consistent with that so I soft-pedal even when I'm coasting so I don't have to remember).
Quote Reply
Re: Platypus Thread: Aero Virtual Elevation Testing Protocol [RChung] [ In reply to ]
Quote | Reply
Hi.
Some excellent information in here.
I have just started playing with Aerolab and today attempted to follow the process and get an estimate of my cda and to see if there is difference between 2 front wheels.
So I did 2 runs - one of 5 laps ( up and back) with frt wheel 1 and one of 6 laps ( because one turn was ruined waiting for traffic and I had to over run the turn point) with frt wheel 2.
The results are confusing however. Firstly my cda number is way bigger than I would have imagined ( around 0.31 - this is with full TT kit) and secondly the VE on run 2 is all over the place for the first 2 laps then ok (ish) for the next 4. So I am wondering if I have made a serious error in my inputs or if the course is just not suitable for purpose.

The course I used is a bit over 3km each way with slight rises at the turn points to allow me to coast to the turn point with nil or very minimal braking to turn. It is a pretty flat course and I rode it at a fairly steady power output around 150 but often lower - (today is a recovery day for me).

I used a Garmin 510 and stages power meter. I used GPS for speed ( I have read that this can be problematic).



This is run 1:

[URL=http://s935.photobucket.com/...zpsoxzeowpk.png.html][/url]

This is run 2:

[URL=http://s935.photobucket.com/...zpsitygvujw.png.html][/url]



Given all of the above...is this data sufficient for (any) purpose?

thanks
Lindsay
Quote Reply
Re: Platypus Thread: Aero Virtual Elevation Testing Protocol [Linds] [ In reply to ]
Quote | Reply
No idea what went wrong on run 2. Is there any chance of brake rub? Also, what in the heck is the green elevation line?

I would start by making sure your equipment is working correctly. You need a real speed sensor (GPS isn't accurate enough) and you should turn the GPS function off. At 3k your course is kinda long. do you really have 3k of consistent pavement and no traffic? I would also start testing something like a road helmet versus an aero helmet. You need to be pretty good at this before you can test for minor differences like front wheels.
Quote Reply
Re: Platypus Thread: Aero Virtual Elevation Testing Protocol [grumpier.mike] [ In reply to ]
Quote | Reply
grumpier.mike wrote:
No idea what went wrong on run 2. Is there any chance of brake rub? Also, what in the heck is the green elevation line?

I would start by making sure your equipment is working correctly. You need a real speed sensor (GPS isn't accurate enough) and you should turn the GPS function off. At 3k your course is kinda long. do you really have 3k of consistent pavement and no traffic? I would also start testing something like a road helmet versus an aero helmet. You need to be pretty good at this before you can test for minor differences like front wheels.


Thanks Mike
No, no sign of brake rubbing.
Yes the 3km w/out traffic is no problem early in the morning on this road and it is a very nice surface.
But I can find a shorter run somewhere if required.

The Garmin 510 elevation is clunky isnt it...it seems overly eratic but it is a very flat course..and how sensitive to actual elevation is this protocol?
I thought I read in here somewhere that the 510 had better GPS data ( than the 500) that made it acceptable for this test? If not, I do have the speed sensor I can put on.

I do hope I have dodgy data..because 0.31 is much worse than expected.
Last edited by: Linds: Nov 29, 15 21:36
Quote Reply
Re: Platypus Thread: Aero Virtual Elevation Testing Protocol [Linds] [ In reply to ]
Quote | Reply
What power meter were you using? Did you send the power meter 3 consecutive "zeros"? Were the offsets all the same?

I've been incorporating a 3-zero protocol lately for the power meters we use when aero testing. It's surprising how often the first zero sent to almost any power meter will be different than the subsequent ones. Try and see.

That may be the source of many aero "puzzles", btw.

AndyF
bike geek
Quote Reply
Re: Platypus Thread: Aero Virtual Elevation Testing Protocol [AndyF] [ In reply to ]
Quote | Reply
stages power meter.
thks
Quote Reply
Re: Platypus Thread: Aero Virtual Elevation Testing Protocol [Linds] [ In reply to ]
Quote | Reply
Linds wrote:
stages power meter.
thks
That introduces a potentially large unquantifiable error.

Aside from very low hanging aero fruit, I would say this is an application unsuitable for a Stages PM.

http://www.cyclecoach.com
http://www.aerocoach.com.au
Quote Reply
Re: Platypus Thread: Aero Virtual Elevation Testing Protocol [AlexS] [ In reply to ]
Quote | Reply
Could you do aero testing with a stages PM if you did it as a one-leg drill?
Quote Reply
Re: Platypus Thread: Aero Virtual Elevation Testing Protocol [AndyF] [ In reply to ]
Quote | Reply
AndyF wrote:
What power meter were you using? Did you send the power meter 3 consecutive "zeros"? Were the offsets all the same?

I've been incorporating a 3-zero protocol lately for the power meters we use when aero testing. It's surprising how often the first zero sent to almost any power meter will be different than the subsequent ones. Try and see.

That may be the source of many aero "puzzles", btw.

Good tip. I usually do at least 3 zeroes both before and after the test - to also see if there has been any drift in the zero values. I have yet to see my SRM drift more than 1W during a test, though - that thing is rock solid. Not neceassarily the case with the other powermeters I've used (none mentioned, none forgotten :p).
Quote Reply
Re: Platypus Thread: Aero Virtual Elevation Testing Protocol [Linds] [ In reply to ]
Quote | Reply
Linds wrote:
Given all of the above...is this data sufficient for (any) purpose?

It's sufficient for learning that you should probably use a speed sensor and you need to zero your PM. The VE profiles for the laps look pretty consistent. Was this an out-and-back with roughly 4 meters of elevation change from the start to the turnaround? Something odd happened on lap 2 of run 2 -- did a couple of cars pass or something? Regardless, I'd ignore that particular lap, though the rest of the laps seem okay. This is one of the good things about this particular protocol -- if you get something like a passing car or you have to hit the brakes or some other interruption, you can sometimes ignore that bit but salvage the rest of the run.

The very first loop I used was a 3.2km long test loop. Slightly longer than ideal but that's what I had available to me at the time.

The Stages might not be the best PM for this particular application, but I don't see anything grossly wrong that would invalidate it.

Whether 0.31 m^2 for CdA is worrisome depends on how tall you are. You've set all-inclusive mass at 92 kg so I'm guessing you're not tiny. In addition, if estimated Crr is low, your estimated CdA will be high, so if your tires had higher rolling resistance it'd drop your CdA estimate a little.

This is a good start.
Quote Reply
Re: Platypus Thread: Aero Virtual Elevation Testing Protocol [AndyF] [ In reply to ]
Quote | Reply
AndyF wrote:
What power meter were you using? Did you send the power meter 3 consecutive "zeros"? Were the offsets all the same?

I've been incorporating a 3-zero protocol lately for the power meters we use when aero testing. It's surprising how often the first zero sent to almost any power meter will be different than the subsequent ones. Try and see.

That may be the source of many aero "puzzles", btw.


Within what time frame?

When I do roller testing of tires, I'm setting the zero on a Quarq every 4-5 minutes and the number returned is typically within 2-3 units (and mine doesn't even have the 10k temperature compensation).

http://bikeblather.blogspot.com/
Last edited by: Tom A.: Nov 30, 15 15:55
Quote Reply
Re: Platypus Thread: Aero Virtual Elevation Testing Protocol [Tom A.] [ In reply to ]
Quote | Reply
Tom A. wrote:
AndyF wrote:
What power meter were you using? Did you send the power meter 3 consecutive "zeros"? Were the offsets all the same?

I've been incorporating a 3-zero protocol lately for the power meters we use when aero testing. It's surprising how often the first zero sent to almost any power meter will be different than the subsequent ones. Try and see.

That may be the source of many aero "puzzles", btw.


Within what time frame?

When I do roller testing of tires, I'm setting the zero on a Quarq every 4-5 minutes and the number returned is typically within 2-3 units (and mine doesn't even have the 10k temperature compensation).

I zero again when I get out to the testing venue but I still usually add an extra lap for the first run of the day that I intend to toss out. For some reason my very first lap often tends to be noisier than subsequent laps. I used to worry about it and try to figure out why but now I just do that first lap as a "reconnaissance" lap to spot my line and then I toss it.
Quote Reply
Re: Platypus Thread: Aero Virtual Elevation Testing Protocol [RChung] [ In reply to ]
Quote | Reply
RChung wrote:
Tom A. wrote:
AndyF wrote:
What power meter were you using? Did you send the power meter 3 consecutive "zeros"? Were the offsets all the same?

I've been incorporating a 3-zero protocol lately for the power meters we use when aero testing. It's surprising how often the first zero sent to almost any power meter will be different than the subsequent ones. Try and see.

That may be the source of many aero "puzzles", btw.


Within what time frame?

When I do roller testing of tires, I'm setting the zero on a Quarq every 4-5 minutes and the number returned is typically within 2-3 units (and mine doesn't even have the 10k temperature compensation).


I zero again when I get out to the testing venue but I still usually add an extra lap for the first run of the day that I intend to toss out. For some reason my very first lap often tends to be noisier than subsequent laps. I used to worry about it and try to figure out why but now I just do that first lap as a "reconnaissance" lap to spot my line and then I toss it.

It's OK...similar things happen in a wind tunnel session ;-)

http://bikeblather.blogspot.com/
Quote Reply
Re: Platypus Thread: Aero Virtual Elevation Testing Protocol [RChung] [ In reply to ]
Quote | Reply
RChung wrote:
Linds wrote:

Given all of the above...is this data sufficient for (any) purpose?


It's sufficient for learning that you should probably use a speed sensor and you need to zero your PM. The VE profiles for the laps look pretty consistent. Was this an out-and-back with roughly 4 meters of elevation change from the start to the turnaround? Something odd happened on lap 2 of run 2 -- did a couple of cars pass or something? Regardless, I'd ignore that particular lap, though the rest of the laps seem okay. This is one of the good things about this particular protocol -- if you get something like a passing car or you have to hit the brakes or some other interruption, you can sometimes ignore that bit but salvage the rest of the run.

The very first loop I used was a 3.2km long test loop. Slightly longer than ideal but that's what I had available to me at the time.

The Stages might not be the best PM for this particular application, but I don't see anything grossly wrong that would invalidate it.

Whether 0.31 m^2 for CdA is worrisome depends on how tall you are. You've set all-inclusive mass at 92 kg so I'm guessing you're not tiny. In addition, if estimated Crr is low, your estimated CdA will be high, so if your tires had higher rolling resistance it'd drop your CdA estimate a little.

This is a good start.

Thanks Robert,

I'm 192cm and 83kg with full bike kit on. I have narrow shoulders and thin limbs...attributes I had hoped might assist being at least somewhat aero.
I have had a professional bike fit and I have adjusted a few things since then but I have no idea what kind of cda is reasonable to aim for for a rider my size/shape.

I'm not sure of the elevation difference from start to turnaround - can only go off the Garmin and the VE but 4m is in the ballpark I suppose.
I will go ahead and put on the speed sensor and be sure to zero the PM next time.
Quote Reply
Re: Platypus Thread: Aero Virtual Elevation Testing Protocol [Tom A.] [ In reply to ]
Quote | Reply
Tom A. wrote:

Within what time frame?


3 quick zeros with a 30-sec time-frame.

Quote:

When I do roller testing of tires, I'm setting the zero on a Quarq every 4-5 minutes and the number returned is typically within 2-3 units (and mine doesn't even have the 10k temperature compensation).


You have a good N=1 power meter. This year, I've seen maybe 60-70 different power meters while aero testing and I need to zero at least 3x and make sure that the last 2 zeros return a similar offset. This is true across all power meter brands that I've seen:
SRM, P2max, Quarq, Powertap hub, Powertap P1 pedals

Yesterday's run, for instance, had a rider with an SRM. We'd hit it with a zero and it would return something like: 532, 527, 528, 528.

AndyF
bike geek
Last edited by: AndyF: Dec 1, 15 2:48
Quote Reply
Re: Platypus Thread: Aero Virtual Elevation Testing Protocol [AndyF] [ In reply to ]
Quote | Reply
I noted what Robert said about the sensitivity of the Cda to the Crr.
A little on line research came up with a Crr for my tyres(vittoria corsa tubulars) of 0.0054.
Using that, my new Cda is 0.265 with my deep dish front.
That is more like I expected.
But still needs careful confirmation which I will do some time soon.
Thks
Quote Reply
Re: Platypus Thread: Aero Virtual Elevation Testing Protocol [AndyF] [ In reply to ]
Quote | Reply
AndyF wrote:
Tom A. wrote:

Within what time frame?


3 quick zeros with a 30-sec time-frame.

Quote:

When I do roller testing of tires, I'm setting the zero on a Quarq every 4-5 minutes and the number returned is typically within 2-3 units (and mine doesn't even have the 10k temperature compensation).


You have a good N=1 power meter. This year, I've seen maybe 60-70 different power meters while aero testing and I need to zero 3x and make sure that the last 2 zeros return a similar offset. This is true across all power meter brands that I've seen:
SRM, P2max, Quarq, Powertap hub, Powertap P1 pedals

Yesterday's run, for instance, had a rider with an SRM. We'd hit it with a zero and it would return something like: 532, 527, 528, 528.

You probably already know this, but the units on the returned zero can vary quite a lot between different brands of powermeters (and even within the same brand depending on the slope). IIRC each unit on Power2max is something on the order of 1-2W (at a cadence of ~90 rpm - but depends on the slope of the individual unit), whereas for a Quarq or SRM it is on the order of 0.3W (but slope-dependent on the SRM at least).
Quote Reply
Re: Platypus Thread: Aero Virtual Elevation Testing Protocol [MTM] [ In reply to ]
Quote | Reply
MTM wrote:

You probably already know this, but the units on the returned zero can vary quite a lot between different brands of powermeters (and even within the same brand depending on the slope). IIRC each unit on Power2max is something on the order of 1-2W (at a cadence of ~90 rpm - but depends on the slope of the individual unit), whereas for a Quarq or SRM it is on the order of 0.3W (but slope-dependent on the SRM at least).

Yup.

But I just wanted to point out that the very first "zero" may sometimes be out-of-whack. Make sure the offset stabilizes, and keep track of your zeros. If they move around too much, then consider sending your pm back to the factory.

The more you know about gluing strain gauges to metal, the more you want to keep close tabs on your pm.

AndyF
bike geek
Quote Reply
Re: Platypus Thread: Aero Virtual Elevation Testing Protocol [AndyF] [ In reply to ]
Quote | Reply
Hi Andy,

Have you tried using a "Headwind" column into Aerolab recently ? I must be doing something wrong, it is being ignored.
Quote Reply
Re: Platypus Thread: Aero Virtual Elevation Testing Protocol [marcag] [ In reply to ]
Quote | Reply
marcag wrote:
Hi Andy,

Have you tried using a "Headwind" column into Aerolab recently ? I must be doing something wrong, it is being ignored.


Lately no, but I was "involved" in getting headwind into Aerolab in the first place. :-)

I think you have to spell it right. "headwind" is what I just found in the code:
https://github.com/...9C%93&q=headwind

AndyF
bike geek
Last edited by: AndyF: Dec 1, 15 4:42
Quote Reply
Re: Platypus Thread: Aero Virtual Elevation Testing Protocol [AndyF] [ In reply to ]
Quote | Reply
AndyF wrote:
marcag wrote:
Hi Andy,

Have you tried using a "Headwind" column into Aerolab recently ? I must be doing something wrong, it is being ignored.


Lately no, but I was "involved" in getting headwind into Aerolab in the first place. :-)

I think you have to spell it right. "headwind" is what I just found in the code:
https://github.com/...9C%93&q=headwind


thanks

I'll play a little more. I tried "Headwind" and "headwind". If I put it in the last column it gets ignored. If I put it right after "Km/h" it gives me an Error message "Insuffucient valid data". I am basing the rest of format on what GC exports to .csv

Minutes, Torq (N-m), Km/h, headwind, Watts, Km, Cadence, Hrate ID, Altitude (m)
0.0166667, 0, 11.1852 ,1.1, 120, 0.00309, 22, 93, 0, 1.20001
Last edited by: marcag: Dec 1, 15 4:46
Quote Reply
Re: Platypus Thread: Aero Virtual Elevation Testing Protocol [marcag] [ In reply to ]
Quote | Reply
marcag wrote:
AndyF wrote:
marcag wrote:
Hi Andy,

Have you tried using a "Headwind" column into Aerolab recently ? I must be doing something wrong, it is being ignored.


Lately no, but I was "involved" in getting headwind into Aerolab in the first place. :-)

I think you have to spell it right. "headwind" is what I just found in the code:
https://github.com/...9C%93&q=headwind


thanks

I'll play a little more. I tried "Headwind" and "headwind". If I put it in the last column it gets ignored. If I put it right after "Km/h" it gives me an Error message "Insuffucient valid data". I am basing the rest of format on what GC exports to .csv

Minutes, Torq (N-m), Km/h, headwind, Watts, Km, Cadence, Hrate ID, Altitude (m)
0.0166667, 0, 11.1852 ,1.1, 120, 0.00309, 22, 93, 0, 1.20001

Cool, I didn't know they had implemented headwind! Let me know if you get it to work.

To go a step further is would be super cool if you could just input a wind speed and direction and then it would calculate the headwind (and apply it) using that information combined with the direction of the ride at any point (using GPS coordinates). I think it could work OK as long as the course you are riding is not too twisty or technical. And yaw angle could then also easily be added - but now we're getting into BBS territory :)
Quote Reply
Re: Platypus Thread: Aero Virtual Elevation Testing Protocol [MTM] [ In reply to ]
Quote | Reply
MTM wrote:

Cool, I didn't know they had implemented headwind! Let me know if you get it to work.

To go a step further is would be super cool if you could just input a wind speed and direction and then it would calculate the headwind (and apply it) using that information combined with the direction of the ride at any point (using GPS coordinates). I think it could work OK as long as the course you are riding is not too twisty or technical. And yaw angle could then also easily be added - but now we're getting into BBS territory :)

I need to poke around more but at first glance

- Headwind is supported
- You can't import it via .csv, but you can add the column in the editor
- It will export to .json
- It seems to import from json
Quote Reply
Re: Platypus Thread: Aero Virtual Elevation Testing Protocol [marcag] [ In reply to ]
Quote | Reply
As an import column it only appears to be supported for JSON files.
I've not tried it as a manual column. In my imported data it comes after Longitude and is 'Headwind'.

Note that it would be better described as air speed than headwind. So a 0 headwind is the same value as Speed and a headwind is a value a bit higher than Speed, if that makes sense.

Developing aero, fit and other fun stuff at Red is Faster
Last edited by: SkippyKitten: Dec 1, 15 22:18
Quote Reply
Re: Platypus Thread: Aero Virtual Elevation Testing Protocol [SkippyKitten] [ In reply to ]
Quote | Reply
Whichever one you code, some much smarter person that comes along 6 years later will make a case for the other. Better to not do anything at all sometimes. :-)

AndyF
bike geek
Last edited by: AndyF: Dec 1, 15 19:17
Quote Reply
Re: Platypus Thread: Aero Virtual Elevation Testing Protocol [AndyF] [ In reply to ]
Quote | Reply
It wasn't a criticism; "Working software over comprehensive documentation" and all that. If I was that smart I'd have pulled my finger out and contributed to GC.

Developing aero, fit and other fun stuff at Red is Faster
Last edited by: SkippyKitten: Dec 2, 15 3:52
Quote Reply
Re: Platypus Thread: Aero Virtual Elevation Testing Protocol [Linds] [ In reply to ]
Quote | Reply
Linds wrote:
I noted what Robert said about the sensitivity of the Cda to the Crr. [..]
But still needs careful confirmation which I will do some time soon.
Is this venue an out-and-back, that's mostly flat?

If you really want to nail down CdA and Crr there's a way to do that, but you'll need a wider range in speed and power than you used previously (you said you did most of those previous tests at around a constant 150 watts, right?). A good side effect is that you typically don't need to do quite so many laps.
Quote Reply
Re: Platypus Thread: Aero Virtual Elevation Testing Protocol [marcag] [ In reply to ]
Quote | Reply
marcag wrote:
MTM wrote:


Cool, I didn't know they had implemented headwind! Let me know if you get it to work.

To go a step further is would be super cool if you could just input a wind speed and direction and then it would calculate the headwind (and apply it) using that information combined with the direction of the ride at any point (using GPS coordinates). I think it could work OK as long as the course you are riding is not too twisty or technical. And yaw angle could then also easily be added - but now we're getting into BBS territory :)


I need to poke around more but at first glance

- Headwind is supported
- You can't import it via .csv, but you can add the column in the editor
- It will export to .json
- It seems to import from json

Thanks for the update. I haven't tried adding columns manually in the editor - can you just copy/paste a column from Excel? I have not worked with .json at all, so don't know if it might be easy to make a .json file to import it from. I was basically thinking of mounting a wind sensor on my bike (have done this before) and try and get that data into the column. The wind sensor I have can export to .csv, so have to add the data into GC semi-manually somehow.
Quote Reply
Re: Platypus Thread: Aero Virtual Elevation Testing Protocol [MTM] [ In reply to ]
Quote | Reply
JSON is a JavaScript representation of your data. Great for manipulating in a browser or a bit of code. Not so good for people, even with a decent editor.

Getting airspeed data in there works wonders! May I ask what you were using to measure it? It took me months to get good quality data.

Developing aero, fit and other fun stuff at Red is Faster
Quote Reply
Re: Platypus Thread: Aero Virtual Elevation Testing Protocol [SkippyKitten] [ In reply to ]
Quote | Reply
SkippyKitten wrote:
JSON is a JavaScript representation of your data. Great for manipulating in a browser or a bit of code. Not so good for people, even with a decent editor.

Getting airspeed data in there works wonders! May I ask what you were using to measure it? It took me months to get good quality data.


Sounds like manual entry into GC will be the way to go for me then. Hope it's easy to copy-paste from Excel.

I'm just using a Brunton ADC Pro which samples every 5 seconds. Nothing fancy and am not expecting to get any breathtaking data from it, mostly playing around and getting a feel for wind speed and things like that. So far I've only mounted it on the handlebar, but the data might suggest I need to put it further out in front to not be impacted too much by the lump behind it (i.e. me).

How is your project getting along? Need any beta testers? ;-)

Edit: Just read your blog, seems like things are getting along nicely. I don't know which Garmin you are using for GPS, but I might suggest the Edge 1000 if you are not already using that. The GLONASS seems to help a lot, but even compared to the Edge 520 (which also has GLONASS) it picks up a signal much faster and is likely also better/more accurate with regards to speed data. I don't even use a speed sensor for field testing anymore and the speed data is perfectly fine (I do field test in a place with a clear view of the sky, though - but the speed data from my old Edge 500 would still be way too bad).
Last edited by: MTM: Dec 2, 15 13:23
Quote Reply
Re: Platypus Thread: Aero Virtual Elevation Testing Protocol [MTM] [ In reply to ]
Quote | Reply
Simply adding the headwind column in the editor seems to break aerolab for me

-Take a file that works fine in aerolab
-Insert headwind column, leaving 0s everywhere
-Aerolab becomes unusable
Quote Reply
Re: Platypus Thread: Aero Virtual Elevation Testing Protocol [marcag] [ In reply to ]
Quote | Reply
Have you tried copying the speed data into the headwind column? I.e. basically telling it there was no wind.
Quote Reply
Re: Platypus Thread: Aero Virtual Elevation Testing Protocol [MTM] [ In reply to ]
Quote | Reply
LOL. I do have contacts in Copenhagen :)
I've got a much better(GLONASS) GPS for next year. I've used an 800, 520 and 520 for various runs. The 520 was the best of those. There is a thread on here somewhere about the project. If you wish to know more it might be worth posting there to stop us drifting off topic.

Developing aero, fit and other fun stuff at Red is Faster
Quote Reply
Re: Platypus Thread: Aero Virtual Elevation Testing Protocol [MTM] [ In reply to ]
Quote | Reply
thanks, that fixed it.
Quote Reply
Re: Platypus Thread: Aero Virtual Elevation Testing Protocol [RChung] [ In reply to ]
Quote | Reply
Advice from the experts please;


I have found a great spot to do laps which is;

a) near to home (very repeatable)
b) a 'good' length (0.8 mile)
c) very quiet outside of normal working hours
d) has variability in gradients

BUT there is a roundabout at the bottom of a slope (I'm blind to traffic approaching the r/a due to the layout) meaning that braking is a necessity (I don't fancy chancing it).

SO... can I use the laps BUT get rid of the braked data? Would it be easier to not have that section of data included in the first instance; my plan is to stop the Garmin at a particular point each lap BEFORE braking and then restart at a point at a similar height (after ascending from the r/a). Would this still give usable results and would it be better to set the Garmin to start and finish at specific points (so I don't have to fiddle with the Garmin/get out of the TT position etc)?
Quote Reply
Re: Platypus Thread: Aero Virtual Elevation Testing Protocol [esox.flucius] [ In reply to ]
Quote | Reply
Find a different spot.
Quote Reply
Re: Platypus Thread: Aero Virtual Elevation Testing Protocol [jbank] [ In reply to ]
Quote | Reply
The only bit of suitable road I can find has a dead turn at either end, a come out of aero and brake job.
Can I cut out these sections and get just the out and back?
Quote Reply
Re: Platypus Thread: Aero Virtual Elevation Testing Protocol [Tomato] [ In reply to ]
Quote | Reply
Coming up and out of aero if you are going very slow is not a deal breaker. Using your brakes at all is. Perhaps RChung has some ideas/method to post-process with cutting those sections out, but seems highly suspect and error prone. This is the whole rationale for a "half-pipe", you use the hill to slow you down enough to turn on both ends so you don't need to brake. A loop hopefully has the same nice property.
Quote Reply
Re: Platypus Thread: Aero Virtual Elevation Testing Protocol [Tomato] [ In reply to ]
Quote | Reply
Tomato wrote:
The only bit of suitable road I can find has a dead turn at either end, a come out of aero and brake job.
Can I cut out these sections and get just the out and back?

If you do brake, brake hard so that it looks like a hill with a slope you couldn't possibly have ridden. Brakes, rolling resistance, and slope all the look the same to the physics.

F = ( Crr + s + b )* m*g , where
s = slope and
b = braking

AndyF
bike geek
Quote Reply
Re: Platypus Thread: Aero Virtual Elevation Testing Protocol [Tomato] [ In reply to ]
Quote | Reply
Tomato wrote:
The only bit of suitable road I can find has a dead turn at either end, a come out of aero and brake job.
Can I cut out these sections and get just the out and back?
Yes you can just cut out that section. I just hit lap on my Garmin twice and cut the piece in between. Use a marker on the road to precisely start and stop at the same point, and pedal through in both directions. I.e. pedal through the stop, turn around, and then start pedalling before the start (just helps with some Garmin recording issues). While I usually use a "half pipe", I actually wrote some simple java software that cuts out the turnaround automatically if needed so it's super easy.
Quote Reply
Re: Platypus Thread: Aero Virtual Elevation Testing Protocol [esox.flucius] [ In reply to ]
Quote | Reply
esox.flucius wrote:
Advice from the experts please;


I have found a great spot to do laps which is;

a) near to home (very repeatable)
b) a 'good' length (0.8 mile)
c) very quiet outside of normal working hours
d) has variability in gradients

BUT there is a roundabout at the bottom of a slope (I'm blind to traffic approaching the r/a due to the layout) meaning that braking is a necessity (I don't fancy chancing it).

SO... can I use the laps BUT get rid of the braked data? Would it be easier to not have that section of data included in the first instance; my plan is to stop the Garmin at a particular point each lap BEFORE braking and then restart at a point at a similar height (after ascending from the r/a). Would this still give usable results and would it be better to set the Garmin to start and finish at specific points (so I don't have to fiddle with the Garmin/get out of the TT position etc)?

As AndyF and Lanierb have said, it's possible to snip out the part where you brake -- but it's kind of a hassle. If the next best venue is far away, I'd use this one and snip it. If the next best venue is close, I might use that one.

I do what Lanier and Andy do: I identify a landmark (can be a chalk mark you "X" onto the pavement) and hit the brake hard there or hit the interval button (depends on how fast I'm going) then turn around and when I come up to the "X" from the other side I hit the interval button again.

The hassle part is that when I snip out parts of ride files, I can't really use Aerolab since there's an "offset" in the elevation at the point when I hit the brakes. I have a bunch of little code snippets that let me analyze the data so I use those, but not everyone can do that.
Quote Reply
Re: Platypus Thread: Aero Virtual Elevation Testing Protocol [RChung] [ In reply to ]
Quote | Reply
RChung wrote:
esox.flucius wrote:
Advice from the experts please;


I have found a great spot to do laps which is;

a) near to home (very repeatable)
b) a 'good' length (0.8 mile)
c) very quiet outside of normal working hours
d) has variability in gradients

BUT there is a roundabout at the bottom of a slope (I'm blind to traffic approaching the r/a due to the layout) meaning that braking is a necessity (I don't fancy chancing it).

SO... can I use the laps BUT get rid of the braked data? Would it be easier to not have that section of data included in the first instance; my plan is to stop the Garmin at a particular point each lap BEFORE braking and then restart at a point at a similar height (after ascending from the r/a). Would this still give usable results and would it be better to set the Garmin to start and finish at specific points (so I don't have to fiddle with the Garmin/get out of the TT position etc)?


As AndyF and Lanierb have said, it's possible to snip out the part where you brake -- but it's kind of a hassle. If the next best venue is far away, I'd use this one and snip it. If the next best venue is close, I might use that one.

I do what Lanier and Andy do: I identify a landmark (can be a chalk mark you "X" onto the pavement) and hit the brake hard there or hit the interval button (depends on how fast I'm going) then turn around and when I come up to the "X" from the other side I hit the interval button again.

The hassle part is that when I snip out parts of ride files, I can't really use Aerolab since there's an "offset" in the elevation at the point when I hit the brakes. I have a bunch of little code snippets that let me analyze the data so I use those, but not everyone can do that.

Thanks for replying Robert, appreciate you taking the time. Would it not be easier to just stop the Garmin just prior to the point of braking and then starting it again at the same point on the way back? Or would this not work as effectively? Similarly in my situation; could I stop the Garmin at the same point going into the round about, brake, accelerate out and start the Garmin at the same point each time on the way out (the second point being at the same altitude as the first, in a 'loop').
Quote Reply
Re: Platypus Thread: Aero Virtual Elevation Testing Protocol [esox.flucius] [ In reply to ]
Quote | Reply
esox.flucius wrote:
Would it not be easier to just stop the Garmin just prior to the point of braking and then starting it again at the same point on the way back? Or would this not work as effectively? Similarly in my situation; could I stop the Garmin at the same point going into the round about, brake, accelerate out and start the Garmin at the same point each time on the way out (the second point being at the same altitude as the first, in a 'loop').

Hmmm. I don't use a Garmin so I don't know how many key presses it takes to "stop" one. I just hit the interval or lap marker, which takes one quick button press, as I pass my landmark.
Quote Reply
Re: Platypus Thread: Aero Virtual Elevation Testing Protocol [esox.flucius] [ In reply to ]
Quote | Reply
esox.flucius wrote:
RChung wrote:
esox.flucius wrote:
Advice from the experts please;


I have found a great spot to do laps which is;

a) near to home (very repeatable)
b) a 'good' length (0.8 mile)
c) very quiet outside of normal working hours
d) has variability in gradients

BUT there is a roundabout at the bottom of a slope (I'm blind to traffic approaching the r/a due to the layout) meaning that braking is a necessity (I don't fancy chancing it).

SO... can I use the laps BUT get rid of the braked data? Would it be easier to not have that section of data included in the first instance; my plan is to stop the Garmin at a particular point each lap BEFORE braking and then restart at a point at a similar height (after ascending from the r/a). Would this still give usable results and would it be better to set the Garmin to start and finish at specific points (so I don't have to fiddle with the Garmin/get out of the TT position etc)?


As AndyF and Lanierb have said, it's possible to snip out the part where you brake -- but it's kind of a hassle. If the next best venue is far away, I'd use this one and snip it. If the next best venue is close, I might use that one.

I do what Lanier and Andy do: I identify a landmark (can be a chalk mark you "X" onto the pavement) and hit the brake hard there or hit the interval button (depends on how fast I'm going) then turn around and when I come up to the "X" from the other side I hit the interval button again.

The hassle part is that when I snip out parts of ride files, I can't really use Aerolab since there's an "offset" in the elevation at the point when I hit the brakes. I have a bunch of little code snippets that let me analyze the data so I use those, but not everyone can do that.


Thanks for replying Robert, appreciate you taking the time. Would it not be easier to just stop the Garmin just prior to the point of braking and then starting it again at the same point on the way back? Or would this not work as effectively? Similarly in my situation; could I stop the Garmin at the same point going into the round about, brake, accelerate out and start the Garmin at the same point each time on the way out (the second point being at the same altitude as the first, in a 'loop').

I think some things are just easier to deal with in a spreadsheet since it requires some level of manual manipulation of data. It's not hard, just a little fiddly. Overlay the VE plot for each of the outward runs on top of each other (and same for return runs) and force the start of each run to begin with same elevation. Enter in assumptions so that at least one of the VE lines resembles the actual elevation change for the section.

Then you see which plots climb an apparently steeper hill than others (or show a less steep decline). The question then becomes why they exhibit such behaviour? In an ideal world it'd be all because of the change you made to your set up, but of course it may also be for uncontrollable things, e.g. differences in air movement (wind, traffic etc).

http://www.cyclecoach.com
http://www.aerocoach.com.au
Quote Reply
Re: Platypus Thread: Aero Virtual Elevation Testing Protocol [AlexS] [ In reply to ]
Quote | Reply
AlexS wrote:
I think some things are just easier to deal with in a spreadsheet since it requires some level of manual manipulation of data. It's not hard, just a little fiddly.
Yeah, sometimes describing what to do takes more time than just doing it. Popping the data into a spreadsheet and snipping out (or, just ignoring) the turnarounds is pretty simple as long as you hit the interval marker.

Quote:
Overlay the VE plot for each of the outward runs on top of each other (and same for return runs) and force the start of each run to begin with same elevation.
When I'm doing an out-and-back I sometimes "mirror" the runs. If all the outbound runs have a little less total VE gain than all the inbound runs, you know there must've been a tailwind on the way out and a headwind on the way back.
Quote Reply
Re: Platypus Thread: Aero Virtual Elevation Testing Protocol [RChung] [ In reply to ]
Quote | Reply
Thanks Rob,
For an out and back how far would you aim for. I have one that is 1 mile stretch so 2 miles in total.

I have a place I can turn at each end, I have to coast right down and come out of aero but can avoid braking.
Quote Reply
Re: Platypus Thread: Aero Virtual Elevation Testing Protocol [AlexS] [ In reply to ]
Quote | Reply
AlexS wrote:
In an ideal world it'd be all because of the change you made to your set up, but of course it may also be for uncontrollable things, e.g. differences in air movement (wind, traffic etc).

Well, at least with the field testing I've done, things like traffic and wind show up as inconsistencies in the VE plot from lap to lap and can thus be identified. I use a very quiet road and only do testing on low-wind days and I find the VE plot very consistent lap to lap, when an occasional car does pass I can see it as an identifiable inconsistency in that one lap and ignore that lap. I've done VE laps on windier days just as practice and the inconsistencies lap to lap and thus lack of data integrity are very clear from the VE plot.

I suppose it's possible for wind to be very consistent and introduce a systemic error that doesn't show inconsistencies lap to lap but at least where I live when there's wind there's also inconsistency. Plus wind is not something our senses can't detect, not that hard to look at the wind speed on weather underground, look at the movement in the leaves, etc. etc.

Seems to me the real challenge is being able to time your VE sessions to occur on low-wind days. I only might see 2-3 such days in a month but I have a flexible work schedule and can do my testing at a time when the road's quiet and temperature is stable, but a lot of folks don't have that flexibility.
Quote Reply
Re: Platypus Thread: Aero Virtual Elevation Testing Protocol [Tomato] [ In reply to ]
Quote | Reply
Tomato wrote:
Thanks Rob,
For an out and back how far would you aim for. I have one that is 1 mile stretch so 2 miles in total.

I have a place I can turn at each end, I have to coast right down and come out of aero but can avoid braking.

I've used out-and-backs that are about that length. I like them to be relatively short so I can do more "laps" while long enough so that I can get a wide range of speed. That is, I like to have a couple of chances to ramp slowly up to TT speed, then coast down, then ramp up again, then coast down for the turnaround. So something along the lines of a kilometer or a mile or so is about the right length. I ramp up and coast down (I soft pedal during the coast downs) on loops, too.
Quote Reply
Re: Platypus Thread: Aero Virtual Elevation Testing Protocol [tttiltheend] [ In reply to ]
Quote | Reply
tttiltheend wrote:
Well, at least with the field testing I've done, things like traffic and wind show up as inconsistencies in the VE plot from lap to lap and can thus be identified. I use a very quiet road and only do testing on low-wind days and I find the VE plot very consistent lap to lap, when an occasional car does pass I can see it as an identifiable inconsistency in that one lap and ignore that lap. I've done VE laps on windier days just as practice and the inconsistencies lap to lap and thus lack of data integrity are very clear from the VE plot.

I suppose it's possible for wind to be very consistent and introduce a systemic error that doesn't show inconsistencies lap to lap but at least where I live when there's wind there's also inconsistency. Plus wind is not something our senses can't detect, not that hard to look at the wind speed on weather underground, look at the movement in the leaves, etc. etc.

Seems to me the real challenge is being able to time your VE sessions to occur on low-wind days. I only might see 2-3 such days in a month but I have a flexible work schedule and can do my testing at a time when the road's quiet and temperature is stable, but a lot of folks don't have that flexibility.

Yeah, VE is actually a diagnostic for the estimator, not the estimator itself. What's cool about VE is that you can, as you've observed, easily see when the run was screwed up by a passing car or a gust of wind, so you can evaluate the quality of the data.
Quote Reply
Re: Platypus Thread: Aero Virtual Elevation Testing Protocol [AndyF] [ In reply to ]
Quote | Reply
AndyF wrote:
If you start getting serious about this, then invest in one of these: http://www.onetreeknoll.com/...ductCode=PI-W-4250BT

Hey Andy do you have an updated link or recommendation for this? Thanks
Quote Reply
Re: Platypus Thread: Aero Virtual Elevation Testing Protocol [kileyay] [ In reply to ]
Quote | Reply
kileyay wrote:
AndyF wrote:
If you start getting serious about this, then invest in one of these: http://www.onetreeknoll.com/...ductCode=PI-W-4250BT


Hey Andy do you have an updated link or recommendation for this? Thanks

Sorry - yes, here is what you need: https://kestrelmeters.com/...el-5100-racing-meter

Just let me know how I can help, ok?

AndyF
bike geek
Quote Reply
Re: Platypus Thread: Aero Virtual Elevation Testing Protocol [AndyF] [ In reply to ]
Quote | Reply
Thanks!
Quote Reply
Re: Platypus Thread: Aero Virtual Elevation Testing Protocol [AndyF] [ In reply to ]
Quote | Reply


Greetings Everyone,
I have been TTing for three years with good success, and now am looking for ways to try to bridge up to the elites in Northern California. I have been playing with the Aero Lab in the Golden Cheetah software and have done a few trial tests. The one I am uploading is just on a road bike, I did a hands on the hoods, and hands in the drops runs. Kept my body still, turned off all smart recordings, no coasting, no brakes. What I am curious about is the little spikes or vampire fangs in the one test. What causes that? Is it mean a bad test? Can I still use that run or should I scrap it? How can I prevent it? This was a mile loop.
Thank you very much for your help and responses.
Regards,
Robb
Quote Reply
Re: Platypus Thread: Aero Virtual Elevation Testing Protocol [Robb] [ In reply to ]
Quote | Reply
Hi Robb,

Glad to see you using Aerolab!

The problem seems to be crummy GPS data. You need to delete the Altitude column. Go to the "Edit" tab and right-click "Remove column" for Altitude. Now if you ran loops or out-and-backs, try using those symmetries to make your data make sense. Altitude gains of the same terrain should be identical if you get the Crr and CdA right.

And keep posting your results.

AndyF
bike geek
Quote Reply
Re: Platypus Thread: Aero Virtual Elevation Testing Protocol [AndyF] [ In reply to ]
Quote | Reply
Hi Andy,
Thank you for your response. I am using the v3.3 cheetah software and there is no option for me to remove the altitude on the edit tab. I can however check the constant altitude (velodrome) on the Aerolab Page, under the Air Density graph. Would that work?
Quote Reply
Re: Platypus Thread: Aero Virtual Elevation Testing Protocol [Robb] [ In reply to ]
Quote | Reply
Robb wrote:
Hi Andy,
Thank you for your response. I am using the v3.3 cheetah software and there is no option for me to remove the altitude on the edit tab. I can however check the constant altitude (velodrome) on the Aerolab Page, under the Air Density graph. Would that work?

Humour me for a sec -- can you please double-check that when you hover over the Altitude column in the Edit tab... that when you right-click it gives you "Remove column" option? Right-click is also CTRL-click (not flower-click) on a Mac.

AndyF
bike geek
Quote Reply
Re: Platypus Thread: Aero Virtual Elevation Testing Protocol [Robb] [ In reply to ]
Quote | Reply
Robb wrote:

What I am curious about is the little spikes or vampire fangs in the one test.
You mean, the little spike in the blue line about 500m into the test? That's due either to a momentary blip in either speed or power.

Where are you getting speed from? Which power meter do you have?
Quote Reply
Re: Platypus Thread: Aero Virtual Elevation Testing Protocol [AndyF] [ In reply to ]
Quote | Reply
Hi Andy,
In the edit tab, it has options to fix elevations errors and fix gps, but I don't see anything about turning off altitude.
Under the Eoffset, I can check the "constant" altitude / velodrome box.

Hi RChung,
I see the little blue spike too, I was curious about the spikes that look like vampire fangs in the green elevation bar, and was wondering if that would throw off my data.

Also, what is the Eoffset do, and should I leave the eoffset auto box checked?

I really appreciate you guys helping me go through this.

I have been racing on a 2013 CBoardman TT Bike and recently got a SWorks Shiv through my team shop. I am trying to figure out which bike is faster through the Aerolab Chung Analysis heading into our State Championships. Once I get that resolved, I plan on testing my wheels, suits and helmets to find the fastest combo.
Quote Reply
Re: Platypus Thread: Aero Virtual Elevation Testing Protocol [Robb] [ In reply to ]
Quote | Reply
Why don't you post the file link here? And don't forget to tell us all the external parameters: total mass rider + bike, air density, Crr, and what kind of power meter.

AndyF
bike geek
Quote Reply
Re: Platypus Thread: Aero Virtual Elevation Testing Protocol [AndyF] [ In reply to ]
Quote | Reply

I am going to try to upload the file.
The above picture is a run on my new Shiv.
Garmin 500 with GPS Turned off, all smart recording turned off and have a garmin speed sensor on my wheel
Shiv has a Elsa Powermeter (spider)
Total mass bike plus rider is 90 kg
Crrr set at .005
Eoffset Auto is checked on
Air Density Rho:1.2268 ( Temp 58 F, Pressure 30.03, Dew Point 47 degrees)

even with GPS turned off, I am getting the blips on the Elevation
Quote Reply
Re: Platypus Thread: Aero Virtual Elevation Testing Protocol [Robb] [ In reply to ]
Quote | Reply
Here is the file from the above run on the Shiv
Quote Reply
Re: Platypus Thread: Aero Virtual Elevation Testing Protocol [Robb] [ In reply to ]
Quote | Reply
Robb wrote:
I was curious about the spikes that look like vampire fangs in the green elevation bar, and was wondering if that would throw off my data.
Ah, I understand now. The green line just shows what your device reports as the elevation, and it seems your device jumps around a bit. However, the green line is just used as a reference and comparison -- the blue line is calculated independently so an error in the green line doesn't affect the blue line.
Quote Reply
Re: Platypus Thread: Aero Virtual Elevation Testing Protocol [RChung] [ In reply to ]
Quote | Reply
RChung wrote:
Robb wrote:
I was curious about the spikes that look like vampire fangs in the green elevation bar, and was wondering if that would throw off my data.

Ah, I understand now. The green line just shows what your device reports as the elevation, and it seems your device jumps around a bit. However, the green line is just used as a reference and comparison -- the blue line is calculated independently so an error in the green line doesn't affect the blue line.


Awesome, that makes me feel better about my tests.

What is the Eoffset, and should I leave the auto checked?

I sincerely appreciate your willingness to help.
Quote Reply
Re: Platypus Thread: Aero Virtual Elevation Testing Protocol [Robb] [ In reply to ]
Quote | Reply
Eoffset is the elevation offset. If you don't check it, at the start of your ride the blue line will begin at zero and it will show the elevation profile relative to your start point (for me, my house). I live near sea level so for me it hardly ever matters. If you have an altimeter and you live in Denver at 1600m elevation that's a big difference -- so eoffset moves the start point of the blue line up to 1600m.

[Edited to add] BTW, speaking of sea level, the air density calculator in Golden Cheetah is based on the barometric pressure at your location (aka "station pressure") not the official barometric pressure you get from the national weather service or official weather stations. The difference is that "official" barometric pressure is always standardized to sea level. So if you really live at an altitude like Denver, you have to make an adjustment for being a mile high (or 1600 meters). Since I live near sea level, station baro pressure and official baro pressure are essentially the same. This is only something to worry about if you're at altitude and you care about the exact CdA that Golden Cheetah gives you. If you're comparing two bikes, it won't matter since (presumably) you'll be using the same source for your baro pressure. The one time it might matter is if you test one bike at sea level and the other in Denver.
Last edited by: RChung: May 22, 16 18:10
Quote Reply
Re: Platypus Thread: Aero Virtual Elevation Testing Protocol [RChung] [ In reply to ]
Quote | Reply
Thank you very much for the information.
Quote Reply
Re: Platypus Thread: Aero Virtual Elevation Testing Protocol [Robb] [ In reply to ]
Quote | Reply
Yesterday I had perfect conditions for testing. I have a local business park that was completely deserted and there was zero wind. I was testing my two TT bikes, trying to determine which one I am going to race for my upcoming District TT (40K race). I have been racing on a 2013 Chris Boardman 9.8, and this year due to team sponsorship, I was able to get a 2016 Specialized Shiv for a great deal. Over two separate days of testing, I have found the Shiv CdA ranges from .226 to .236 CdA for an average of .230 (7 runs). The Boardman from .246 to .256 with an average of .252 CdA (5 runs). I am pretty confident now the Shiv is faster by avg of .022 CdA. From looking at if .003 saves 3 watts or .13 mph, I would think I am gaining approx .9 mph in speed?

I am now planning on testing skin suits, helmets, wheels and shoe covers. I really appreciate the info you share and willingness to answer questions.

Thank you,
Robb
Quote Reply
Re: Platypus Thread: Aero Virtual Elevation Testing Protocol [Robb] [ In reply to ]
Quote | Reply
Always nice when you get the right conditions. Did you test both bikes on both days? Did you have the same wheels, or tyres, or at least tyre pressures?

Also those numbers are a little high perhaps. What value were you using for Crr?

Developing aero, fit and other fun stuff at Red is Faster
Quote Reply
Re: Platypus Thread: Aero Virtual Elevation Testing Protocol [SkippyKitten] [ In reply to ]
Quote | Reply
Hi Skippy,

I was using .005 for Crr for all tests and keeping it constant for both days, I wore the same skin suit, helmet and shoes.
I used the same front and rear wheel with 100 psi in both.
So the only thing I was really looking at was the two frames and my position on each, to see which would be the fastest.

My next step now, will be determine which skin suit, helmet and wheel set is the fastest combo. Once I have those, I plan to make some final runs with lower tire pressure, shaved legs and shoe covers to see what my final CdA will be.

*** I did test both bikes on both days. I also switched the order of bikes, on the first day, I tested the boardman first, shiv second. On the second day (one with perfect conditions) I did the Shiv first, boardman second and then made a few more runs on the shiv.
Last edited by: Robb: May 30, 16 18:04
Quote Reply
Re: Platypus Thread: Aero Virtual Elevation Testing Protocol [Robb] [ In reply to ]
Quote | Reply
Robb wrote:
So the only thing I was really looking at was the two frames and my position on each, to see which would be the fastest.

Was your position the same on each (i.e. pad x/pad y/saddle height and setback/crank length)?
Quote Reply
Re: Platypus Thread: Aero Virtual Elevation Testing Protocol [Robb] [ In reply to ]
Quote | Reply
Good stuff here all around. Multiple runs of each bike, tight distribution of estimates within each bike, and the distribution of CdA estimates between either bikes don't overlap at all.

While it's clear that you have a lower CdA on the Shiv, can you say with confidence that the difference is due to the bike? ...that is, do you have the same coordinates ('fit') on both bikes? (Genuine question...)

I've been keen on doing this and have found my 'half-pipe' to do my testing on. I think your post has just given me the final push that I need to get out there and do (...I was also waiting on the weather, which is here!).
Quote Reply
Re: Platypus Thread: Aero Virtual Elevation Testing Protocol [kileyay] [ In reply to ]
Quote | Reply
We did our best to "mirror" the two bikes, i.e. saddle fore and aft, saddle height, drop from saddle to pads, crank length are the same. The only differences are the pads on the Shiv are a little closer together and the front end on the shiv is way cleaner (less cables) as we were able to do more internal routing.
Quote Reply
Re: Platypus Thread: Aero Virtual Elevation Testing Protocol [Robb] [ In reply to ]
Quote | Reply
Lots of goodness in what you're doing.

In the UK, Crr of 0.005 on the road is optimistic.

Developing aero, fit and other fun stuff at Red is Faster
Quote Reply
Re: Platypus Thread: Aero Virtual Elevation Testing Protocol [SkippyKitten] [ In reply to ]
Quote | Reply
What is the crr that you usually use?
Quote Reply
Re: Platypus Thread: Aero Virtual Elevation Testing Protocol [Robb] [ In reply to ]
Quote | Reply
On a typical UK road with good tyres: .006 upwards.

Lately I've been able to solve for CdA and Crr in most cases, but that's another story. :)

Developing aero, fit and other fun stuff at Red is Faster
Quote Reply
Re: Platypus Thread: Aero Virtual Elevation Testing Protocol [SkippyKitten] [ In reply to ]
Quote | Reply
With everyone's help and guidance, I am excited about my upcoming District Championships 40 K TT.
I feeling very confident that I will be using my fastest combo set up. Now it just comes down to power.

A couple of questions about testing...

1) I thought i read somewhere that a savings of .003 CdA is equal to about .10 mph and or 13 watts saved?
Can anyone confirm that?

2) With running laps for testing, yesterday I scrubbed several runs due to cars. The cars were coming in the opposite direction, but due to the location, they were usually traveling less than 15 mph. Did I need to stop those runs, or would even a slow moving car displace enough air to corrupt my data?

Robb
Quote Reply
Re: Platypus Thread: Aero Virtual Elevation Testing Protocol [AndyF] [ In reply to ]
Quote | Reply
Hypothetical: my rollout for my 23mm GP4000S IIs on my Zipps is 2136mm. If I were to adjust that to 1068mm and put a magnet opposite my existing magnet, could I get higher resolution speed data? At the top of my new "half-pipe" I'm usually only doing about 5mph. This lets me turn around without using the brakes.

While I've got you here:
-is there anything out there I could use to automatically start/stop my Garmin? Like some sort of a wire I could ride over that would send a start/stop signal?
-any tips for surveying a course?
Quote Reply
Re: Platypus Thread: Aero Virtual Elevation Testing Protocol [GreenPlease] [ In reply to ]
Quote | Reply
2 magnets does work. Not tried it with Garmin myself. There could be a small problem if they're not exactly a half turn apart (for speed in particular).

I can't think of anything that'll auto start stop a Garmin apart from the autolap marker. That's a geofence type thing and may not be too great for this. If you've got a GLONASS/GPS unit (510 onwards) give it a try maybe.

As for course surveying, I'm not sure what you mean. If you mean to generate a topographical map, I can get pretty good elevation plots these days. I'd love to say buy my system, but they're not for sale I'm afraid.

Developing aero, fit and other fun stuff at Red is Faster
Quote Reply
Re: Platypus Thread: Aero Virtual Elevation Testing Protocol [SkippyKitten] [ In reply to ]
Quote | Reply
I'm having a problem with my data in that the starting and ending elevations don't match and it's very annoying. I've never had this happen before. The ending elevation is consistently lower than the start elevation by about 5' and that's on a course that's barely half a mile one way. Using a Garmin Edge 1000.
Quote Reply
Re: Platypus Thread: Aero Virtual Elevation Testing Protocol [GreenPlease] [ In reply to ]
Quote | Reply
If this has just started, have you moved your Garmin? You may be getting a pressure difference with a stagnation component now.

Developing aero, fit and other fun stuff at Red is Faster
Last edited by: SkippyKitten: Dec 11, 16 23:07
Quote Reply
Re: Platypus Thread: Aero Virtual Elevation Testing Protocol [GreenPlease] [ In reply to ]
Quote | Reply
GreenPlease wrote:
Hypothetical: my rollout for my 23mm GP4000S IIs on my Zipps is 2136mm. If I were to adjust that to 1068mm and put a magnet opposite my existing magnet, could I get higher resolution speed data? At the top of my new "half-pipe" I'm usually only doing about 5mph. This lets me turn around without using the brakes.
Depends on the speed sensor and head unit you're using but, yes, it's possible to do this. First, flip from mph to km/h. For some head units this will get you a bit more resolution. Second, two magnets may limit your top end speed accuracy. Reed switches do take a little bit of time to re-open, and the original PT hub started to get wonky speed readings up above 60 mph (that's about 14 wheel revolutions per second), so if you put two magnets on one of them you might get wonky readings above 30 mph (~50 km/h). I haven't gotten above 80 km/h on my current generation of PT so I don't know if this is still the case.

Quote:
-any tips for surveying a course?
Topcon GPT-3000.
Quote Reply
Re: Platypus Thread: Aero Virtual Elevation Testing Protocol [GreenPlease] [ In reply to ]
Quote | Reply
GreenPlease wrote:
Hypothetical: my rollout for my 23mm GP4000S IIs on my Zipps is 2136mm. If I were to adjust that to 1068mm and put a magnet opposite my existing magnet, could I get higher resolution speed data? At the top of my new "half-pipe" I'm usually only doing about 5mph. This lets me turn around without using the brakes.
Yes, you can. The only thing you have to watch is if you're using 3 magnets at top speed, you might saturate the reed switches on the speed sensor.

Quote:
While I've got you here:
-is there anything out there I could use to automatically start/stop my Garmin? Like some sort of a wire I could ride over that would send a start/stop signal?
-any tips for surveying a course?

It's not necessary to mark the start/end of a lap. It becomes very clear where your lap boundaries are.

Surveying a course: there's plenty already written in this thread near the beginning of the thread.

Hey, thanks for using Aerolab and be safe!

AndyF
bike geek
Quote Reply
Re: Platypus Thread: Aero Virtual Elevation Testing Protocol [RChung] [ In reply to ]
Quote | Reply
Thanks

I consistently max out around 28mph on my short little loop so I'll give it a try :)
Quote Reply
Re: Platypus Thread: Aero Virtual Elevation Testing Protocol [AndyF] [ In reply to ]
Quote | Reply
Thanks

It just occurred to me that I updated my edge 1000 recently and that the speed preferences might be botched and it's using GPS for speed.
Quote Reply
Re: Platypus Thread: Aero Virtual Elevation Testing Protocol [GreenPlease] [ In reply to ]
Quote | Reply
GreenPlease wrote:
Thanks

I consistently max out around 28mph on my short little loop so I'll give it a try :)

Remember that the larger your speed range are, the better your results will be.

AndyF
bike geek
Quote Reply
Re: Platypus Thread: Aero Virtual Elevation Testing Protocol [GreenPlease] [ In reply to ]
Quote | Reply
GreenPlease wrote:
Hypothetical: my rollout for my 23mm GP4000S IIs on my Zipps is 2136mm. If I were to adjust that to 1068mm and put a magnet opposite my existing magnet, could I get higher resolution speed data?

Did you try this in the end?

Does it make any notable improvements in the VE data or profile?
Quote Reply
Re: Platypus Thread: Aero Virtual Elevation Testing Protocol [awenborn] [ In reply to ]
Quote | Reply
The furthest I've gotten is gluing magnets to my disc wheel haha. Hopefully this weekend I'll get to it
Quote Reply
Re: Platypus Thread: Aero Virtual Elevation Testing Protocol [GreenPlease] [ In reply to ]
Quote | Reply
Cool, well keep us posted, it sounds like a very neat idea if it can boost the quality of the data.
Quote Reply
Re: Platypus Thread: Aero Virtual Elevation Testing Protocol [AndyF] [ In reply to ]
Quote | Reply
So this weekend, I had a try at using multiple hill runs to decouple CdA and Crr as detailed on pg 43 of Robert Chung's Estimating CdA with a Power Meter presentation. The conditions weren't exactly perfect but the data that I retrieved from it look pretty decent for a first attempt, (at least to my untrained eye!). I read through this entire thread beforehand (as well as numerous other resources) and didn't see this particular protocol discussed that much, so I thought I'd share my experiences and see what you experts think!

Test conditions:
  • Test course was 1.70 km with 87.6 m elevation gain; average gradient 5.2%.
  • Rider: 5'7" (170cm) and 148 lbs (65 kg); weighed accurately with bike beforehand.
  • Collecting data with a Quarq DZero power meter, Garmin 820 and Garmin GSC-10 with GPS off.
  • Riding road bike on the hoods (i.e. typical climbing position), held the same position for all runs.
  • Tight fitting winter clothing.
  • Winds conditions were extremely favourable; essentially windless and well sheltered.
  • Road surface conditions were typically British, slightly rough chip-seal and wet surface.
  • Running 25mm GP4000s IIs with latex tubes @80 PSI.
  • The first two runs each had a couple of instances of car-passing but because of the hill, the speed differential was low and they passed relatively wide (~1.5m).
As a quick summary, I did four consecutive runs, alternating high-speed/low-speed/high-speed/low-speed; the high-speed runs were @285W (~21 kph) and the low-speed runs were @200W (~15 kph). I calculated the Virtual Elevation from these data in Excel and when I put in what I thought would be reasonable CdA and Crr values there was a clear separation of the high-speed vs low-speed runs, but each equivalent run aligned pretty well. I adjusted the CdA until the four runs aligned as best I could and then I adjusted the Crr to match the known elevation gain of the climb. The resultant VE profile for the four runs looked like this:


Before tweaking CdA and Crr values (CdA = 0.350, Crr = 0.0060):
Click to enlarge.




After tweaking CdA and Crr values (CdA = 0.218, Crr = 0.0084):
Click to enlarge.


Apologies for the picture quality of the graphs; I could make the lines thicker and more visible, but then they all just obscure each other.


The striking thing is that the CdA seems way too low and the Crr seems somewhat high; I guess I have a few questions that I was wondering if you guys could share some experiences on:
  1. First and foremost, was the speed differential in these runs (15 vs 21 kph) sufficient for this kind of testing? I could've hammered the fast runs harder but wanted to focus on maintaining a consistent and stable position.
  2. Were the instances of car passing likely to have ruined the data from the first two runs? I tried just analysing the second two runs (which were cleaner in this regard) and whilst the profiles aligned much more closely, the resultant CdA and Crr values were very similar to above.
  3. How much rolling resistance could you expect a wet road surface to add compared to a dry one?
  4. Does tweaking the "known" elevation gain of the hill only affect the calculated Crr? The CdA is determined by the alignment of the runs at differing speeds, right?
  5. I haven't accounted for drivetrain power losses downstream of the Quarq at all; how significant might this be? What might be a good way to account for this, a fixed value of power loss (e.g. subtract 10 Watts), a fixed-percentage reduction in power values (e.g. multiply by 95%) or something else?
  6. What other factors might have produced an artificially low CdA and high Crr?
I'm sure I can improve on this given experience and better conditions, but I thought I'd see if you guys can help me work out where my biggest sources of error are coming from.

I really appreciate all the hard work that you guys (Andy Froncioni, Robert Chung and Alex Simmons in particular!) have put in to developing these methods and especially for documenting them in such an easy to digest and replicate fashion. Thanks!
Last edited by: awenborn: Dec 20, 16 2:52
Quote Reply
Re: Platypus Thread: Aero Virtual Elevation Testing Protocol [awenborn] [ In reply to ]
Quote | Reply
awenborn wrote:
The resultant VE profile for the four runs looked like this:


Before tweaking CdA and Crr values (CdA = 0.350, Crr = 0.0060):
Click to enlarge.




After tweaking CdA and Crr values (CdA = 0.218, Crr = 0.0084):
Click to enlarge.



Apologies for the picture quality of the graphs; I could make the lines thicker and more visible, but then they all just obscure each other.


The striking thing is that the CdA seems way too low and the Crr seems somewhat high; I guess I have a few questions that I was wondering if you guys could share some experiences on:
  1. First and foremost, was the speed differential in these runs (15 vs 21 kph) sufficient for this kind of testing? I could've hammered the fast runs harder but wanted to focus on maintaining a consistent and stable position
  2. Were the instances of car passing likely to have ruined the data from the first two runs? I tried just analysing the second two runs (which were cleaner in this regard) and whilst the profiles aligned much more closely, the resultant CdA and Crr values were very similar to above.
  3. How much rolling resistance could you expect a wet road surface to add compared to a dry one?
  4. Does tweaking the "known" elevation gain of the hill only affect the calculated Crr? The CdA is determined by the alignment of the runs at differing speeds, right?
  5. I haven't accounted for drivetrain power losses downstream of the Quarq at all; how significant might this be? What might be a good way to account for this, a fixed value of power loss (e.g. subtract 10 Watts), a fixed-percentage reduction in power values (e.g. multiply by 95%) or something else?
  6. What other factors might have produced an artificially low CdA and high Crr?
I'm sure I can improve on this given experience and better conditions, but I thought I'd see if you guys can help me work out where my biggest sources of error are coming from.

I really appreciate all the hard work that you guys (Andy F, Robert Chung and Alex Simmons in particular!) have put in to developing these methods and especially for documenting them in such an easy to digest and replicate fashion. Thanks!

First, congratulations on your first aero test! It takes a bit of work and, as you found out, quite a lot of reading. And thanks for being so clear about your protocol.

1. Yes, that was a very small range of speeds. You could do better with a factor of 2 speed range.

2. Any passing cars will upset your CdA estimate. Anything up to 15m in front of you or 6m to the side will have a big impact. It then depends on how long they stayed near you.

3. Most slightly wet surfaces exhibit a lower Crr than dry ones. However my experience with British chip seal in wet weather is limited. Still, I would expect no more than a Crr of 0.006.

4. I don't know what you mean by tweaking the known elevation gain. Could you elaborate, please? May I suggest turning your 1-way course into an out-and-back by turning around (safely!!) at the top of the hill? This would allow you to elevate-mate the up and down segments.

5. When you don't know, use 0.975. :-)

6. A high Crr estimate will artificially produce a low CdA. So I would start by trying to make the curves match by using a guessed Crr of 0.005. See how good a CdA estimate you can get from the data you have.

AndyF
bike geek
Quote Reply
Re: Platypus Thread: Aero Virtual Elevation Testing Protocol [awenborn] [ In reply to ]
Quote | Reply
Good work! I'd be very chuffed if my first attempts had been half as good as that. You're doing the right thing in learning what works test wise now.

Just to add to what Andy wrote, and with experience of British chip seal (unfortunately). Crr can be up around 0.006 in the dry. I've not looked at the effects of damp though.

Definitely go for out and back. A headwind or tailwind (even a barely noticible one) will affect you on single direction runs.

Where the heck in the UK were drivers giving you 1.5m clear space?! ;) you should see lumps and bumps from cars passing on the VE plot that would step it away from the true elevation plot.

Developing aero, fit and other fun stuff at Red is Faster
Quote Reply
Re: Platypus Thread: Aero Virtual Elevation Testing Protocol [ In reply to ]
Quote | Reply
Thanks for the replies guys, that's all very helpful info!

So, I just had a quick play with reducing the power values by 2.5% to account for drivetrain efficiency and this immediately brings the Crr down to something slightly more realistic (0.0069). What kind of values are typical for drivetrain efficiency? This test was on my dirty winter road bike, so I'd guess that it'd be at the higher-end of typical losses; would a value of 3, 4 or 5% still be realistic? It certainly makes me think I should give it a good clean and service!

Unfortunately on this course it's not really possible to make this loop an out-and-back, I could turn at the top easily enough, but descending without braking would be a bit sketchy on that long 8-10% stretch in the middle, given the layout of the road. I'm definitely going to give the halfpipe protocol a try next time round; I tried to do some runs on a looped-section after these runs, but quickly found out that my chosen loop had a corner on a short downhill section and it was very tough to take it without using the brakes or changing position. I'll find a more suitable testing ground and give it another shot as soon as I can.

To be honest, I'm surprised I picked up a differential at all between the slow and fast runs because, as you say, 15 vs 21 kph isn't a huge range and even at the top end, that's not the kind of speed where I would be particularly concerned about staying aero although perhaps I should be!
Quote Reply
Re: Platypus Thread: Aero Virtual Elevation Testing Protocol [awenborn] [ In reply to ]
Quote | Reply
That all sounds right, awenborn.

Whatever you do, please be safe! We appreciate your excellent documentation skills and would miss you if you got hurt.

AndyF
bike geek
Quote Reply
Re: Platypus Thread: Aero Virtual Elevation Testing Protocol [awenborn] [ In reply to ]
Quote | Reply
awenborn wrote:

So, I just had a quick play with reducing the power values by 2.5% to account for drivetrain efficiency and this immediately brings the Crr down to something slightly more realistic (0.0069). What kind of values are typical for drivetrain efficiency? This test was on my dirty winter road bike, so I'd guess that it'd be at the higher-end of typical losses; would a value of 3, 4 or 5% still be realistic? It certainly makes me think I should give it a good clean and service!

First off, that was a fantastic first attempt!

It's impressive that you were able to pry apart the (CdA, Crr) pairs with that small differential in speed. I don't usually do one-way hill climbs to separate CdA and Crr but when I came up with this protocol I think I did something like a 50% spread in speed and got pretty good matching.

Your Crr estimate will definitely depend on getting the exact total elevation change nailed. Crr scales exactly like slope, so being off by 1 m in total elevation on a 1km hill will mean an error in Crr of .001. Fortunately in my case, I had a USGS topo map (the equivalent of your ordnance maps) with verified benchmarks that had the exact altitude at two points, so I knew the true gain. This is a situation where GPS altitude definitely isn't good enough.

I came up with this version of the protocol to deal with situations where one couldn't find an appropriate (=safe) out-and-back. One nice thing about "twice up the same hill at different powers" is that you can sometimes find a wind-sheltered hill more easily than a wind-sheltered flat or half-pipe venue. As always, you want to find a place where you can do this safely, without interference from cars, so this variant expands the number of places you can test.

I would think 2.5% drive train loss for a dirty chain is on the low end.

Glad you tried this! Some people think that one can't use VE to pry apart the (CdA, Crr) parameters, but it's just math and experimental technique. If you can nail down the exact elevation change (and your speed and power sensors are accurate and precise) then things will work.
Last edited by: RChung: Dec 19, 16 12:47
Quote Reply
Re: Platypus Thread: Aero Virtual Elevation Testing Protocol [awenborn] [ In reply to ]
Quote | Reply
awenborn wrote:
So this weekend, I had a try at using multiple hill runs to decouple CdA and Crr as detailed on pg 43

BTW, when I do this, I use the approach I mention near the bottom of page 70. In your case, since you made four runs you'd end up with four equations and two unknowns (CdA and Crr), which you could solve in one of the usual ways. A nice thing about this is that you can then do sensitivity analysis to see how much a difference in the drive train loss of 1% (from 2.5% to 3.5%) makes in the estimates, or a small difference in the total climb (from 87.6m to 87 or 88m), or a 1 kg difference in mass. I usually found that small differences in these variables affected Crr more (in percentage terms) than CdA so I really had to know the change in elevation pretty well, and weigh myself and the bike carefully. I use a Power Tap so I don't have to worry about drive train losses.
Quote Reply
Re: Platypus Thread: Virtual Elevation Protocol [jbank] [ In reply to ]
Quote | Reply
jbank wrote:
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 ;)

We consider it an upside to be sharing testing protocols. :-) Thank you for doing it!

AndyF
bike geek
Quote Reply
Re: Platypus Thread: Aero Virtual Elevation Testing Protocol [AndyF] [ In reply to ]
Quote | Reply
i have read through all 11 pages but still have a few questions. I have a couple of potential courses picked out, 2 of which are loops and 2 are out and backs. Is there any way to do this with wind? Living in Oklahoma there is only about one day a month without 10-15 mph winds. I get the part about doing multiple loops for one session. The part I am not clear on is varying the speed. Do you vary the speed by each loop or within the loop? I am guessing within each loop so speed/power will be varying through the entire run of say 5 loops for 1 session. My next question with knowing the answer to the previous is, after an equipment change for example, you do not have to match the speed/power variations with the previous run correct? You just do another series of 5 loops for the one session but the course needs to match the exact same as the previous run? Sorry if these seem like common sense answers. I am trying to learn about this as I go and want to make sure I am interpreting the test measures correctly.
Quote Reply
Re: Platypus Thread: Aero Virtual Elevation Testing Protocol [LSchmitt] [ In reply to ]
Quote | Reply
Wind is tricky, so I will let the more knowledgeable people answer that.

The Chung method uses "virtual" elevation, so what you are doing is calculating what the elevation change has to be. For example, if you are doing 250 watts on the flats at 26 mph, but you hold 250 watts and slow down to 20 mph, the physics of the system says you must have been going up a hill. The equations take all the known inputs to the system (weight, power, rolling resistance, air density,..) and determines the elevation change for any CdA value. On each lap your net elevation gain is 0. Repeat this 5 or so times and you just choose the slider values that says you started and ended at the same elevation.

You don't have to vary your power output at the same place each lap I do easy laps and hard laps. My one suggestion would be to not go too easy or too hard. Going super hard might cause you to change position you can have an uneven cadence if you are coasting down hills. You are looking to hold a consistent position and make the route you ride as consistent as possible.
Quote Reply
Re: Platypus Thread: Aero Virtual Elevation Testing Protocol [LSchmitt] [ In reply to ]
Quote | Reply
Hi LSchmitt,

Wow, you read through everything? You are very diligent -- that'll come in handy.

The best way to vary speed is by choosing a course with a little elevation. A speed range of 3-5 m/s is usually enough.

What to do with wind, huh? Well, if you have an out-and-back you can assume the wind is the same going out as coming back (ie. that headwind reverses sign on the way back). And then you can add a "headwind" column in the Editor tab and insert whatever you think the wind might've been. When the elevation is right, you have the right headwind.

I'd also try to keep as much the same as possible. Same course until you can reproduce a CdA that makes sense 4 or 5 times on different occasions.

AndyF
bike geek
Quote Reply
Re: Platypus Thread: Aero Virtual Elevation Testing Protocol [LSchmitt] [ In reply to ]
Quote | Reply
Reading all this is quite an effort, but the right thing to do to get useful results. Andy beat me to it with the 'headwind' column in GC, as he should as he wrote it.

If you can find a course that's out and back or a long racetrack shape where the wind is predominantly along the long bit that'll help too. Just so you know, it's not really headwind, it's air so you don't have to factor in the bike's ground speed.

Developing aero, fit and other fun stuff at Red is Faster
Quote Reply
Re: Platypus Thread: Aero Virtual Elevation Testing Protocol [RChung] [ In reply to ]
Quote | Reply
RChung wrote:
If you're getting air pressure from an official weather station it's usually standardized to sea level. If you're getting air pressure from a local source it can sometimes be "station pressure" so it's not.

If you're on an island in the Channel you probably don't have to worry too much about the difference.

Not replying to anyone in particular, but just wanted to ask a bit more about discussion on page 5 regarding sources of weather data. Has anyone ever attempted to obtain data from on-sight, perhaps from a DIY mobile weather station (raspberry pi or otherwise)?

When I'm analyzing my races I sometimes have difficulty finding atmospheric pressure and dew point from a source that is reasonably nearby. Further, one course in particular is often very much in the wind but I'm unsure how accurate the wind data I get from those same sources that aren't on-site. I've considered building my own weather station that I'd set up at a race or during my testing protocol but wasn't sure if anyone has attempted this before and if it worked well. Or should I continue using the data I'm not too confident in?
Quote Reply
Re: Platypus Thread: Aero Virtual Elevation Testing Protocol [racehd] [ In reply to ]
Quote | Reply
The easiest thing would be to buy a weather station. They're pretty good for Rho, and ok for wind speed. Not that published weather stations also normalise wind speed to a set height so its lower than reported at 'bike height'. (Wind speed gradient). Some of the stations out there will display Rho for you. E.g. Kestrel 5100.

Some of us may have tried building weather stations for this purpose. I would suggest that it's a lot easier to buy one.

Developing aero, fit and other fun stuff at Red is Faster
Quote Reply
Re: Platypus Thread: Aero Virtual Elevation Testing Protocol [SkippyKitten] [ In reply to ]
Quote | Reply
Thanks for the tip. I had considered a bought weather station but wasn't sure how great they would be for this purpose. I'll give them some more consideration. The DIY method was more of an idea for a summer project in what little free time I have these days.
Quote Reply
Re: Platypus Thread: Aero Virtual Elevation Testing Protocol [SkippyKitten] [ In reply to ]
Quote | Reply
SkippyKitten wrote:
Not that published weather stations also normalise wind speed to a set height so its lower than reported at 'bike height'. (Wind speed gradient).

i thought that reported winds are at 5m and are typically higher than what is experienced at bike height. am i mistaken?
Quote Reply
Re: Platypus Thread: Aero Virtual Elevation Testing Protocol [tetonrider] [ In reply to ]
Quote | Reply
I think they're at 10m.

I have a Kestrel 5100, which reports rho. The wind meter doesn't read quite as low as I'd like (sometimes it says there's 0 wind when I can feel a tiny breeze) but it's still pretty handy.
Quote Reply
Re: Platypus Thread: Aero Virtual Elevation Testing Protocol [RChung] [ In reply to ]
Quote | Reply
Correct, 10 meters.
Quote Reply
Re: Platypus Thread: Aero Virtual Elevation Testing Protocol [tetonrider] [ In reply to ]
Quote | Reply
10m normally.

I re-read what I wrote and I can see that it's easy to misinterpret. Sorry. The reported wind speed will be higher than the wind speed at bike height.

Developing aero, fit and other fun stuff at Red is Faster
Quote Reply
Re: Platypus Thread: Aero Virtual Elevation Testing Protocol [RChung] [ In reply to ]
Quote | Reply
RChung wrote:
I think they're at 10m.

I have a Kestrel 5100, which reports rho. The wind meter doesn't read quite as low as I'd like (sometimes it says there's 0 wind when I can feel a tiny breeze) but it's still pretty handy.
I think the Kestrels require at least 0.6m/s to record an air speed value. That's pretty significant in terms of power demand, ~20-25W.

http://www.cyclecoach.com
http://www.aerocoach.com.au
Quote Reply
Re: Platypus Thread: Aero Virtual Elevation Testing Protocol [AlexS] [ In reply to ]
Quote | Reply
AlexS wrote:

I think the Kestrels require at least 0.6m/s to record an air speed value. That's pretty significant in terms of power demand, ~20-25W.
The "operating range" of wind speed is 0.6 m/s and up, but I think (?) I've seen values below 0.6. I don't know how accurate the sensor is below 0.6, though.

In track & field, the maximum wind for a legal record is 2.0 m/s. Since I started thinking about bicycle aerodynamics I've come to realize how windy that is.
Quote Reply
Re: Platypus Thread: Aero Virtual Elevation Testing Protocol [RChung] [ In reply to ]
Quote | Reply
Total newbie question here, but.... lower on the Aerolab graph is "better" CdA, correct? For example, this run would be higher CdA at the start, then it got better, then worse again? Or do I have that backwards? Thanks.


Quote Reply
Re: Platypus Thread: Aero Virtual Elevation Testing Protocol [2wheels] [ In reply to ]
Quote | Reply
2wheels wrote:
Total newbie question here, but.... lower on the Aerolab graph is "better" CdA, correct? For example, this run would be higher CdA at the start, then it got better, then worse again? Or do I have that backwards? Thanks.


You can answer your own question by moving the CdA slider to see what impact it has on the section where VE trends down and where it trends upwards. IOW adjust it so that the other sections (series of laps) are "levelled out".

Keep in mind that depending on what you did (or didn't do) this is telling you the difference in apparent CdA between those sections of the ride. What actually caused the plot to head one way or another could be various things besides a change in CdA.

http://www.cyclecoach.com
http://www.aerocoach.com.au
Quote Reply
Re: Platypus Thread: Aero Virtual Elevation Testing Protocol [2wheels] [ In reply to ]
Quote | Reply
Downsloping = 'faster',or as Alex points out,'might be 'faster.

I did some testing today and found that one bike was way slower than the other, to discover that the rear brake housing was too short and pulling brake on ,ever so slightly as a I cornered,which I happened to be doing a lot of.

I have found a great venue but it requires riding in quite tight circles,and it seems that the CRR goes up a lot as the speed increases,It is not cambered.
I'm struggling to work out if there is a formula I can apply for test sessions done at different speeds.
Does anyone have any rules of thumb?
Quote Reply
Re: Platypus Thread: Aero Virtual Elevation Testing Protocol [kevinkeegan] [ In reply to ]
Quote | Reply
Tight corners can be a bit like braking: noticible but tricky to account for. How long are the corners? One simple option is exclude them, if you can.

Developing aero, fit and other fun stuff at Red is Faster
Quote Reply
Re: Platypus Thread: Aero Virtual Elevation Testing Protocol [kevinkeegan] [ In reply to ]
Quote | Reply
I think most peoples instinct is to carry as much speed as possible from a natural race mindset. I've found that coasting to a near crawl in the turnarounds helps produce nice, consistent results.
Quote Reply
Re: Platypus Thread: Aero Virtual Elevation Testing Protocol [SkippyKitten] [ In reply to ]
Quote | Reply
I can't remove corners as I follow a ~130m oval,which I estimate has two 25 metre straights and and a turn radius of ~13 metres,so a lot of turning.
The height of the 'hills' on the aerolab plot goes up by over 50%from a very low speed(say 8kmh) to the speed I can do consistently(~28kmh)

The location is great as I can almost eliminate wind,but am madly frustrated by the apparent altering crr with harder cornering.

If I want to tease out smaller cda changes ,then I need to go faster.....
Quote Reply
Re: Platypus Thread: Aero Virtual Elevation Testing Protocol [kevinkeegan] [ In reply to ]
Quote | Reply
so this is how the plot looks like as I change speed but keep position.
The difference in drag seems way in excess of what you would expect due to extra G force.
Does this imply lots of extra rolling resistance due to increased tyre slip angle?
the numbers after speed show the CRR i'd have to choose to level those sections up,with CDA remaining static,but as the speed drops the crr number looks totally unrealistic(ie a CRR of 0.00005 won't level the plot at 20.3kph)
Quote Reply
Re: Platypus Thread: Aero Virtual Elevation Testing Protocol [kevinkeegan] [ In reply to ]
Quote | Reply
kevinkeegan wrote:
so this is how the plot looks like as I change speed but keep position.
The difference in drag seems way in excess of what you would expect due to extra G force.
Does this imply lots of extra rolling resistance due to increased tyre slip angle?
the numbers after speed show the CRR i'd have to choose to level those sections up,with CDA remaining static,but as the speed drops the crr number looks totally unrealistic(ie a CRR of 0.00005 won't level the plot at 20.3kph)

Is this a running track, by chance? If so...what's the surface material?

http://bikeblather.blogspot.com/
Quote Reply
Re: Platypus Thread: Aero Virtual Elevation Testing Protocol [Tom A.] [ In reply to ]
Quote | Reply
No,it's a pretty nice smooth 'tarmac' surface( in a part underground car park,so low wind conditions)
The surface is also very flat,with no discernible camber.My phone suggests under 1 degree slope.

As I go faster ,I obviously have to lean more ( so my CoM is travelling a smaller distance),but I try to keep on the (imaginary) blue line.

I see earlier in the thread that AndyF said ignoring cornering effects (for a velodrome)would overestimate crr and underestimate cda by 2-3%.My data seems way different.

Any ideas(could it be bearing related,or my wheel rubbing brakes on leaning?)?
The same effect is noted with two different powertap wheels and different frames
Quote Reply
Re: Platypus Thread: Aero Virtual Elevation Testing Protocol [kevinkeegan] [ In reply to ]
Quote | Reply
kevinkeegan wrote:
No,it's a pretty nice smooth 'tarmac' surface( in a part underground car park,so low wind conditions)
The surface is also very flat,with no discernible camber.My phone suggests under 1 degree slope.

As I go faster ,I obviously have to lean more ( so my CoM is travelling a smaller distance),but I try to keep on the (imaginary) blue line.

I see earlier in the thread that AndyF said ignoring cornering effects (for a velodrome)would overestimate crr and underestimate cda by 2-3%.My data seems way different.

Any ideas(could it be bearing related,or my wheel rubbing brakes on leaning?)?
The same effect is noted with two different powertap wheels and different frames

OK...never mind then.

I did some trials once on the HS running track, which has a "cushy" surface. There were some weird non-linear effects on Crr with varying speed...which makes sense, if you think about it.

http://bikeblather.blogspot.com/
Quote Reply
Re: Platypus Thread: Aero Virtual Elevation Testing Protocol [Tom A.] [ In reply to ]
Quote | Reply
Could my graph shape be to do with non linear crr?
this image below shows this for cars ( I don't know the provenance)
it looks more linear at higher pressures and between 40 & 100 kmh.
Not fantastically relevant to most STers,but could this affect estimates of power required to climb steep hills?

Quote Reply
Re: Platypus Thread: Aero Virtual Elevation Testing Protocol [kevinkeegan] [ In reply to ]
Quote | Reply
kevinkeegan wrote:
so this is how the plot looks like as I change speed but keep position.

The difference in drag seems way in excess of what you would expect due to extra G force.
Does this imply lots of extra rolling resistance due to increased tyre slip angle?
the numbers after speed show the CRR i'd have to choose to level those sections up,with CDA remaining static,but as the speed drops the crr number looks totally unrealistic(ie a CRR of 0.00005 won't level the plot at 20.3kph)

Factors that will change with speed on the curves
  • Locus of body with lean. Either body takes a shorter route or your wheels take a longer route as you compensate. Either way, you have some "interesting" speed adjustment factors to implement. Your data input is wheel speed?
  • Apparent yaw angle, even in still air.
  • Rolling radius of tyre may vary with lean angle? Nothing as severe as a MotoGP bike, but maybe something
  • Crr change due to lateral forces
  • Crr change due to road speed. Think the variation in the car tyre chart is to do with the carcass deflection at contact point failing to return to nearasdammit round by the next rotation, this would surely be less on a bike tyre at much lower speeds
I'm lacking in maths here - the magnitude of the change is shown by the curvature (change in slope) of the trace, not the slope? It appears to change less at higher speeds, though the speed itself does not ramp so fast as the test distance increases. Odd that it appears almost flat at 16.4 as well as 29.5
From a protocol aspect, is it better to test slow to fast, or fast to slow? Gut reaction says it would be easier not to change position going fast to slow, though the whole speed range isn't physically taxing here. Are you cornering comfortably at the higher end of the speed range?
Which way do you have to trade CdA vs Crr to get a flattened trace?
Last edited by: dontswimdontrun: Sep 24, 17 5:38
Quote Reply
Re: Platypus Thread: Aero Virtual Elevation Testing Protocol [dontswimdontrun] [ In reply to ]
Quote | Reply
I've run the average speed and watts per interval thru a calculator
this one:https://www.gribble.org/...g/power_v_speed.html
and the numbers make sense from 25kmh upwards ie,at the parameters on the GC screenshot-all give CdA ~.325-.330
below that speed the CdA needs to be massively reduced to make it add up,ie I'm getting too much speed for my watts.

So .I am guessing,-a) different CdA and/or Crr at low speed,or more likely(?) the (wired) PT is overreporting watts
I have ignored centripetal force and centre of mass travelling a shorter course so far,as these are much smaller effects.
AndyF has reported somewhere,if you ignore these effects ( in a velodrome)you'll mis-estimate by 2-3%.

I do have another (wireless ) PT ,so can try again with that wheel,and was thinking of doing some tests with my trainer at varying speeds to see if Crr is linear.
Quote Reply
Re: Platypus Thread: Aero Virtual Elevation Testing Protocol [kevinkeegan] [ In reply to ]
Quote | Reply
kevinkeegan wrote:
Could my graph shape be to do with non linear crr?
this image below shows this for cars ( I don't know the provenance)
it looks more linear at higher pressures and between 40 & 100 kmh.
Not fantastically relevant to most STers,but could this affect estimates of power required to climb steep hills?

Doubtful. Most references for bicycle tires over typical speed ranges show basically no speed dependence.

Car tires have a significantly different construction than bicycle tires.

http://bikeblather.blogspot.com/
Quote Reply
Re: Platypus Thread: Aero Virtual Elevation Testing Protocol [AndyF] [ In reply to ]
Quote | Reply
Hi, just wondering if there was a consensus on whether there is any difference in using a wheel-magnet based speed sensor (e.g. a GSC-10) vs a hub-based accelerometer one (e.g. the newer Garmin ones)?

I thought I'd read somewhere that magnet ones were preferable but I'd rather avoid shifting my GSC-10 around between bikes if possible. Thanks!
Quote Reply
Re: Platypus Thread: Aero Virtual Elevation Testing Protocol [awenborn] [ In reply to ]
Quote | Reply
The hub based ones are not precise enough for VE testing.
Quote Reply
Re: Platypus Thread: Aero Virtual Elevation Testing Protocol [GreenPlease] [ In reply to ]
Quote | Reply
GreenPlease wrote:
The hub based ones are not precise enough for VE testing.

Genuine question, is there anything to back up that statement?
Quote Reply
Re: Platypus Thread: Aero Virtual Elevation Testing Protocol [dangle] [ In reply to ]
Quote | Reply
dangle wrote:
GreenPlease wrote:
The hub based ones are not
precise enough for VE testing.


Genuine question, is there anything to back up that statement?


Have a look at the plots here:
https://www.dcrainmaker.com/2014/05/garmins-spd-cad-magnetless-sensors.html


And this sentence:
"So would I recommend the speed sensor from a data standpoint? For most riders, they realistically won’t likely even notice the noise. Ultimately it’s giving you the basically same speed (albeit with a bit of noise that’s barely noticeable), and it’s giving you basically the same distance. But really for most folks would use GPS outside anyway, so it’s really just indoor training where you might be using some sort of app that utilizes speed.
But there are some use cases where I wouldn’t recommend it. For example, if doing aero testing (such as with Alphamantis), this speed sensor would be a nightmare and skew the data too much. Same goes for any other scenario that relies on incredibly clean and high fidelity speed sensor data. If you’ve never put those words together in the same sentence before, then you likely don’t fall into that camp. Also of note is that I haven’t done any mountain biking. While the cobbles I do have can throw a wrench in things, so can rocks and stumps. So just keep that in mind if you’re looking to go on trails instead."

You have so much other unknowns to control/check that you will not take the risk of using magnetless speed sensor or GPS speed. Use magnet speed sensor. And wired sensors would be even better.

Blog | Twitter| Bike CdaCrr app
Last edited by: bugno: Sep 25, 17 14:00
Quote Reply
Re: Platypus Thread: Aero Virtual Elevation Testing Protocol [dangle] [ In reply to ]
Quote | Reply
I'm not expert. I read your question and did a bit of research because I'm interested in doing some testing and I have the magnetless speed sensor.


I found these three paragraphs at the end of the Speed sensor section on DCR's review for the new sensors in 2014 (link below).



Quote:
So would I recommend the speed sensor from a data standpoint? For most riders, they realistically won’t likely even notice the noise. Ultimately it’s giving you the basically same speed (albeit with a bit of noise that’s barely noticeable), and it’s giving you basically the same distance. But really for most folks would use GPS outside anyway, so it’s really just indoor training where you might be using some sort of app that utilizes speed.

But there are some use cases where I wouldn’t recommend it. For example, if doing aero testing (such as with Alphamantis), this speed sensor would be a nightmare and skew the data too much. Same goes for any other scenario that relies on incredibly clean and high fidelity speed sensor data. If you’ve never put those words together in the same sentence before, then you likely don’t fall into that camp. Also of note is that I haven’t done any mountain biking. While the cobbles I do have can throw a wrench in things, so can rocks and stumps. So just keep that in mind if you’re looking to go on trails instead.

Like anything else, it appears to be a balance between convenience and accuracy. If you want super-high accuracy – go with the magnet. But for most folks, it’ll likely be a wash.


https://www.dcrainmaker.com/2014/05/garmins-spd-cad-magnetless-sensors.html


Not sure if this also applies to Aerolab testing.


Sounds like a bit of a bummer. I may have to dig up my old GSC-10.
Quote Reply
Re: Platypus Thread: Aero Virtual Elevation Testing Protocol [dangle] [ In reply to ]
Quote | Reply
dangle wrote:
GreenPlease wrote:
The hub based ones are not precise enough for VE testing.


Genuine question, is there anything to back up that statement?

Yup, check out DCR's review and look at the speed data. It's not off by much but it's off by enough to screw up a VE test.
Quote Reply
Re: Platypus Thread: Aero Virtual Elevation Testing Protocol [dangle] [ In reply to ]
Quote | Reply
dangle wrote:
GreenPlease wrote:
The hub based ones are not precise enough for VE testing.


Genuine question, is there anything to back up that statement?


Thanks for the replies. I had just been a hardcore lurker in this thread until today. I really only care about A:B testing, so it's precision that I'm after vs. accuracy. After perfectly matching two B runs last week, I was feeling good until seeing these links. Thanks for contributing to a great thread.

Edit: The DCR link above also said that he was using it on a big Powertap hub (transmitting it's own info) and Saris/Cycleops said that it was likely causing interference. DCR said he would have an update in the Edge 1000 review after trying it on a different wheel. I clicked over to that and the speed sensor data is WAY cleaner and he said he had no problems recommending it now. The exact page is here. The exact text is below:

********************

In my initial testing in my earlier post I saw some oddities with speed and noisiness of the data using the new sensor, compared to traditional magnet-based sensors. Garmin did some poking and believed it was due to the new sensor being installed on a PowerTap hub, which they believe may have introduced some electronic interference. So instead, I moved it to both a different wheelset, as well as to the front wheel. In doing so, here’s the data I saw on about a 90 minutes or so ride:

(Note: Data is in wheel rotations, in order to ensure everything matches exactly, it’s not in precise speed which is simply a function of the wheel circumference)
Here’s a smaller section (1,000 to 1,800) zoomed in:

And, zoomed in one step further (250-500 of the above chart):

As you can see, it’s far cleaner now, and I’d have no problems recommending it.
*************
This would lead me to believe that there's no reason the magnetless sensor wouldn't work. Or more accurately, it may invalidate the reasons above against using the magnetless sensor.
Last edited by: dangle: Sep 25, 17 14:31
Quote Reply
Re: Platypus Thread: Aero Virtual Elevation Testing Protocol [dangle] [ In reply to ]
Quote | Reply
dangle wrote:
dangle wrote:
GreenPlease wrote:
The hub based ones are not precise enough for VE testing.


Genuine question, is there anything to back up that statement?


Thanks for the replies. I had just been a hardcore lurker in this thread until today. I really only care about A:B testing, so it's precision that I'm after vs. accuracy. After perfectly matching two B runs last week, I was feeling good until seeing these links. Thanks for contributing to a great thread.

Edit: The DCR link above also said that he was using it on a big Powertap hub (transmitting it's own info) and Saris/Cycleops said that it was likely causing interference. DCR said he would have an update in the Edge 1000 review after trying it on a different wheel. I clicked over to that and the speed sensor data is WAY cleaner and he said he had no problems recommending it now. The exact page is here. The exact text is below:

********************
...
And, zoomed in one step further (250-500 of the above chart):

As you can see, it’s far cleaner now, and I’d have no problems recommending it.
*************
This would lead me to believe that there's no reason the magnetless sensor wouldn't work. Or more accurately, it may invalidate the reasons above against using the magnetless sensor.

Indeed, thanks for pointing out. I would check nevertheless the data from any magnetless sensor to see if it is noisy or not (because of interference or vibration) if I used one...

Blog | Twitter| Bike CdaCrr app
Quote Reply
Re: Platypus Thread: Aero Virtual Elevation Testing Protocol [bugno] [ In reply to ]
Quote | Reply
Thanks for all the replies.

Perhaps I'll give it a try using both a GSC-10 and a hub-based one, connected to different head units and compare the data.

GreenPlease, did you ever try out your double wheel-magnet idea in the end and did it improve the data notably?

I've finally found a good half-pipe location, so I'm hoping to do a good bit of testing over the off-season, just need some calm weather now!
Quote Reply
Re: Platypus Thread: Aero Virtual Elevation Testing Protocol [awenborn] [ In reply to ]
Quote | Reply
Yes I did try it out. Did it improve the data? Eh... not really. It's probably not worth doing tbh.
Quote Reply
Re: Platypus Thread: Aero Virtual Elevation Testing Protocol [AndyF] [ In reply to ]
Quote | Reply
 
Did a Chung test with 3 different configurations today (intervals 2, 4, and 6). Air density was 1.212. Road was chipseal. I'm guessing Crr of .005.

Can anyone comment on whether this data is clean enough to draw conclusions from? And if so, what? I usually have better data, but today there was an occasional tuft of wind.


-- jens

My latest book: "Out of the Melting Pot, Into the Fire" is on sale on Amazon and at other online and local booksellers
Quote Reply
Re: Platypus Thread: Aero Virtual Elevation Testing Protocol [jens] [ In reply to ]
Quote | Reply
Just quick-and-dirty look, but that look sez the middle interval had lower overall drag.

I can take a longer look tomorrow.
Quote Reply
Re: Platypus Thread: Aero Virtual Elevation Testing Protocol [jens] [ In reply to ]
Quote | Reply
jens wrote:

Did a Chung test with 3 different configurations today (intervals 2, 4, and 6). Air density was 1.212. Road was chipseal. I'm guessing Crr of .005.

Can anyone comment on whether this data is clean enough to draw conclusions from? And if so, what? I usually have better data, but today there was an occasional tuft of wind.

-- jens
Do you have a .fit file? I have java code that reads fit files and computes CdA for each interval. It's very easy to use and, while I could analyze your worksheet instead, it would take a lot more work.
Quote Reply
Re: Platypus Thread: Aero Virtual Elevation Testing Protocol [lanierb] [ In reply to ]
Quote | Reply
  
It's attached. You may have to negotiate some garbage. (e.g. at one point, I dropped the chain and coasted to the start of the loop to put it back on.)

cheers! Jens

My latest book: "Out of the Melting Pot, Into the Fire" is on sale on Amazon and at other online and local booksellers
Last edited by: jens: May 3, 18 15:27
Quote Reply
Re: Platypus Thread: Aero Virtual Elevation Testing Protocol [jens] [ In reply to ]
Quote | Reply
I don't know your weight so I assumed about 180lbs. I also assumed a pedal or crank based power meter. Rho=1.212, CRR=0.005. Based on those inputs I got 0.176 for lap 2, 0.165 for lap 4, and 0.164 for lap 6. These are pretty low. If you weigh less than 180 they would go up a bit but my guess is either you were riding with traffic or your power meter was reading a bit low. Average power for lap 4 was only 125w, and for lap 6 was only 130w. Also note that these calcs are only valid if (1) the elevation that you end the lap is exactly the same as the elevation that you started the lap, and (2) there is no wind or the wind at least approximately averages out (such as on a loop or out and back).
Quote Reply
Re: Platypus Thread: Aero Virtual Elevation Testing Protocol [lanierb] [ In reply to ]
Quote | Reply
 
Thanks for checking! I'm exactly 185lbs with the bike. I was doing an exact loop with same starting and endpoint. No close-by traffic.

The powermeter is a powertap, which might account for the low CdA numbers. I was expecting a CdA of 0.18 to 0.19. The bad news is the data is probably worthless. I didn't mention that the first and last intervals were the some setup. So it looks to me like there was drift throughout the session.

You might be interested -- what I was testing was a Hed Jet+9 front with Conti SS 20C vs. a Enve 8.9 with Corsa Speed tire. It was really a sanity check to make sure neither setup was a disaster.

My latest book: "Out of the Melting Pot, Into the Fire" is on sale on Amazon and at other online and local booksellers
Quote Reply
Re: Platypus Thread: Aero Virtual Elevation Testing Protocol [jens] [ In reply to ]
Quote | Reply
Updated the parameters for (a) your weight, (b) the Powertap, and (c) Corsa Speed tires, which should give you CRR around 0.0035 on normalish imperfect pavement, as long as the pavement isn't terrible. (I've tested this in many ways.) This gives me Lap 2=0.203, Lap 4=0.194, and Lap 6=0.193. These are much more reasonable/believable numbers, but you still have a big difference between 2 and 6, which means something went wrong since they are supposed to be the same.

I test a lot, and in my experience I get within about 0.001-0.002 with tests of length ~7mins. Your tests are quite a bit longer than that. Your first test is 20% higher power so maybe that's part of the reason, though they are all very low power so not sure that would matter.

BTW if you want the software PM me and I'll send you a link. I never prettied it up for public consumption, but it's extremely easy to use and only requires that you have java installed, which most people do.
Quote Reply
Re: Platypus Thread: Aero Virtual Elevation Testing Protocol [jens] [ In reply to ]
Quote | Reply
I can’t speak to the ENVE setup but I can tell you the Jet 9+ with the 20mm SS is fast. REALLY FAST. PM Grill, he has data.
Quote Reply
Re: Platypus Thread: Aero Virtual Elevation Testing Protocol [jens] [ In reply to ]
Quote | Reply
jens wrote:
Thanks for checking! I'm exactly 185lbs with the bike. I was doing an exact loop with same starting and endpoint. No close-by traffic.

The powermeter is a powertap, which might account for the low CdA numbers. I was expecting a CdA of 0.18 to 0.19. The bad news is the data is probably worthless. I didn't mention that the first and last intervals were the some setup. So it looks to me like there was drift throughout the session.

You might be interested -- what I was testing was a Hed Jet+9 front with Conti SS 20C vs. a Enve 8.9 with Corsa Speed tire. It was really a sanity check to make sure neither setup was a disaster.

If you are testing different wheels AND tires, how do you justify assuming a constant Crr??
Quote Reply
Re: Platypus Thread: Aero Virtual Elevation Testing Protocol [lanierb] [ In reply to ]
Quote | Reply
  
Awesome. Thanks. I'm still guessing Crr of closer to .005. I used to do regression field tests down on Bayshore road (Sundays 4-5 am of course). That was .0035 Crr. Now I'm riding on Oregon chipseal, which must be worse. But even assuming it is .0035, if I add shoe covers and put my best skinsuit on I should be able to get into .18 territory.


Andrew Coggan wrote:

If you are testing different wheels AND tires, how do you justify assuming a constant Crr??


I have tested both tires on the rollers. The Crr difference was .0001 So we're talking less than half a watt difference for the front tire at the speeds I was going (22mph).


GreenPlease wrote:
I can’t speak to the ENVE setup but I can tell you the Jet 9+ with the 20mm SS is fast. REALLY FAST. PM Grill, he has data.


It has done real well for me so far. I used the Enve wheel in the last race, and the CdA wasn't quite as good as expected. So I thought I'd test to see if there were any dramatic differences. I have to get a better test environment. The problem is there are too many corners so I have to softpedal a lot to avoid braking.

My latest book: "Out of the Melting Pot, Into the Fire" is on sale on Amazon and at other online and local booksellers
Last edited by: jens: May 3, 18 18:10
Quote Reply
Re: Platypus Thread: Aero Virtual Elevation Testing Protocol [jens] [ In reply to ]
Quote | Reply
As long as you are comfortable with your assumptions...
Quote Reply
Re: Platypus Thread: Aero Virtual Elevation Testing Protocol [jens] [ In reply to ]
Quote | Reply
Jens what do you think the optimal pressure is for the jet+ 20c supersonic combo onsmooth roads?
Quote Reply
Re: Platypus Thread: Aero Virtual Elevation Testing Protocol [Sean H] [ In reply to ]
Quote | Reply
Sean H wrote:
Jens what do you think the optimal pressure is for the jet+ 20c supersonic combo onsmooth roads?

I've bent a little to the Josh + Tom A. school of rolling resistance and have been running around 95 (I used to 115+). But that's really based on my trust in them, rather than any data I've gathered myself.

My latest book: "Out of the Melting Pot, Into the Fire" is on sale on Amazon and at other online and local booksellers
Quote Reply
Re: Platypus Thread: Aero Virtual Elevation Testing Protocol [jens] [ In reply to ]
Quote | Reply
Would be interesting to test that at 80, 90, 100 & 110 psi outside and see if you can see any difference in the results.
Quote Reply
Re: Platypus Thread: Aero Virtual Elevation Testing Protocol [Sean H] [ In reply to ]
Quote | Reply
Based on Tom A.'s roller data, a change in pressure across that range would be expected to alter Crr by up to ~0.0005. A difference of that magnitude is measurable using field testing, at least using the regression approach:

http://www.trainingandracingwithapowermeter.com/...st-results-part.html
Quote Reply
Re: Platypus Thread: Aero Virtual Elevation Testing Protocol [Sean H] [ In reply to ]
Quote | Reply
Sean H wrote:
Would be interesting to test that at 80, 90, 100 & 110 psi outside and see if you can see any difference in the results.
I haven't tested the GPSS in this way, but I did test once Vittoria CS 23's at a wide range of pressures on a fairly rough chip seal TT course and here's what I found: (I weigh 180 so figure 200lbs total weight)

Pressure: CRR
110/120 0.0043
100/110 0.0037
90/100 0.0037
80/90 0.0038
Quote Reply
Re: Platypus Thread: Aero Virtual Elevation Testing Protocol [lanierb] [ In reply to ]
Quote | Reply
I’m really curious about putting the 20c tire on a wide rim like a jet +. I have measured it and it actually measures 25mm wide, perfectly inline with the rim. I’m convinced it’s the fastest tire for the jet + but just not sure if I should treat it the same as a 23mm tire that measures 27mm on a Jet + (conti TT), or should I put in a little more pressure. But as Josh showed in his graph, and your data seems to agree with, you’re better off under inflating than over inflating.
Quote Reply
Re: Platypus Thread: Aero Virtual Elevation Testing Protocol [RChung] [ In reply to ]
Quote | Reply
I'm getting a higher Crr: .00505
For interval 2 I'm getting a mean estimated CdA of .1906
For interval 4 I'm getting .1827
For interval 6 I'm getting .1845

The last couple of laps of interval 2 and the first few laps of interval 4 are pretty noisy.
Quote Reply
Re: Platypus Thread: Aero Virtual Elevation Testing Protocol [RChung] [ In reply to ]
Quote | Reply
Wind is thine enemy.

(A ~0.006 m^2 difference in CdA for the same set-up? Toss the data.)
Quote Reply
Re: Platypus Thread: Aero Virtual Elevation Testing Protocol [Andrew Coggan] [ In reply to ]
Quote | Reply
I'm not so sure. The natural question is why parts of the data were noisy but other parts were more stable. That could tell you whether the entire test is trash and unsalvageable, whether some portion of it can be used but other parts need to be dropped, or whether some lesson can be learned. For example, it looks like Jens was getting slightly better at handling the corners in the latter part of the test than in the first part.

Several years ago when I was down at Carson observing a test, the CdA suddenly went wacky. Then one of the guys noticed that the outside door to the loading dock had been opened. That threw off the measurements. We took a break and waited until the door closed, and a few minutes more for things to settle down and then resumed the test. The rider's CdA went back to what it was just before it went wacky. We didn't have to toss out the entire test, we identified something that caused a systematic (as opposed to random) error in the measurements, and just tossed that one piece. That was an easy explanation, and not all explanations are going to be so easy and obvious.
Quote Reply
Re: Platypus Thread: Aero Virtual Elevation Testing Protocol [RChung] [ In reply to ]
Quote | Reply
That's precisely the sort of thinking that leads many a scientist down the proverbial primrose path.

Jens has already identified one known issue with the experimental conditions, i.e., too much wind. Furthermore, this wasn't a billion dollar space mission where you would want to try to salvage anything you could. The wise approach is therefore just to scrap the entire test.
Last edited by: Andrew Coggan: May 6, 18 4:00
Quote Reply
Re: Platypus Thread: Aero Virtual Elevation Testing Protocol [RChung] [ In reply to ]
Quote | Reply
RChung wrote:
I'm getting a higher Crr: .00505
For interval 2 I'm getting a mean estimated CdA of .1906
For interval 4 I'm getting .1827
For interval 6 I'm getting .1845

The last couple of laps of interval 2 and the first few laps of interval 4 are pretty noisy.
I hate to say it but I'm kind of with Andy on this one. I didn't snoop the data too closely, but there are some data issues in there too, dropped data and repeated values. I cleaned up a few of them before calculating, but I'm sure there are more. Also he's using GPS for distance/speed, and the two fields don't match, so pick which one to use -- I used the distance one. In my experience that's not as precise as a speed sensor. Also, if he's using Vittoria CS 23's there's almost no way CRR=0.00505. I've tested them thoroughly inside and out and 0.0035 is a good guess for an imperfect but otherwise decent road. That's a huge difference. The fact that you get such a big difference off of such long laps means something really different was going on across those laps. It's not statistical noise.

That said, if I've issued you a data challenge, I fully expect you to rise to it :-)
Quote Reply
Re: Platypus Thread: Aero Virtual Elevation Testing Protocol [lanierb] [ In reply to ]
Quote | Reply
GPS for speed? That's a deal-killer right there.
Quote Reply
Re: Platypus Thread: Aero Virtual Elevation Testing Protocol [Andrew Coggan] [ In reply to ]
Quote | Reply
Andrew Coggan wrote:
GPS for speed? That's a deal-killer right there.

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
Quote Reply
Re: Platypus Thread: Aero Virtual Elevation Testing Protocol [jens] [ In reply to ]
Quote | Reply
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.
Quote Reply
Re: Platypus Thread: Aero Virtual Elevation Testing Protocol [lanierb] [ In reply to ]
Quote | Reply
lanierb wrote:
That said, if I've issued you a data challenge, I fully expect you to rise to it :-)

I'm envious of your quick code. My code is much more laborious, so I had to wait until Friday to analyze the data.
Quote Reply
Re: Platypus Thread: Aero Virtual Elevation Testing Protocol [RChung] [ In reply to ]
Quote | Reply
 
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
Quote Reply
Re: Platypus Thread: Aero Virtual Elevation Testing Protocol [jens] [ In reply to ]
Quote | Reply
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.
Quote Reply
Re: Platypus Thread: Aero Virtual Elevation Testing Protocol [RChung] [ In reply to ]
Quote | Reply
RChung wrote:
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.
Quote Reply
Re: Platypus Thread: Aero Virtual Elevation Testing Protocol [lanierb] [ In reply to ]
Quote | Reply
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.
Quote Reply
Re: Platypus Thread: Aero Virtual Elevation Testing Protocol [RChung] [ In reply to ]
Quote | Reply
RChung wrote:
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.
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.
Quote Reply
Re: Platypus Thread: Aero Virtual Elevation Testing Protocol [dontswimdontrun] [ In reply to ]
Quote | Reply
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
Quote Reply
Re: Platypus Thread: Aero Virtual Elevation Testing Protocol [SkippyKitten] [ In reply to ]
Quote | Reply
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
Last edited by: pad: May 7, 18 10:15
Quote Reply
Re: Platypus Thread: Aero Virtual Elevation Testing Protocol [pad] [ In reply to ]
Quote | Reply
pad wrote:
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/
Quote Reply
Re: Platypus Thread: Aero Virtual Elevation Testing Protocol [pad] [ In reply to ]
Quote | Reply
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
Quote Reply
Re: Platypus Thread: Aero Virtual Elevation Testing Protocol [Tom A.] [ In reply to ]
Quote | Reply
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?
Last edited by: pad: May 7, 18 11:30
Quote Reply
Re: Platypus Thread: Aero Virtual Elevation Testing Protocol [pad] [ In reply to ]
Quote | Reply
pad wrote:
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/
Last edited by: Tom A.: May 8, 18 7:33
Quote Reply
Re: Platypus Thread: Aero Virtual Elevation Testing Protocol [SkippyKitten] [ In reply to ]
Quote | Reply
SkippyKitten wrote:
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.


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.

Quote Reply
Re: Platypus Thread: Aero Virtual Elevation Testing Protocol [GreenPlease] [ In reply to ]
Quote | Reply
GreenPlease wrote:
At this point if I see a puff of wind rustle the trees I just scrap my session and come back another day.

Wind is thine enemy.
Quote Reply
Re: Platypus Thread: Aero Virtual Elevation Testing Protocol [Andrew Coggan] [ In reply to ]
Quote | Reply
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
Quote Reply
Re: Platypus Thread: Aero Virtual Elevation Testing Protocol [pad] [ In reply to ]
Quote | Reply
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?
Quote Reply
Re: Platypus Thread: Aero Virtual Elevation Testing Protocol [jmulvey] [ In reply to ]
Quote | Reply
jmulvey wrote:
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/
Quote Reply
Re: Platypus Thread: Aero Virtual Elevation Testing Protocol [Tom A.] [ In reply to ]
Quote | Reply
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
Quote Reply
Re: Platypus Thread: Aero Virtual Elevation Testing Protocol [AndyF] [ In reply to ]
Quote | Reply
AndyF wrote:
Hi All,

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:


  1. First and foremost: be safe!!!!! Scrap the run if you encounter danger. It's just not worth it.
  2. Weigh yourself as accurately as possible. And use a well-calibrated power meter.
  3. Do the tests on a windless day -- it will save you a lot of headaches.
  4. 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.
  5. Choose a course which has some elevation change, and on which you (safely) won't have to use your brakes.
  6. 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.
  7. 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.
  8. Did I mention not to use the brakes? That.
  9. 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-4250BT
  10. If 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.
  11. 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".

Cheers!


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.


  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
Quote Reply
Re: Platypus Thread: Aero Virtual Elevation Testing Protocol [geoffreydean] [ In reply to ]
Quote | Reply
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.
Quote Reply
Re: Platypus Thread: Aero Virtual Elevation Testing Protocol [geoffreydean] [ In reply to ]
Quote | Reply
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.
Quote Reply
Re: Platypus Thread: Aero Virtual Elevation Testing Protocol [geoffreydean] [ In reply to ]
Quote | Reply
geoffreydean wrote:
  1. 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?
  2. How do I get elevation information with GPS turned off? Does RidewithGPS.com give me the info needed for Aerolab?

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?
Quote Reply
Re: Platypus Thread: Aero Virtual Elevation Testing Protocol [geoffreydean] [ In reply to ]
Quote | Reply
geoffreydean wrote:
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.

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.
Quote Reply
Re: Platypus Thread: Aero Virtual Elevation Testing Protocol [rruff] [ In reply to ]
Quote | Reply
rruff wrote:
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?

Not currently, but I think it would be possible to add that if you know how to code.
Quote Reply
Re: Platypus Thread: Aero Virtual Elevation Testing Protocol [RChung] [ In reply to ]
Quote | Reply
RChung wrote:
Not currently, but I think it would be possible to add that if you know how to code.

I don't have any recent (decades) coding experience, but I do it in a spreadsheet.

Any wind really increases the scatter, though. Would be nice to have an aerostick and good software for this.
Quote Reply
Re: Platypus Thread: Aero Virtual Elevation Testing Protocol [RChung] [ In reply to ]
Quote | Reply
RChung wrote:
geoffreydean wrote:

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.


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.

Thanks. MapmyRide has elevation of the street so I think I can use the calculator to determine air density.

I assume I should stay in one gear?

Geoff from Indy
http://www.tlcendurance.com
Quote Reply
Re: Platypus Thread: Aero Virtual Elevation Testing Protocol [geoffreydean] [ In reply to ]
Quote | Reply
Staying in one gear is good as there is no loss from any changes and Eta stays constant throughout the test.

The correct elevation tool in GC will be a help.

Developing aero, fit and other fun stuff at Red is Faster
Quote Reply
Re: Platypus Thread: Aero Virtual Elevation Testing Protocol [geoffreydean] [ In reply to ]
Quote | Reply
geoffreydean wrote:

I assume I should stay in one gear?


James ("SkippyKitten") has it right: for best results, you should probably stay in one gear. Most modern derailleur systems don't have a lot of loss in close gears so *if you need to* you could switch one or two cogs but I wouldn't flip from one ring to another. (I also have a Power Tap, so I don't really worry too much about drive train losses).

Another thing I do is to soft-pedal when coast (and I do coast). For me, remembering to soft-pedal is easier than trying to remember exactly where to hold my feet while coasting.

But I would say both of these latter two things are details when you start to get good and serious. When you first start out, there's already a lot to remember. That's sort of why I recommend looking at a regular ride or two in Golden Cheetah, just so you can understand how it works and how careful you need to be to get precision. The first couple of times you do this you probably shouldn't expect too much precision -- that will come with a little bit of experience.
Last edited by: RChung: Sep 9, 18 13:52
Quote Reply
Re: Platypus Thread: Aero Virtual Elevation Testing Protocol [geoffreydean] [ In reply to ]
Quote | Reply
geoffreydean wrote:
RChung wrote:
geoffreydean wrote:

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.


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.


Thanks. MapmyRide has elevation of the street so I think I can use the calculator to determine air density.

I assume I should stay in one gear?

I created an easy to use air density calculator here:
http://www.aerocoach.com.au/air-density/

http://www.cyclecoach.com
http://www.aerocoach.com.au
Quote Reply
Re: Platypus Thread: Aero Virtual Elevation Testing Protocol [AlexS] [ In reply to ]
Quote | Reply
AlexS wrote:
I assume I should stay in one gear?

I created an easy to use air density calculator here:
http://www.aerocoach.com.au/air-density/[/quote]
Great work Alex!

Hamish Ferguson: Cycling Coach
Quote Reply
Re: Platypus Thread: Aero Virtual Elevation Testing Protocol [AlexS] [ In reply to ]
Quote | Reply
AlexS wrote:

I created an easy to use air density calculator here:
http://www.aerocoach.com.au/air-density/

Very nice!

I should clarify, there are two standards for showing barometric pressure: when you get it from an official weather service, most likely the pressure has been standardized to sea level. However, sometimes, you'll find the pressure reported as "station" pressure. In that case, the altitude at the station where the pressure gauge is located is already included. The Golden Cheetah air density calculator uses "station" pressure, which is why it doesn't have altitude. Official barometric pressure that's been standardized to sea level doesn't vary much over long distances so, as Alex says, you can grab the barometric pressure from any nearby location. However, the altitude can vary quite a bit depending on terrain, so if you're using official reports you have to adjust for that.
Quote Reply
Re: Platypus Thread: Aero Virtual Elevation Testing Protocol [RChung] [ In reply to ]
Quote | Reply
I just did my first test, yesterday. I have an old wired powertap hub. I'm using the spreadsheet version because GC doesn't like the csv files for some reason. I think I found the spreadsheet from AlexS.

I think I have a pretty good test location. It's a 3/4 mile, bathtub section that runs north/south and is sheltered by trees on both sides. The main stretch is mostly flat, and the ends turn uphill allowing me to coast down and U-turn. There is also very little traffic. I saw a total of two cars yesterday.

I just did two simple runs (5 laps each). Each set of 5 laps took about 12 minutes to complete. One on the bull horns and one in the aerobars. Assuming a crr of 0.005, I got cda of 0.330 and 0.242, respectively.

My main question is how to use the spreadsheet to tease out crr? I'd like to establish a known baseline crr for my tire/test area/road conditions.

I've read the pdf, and this entire thread. I think I understand the concept, just not the practical mechanics.

At one end of my test location there is a short hill that I can climb. It's 50 ish feet tall, and about 1/4 mile long...it is Texas, afterall. Is that sufficient? I'm guessing not, since any error in elevation would propagate into crr.

Would I ride up/down this hill at two different speeds, and then adjust cda/crr to level the VE profile and match the elevation change?

If that's not sufficient, would it be better to do multiple (5, 10?) laps on my planned bathtub, at increasing speeds? If so, how much speed change is practically necessary and how slow can I start? Do I need to ramp up AND down... Or is monotonically, increasing sufficient?

Any recommended search method for finding crr/cda values graphically?

Thanks... Sorry for the barrage of questions.
Quote Reply
Re: Platypus Thread: Aero Virtual Elevation Testing Protocol [Tom_hampton] [ In reply to ]
Quote | Reply
The best way to get Crr right in my experience is, yes, to vary speed. Without accurate elevation data over the course, it’s better to do this over different runs/laps rather than as part of one run. This makes the ‘shape’ of the VE profile less important than the overall VE change.

Try and maximise the difference in speed while still maintaining pose so that CdA is less affected. Get accurate spot heights for top and bottom and record mass when testing.

Also, a consistent road surface is helpful.

Developing aero, fit and other fun stuff at Red is Faster
Quote Reply
Re: Platypus Thread: Aero Virtual Elevation Testing Protocol [SkippyKitten] [ In reply to ]
Quote | Reply
SkippyKitten wrote:
The best way to get Crr right in my experience is, yes, to vary speed. Without accurate elevation data over the course, it’s better to do this over different runs/laps rather than as part of one run. This makes the ‘shape’ of the VE profile less important than the overall VE change.

Try and maximise the difference in speed while still maintaining pose so that CdA is less affected. Get accurate spot heights for top and bottom and record mass when testing.

Also, a consistent road surface is helpful.

Ok. Thanks.

Is it better to ramp over several runs, or is a single (or 2-3) slow and max-aero-fast pass sufficient? Eg 2x16mph and 2x25mph?

Do you have a good search heuristic for finding crr and cda? Ie, when to inc/dec crr/cda based on VE shape?
Quote Reply
Re: Platypus Thread: Aero Virtual Elevation Testing Protocol [SkippyKitten] [ In reply to ]
Quote | Reply
SkippyKitten wrote:
The best way to get Crr right in my experience is, yes, to vary speed. Without accurate elevation data over the course, it’s better to do this over different runs/laps rather than as part of one run. This makes the ‘shape’ of the VE profile less important than the overall VE change.

Try and maximise the difference in speed while still maintaining pose so that CdA is less affected. Get accurate spot heights for top and bottom and record mass when testing.

Also, a consistent road surface is helpful.

Good info. What sort of a protocol would you proscribe for teasing out the fastest air pressure for a given tire/rider?
Quote Reply
Re: Platypus Thread: Aero Virtual Elevation Testing Protocol [Tom_hampton] [ In reply to ]
Quote | Reply
More runs always better, but you don’t have to keep at the same speed for particular runs. If it’s a half pipe course, then go with the flow - speed up and slow down with the terrain. If you want to coast I tend to soft pedal, partly to keep things the same CdA wise, partly to keep certain power meters happy. Powertap doesn’t have any issues there though.

Just to be clear, it’s best to hold the same position for all the runs, so on the basebar, even though this does let your body move a bit more.

Developing aero, fit and other fun stuff at Red is Faster
Quote Reply
Re: Platypus Thread: Aero Virtual Elevation Testing Protocol [GreenPlease] [ In reply to ]
Quote | Reply
Thanks. 10psi steps are realistic. Use the pump or gauge you use on race day. Start at low pressure and increase (debatable). Pump slowly to avoid heating things up. Overcast days are more consistent for Crr tests in my experience. Setting front and rear togetheris easier.

The Red is Faster system does give me a bit of flexibility on courses, like only running in one direction. This means I can use nice long climbs and not care about the turning point. I also have TyreWiz which is handy for this sort of thing.

Developing aero, fit and other fun stuff at Red is Faster
Quote Reply
Re: Platypus Thread: Aero Virtual Elevation Testing Protocol [Tom_hampton] [ In reply to ]
Quote | Reply
Tom_hampton wrote:
I just did my first test, yesterday. I have an old wired powertap hub. I'm using the spreadsheet version because GC doesn't like the csv files for some reason. I think I found the spreadsheet from AlexS.

I think I have a pretty good test location. It's a 3/4 mile, bathtub section that runs north/south and is sheltered by trees on both sides. The main stretch is mostly flat, and the ends turn uphill allowing me to coast down and U-turn. There is also very little traffic. I saw a total of two cars yesterday.

I just did two simple runs (5 laps each). Each set of 5 laps took about 12 minutes to complete. One on the bull horns and one in the aerobars. Assuming a crr of 0.005, I got cda of 0.330 and 0.242, respectively.

My main question is how to use the spreadsheet to tease out crr? I'd like to establish a known baseline crr for my tire/test area/road conditions.

I've read the pdf, and this entire thread. I think I understand the concept, just not the practical mechanics.

At one end of my test location there is a short hill that I can climb. It's 50 ish feet tall, and about 1/4 mile long...it is Texas, afterall. Is that sufficient? I'm guessing not, since any error in elevation would propagate into crr.

Would I ride up/down this hill at two different speeds, and then adjust cda/crr to level the VE profile and match the elevation change?

If that's not sufficient, would it be better to do multiple (5, 10?) laps on my planned bathtub, at increasing speeds? If so, how much speed change is practically necessary and how slow can I start? Do I need to ramp up AND down... Or is monotonically, increasing sufficient?

Any recommended search method for finding crr/cda values graphically?

Thanks... Sorry for the barrage of questions.

So, the underlying issue is that if you need to estimate both Crr and CdA, you have two unknowns rather than one, so you need at least two equations. If you have a hill of unknown height, that's a thrid unknown so you need at least three equations. You can get those equations by varying speed up the same hill, or by doing loops on your bathtub at different speeds. The wider the range of speed, the more stable the estimates are going to be (that is, the more precise).

So let's say you're using the hill. You take 3 runs at widely varying speed or power. Then you pop the data into the spreadsheet and either solve analytically for the CdA, Crr, and hill height, or you can try different values to solve graphically. (I solve analytically then take the estimated values of CdA and Crr and produce overlapping VE profiles as a diagnostic of fit).
Quote Reply
Re: Platypus Thread: Aero Virtual Elevation Testing Protocol [RChung] [ In reply to ]
Quote | Reply
RChung wrote:
So, the underlying issue is that if you need to estimate both Crr and CdA, you have two unknowns rather than one, so you need at least two equations. If you have a hill of unknown height, that's a thrid unknown so you need at least three equations. You can get those equations by varying speed up the same hill, or by doing loops on your bathtub at different speeds. The wider the range of speed, the more stable the estimates are going to be (that is, the more precise).

So let's say you're using the hill. You take 3 runs at widely varying speed or power. Then you pop the data into the spreadsheet and either solve analytically for the CdA, Crr, and hill height, or you can try different values to solve graphically. (I solve analytically then take the estimated values of CdA and Crr and produce overlapping VE profiles as a diagnostic of fit).

In theory yes, but only if both Crr and CdA are independant from speed. Is this allways the case? When is it true?
Quote Reply
Re: Platypus Thread: Aero Virtual Elevation Testing Protocol [BergHugi] [ In reply to ]
Quote | Reply
They don't have to be independent from speed. They just have to be different functions of speed.
Quote Reply
Re: Platypus Thread: Aero Virtual Elevation Testing Protocol [BergHugi] [ In reply to ]
Quote | Reply
BergHugi wrote:

In theory yes, but only if both Crr and CdA are independant from speed. Is this allways the case?


Good point. In the range of speeds we *usually* ride in, on the kinds of surfaces that we *usually* use for TTs or road racing or velodrome track racing, we can *usually* get away with the assumption that Crr and CdA are invariant with speed. However, there are some surfaces where I've gone from paved road to a short segment of dirt or mud or cobblestones and I suspect that the Crr isn't invariant with speed (that's not a wild suspicion -- I've got a tiny bit of data on that). Likewise (and this may come up more frequently now that airspeed indicators are starting to hit the market) in gusty wind conditions, especially from different directions, we might expect that the Reynolds number will *not* be constant so CdA will not be independent of either ground speed or airspeed. There are ways to estimate the Crr and CdA under varying conditions but, from a practical point of view, when I'm trying to estimate CdA it's simpler not to use a test venue with cobblestones mixed in with smooth asphalt. Similarly, while I do occasionally test when there are gentle breezes I never test when the wind is highly variable in both speed and direction. (The reason I have only a tiny bit of data on venues with cobblestones is because once I noticed it I avoided using those venues. I recommend that you do, too). [Edited to add:] Listen to Josh Poertner's anecdotes about doing testing on certain sectors of the Paris-Roubaix course. It's very cool.

Quote:
When is it true?


So, above I wrote "usually." A good thing about the VE profile is that it provides a good diagnostic for when the conditions were too variable to get a good estimate. There have long been methods that will allow you to solve for two unknowns from data; the value of VE is that it provides a pretty handy diagnostic of fit and (especially) misfit.
Last edited by: RChung: Oct 17, 18 9:26
Quote Reply
Re: Platypus Thread: Aero Virtual Elevation Testing Protocol [RChung] [ In reply to ]
Quote | Reply
Hi, I'm new to this forum. I have a question about repeatability of CdA testing obtained using the VE method.

I've been a cyclist for about 25 years (mainly MTB’ing - sorry!). In the last few years, though, I've got into time trialling. I'm an aerodynamicist as a profession, albeit for an aircraft manufacturer, so technical side of time trialling really interests and appeals to me.

I want to focus on improving my position and CdA, which is in the 0.27-0.29 region (so there's room for improvement!). After some haphazard experimentation with field testing over the last couple of years, this summer I spent some time properly researching field test techniques, and came across Robert Chung's VE method, which I really like and am now using.

I have fully read this thread and have used all the useful information and comments to refine my test technique. However, I still have the feeling that the repeatability of my testing is quite poor. The repeatability I'm getting is around 2%, for CdA differences between two tests within the same session. I was wondering what level of CdA repeatability other people are getting when doing VE field tests?

Here is a few details about my test protocol. Sorry this is long, but I hope more information is better than not enough:
1) I use a 1-mile oval road on an industrial estate, near Bristol in England (https://www.strava.com/...62528?filter=overall). It has approximately 30ft of elevation change. The slowest speed is about half the fastest speed when ridden at constant power. No braking is ever required. There is no traffic at the weekend. The only downside is the asphalt is quite rough (slightly rougher even than average UK roads!).
2) I do 5 laps at a time, so each run is 5 miles & takes 13-14 minutes.
3) I use a Stages left-hand PM. I know this is not ideal, but it's all I've got.
4) I keep my power at 230-240W, which is tempo/sweet-spot for me in my TT position. I know it's not necessary to keep power constant, but my thinking is that any left/right leg imbalance will then be similar from one run to another if I keep the power similar. It also helps me correct occasional signal dropouts when I know I’m riding at constant power.
5) I now do three runs per session, in an A/B/A configuration sequence. Three runs are about my limit (~40 mins total), and it also gives me a useful workout! I've tried doing a 4th run, but fatigue was affecting my form and position.
6) I now use a GSC-10 speed sensor, and have GPS turned off (thanks to reading this thread).
7) I analyse the VE profile in Excel, mainly because I like to know what's being calculated and I can manually identify and correct the occasion zero due to dropouts. In any case, I have checked my Excel-derived CdA against Golden Cheetah, and the CdA agreement was within 0.001, so I'm confident there are no bugs in my spreadsheet.
8) I have done one session where the 2nd run was done slower at 100-150W instead. This slower run allowed me estimate that CRR should be 0.006 instead of the 0.005 that I initially estimated.
9) Completely calm days (<3-4mph) never happen in the West of England, unfortunately. On a ‘good’ day, the reported wind speed is about 5-10mph, which I understand corresponds to wind speed at 10m. I therefore target those 5-10mph days to do my testing, which happen about approximately 20-30% of the year. Most of the days in the year are more windy than that. I realise this wind speed is not good for VE testing, but I can't do a lot about it. My hope is that within a single session the wind speed will not change much, but it's just a hope. I am certainly not expecting good repeatability between tests on different days, because the wind will certainly be different.

There are one or two remaining things I can try to further improve things:
- Stay in the same gear. Currently I shift across a few sprockets to avoid the spinning too fast or grinding too slowly (which is more a personal preference than a real constraint). I am fairly consistent between runs I think.
- There's a chance my body position between the first and last run of the A/B/A sequence differs, due to fatigue, especially my head position. One thought I had is to attach a zip tie to the stem to 'tickle' my chin so I know my head's in the right position.
- An bike-mounted anemometer would be brilliant, to try to adjust my calculations for wind variations, but I can't anybody selling them at the moment. The cost may be an issue anyway.

Any other tips or suggestions would be appreciated.

The repeatability I've achieved for three sessions so far has been 0.018, 0.005 and 0.006. This is the difference in CdA between the first and third runs (i.e. in identical configurations). Only my most recent session was done using the GSC-10 sensor, though, so I am taking that 0.006 value as my only really valid repeatability data point so far. A 0.006 delta-CdA equates to just over 2%. Of course, I need to gather more data to see whether this was a 'lucky' repeat, or an unlucky one. With enough testing I could get a repeatability standard deviation, I guess.

Could other people that have done multiple VE field tests please let me know what level of repeatability that they get within the same session please? Is 2% typical, or do people achieve much better? This information would help me decide whether I need to keep working to refine my protocol, or accept it as it is.

Sorry for the long post.
Quote Reply
Re: Platypus Thread: Aero Virtual Elevation Testing Protocol [NickD1] [ In reply to ]
Quote | Reply
I used to use Aztec West as an aero testing loop many years ago (pre Strava!) but found that inconsistencies in the road surface would really add up and unless you hit the exact same patches each time it'll introduce a lot of noise into the data. I wouldn't recommend using it.

Your methodology is good but you probably want to reduce lap distance so that you can get 5 data points per experiment for VE profiling. How about hopping over the bridge to Maindy velodrome in Cardiff? You'll get a lot done there in an afternoon and it would take less than half the time to collect the same amount of data. For a flat quiet road if you were to do out and back testing Pilning St would be okay but a bit more exposed.

AeroCoach UK
http://www.aero-coach.co.uk
Quote Reply
Re: Platypus Thread: Aero Virtual Elevation Testing Protocol [NickD1] [ In reply to ]
Quote | Reply
2% really is not bad in my opinion especially given your environment. My suggestion would be to do shorter loops. Do one or two laps instead of three or four. IMO this will spread any variability due to wind over your sample. Personally I don’t shift when I test but I’m not sure how the Stages power meter behaves with regards to cadence so... I’d suggest experimenting with not shifting and then look at the power file to see if there are any weird spikes or dropouts.
Quote Reply
Re: Platypus Thread: Aero Virtual Elevation Testing Protocol [NickD1] [ In reply to ]
Quote | Reply
First, and this is important, pay attention to suggestions that Xav makes. He's the real deal. That he used Aztec West is amazing, almost as amazing as that there’s a place in England called “Aztec West.†Is there an Aztec East?

Second, considering your overall situation (wind, road surface, level of experience, power meter) a delta of .006 m^2 on a base of 0.28 m^2 is not bad.

Third, whether at Aztec West or elsewhere, I would vary speed/power more. In fact, I think it would be preferable to reduce the number of laps from 5 to maybe 3 if you varied the speed/power; I think a protocol where you did the first lap at around 160 watts, then around 200, then around 240 would help you better identify both Crr and CdA *plus* it would help you identify whether the wind was changing. Fewer laps at lower avg power may also help you reduce fatigue and perhaps help you maintain your "form."(All that said, I usually toss the first lap of a test since for some reason that first lap is always noisier than subsequent ones, so I often will do 4 laps for the first set with the plan of tossing the first lap, then do 3 laps for subsequent sets).

As for your original question, I've analyzed data from experienced riders on calm days with power measured at the rear wheel on an outdoor course where the CV was around 0.5%.
Last edited by: RChung: Nov 3, 18 8:41
Quote Reply
Re: Platypus Thread: Aero Virtual Elevation Testing Protocol [Xavier] [ In reply to ]
Quote | Reply
Xavier wrote:
I used to use Aztec West as an aero testing loop many years ago (pre Strava!) but found that inconsistencies in the road surface would really add up and unless you hit the exact same patches each time it'll introduce a lot of noise into the data. I wouldn't recommend using it.

Your methodology is good but you probably want to reduce lap distance so that you can get 5 data points per experiment for VE profiling. How about hopping over the bridge to Maindy velodrome in Cardiff? You'll get a lot done there in an afternoon and it would take less than half the time to collect the same amount of data. For a flat quiet road if you were to do out and back testing Pilning St would be okay but a bit more exposed.

Thanks Xavier. Amazing coincidence that someone has also used Aztec West before. It's a small world! I know what you mean about the road surface. I have been trying hard to follow the exact same line each lap, 3ft from the kerb, but it has been in the back of my mind that it may be contributing to the variability. I might give Pilning Street a go. It's part of one the local 10m TT courses I sometimes ride, and thinking about it now, I can see why it would be a good stretch of road for out-and-back testing. I wasn't aware of that Maindy velodome in Cardiff, so thanks, I'll check that out.

By the way, I really liked the Mark Florence time trialling podcasts that you've done. I haven't heard the entire series of podcasts yet, but all the ones where yourself or Andy Fronchioni have guested on are excellent.
Quote Reply
Re: Platypus Thread: Aero Virtual Elevation Testing Protocol [GreenPlease] [ In reply to ]
Quote | Reply
GreenPlease wrote:
2% really is not bad in my opinion especially given your environment. My suggestion would be to do shorter loops. Do one or two laps instead of three or four. IMO this will spread any variability due to wind over your sample. Personally I don’t shift when I test but I’m not sure how the Stages power meter behaves with regards to cadence so... I’d suggest experimenting with not shifting and then look at the power file to see if there are any weird spikes or dropouts.

That's great, many thanks. The advice is certainly consistent from everyone that I should do less laps. My legs and neck will appreciate doing only 3 laps at a time instead, so I'll try that! I'll also experiment with using a fixed gear and see how that goes.
Quote Reply
Re: Platypus Thread: Aero Virtual Elevation Testing Protocol [RChung] [ In reply to ]
Quote | Reply
RChung wrote:
Third, whether at Aztec West or elsewhere, I would vary speed/power more. In fact, I think it would be preferable to reduce the number of laps from 5 to maybe 3 if you varied the speed/power; I think a protocol where you did the first lap at around 160 watts, then around 200, then around 240 would help you better identify both Crr and CdA *plus* it would help you identify whether the wind was changing. Fewer laps at lower avg power may also help you reduce fatigue and perhaps help you maintain your "form."(All that said, I usually toss the first lap of a test since for some reason that first lap is always noisier than subsequent ones, so I often will do 4 laps for the first set with the plan of tossing the first lap, then do 3 laps for subsequent sets).

As for your original question, I've analyzed data from experienced riders on calm days with power measured at the rear wheel on an outdoor course where the CV was around 0.5%.

That's a great suggestion, thanks Robert. Changing power each lap will help to prise apart the different drag contributors, but keeping it constant within each lap will still allow me to fix signal dropouts if they occur. Doing an extra lap, with the option to discard the first one makes sense too.

Getting a CV of 0.5% is impressive, considering it's an uncontrolled environment (outdoors). That's not too dissimilar to the variability I see from wind tunnel tests done as part of my day job. If I can get close to 1% CV, I'll feel more satisfied I think.
Quote Reply
Re: Platypus Thread: Aero Virtual Elevation Testing Protocol [NickD1] [ In reply to ]
Quote | Reply
NickD1 wrote:
That's not too dissimilar to the variability I see from wind tunnel tests done as part of my day job.

You ever get a chance to test 19 different wheels in that wind tunnel at yaw?
Quote Reply
Re: Platypus Thread: Aero Virtual Elevation Testing Protocol [RChung] [ In reply to ]
Quote | Reply
RChung wrote:
You ever get a chance to test 19 different wheels in that wind tunnel at yaw?

Ha ha, no that wasn’t me! I read that discussion with interest, but I don’t know Sachin Hambini or those guys.

There was suggestion that they work for Airbus, but that’s not true (certainly not in my Aerodynamics department anyway).
Quote Reply
Re: Platypus Thread: Aero Virtual Elevation Testing Protocol [AlexS] [ In reply to ]
Quote | Reply
AlexS wrote:
I created an easy to use air density calculator here:
http://www.aerocoach.com.au/air-density

Alex-

I was trying to play with your "speed from power" and "power from speed" tools this weekend. I noted that both the Crr and CdA sliders were stuck at "0", and would snap back to zero when I move them. I tried Android Chrome, Windows 10 Chrome, Win10 Edge, and Win7 IE-11. All did exactly the same thing.

They both worked for me last week.
Last edited by: Tom_hampton: Nov 5, 18 7:52
Quote Reply
Re: Platypus Thread: Aero Virtual Elevation Testing Protocol [Tom_hampton] [ In reply to ]
Quote | Reply
Tom_hampton wrote:
AlexS wrote:
I created an easy to use air density calculator here:
http://www.aerocoach.com.au/air-density


Alex-

I was trying to play with your "speed from power" and "power from speed" tools this weekend. I noted that both the Crr and CdA sliders were stuck at "0", and would snap back to zero when I move them. I tried Android Chrome, Windows 10 Chrome, Win10 Edge, and Win7 IE-11. All did exactly the same thing.

They both worked for me last week.

Thanks for the heads up. I'm not sure what's happened there.

Calculoid have been making some changes of late. I'll see what they say.

http://www.cyclecoach.com
http://www.aerocoach.com.au
Quote Reply
Re: Platypus Thread: Aero Virtual Elevation Testing Protocol [Tom_hampton] [ In reply to ]
Quote | Reply
It's working again.

Calculoid said there was some problem at their end which they fixed. I'm still yet to have the default value setting fixed (they should sit mid range rather than at zero) but at least the sliders should be working again.

http://www.cyclecoach.com
http://www.aerocoach.com.au
Quote Reply
Re: Platypus Thread: Aero Virtual Elevation Testing Protocol [AlexS] [ In reply to ]
Quote | Reply
Cool. Thanks. Works for me, also.

I did some position tweak testing this weekend and wanted to confirm the estimated speed improvment at race power....Beyond the usual rule of thumb.
Quote Reply
Re: Platypus Thread: Aero Virtual Elevation Testing Protocol [RChung] [ In reply to ]
Quote | Reply
I did my first attempt at field testing this weekend.Didn't have too much time but was able to get a 5 loop uninterrupted run on a small loop in a nearby park, closed to traffic, no one around (before a roller blade guy showed up). It's completely flat and about 525m long as measured by my speed sensor.



Wanted to run through my protocol and see if I'm on the right track here or if there's anything extra I need to do.


1. Measure weight (bike 10.2kg, suit+helmet+shoes 1.8kg, me: 73kg). Total weight 85kg
2. Found a wunderground weather station less than a mile away from the park
3. Using Garmin 520: GPS turned off, using the Garmin hub based speed sensor, disabled auto calibration and set wheel circumference to 2096 (700x23c).
4. Pumped tires to 80psi (HED Jet 6+ with GP4000s 23c and butyl tubes). Assuming a crr of 0.00411 based on this test
5. Zero PM (using crank P2M).
6. Rode a few loops to get familiar with the course and gauge speed in corners etc. Averaged around 190-200W. Kept it in the same gear, no braking, no coasting.
7. There's an actual start line (they do crits on this course). Hit Lap button on Garmin at the start line and rode 5 loops all recorded on the same lap / interval on my Garmin.
8. Download data in Golden Cheetah
9. Calculate air density based on weather data (69F, 100% humidity, 0 wind, 30.01 pressure) -> 1.21821
10. Fire up Aerolab
- set crr, mass, Rho
- Elevation line looks almost flat - as expected - can I just mark the "constant altitude box"?
- move CdA slider to make blue line as horizontal as possible? There are some micro dips in the line but every hard to align.

Question: how do I make my numbers not suck? just kidding... but if you could give me some feedback on my protocol that would be awesome. I plan on going back the following weekends and experiment some more and see if I can get repeatable numbers before I start doing some A/B testing.








EDIT1:
Okay... Read a bunch of the previous threads and I'm adding these findings:
- Fudged air density calculation: correct should be 69F, dew point 69F, pressure 30.1 ==> 1.19816
- I need to loop my Garmin every loop. It helps visualize the VE for every loop of the run and weed out loops with anomalies. I did not do this and ended up with one interval with no way of knowing where each loop starts and ends unless I split by distance.
- Crr of 0.0041 as per the roller test is probably not accurate on the road. This loop while it's not super crappy asphalt is not exactly super smooth either. Problem is that the difference between a Crr setting of 0.004 and 0.006 is the difference between solving for a CdA of 0.277 and 0.240 which is pretty significant. How do I get a better Crr estimate?
- I'm at sea level and since this is a flat loop with a 100m radius, actual elevation changes are probably not important so removing the Garmin elevation data and then trying to flatten the VE graph as best as possible should be the way to go.
- Set Eta to .98 for crank PM

- Will try to mark the course turns to make sure I take similar lines for as much as possible.

What's your CdA?
Last edited by: trailerhouse: Dec 17, 18 18:16
Quote Reply
Re: Platypus Thread: Aero Virtual Elevation Testing Protocol [trailerhouse] [ In reply to ]
Quote | Reply
no feedback to your protocol, but I wanted to mention that I've been looking for somewhere to do some testing and the thought of using the piccolo road course had crossed my mind!! i'm very interested in how this goes for you
Quote Reply
Re: Platypus Thread: Aero Virtual Elevation Testing Protocol [jazzymusicman] [ In reply to ]
Quote | Reply
Yep, happy to share any info :)
jazzymusicman wrote:
no feedback to your protocol, but I wanted to mention that I've been looking for somewhere to do some testing and the thought of using the piccolo road course had crossed my mind!! i'm very interested in how this goes for you

What's your CdA?
Quote Reply
Re: Platypus Thread: Aero Virtual Elevation Testing Protocol [trailerhouse] [ In reply to ]
Quote | Reply
If you know that the loop is 525 m long you don't really need to hit the lap button every lap.

Uncheck the "constant altitude" box.
Quote Reply
Re: Platypus Thread: Aero Virtual Elevation Testing Protocol [RChung] [ In reply to ]
Quote | Reply
Thanks!

Any suggestions on how to better estimate or calculate actual Crr? It seems like it's pretty crucial to get an accurate CdA #.

It might not matter that much for an A/B test scenario where I can assume some constant (.004 or .005 whatever it may be) and look at the differences in CdA between A and B. I guess this is ultimately what matters but would be nice to have a semi accurate CdA as well :)



RChung wrote:
If you know that the loop is 525 m long you don't really need to hit the lap button every lap.
Uncheck the "constant altitude" box.

What's your CdA?
Quote Reply
Re: Platypus Thread: Aero Virtual Elevation Testing Protocol [trailerhouse] [ In reply to ]
Quote | Reply
trailerhouse wrote:
Thanks!

Any suggestions on how to better estimate or calculate actual Crr? It seems like it's pretty crucial to get an accurate CdA #.

It might not matter that much for an A/B test scenario where I can assume some constant (.004 or .005 whatever it may be) and look at the differences in CdA between A and B. I guess this is ultimately what matters but would be nice to have a semi accurate CdA as well :)



RChung wrote:
If you know that the loop is 525 m long you don't really need to hit the lap button every lap.
Uncheck the "constant altitude" box.


You are correct in that an accurate crr is necessary for an accurate cda but not necessary for the purposes of A/B testing and getting faster. The simplest way I've found to coax out crr on the road is to climb a very, very steep hill at a low speed. There's another method but it eludes me at the moment.
Last edited by: GreenPlease: Dec 18, 18 7:01
Quote Reply
Re: Platypus Thread: Aero Virtual Elevation Testing Protocol [trailerhouse] [ In reply to ]
Quote | Reply
trailerhouse wrote:
Thanks!

Any suggestions on how to better estimate or calculate actual Crr? It seems like it's pretty crucial to get an accurate CdA #.

It might not matter that much for an A/B test scenario where I can assume some constant (.004 or .005 whatever it may be) and look at the differences in CdA between A and B. I guess this is ultimately what matters but would be nice to have a semi accurate CdA as well :)



RChung wrote:
If you know that the loop is 525 m long you don't really need to hit the lap button every lap.
Uncheck the "constant altitude" box.


If you vary the speed across the multiple laps, then only a unique set of CdA AND Crr will both "level" the plot AND result in each lap elevation variation being the same. Alternatively, if you KNOW the actual elevation variation within a lap, that helps too.

See "Shen Method"...http://nyvelocity.com/...ess/the-shen-method/

http://bikeblather.blogspot.com/
Last edited by: Tom A.: Dec 18, 18 7:37
Quote Reply
Re: Platypus Thread: Aero Virtual Elevation Testing Protocol [Tom A.] [ In reply to ]
Quote | Reply
Tom A. wrote:
If you vary the speed across the multiple laps, then only a unique set of CdA AND Crr will both "level" the plot AND result in each lap elevation variation being the same. Alternatively, if you KNOW the actual elevation variation within a lap, that helps too.

See "Shen Method"...http://nyvelocity.com/...ess/the-shen-method/

Yup. Andy Shen's Method works pretty well in this.

The underlying reason is that aero drag varies with the cube of speed while rolling drag varies linearly with speed, so in order to "pry apart" the components due to CdA and Crr, you need to vary speed and power. The wider the range of speed and power, the easier it is to pry them apart. That's why I often include a little ramp up and coast down even on a flat surface (like the one trailerhouse is using), and I'll do that it at least a couple of different places.
Quote Reply
Re: Platypus Thread: Aero Virtual Elevation Testing Protocol [RChung] [ In reply to ]
Quote | Reply
Great stuff! I'll look into all of this.

One more question since you mention coasting. Does zero cadence - zero power data points influence negatively the VE calculation. I want to know like how paranoid should I be about this stuff :)

RChung wrote:
Tom A. wrote:

If you vary the speed across the multiple laps, then only a unique set of CdA AND Crr will both "level" the plot AND result in each lap elevation variation being the same. Alternatively, if you KNOW the actual elevation variation within a lap, that helps too.

See "Shen Method"...http://nyvelocity.com/...ess/the-shen-method/


Yup. Andy Shen's Method works pretty well in this.

The underlying reason is that aero drag varies with the cube of speed while rolling drag varies linearly with speed, so in order to "pry apart" the components due to CdA and Crr, you need to vary speed and power. The wider the range of speed and power, the easier it is to pry them apart. That's why I often include a little ramp up and coast down even on a flat surface (like the one trailerhouse is using), and I'll do that it at least a couple of different places.

What's your CdA?
Quote Reply
Re: Platypus Thread: Aero Virtual Elevation Testing Protocol [trailerhouse] [ In reply to ]
Quote | Reply
trailerhouse wrote:
Great stuff! I'll look into all of this.

One more question since you mention coasting. Does zero cadence - zero power data points influence negatively the VE calculation. I want to know like how paranoid should I be about this stuff :)


Actually, it's my opinion that zero power data points help the accuracy and precision of the VE calculations, in that most power meters report zero power fairly accurately AND precisely ;-)

Because of that, I will "soft pedal" (i.e. turning cranks but not engaging freewheel) on the downhill portions of my "half-pipe" style course, with the added benefit from using a PT hub set to "autozero on coasting" of having the PM re-zeroed ("calibrated" in Garmin parlance) continuously throughout the test run. With a crank-based PM, the soft-pedaling should result in the power reading being zero as well (or very close)...if not, then the PM may need to be re-zeroed, or you might want to look at cleaning the drivetrain ;-)

For flat courses, I like to follow the "Shen Method" protocol of continuously increasing speed and power across a few laps, with the final lap having as much coasting as possible.

http://bikeblather.blogspot.com/
Last edited by: Tom A.: Dec 18, 18 9:53
Quote Reply
Re: Platypus Thread: Aero Virtual Elevation Testing Protocol [Tom A.] [ In reply to ]
Quote | Reply
Awesome, my Power2Max reports zeros and it's supposed to auto zero as well when you coast.

Tom A. wrote:
trailerhouse wrote:
Great stuff! I'll look into all of this.

One more question since you mention coasting. Does zero cadence - zero power data points influence negatively the VE calculation. I want to know like how paranoid should I be about this stuff :)


Actually, it's my opinion that zero power data points help the accuracy and precision of the VE calculations, in that most power meters report zero power fairly accurately AND precisely ;-)

Because of that, I will "soft pedal" (i.e. turning cranks but not engaging freewheel) on the downhill portions of my "half-pipe" style course, with the added benefit from using a PT hub set to "autozero on coasting" of having the PM re-zeroed ("calibrated" in Garmin parlance) continuously throughout the test run. With a crank-based PM, the soft-pedaling should result in the power reading being zero as well (or very close)...if not, then the PM may need to be re-zeroed, or you might want to look at cleaning the drivetrain ;-)

For flat courses, I like to follow the "Shen Method" protocol of continuously increasing speed and power across a few laps, with the final lap having as much coasting as possible.

What's your CdA?
Quote Reply
Re: Platypus Thread: Aero Virtual Elevation Testing Protocol [trailerhouse] [ In reply to ]
Quote | Reply
trailerhouse wrote:

and set wheel circumference to 2096 (700x23c).

It seems to me that you should get on the bike and roll it marking the distance for one revolution of a wheel to get an accurate measurement of wheel circumference (i.e., circumference is dependent on more variables than just wheel diameter and tire size, e.g., rim width, tire pressure, etc.)
Quote Reply
Re: Platypus Thread: Aero Virtual Elevation Testing Protocol [hugoagogo] [ In reply to ]
Quote | Reply
Good point. Thanks!

hugoagogo wrote:
trailerhouse wrote:

and set wheel circumference to 2096 (700x23c).


It seems to me that you should get on the bike and roll it marking the distance for one revolution of a wheel to get an accurate measurement of wheel circumference (i.e., circumference is dependent on more variables than just wheel diameter and tire size, e.g., rim width, tire pressure, etc.)

What's your CdA?
Quote Reply
Re: Platypus Thread: Aero Virtual Elevation Testing Protocol [trailerhouse] [ In reply to ]
Quote | Reply
trailerhouse wrote:
Awesome, my Power2Max reports zeros and it's supposed to auto zero as well when you coast.

I'd be careful with that, since it may be detecting "coasting" from zero cadence reported. In other words, it may not auto zero in that condition like a PT hub would (i.e. during soft-pedaling).

http://bikeblather.blogspot.com/
Quote Reply
Re: Platypus Thread: Aero Virtual Elevation Testing Protocol [Tom A.] [ In reply to ]
Quote | Reply
Tom A. wrote:

Actually, it's my opinion that zero power data points help the accuracy and precision of the VE calculations, in that most power meters report zero power fairly accurately AND precisely ;-)

Yes, though some PMs lag when starting up again so you can see the speed increasing even though the power will be zero for a second or two. That's annoying.

Tom A. wrote:
Because of that, I will "soft pedal" (i.e. turning cranks but not engaging freewheel) on the downhill portions of my "half-pipe" style course, with the added benefit from using a PT hub set to "autozero on coasting" of having the PM re-zeroed ("calibrated" in Garmin parlance) continuously throughout the test run. With a crank-based PM, the soft-pedaling should result in the power reading being zero as well (or very close)...if not, then the PM may need to be re-zeroed, or you might want to look at cleaning the drivetrain ;-)

For flat courses, I like to follow the "Shen Method" protocol of continuously increasing speed and power across a few laps, with the final lap having as much coasting as possible.


Trailerhouse: Your should listen to Tom A.'s suggestions. He gets better precision from testing than I do, damn him.
Last edited by: RChung: Dec 18, 18 13:05
Quote Reply
Re: Platypus Thread: Aero Virtual Elevation Testing Protocol [Tom A.] [ In reply to ]
Quote | Reply
I just want to note that testing requires a slightly different mindset with regards to power application. It actually takes a bit of practice to intentionally soft pedal and not engage the freehub. Personally I try to avoid stationary legs as a slight change in where one stops pedaling (level vs one leg down), heel drop, etc can really throw one’s results off.
Quote Reply
Re: Platypus Thread: Aero Virtual Elevation Testing Protocol [trailerhouse] [ In reply to ]
Quote | Reply
Another tip I would add is to start with doing repeats in the exact same position and setup. I would do at least 3 and preferrably 5-6. Until you've done that you don't really know the precision/repeatability of your testing. This will test evertything from powermeter precision to your ability to hold the same position. Once you know your repeatability you know which kind of changes in drag you should be able to test for - no idea trying to test for differences of ~1W if your precision is 10 times that.
Quote Reply
Re: Platypus Thread: Aero Virtual Elevation Testing Protocol [MTM] [ In reply to ]
Quote | Reply
Thank you. I want to make sure my protocol is effective so I won't be making any kind of changes in my position and equipment until I can get some consistent results across different runs and different sessions.

What's a good CV to aim for? I'm thinking <1.5% between runs.

When I was out this weekend I also used the CdaCrr Android app
It looks like the numbers correlate well with Aerolab and that's another control I'll use. What's nice about this app is that it gives you a CdA for each lap when you hit the lap button. In my first run I got a 1.7% CV and as I got used to riding the course I got 1.0% on the second run.

MTM wrote:
Another tip I would add is to start with doing repeats in the exact same position and setup. I would do at least 3 and preferrably 5-6. Until you've done that you don't really know the precision/repeatability of your testing. This will test evertything from powermeter precision to your ability to hold the same position. Once you know your repeatability you know which kind of changes in drag you should be able to test for - no idea trying to test for differences of ~1W if your precision is 10 times that.

What's your CdA?
Quote Reply
Re: Platypus Thread: Aero Virtual Elevation Testing Protocol [trailerhouse] [ In reply to ]
Quote | Reply
I found it somewhat useful to do a series of ABBA runs with gross differences like sitting up in the hoods vs. TT position when tuning my protocol. To me this was better for protocol tuning than just doing AAAA runs. YMMV.
Quote Reply
Re: Platypus Thread: Aero Virtual Elevation Testing Protocol [trailerhouse] [ In reply to ]
Quote | Reply
A run-to-run CV of 1.5% is decent, should be ~0.003-0.004 m2 for most people. That will roughly speaking mean you will be able to discern differences of ~3W or greater at 40-45 kph. Unless your powermeter is also very stable I doubt you will be able to do better than that (I have a 1st gen Power2Max and I don't think that would be able to give consistent enough data to produce less than 1.5% CV).

Within run CV I guess can be good for getting better at holding position and checking stuff doesn't change within a run, but it would be the differences between runs I would be interested in.

Consistency between days is a bit tougher. So many things can change that doesn't usually change as much within a few hours - air temperature, air pressure, humidity, tire/road temperature, wind direction. I think you would be hard pressed to get CV of less than 1.5% between days.
Quote Reply
Re: Platypus Thread: Aero Virtual Elevation Testing Protocol [MTM] [ In reply to ]
Quote | Reply
I think you can learn a lot about the nature of variability by looking at the VE profiles of a delta mass test.
Quote Reply
Re: Platypus Thread: Aero Virtual Elevation Testing Protocol [Tom A.] [ In reply to ]
Quote | Reply
Not pedaling, with most ANT+ power meters is a pretty terrible idea sadly. You're better off turning the cranks without pressing on... (But even that is worse than just pedaling)
Quote Reply
Re: Platypus Thread: Aero Virtual Elevation Testing Protocol [motd2k] [ In reply to ]
Quote | Reply
motd2k wrote:
Not pedaling, with most ANT+ power meters is a pretty terrible idea sadly. You're better off turning the cranks without pressing on... (But even that is worse than just pedaling)

But I didn't say to "not pedal", I said to turn the cranks slow enough that the freewheel still coasts...A.K.A. "soft-pedaling".

http://bikeblather.blogspot.com/
Quote Reply
Re: Platypus Thread: Aero Virtual Elevation Testing Protocol [MTM] [ In reply to ]
Quote | Reply
MTM wrote:
Another tip I would add is to start with doing repeats in the exact same position and setup. I would do at least 3 and preferrably 5-6. Until you've done that you don't really know the precision/repeatability of your testing. This will test evertything from powermeter precision to your ability to hold the same position. Once you know your repeatability you know which kind of changes in drag you should be able to test for - no idea trying to test for differences of ~1W if your precision is 10 times that.


IMO, one should also attempt what Doc Coggan call's "The Tom Compton Challenge" (cue RChung discussing "delta mass" instead :-)

http://bikeblather.blogspot.com/...ng-chung-method.html

http://bikeblather.blogspot.com/
Quote Reply
Re: Platypus Thread: Aero Virtual Elevation Testing Protocol [AndyF] [ In reply to ]
Quote | Reply
I have a chance to do a few hours of indoor track testing and I have a couple questions about the best approach for doing the data analysis. I have been working on my outdoor VE testing on a loop with about 3 m of elevation change and I can get fairly repeatable results with AeroLab, but the lack of elevatio change has a bit flummoxed . So here goes.

1. I came across a post from Tom A with the regression method (page 14 of the thread) and was wondering if that would be preferable to virtual elevation when you don't have any elevation change (i.e., riding the apron of the track). Also regarding the regression method. Is there a source/documentation explaining the different inputs or is there a spreadsheet available? I looked at the axes on Tom's graph and how you get from something like wattage to "average wind pressure N/m^2" is a little confusing, given that watts are N-m/s.

2. I vary power output across different laps for VE testing, but one of the early post recommends holding a constant speed on the track. The regression method looks like varying speed would be best for estimating slope. It would seem that VE might be better with constant speed. Any insights into the most appropriate riding technique would be appreciated.

3. Is it possible to monitor changes in temperature, pressure and humidity with a relatively inexpensive weather station like one I would find at the hardware store?
Quote Reply
Re: Platypus Thread: Aero Virtual Elevation Testing Protocol [trailerhouse] [ In reply to ]
Quote | Reply
Follow-up to my original thread from a few weeks ago... It's been windy out here in FL with all the cold fronts and so I didn't get around to do too much real life testing. However with the extra time around the holidays and some time spent on weekends I starting rolling my own implementation of the VE algorithm as a web app. I played with Golden Cheetah's Aerolab but I wanted to have the ability to more easily select different segments, run my analysis and save the inputs so I can tweak them later and also keep a history of tests and compare different runs within those tests. But mostly this was an opportunity for me to learn some new technologies I've been meaning to play with outside of my day-to-day software job.

So far I've implemented the basics and it seems to be working OK with the limited test data that I have ( who wants to estimate their Zwift CdA? :-) ) A rough (for now) description and some screen shots are available here and a beta installation is available at https://mycda.app if you'd like to check it out.

The code is free and it's posted up on GitHub. Accounts are free and I intend to keep it that way unless the cost of hosting this thing turns out to be too much. If anything you could download the source code, install it locally and run it that way if you really wanted to. I don't anticipate needing to support thousands of users or anything so I should be able to keep this running on a minimal Google Firebase account.

I've still have a few things to figure out and a few more features in the pipeline but I'd like your feedback and if you've done tests before and have some .FIT files laying around I'd appreciate if you'd try them out and let me know if the results match your previous calculations or if you find any bugs. Also, I'm very open for suggestions on new features so please let me know what you'd like to see added.

I'm also I'm looking to add an FAQ / help section with general info on aero VE testing and more details on how to get started using the app and the protocol to follow. I think for someone who's familiar with the concepts it should be self explanatory but for the every day person out there it might require some additional guidance.

Let me know if you run into any issues.
Thanks!!

Edit:
A few notes about file support. Currently it only supports single sport files (no triathlon / multi sport combined files) and the FIT file needs to be fully formatted (included the session and lap average fields). Will be enhancing the parser so that stuff such as activity average power, average speed, etc.. is calculated from the data points if they are not present in separate fields). Also planning to add some more user feedback for file format issues.

What's your CdA?
Last edited by: trailerhouse: Feb 8, 19 10:54
Quote Reply
Re: Platypus Thread: Aero Virtual Elevation Testing Protocol [trailerhouse] [ In reply to ]
Quote | Reply
Thanks to those who signed up and provided feedback. I've implemented a few fixes which should hopefully resolve a few of the issues that I've seen happening. I did not anticipate some different flavors of .fit files being thrown at this thing and the import user error reporting was a little sketchy.
1. If there's an import error the new activity will no longer hang and you'll see it marked as error. There's an "Error Details" button next to it which should hopefully give you more info in some cases.
2. Validating that import file is type cycling and not triathlon / multisport etc.
3. Importing custom .fit files with missing activity and lap stats (avg. power, avg. speed etc). In this cases the app will calculate the stats from individual data points.
4. Small fixes in the VE algorithm to make it more resilient to data anomalies (dropouts etc.)

What's your CdA?
Quote Reply
Re: Platypus Thread: Aero Virtual Elevation Testing Protocol [trailerhouse] [ In reply to ]
Quote | Reply
MyCdA seems great indeed, I confirm I got some issues with my Fit files (now solved). Will you support Fit developer field for airspeed (or air density) for instance ?

Blog | Twitter| Bike CdaCrr app
Last edited by: bugno: Feb 8, 19 23:11
Quote Reply
Re: Platypus Thread: Aero Virtual Elevation Testing Protocol [bugno] [ In reply to ]
Quote | Reply
Thank you for trying it out and glad I was able to make it work for you. I'll look into adding support for developer fields. Do you have some example files containing air speed or other fields?

bugno wrote:
MyCdA seems great indeed, I confirm I got some issues with my Fit files (now solved). Will you support Fit developer field for airspeed (or air density) for instance ?

What's your CdA?
Quote Reply
Re: Platypus Thread: Aero Virtual Elevation Testing Protocol [trailerhouse] [ In reply to ]
Quote | Reply
Thanks Great app. We did some Velodrome aero testing this week in which we used raw numbers to determine Cda and aerolab. The test had the raw numbers and aerolab within .001-.0015 of each other. I just ran your app while very easy and nicely laid out the absolute CdA was about .005 higher than the other two methods. (It was fairly consistent which is what most of us want). I'm not smart enough to understand why there is was difference nor do I know which method is closer to true absolute CdA, just wanted to share the data.

BoulderCyclingCoach.com
Quote Reply
Re: Platypus Thread: Aero Virtual Elevation Testing Protocol [rockdude] [ In reply to ]
Quote | Reply
Might be because Aerolab also uses a drivetrain / mechanical / friction loss parameter as input to their calculation and I didn't include that yet. It amounts to about 1% if you're using a crank / pedal based PM which nowadays it's pretty much the norm as powertap hubs are not as popular anymore. I'll probably include it implicitly in the calculation or as a profile setting with a 1% default.

What's your CdA?
Quote Reply
Re: Platypus Thread: Aero Virtual Elevation Testing Protocol [trailerhouse] [ In reply to ]
Quote | Reply
There in lies the difference. Drive train/mechanical loss is likely around 3% with the wheels, BB, chain, pedals etc. It would be a nice to have a adjustable setting in future upgrades. Great product! thanks for sharing it.

BoulderCyclingCoach.com
Quote Reply
Re: Platypus Thread: Aero Virtual Elevation Testing Protocol [bugno] [ In reply to ]
Quote | Reply
I've looked into developer fields and should be doable. Checked into one of the files that failed the import and they were missing the session and activity definition messages which I'm reliant upon and according to FIT SDK should be present. This caused the rest of the import to fail - this should be fixable either in the app that generates the file or I could make the parse a little more forgiving.
I guess the only question is if an air speed field is present in the file then the name of the field needs to be stored in configuration per user or as an activity setting. I wish there was a standard field for this, maybe it's coming in a next iteration of the SDK. With all the new aero stick devices I'm thinking there should be a standard way to capture this type of data soon.

bugno wrote:
MyCdA seems great indeed, I confirm I got some issues with my Fit files (now solved). Will you support Fit developer field for airspeed (or air density) for instance ?

What's your CdA?
Quote Reply
Re: Platypus Thread: Aero Virtual Elevation Testing Protocol [trailerhouse] [ In reply to ]
Quote | Reply
Quick update on MyCdA. I've been busy adding adding a bunch of new features which I think are really useful additions to the app. Here's what changed since the last time I posted here:

- You can now define a Drivetrain Loss (%) in your user profile and include this adjustment in CdA calculation. If using a hub based power meter this should probably be either 0 or 1% or in case of a crank based one depending on drivetrain condition and if you're using optimized chains and ceramic bearing this could be something between 3% and 10% if you're riding with a rusted old chain :)
- You can define segments from the CdA analysis screen, either by lap or free selection from the chart and save your analysis for each one along with a name, description and all parameters used in the calculation
- You can designate segments as "baseline" segments. Calculate CdA % Delta, Watts Saved and Seconds / 40k estimated for each segment / run when compared to the baseline. Also now showing average CdA, CV and SD for all segments in an activity
- Added mapping support: if your activity has GPS data this is now displayed on a map and synced with the activity chart to show Start / End points for the activity and selection as well as the location of the current chart data point on the map.
- Displaying optional lap markers on the VE chart in case you use laps to separate each loop.
- Added an FAQ to help troubleshoot file import issue and to describe an example protocol to follow while collecting data.

Hope you enjoy using the app and again, any feedback is appreciated. Thanks!

What's your CdA?
Last edited by: trailerhouse: Mar 7, 19 10:34
Quote Reply
Re: Platypus Thread: Aero Virtual Elevation Testing Protocol [trailerhouse] [ In reply to ]
Quote | Reply
Very nice. I'll check it out.
Quote Reply
Re: Platypus Thread: Aero Virtual Elevation Testing Protocol [trailerhouse] [ In reply to ]
Quote | Reply
I think at least a WAG Crr adjustment factor would be really helpful for most users. So assuming you are using reasonable tire inflation based on Josh Portner's et al. information you could provide reasonable scaling factors classes. For example, crummy chip-seal with frost cracks is 1.8 times Tom A's roller Crr, decent asphalt is 1.5, cement is 1.4, poorly finished wood velodrome is 1.2, smooth wood velodrome 1.1.

I am suggesting this because I am just making up these correction factors. I welcome anyone's WAG values.
Quote Reply
Re: Platypus Thread: Aero Virtual Elevation Testing Protocol [grumpier.mike] [ In reply to ]
Quote | Reply
If I'm in a hurry I use rules of thumb like yours, too. When it matters, I estimate both CdA and Crr from the data.
Quote Reply
Re: Platypus Thread: Aero Virtual Elevation Testing Protocol [RChung] [ In reply to ]
Quote | Reply
Well so far I am only now getting to the point that I think my VE testing works OK for CdA estimation. I noticed the "Estimate CdA and Crr" button on Aerolab, but it crashes when I try it. Is there a protocol for the ride that is required for the use of this feature, such as a type of lap (e.g., loops with elevation gain, velodrome,...). I understand the know elevation approach from the slide set you wrote, but that would take some fairly extensive file editing. I don't know if my problems with the simultaneous estimation of both parameters is related to the data I am trying use.
Quote Reply
Re: Platypus Thread: Aero Virtual Elevation Testing Protocol [grumpier.mike] [ In reply to ]
Quote | Reply
That's intended for flat loops (like, a velodrome). If you aren't on a velodrome (or a flat loop) you need to know the exact loop length, and then ride consistently enough that the lengths don't vary (don't go wide on the corners sometimes and then cut them close on others). That's one of the things that can be improved in v.2 of Aerolab: being able to specify lap lengths rather than to fit over the whole data set.
Quote Reply
Re: Platypus Thread: Aero Virtual Elevation Testing Protocol [grumpier.mike] [ In reply to ]
Quote | Reply
Sounds like a good idea. Wish there was some test data on real world Vs. roller crr for different surfaces.

grumpier.mike wrote:
I think at least a WAG Crr adjustment factor would be really helpful for most users. So assuming you are using reasonable tire inflation based on Josh Portner's et al. information you could provide reasonable scaling factors classes. For example, crummy chip-seal with frost cracks is 1.8 times Tom A's roller Crr, decent asphalt is 1.5, cement is 1.4, poorly finished wood velodrome is 1.2, smooth wood velodrome 1.1.
I am suggesting this because I am just making up these correction factors. I welcome anyone's WAG values.

What's your CdA?
Quote Reply
Re: Platypus Thread: Aero Virtual Elevation Testing Protocol [trailerhouse] [ In reply to ]
Quote | Reply
There's some anecdotal evidence but, if the test protocol is reliable, you can estimate both CdA and Crr so you don't have to rely exclusively on guesses and corrections.

That said, I often use Crr guesses to put me in the right ballpark.
Quote Reply
Re: Platypus Thread: Aero Virtual Elevation Testing Protocol [grumpier.mike] [ In reply to ]
Quote | Reply
grumpier.mike wrote:
For example, crummy chip-seal with frost cracks is 1.8 times Tom A's roller Crr, decent asphalt is 1.5, cement is 1.4, poorly finished wood velodrome is 1.2, smooth wood velodrome 1.1.

On the road where I used to do aero testing, I assumed .004 Crr at 80F when it was good asphalt. When they chipsealed it, that went up to ~.0075. The smooth shoulder that just had a layer of tar was nearly as high at ~.007. Speed on that road dropped ~1.5mph for the same power. With age it got better, but it's still ~1mph hit.

Chipseal is the devil, but it depends a lot on the aggregate they use, how soft the tar is, and whether they use a smooth fill coat over the top. The part of the Moriarty road that was refinished a few years back is actually chipseal over asphalt, but it's very smooth. I suspect it is still not very fast, but it seems better than the "old" pavement on that course.
Quote Reply
Re: Platypus Thread: Aero Virtual Elevation Testing Protocol [RChung] [ In reply to ]
Quote | Reply
RChung wrote:
That's intended for flat loops (like, a velodrome). If you aren't on a velodrome (or a flat loop) you need to know the exact loop length, and then ride consistently enough that the lengths don't vary (don't go wide on the corners sometimes and then cut them close on others). That's one of the things that can be improved in v.2 of Aerolab: being able to specify lap lengths rather than to fit over the whole data set.

This deserves a good dope slap/Homer Simpson "DOH!". Once you said "flat loop" it occurred to me that no elevation gain is equivalent to a climb with a start and finish where you know the evaluation change is zero. I am amazed at my ability to overlook the obvious.
Quote Reply
Re: Platypus Thread: Aero Virtual Elevation Testing Protocol [grumpier.mike] [ In reply to ]
Quote | Reply
grumpier.mike wrote:
RChung wrote:
That's intended for flat loops (like, a velodrome). If you aren't on a velodrome (or a flat loop) you need to know the exact loop length, and then ride consistently enough that the lengths don't vary (don't go wide on the corners sometimes and then cut them close on others). That's one of the things that can be improved in v.2 of Aerolab: being able to specify lap lengths rather than to fit over the whole data set.


This deserves a good dope slap/Homer Simpson "DOH!". Once you said "flat loop" it occurred to me that no elevation gain is equivalent to a climb with a start and finish where you know the evaluation change is zero. I am amazed at my ability to overlook the obvious.

At some point I guess I should do an explanation video or something. Some of these things seem clear to me but it's cuz I've thought about it for a while, and I forget that not everyone sees things the same way as I do.
Quote Reply
Re: Platypus Thread: Aero Virtual Elevation Testing Protocol [ In reply to ]
Quote | Reply
I did some testing early this morning ,as the wind was low (UK).
Was testing 40cm bars vs 44 and surprised to find the 44s ' faster'
Looking at the weather data,the temperature went up by 2--3degC,and the solar radiation doubled (from ~50w/m2 to ~100) during the time I was on the road.
I set off from the house, so tyres were 'warm' then presumably cooled outside, then I switched the bars (inside the house),and went back out.
I didn't do ABA ,so am unsure if this is a real difference,and wonder if anyone has experience of w/m2 affecting crr?
( I compensated for ambient temp change)
Interestingly the garmin recorded a swing of ~9 deg C over the time I was out,compared to 2 deg from the weather station.
Thoughts welcome!
Quote Reply
Re: Platypus Thread: Aero Virtual Elevation Testing Protocol [kevinkeegan] [ In reply to ]
Quote | Reply
That's a big swing in temperature. Depending on what the starting conditions were, a 9 deg C. increase in temp can mean 2-3% decrease in air density, and also a decrease in Crr. The smaller the change in position or equipment, the more careful you have to be in tracking changes in conditions. Was the difference between the 40 and the 44 on that order of size, or was it larger than that?

[edited to add:] This method is sensitive enough to detect changes in the weight of air. Fortunately, if you keep track of the temperature and barometric pressure (humidity makes a small amount of difference, too) you can calculate the weight of the air and account for it. That's pretty cool.
Last edited by: RChung: May 12, 19 20:21
Quote Reply
Re: Platypus Thread: Aero Virtual Elevation Testing Protocol [RChung] [ In reply to ]
Quote | Reply
The swing between setups I get as 3.8% (road bike,drops,from 40cm to 44 cm bars,44 being faster
Using the weather station data (about a mile away)- the air density reduced by a max of 0.85%

Looking back at the data:
The weather station recorded a +3 degree (celsius) temp change outside.
(It also showed zero wind at the beginning,going up to between 1 & 2 kmh by the end of testing)
The Garmin showed a 6 degree drop during '40' testing,but no drop on '44' testing ( the sun had come out a bit more)

I am wondering that if the Garmin showed this,were the tyres experiencing something similar ?

I do have an infrared thermometer (at work),that I will try out if I get a chance
Last edited by: kevinkeegan: May 12, 19 22:16
Quote Reply
Re: Platypus Thread: Aero Virtual Elevation Testing Protocol [kevinkeegan] [ In reply to ]
Quote | Reply
kevinkeegan wrote:
I do have an infrared thermometer (at work),that I will try out if I get a chance
Better to use something that measures air temp (and isn't in direct sunlight), not surface temp (highly influenced by emissivity and sun exposure).
Quote Reply
Re: Platypus Thread: Aero Virtual Elevation Testing Protocol [MattyK] [ In reply to ]
Quote | Reply
MattyK wrote:
kevinkeegan wrote:
I do have an infrared thermometer (at work),that I will try out if I get a chance

Better to use something that measures air temp (and isn't in direct sunlight), not surface temp (highly influenced by emissivity and sun exposure).
Right, air temp is really what to measure.

Did you [kevinkeegan] zero your torque between the runs? I do that when there are wide swings in temperature -- even though some PMs say they compensate for (or are immune to) temperature variation, it's good practice to do so. And, of course, some PMs are better for this sort of thing than others.
Quote Reply
Re: Platypus Thread: Aero Virtual Elevation Testing Protocol [RChung] [ In reply to ]
Quote | Reply
 

Did you [kevinkeegan] zero your torque between the runs? I do that when there are wide swings in temperature -- even though some PMs say they compensate for (or are immune to) temperature variation, it's good practice to do so. And, of course, some PMs are better for this sort of thing than others.[/quote]
I didn't zero torque.Am using powertap wheel,and did plenty of coasting.
The air temperature didn't actually vary much(from 6 to 9 degC)
Will zero torque the next time
Quote Reply
Re: Platypus Thread: Aero Virtual Elevation Testing Protocol [kevinkeegan] [ In reply to ]
Quote | Reply
kevinkeegan wrote:
...
I didn't do ABA ,so am unsure if this is a real difference
...

I hope this doesn't come off as too negative. But if you didn't do ABBA and convince yourself you can reproduce your results it is pretty hopeless for any of us to try to draw conclusions. I wasted quite a bit of time/runs back when I was doing this kind of testing working with poor protocols and thus having junk results (it has been a few years since I did any aero testing). I wish I had been urged more strongly to do ABBA testing as the very first thing and not move on to anything else until I was sure I had that nailed.
Quote Reply
Re: Platypus Thread: Aero Virtual Elevation Testing Protocol [jbank] [ In reply to ]
Quote | Reply
jbank wrote:
I wish I had been urged more strongly to do ABBA testing as the very first thing and not move on to anything else until I was sure I had that nailed.

If possible do ABABAB etc...

Seems to me that a good first step is to see what SD or CV you can acheive when you are not changing anything.
Quote Reply
Re: Platypus Thread: Aero Virtual Elevation Testing Protocol [rruff] [ In reply to ]
Quote | Reply
I don't think it's always necessary to do ABABAB... testing. Sometimes it's clear after an AB comparison that something is wrong and you should either postpone to another day|venue|PM|speed sensor| or else measure your rho more carefully or else convert the test session to practice runs to refine your protocols.

Even a bad run can provide you with good information -- just sometimes what you learn is what not to do the next time.
Quote Reply
Re: Platypus Thread: Aero Virtual Elevation Testing Protocol [AndyF] [ In reply to ]
Quote | Reply
Hello,

I'm planning to do my first aero testing in the following days. Given the density of traffic where I live, I have decided (unless you have any reasons against it) my best bet is to do my testing in an outdoor 185m concrete velodrome and follow the black line. From my testing, I'd like to be able to distinguish CdA and Crr because ideally I'd like to be able to reasonably compare CdA values from one testing session to the next one (that is, one position should give a close enough CdA value testing in separate days). I haven't found a clear enough protocol, but I think the consensus is:

  • Record the whole test in one file, and every run as a lap within the file.
  • The runs should be long enough, I think 10 laps of the track is okay (1.85 km).

    • Should they be longer? Is it better to make them shorter?
  • Each of the runs should be building speed, let's say from 15 km/h to 45 km/h (Shen method)

    • Do this have to be precise (ie. I increase 3 km/h every 3 laps) or is it okay if I just build the speed but without being particularly precise about the specifics?
    • Should the steps of the speed build be long enough? For example, keep the same speed every 3 laps or build each lap
    • Do I have to come back down again to 15 km/h ?
  • Do alternate runs with the set ups you want to test. For example, A/B/C/C/B/A
  • Analyze every run (a lap in the file) as an individual ride in golden cheetah and play with CdA and Crr until I get a flat virtual elevation, but:

    • How flat is flat enough?
  • The velodrome is around a soccer/rugby pitch, I highly doubt I'm going to find any other cyclist but, do I have to worry about people playing affecting my results?
  • My area is a bit windy, what is considered still enough? Below 10 km/h wind? 15 km/h?



Thanks a lot in advance, really looking forward to hear from you.
Last edited by: dense: Aug 27, 19 1:48
Quote Reply
Re: Platypus Thread: Aero Virtual Elevation Testing Protocol [dense] [ In reply to ]
Quote | Reply
185m is okay, as long as you can follow the black line; sometimes on very short tracks the turns are so tight that you may go wide on the transitions -- just do the best you can.

You don't have to build your speed by equal increments on a set schedule: the raison d'etre for this method is cuz I couldn't follow a constant speed or power method, so I needed to come up with something that was more practical to follow.

You don't have to come back down in speed -- but you can if you want. That would give you another way to check the CdA/Crr estimates.

The VE profile is, above all, a diagnostic of fit. Although you're actually riding on a velodrome, the virtual amplitude of the laps should be pretty small but even and easily discernible. If not, then it was too windy.
Quote Reply
Re: Platypus Thread: Aero Virtual Elevation Testing Protocol [RChung] [ In reply to ]
Quote | Reply
Thanks for the clarifications, hopefully it goes well!
Quote Reply
Re: Platypus Thread: Aero Virtual Elevation Testing Protocol [dense] [ In reply to ]
Quote | Reply
For a 185m long track I would estimate the curve radius to be around 17m. With 45km/h on the black line you will have a lean angle of around 45° thus you center of gravity will go down and up about 50cm twice a round. When you get the speed from a wheel sensor Virtual Elevation a la Chung will overestimate your elevation variation, i.e. you will clearly see the half laps in the virtual elevation profile.
VE is a quit good and robust method to solve the underlying equation of motion. It will underestimate Cda a little on a short track with tight turns.
To get both Cda and Crr from a single fit of some laps in GC Virtual Elevation is very optimistic. As I know VA in GC doesn‘t account for higher rolling resistance in the curves and some other tricky problems arising from cycling in turns are not considered. Above all, the dependance of power from Cda is higher than from Crr at reasonable speeds making it difficult to get a reliable fit of a model. But may be I am just too stupid to do it.
Quote Reply
Re: Platypus Thread: Aero Virtual Elevation Testing Protocol [BergHugi] [ In reply to ]
Quote | Reply
Might be a bit too optimistic, I have no idea. Worst case scenario I hope to be able to make A/B comparisons. Anyway, this week I'm only going there to try see how everything works. I'll let you know.
Quote Reply
Re: Platypus Thread: Aero Virtual Elevation Testing Protocol [BergHugi] [ In reply to ]
Quote | Reply
BergHugi wrote:
To get both Cda and Crr from a single fit of some laps in GC Virtual Elevation is very optimistic. As I know VA in GC doesn‘t account for higher rolling resistance in the curves and some other tricky problems arising from cycling in turns are not considered. Above all, the dependance of power from Cda is higher than from Crr at reasonable speeds making it difficult to get a reliable fit of a model.

To separate the instantaneous CdA from the instantaneous Crr is hard, so I usually just think about the CdA and Crr over lap-length intervals, averaging over both the straights and the turns. In addition, there are small non-zero yaw effects on a velodrome (since you're going 'round and 'round in one direction) that will bias the estimates. But these are relatively small effects and, if you need to know, there are ways to get around them (though they're a pain in the butt to do so you really have to want to go to that extra effort). The different dependence of aero drag and rolling drag with speed is the reason why you want a wide range of speeds -- the thing you have to worry about is dipping into a realm where the Re number is changing.

I agree that GC's Aerolab needs a refresher. If I could code in a credible way I'd've done it myself.
Quote Reply
Re: Platypus Thread: Aero Virtual Elevation Testing Protocol [BergHugi] [ In reply to ]
Quote | Reply
BergHugi wrote:
Above all, the dependance of power from Cda is higher than from Crr at reasonable speeds making it difficult to get a reliable fit of a model. But may be I am just too stupid to do it.

You're right on. Making Crr a variable while trying to determine CdA differences doesn't work well. It's far better to make an educated guess on Crr and insure that it's the same for configuration A as B.

Also, I did several repeatable tests this summer that indicate that Crr is highly speed dependent (increasing with speed). This was by testing slow and fast runs on ~1% grade with a strong tailwind (~15km/hr), to remove the affect of aero drag as much as possible. It could be that something else was wonky, but increasing Crr with speed was the only thing I found that fit the data. I was measuring airspeed, BTW.
Quote Reply
Re: Platypus Thread: Aero Virtual Elevation Testing Protocol [dense] [ In reply to ]
Quote | Reply
dense wrote:
Might be a bit too optimistic, I have no idea. Worst case scenario I hope to be able to make A/B comparisons. Anyway, this week I'm only going there to try see how everything works. I'll let you know.

If swapping between A and B is easy, then do it several times.

Don't get discouraged if your first time doesn't work out. Good controlled testing isn't easy, it takes some know-how and practice.
Quote Reply
Re: Platypus Thread: Aero Virtual Elevation Testing Protocol [rruff] [ In reply to ]
Quote | Reply
rruff wrote:
Also, I did several repeatable tests this summer that indicate that Crr is highly speed dependent (increasing with speed). This was by testing slow and fast runs on ~1% grade with a strong tailwind (~15km/hr), to remove the affect of aero drag as much as possible. It could be that something else was wonky, but increasing Crr with speed was the only thing I found that fit the data. I was measuring airspeed, BTW.

Depends on the surface, I suspect. I've done tests on out-and-back courses (both "half-pipe" and relatively flat). On the flat courses, I vary the speed widely over the same spots on the course in the different directions; on half-pipes, I go slower on the climbs than on the descents over the same spots on the course. If Crr were highly speed dependent on those courses, the mirrored VE profiles wouldn't match. In either case, the VE profile is a diagnostic: different types of mismatches in the VE reflect different types of errors.
Quote Reply
Re: Platypus Thread: Aero Virtual Elevation Testing Protocol [rruff] [ In reply to ]
Quote | Reply
rruff wrote:
Don't get discouraged if your first time doesn't work out. Good controlled testing isn't easy, it takes some know-how and practice.

Yeah. My kid is trying to learn to play the guitar and you can't expect to sound like Clapton the first time out. VE is easier than learning to play the guitar but, like almost all things worth doing, practice helps.
Quote Reply
Re: Platypus Thread: Aero Virtual Elevation Testing Protocol [RChung] [ In reply to ]
Quote | Reply
RChung wrote:
In either case, the VE profile is a diagnostic: different types of mismatches in the VE reflect different types of errors.

Would be really cool to have software that would identify and diagnose those anomalies...

The road was pretty decent but lumpy asphalt (not chipseal) with some gravel and tar patches. I got Crr ~.0030 at 20km/hr and ~.0045 at 40km/hr. Seems like a speed dependence like that would be hard to separate from CdA without conditions like I had (uphill, tailwind), since the drag vs speed relationship is so similar.
Quote Reply
Re: Platypus Thread: Aero Virtual Elevation Testing Protocol [rruff] [ In reply to ]
Quote | Reply
rruff wrote:

Would be really cool to have software that would identify and diagnose those anomalies...


Well, if you do loops or out-and-backs over that road at varying speeds you can try plotting the segment CdA/Crr against position on the course to see whether variation in either is specific to location or to speed. That's what I do. But I use my own routines to do that.
Quote Reply
Re: Platypus Thread: Aero Virtual Elevation Testing Protocol [RChung] [ In reply to ]
Quote | Reply
Had a go at testing after finally finding what I thought was a decent spot. Since I'm new to this, was wondering if anyone had any critiques/insights. I didn't have time to do A/B etc. So I just repeated laps of a half pipe to get familiar with the protocol/analysis.

Does the half pipe look too short? It felt like I was either descending pretty rapidly or slowing rapidly. Didn't feel like a time trial where I'm on close to flat ground for extended periods. But maybe that is ok? I was thinking maybe my posture on the bike may be a bit different.

I thought my turn-arounds were pretty poorly executed while riding, but now looking at the plots it doesn't seem so bad (?). The road was decent, but there were a couple spots where there were seams or rough spots. I guess for that you would assume the crr is just a bit worse?

Thanks!


Quote Reply
Re: Platypus Thread: Aero Virtual Elevation Testing Protocol [brbbiking] [ In reply to ]
Quote | Reply
600 meters one-way isn't too short, but I'm a little confused by the scale on the y-axis: is that also meters?
Quote Reply
Re: Platypus Thread: Aero Virtual Elevation Testing Protocol [RChung] [ In reply to ]
Quote | Reply
Oops, apparently I had imperial units selected in my profile so it was somehow mixing units. Anyway, changed to metric in my profile and rebooted GC, and here's the new plot:


Quote Reply
Re: Platypus Thread: Aero Virtual Elevation Testing Protocol [brbbiking] [ In reply to ]
Quote | Reply
Yesterday I did some runs in an outdoor velodrome. Do the larger undulations look like wind? From other posts, I understand there will be some effect from the cornering, but I'm thinking those are the smaller ones? Is it a reasonable run for a velodrome, or does it look like I was encountering too much wind?

Thanks for any insights.

Edit: New thought: The larger undulations may be straying further from the black line and hitting more banking on the shorter sides of the track? They also tend to increase in size as I was going faster (later in a run), which would make sense.


Last edited by: brbbiking: Sep 26, 19 7:31
Quote Reply
Re: Platypus Thread: Aero Virtual Elevation Testing Protocol [brbbiking] [ In reply to ]
Quote | Reply
What's the length of the velodrome, what power meter are you using, and what are you using to calculate rho?
Quote Reply
Re: Platypus Thread: Aero Virtual Elevation Testing Protocol [RChung] [ In reply to ]
Quote | Reply
400 meter velodrome, Quarq dzero sram red powermeter, and used Golden Cheetah's calculator/estimator for rho. I was a little concerned with the power meter, because I repeated zeroing, and it still seemed to jump around a bit (e.g., 585, 576, 585). For rho, I have a kestrel device I am getting, so next time should be more accurate (I can also more easily check for wind).
Quote Reply
Re: Platypus Thread: Aero Virtual Elevation Testing Protocol [brbbiking] [ In reply to ]
Quote | Reply
OK, so those undulations look to be about 400m apart. Since the velodrome is 400m, I'd expect peaks at 200m unless you're getting something that happens only once per lap -- and the most likely thing is, as you suspected, wind.

The good news is that your eta should be a little less than 1.0 since you're using a crank-spider based power meter, so your total drag is actually a bit lower. I'd use something like 0.97 or so for eta.

The rho calculator in Golden Cheetah assumes you're using "station" barometric pressure, i.e., if you're using "official weather station" baro pressure you have to adjust for altitude. If you're anywhere near sea level you don't have to make any adjustment. If you're at altitude and using official weather station pressure, there are online calculators that'll calculate rho exactly but a rough rule of thumb is that for each 100m gain in altitude above sea level you should reduce rho by 1%.
Quote Reply
Re: Platypus Thread: Aero Virtual Elevation Testing Protocol [RChung] [ In reply to ]
Quote | Reply
That makes sense, thanks a lot, Robert.

(And thanks to the others that contributed to this old thread, I've learned a lot.)
Quote Reply
Re: Platypus Thread: Aero Virtual Elevation Testing Protocol [brbbiking] [ In reply to ]
Quote | Reply
Power meter offset issues


(Quarq Dzero Sram Red)


Did some more runs at the velodrome. Up to this point, I have been zeroing my PM after each run (just to make sure) -- getting 3 successive offsets that are equal or very close. Today, I did ABAB (laps 2, 4, 6, 8 below), but zeroed only between 4 and 6. And you can see that the second set of AB have a significantly higher CdA. So I'm thinking it was the PM difference in offset that threw things off.

So, is there something wrong with my PM? In theory, I should be able to zero it more often, and that would be better (judging by earlier posts in this thread)? But actually that makes my results less consistent. I'm usually there for less than an hour, so temperature differences are usually not too significant (and the PM should be able to adjust via calculations anyway). So I can just not zero the PM from here on out (other than once at the beginning), but I'm wondering if there's actually something off with my PM. I haven't done anything like calibrating against a known weight. I should likely update the firmware, although not sure if that would change anything.

I was thinking of just getting a Powertap hub, since it seems like that's what a lot of folks use, and then I wouldn't have to worry about estimating the Eta/drivetrain-loss value. But not sure if it would be susceptible to the same sort of problem anyway.


Quote Reply
Re: Platypus Thread: Aero Virtual Elevation Testing Protocol [brbbiking] [ In reply to ]
Quote | Reply
I don't have any experience with the Dzero.

What were runs 10, 12, 14, 16, and how did they differ from 2, 4, 6, 8? They appear to be pretty consistent.
Quote Reply
Re: Platypus Thread: Aero Virtual Elevation Testing Protocol [RChung] [ In reply to ]
Quote | Reply
I adjusted the pad stack a bit before runs >= 10, again alternating ABAB (just a different helmet for A vs B). Yeah, the results look much more consistent after that point. It could be that the offset was off for 4 and 6.

Although, in general my results haven't been very consistent, and I think it was probably because I was getting different offsets for my PM, and zeroing too much. I think I'll try just zeroing once at the beginning of a session, since my sessions don't last that long so I don't expect much change due to temperature. I also updated my firmware, and I may at some point try calibrating the slope with a known weight.
Quote Reply
Re: Platypus Thread: Aero Virtual Elevation Testing Protocol [brbbiking] [ In reply to ]
Quote | Reply
In an ideal world, if your offset is off (but doesn't change) then your Crr will be wrong but your CdA should be OK. If you slope is off (but doesn't change) your CdA will be wrong but your Crr should be okay. If your slope is off (but doesn't change) absolute differences in CdA will be wrong but the relative differences should be okay (so setup A will have the same relationship to setup B).

Since Crr scales like slope, if your offset is off the amplitude of the VE profiles will be off but the peaks and valleys should be in the same places.

At least, I think so.
Last edited by: RChung: Oct 3, 19 13:30
Quote Reply
Re: Platypus Thread: Aero Virtual Elevation Testing Protocol [RChung] [ In reply to ]
Quote | Reply
That seems to make sense. In my case I haven’t been teasing apart cda/crr (eg via Shen method). Instead I have been assuming a crr value based on independently reported rolling resistance for the tire type and multiplying by a small factor for the velodrome surface. So I guess my cda will still be off even if only my pm offset is incorrect (since the error is not “absorbed†by the crr). (Of course, it may already be incorrect since I’m assuming a crr, but it seemed more accurate than what I would estimate via the Shen method — maybe I’m doing it wrong). But I would still get the relative cda’s.
Quote Reply
Re: Platypus Thread: Aero Virtual Elevation Testing Protocol [brbbiking] [ In reply to ]
Quote | Reply
brbbiking wrote:

I was thinking of just getting a Powertap hub, since it seems like that's what a lot of folks use, and then I wouldn't have to worry about estimating the Eta/drivetrain-loss value. But not sure if it would be susceptible to the same sort of problem anyway.

IMO, the offset issues are accentuated on a Powertap hub cause the measured torque is lower on the hub compared to the torque at the chainring because of the bigger gear ratio used at high speed for aero testing. I get more reproducible results since I switched to a Power2max during morning sessions with changing temperature conditions.

Blog | Twitter| Bike CdaCrr app
Quote Reply
Re: Platypus Thread: Aero Virtual Elevation Testing Protocol [brbbiking] [ In reply to ]
Quote | Reply
I would do as you suggest yourself and just not zero between runs when the temperature (and pressure) is not changing much anyway. I have seen the same issue with both the older Quarq (Red) and an older Powertap. I strictly use SRM now - one very nice thing about that is that I can check the ZO without actually saving it, so I can go in and check that it still is around the same value without actually introducing any noise by saving the value.
Quote Reply
Re: Platypus Thread: Aero Virtual Elevation Testing Protocol [MTM] [ In reply to ]
Quote | Reply
I do not zero while testing but do zero at the end and record it.
I use a Quarq as my reference from tests to test but I also ride with Favero pedals. To date they have always tracked very well.

I also measure asphalt temperature at beginning and end of a session. I find that has a bigger impact on my results than PM drift.
Quote Reply
Re: Platypus Thread: Aero Virtual Elevation Testing Protocol [MTM] [ In reply to ]
Quote | Reply
Good to know I'm not the only one, and others have taken a similar approach. Maybe in the future I'll invest in a higher quality PM like the Power2Max Bugno (wow, cool that it is +- 1% accurate), or the SRM.
Quote Reply
Re: Platypus Thread: Aero Virtual Elevation Testing Protocol [marcag] [ In reply to ]
Quote | Reply
That's a good point about the surface temperature. Actually, in general I wasn't factoring temperature into the crr. Looking at the following, seems that could affect it quite a bit: https://fitwerx.com/...in-the-cold-weather/ .
Quote Reply
Re: Platypus Thread: Aero Virtual Elevation Testing Protocol [marcag] [ In reply to ]
Quote | Reply
marcag wrote:
I also measure asphalt temperature at beginning and end of a session. I find that has a bigger impact on my results than PM drift.

What you do with that number?

IME the tire temperature tends to track ~1/3 of the way between the asphalt and air temperatures. This can have pretty huge effect on Crr if it's sunny.
Quote Reply
Re: Platypus Thread: Aero Virtual Elevation Testing Protocol [rruff] [ In reply to ]
Quote | Reply
rruff wrote:
marcag wrote:
I also measure asphalt temperature at beginning and end of a session. I find that has a bigger impact on my results than PM drift.


What you do with that number?

IME the tire temperature tends to track ~1/3 of the way between the asphalt and air temperatures. This can have pretty huge effect on Crr if it's sunny.

I should clarify. In the past I would take air temperature, asphalt temperature and tire temperature. I still do now and then but much less frequently.
I would then try to correlate each of them to CRR and I could.

But since air temperature is easiest to record, I now use that with pretty good results. I do adjust my CRR to temperature in a way very similar to what Tom A posted here a while back.
Quote Reply
Re: Platypus Thread: Aero Virtual Elevation Testing Protocol [marcag] [ In reply to ]
Quote | Reply
What did you find when you measured them all? I'm hoping to eventually get good day to day consistency outdoors, and the effect of road temperature is too big to ignore.
Quote Reply
Re: Platypus Thread: Aero Virtual Elevation Testing Protocol [rruff] [ In reply to ]
Quote | Reply
rruff wrote:
What did you find when you measured them all? I'm hoping to eventually get good day to day consistency outdoors, and the effect of road temperature is too big to ignore.

Do you correct CRR with temperature ?
Quote Reply
Re: Platypus Thread: Aero Virtual Elevation Testing Protocol [marcag] [ In reply to ]
Quote | Reply
Yes. What I'm wondering is what you got for the relationship between the temperature of air, road, and tire in different conditions.

1%/F is a 20% difference in Crr if the tire is 20F hotter than the air. With my data that's about a 6% difference in CdA... way too much to ignore.
Quote Reply
Re: Platypus Thread: Aero Virtual Elevation Testing Protocol [rruff] [ In reply to ]
Quote | Reply
2 deg C, say between 20 and 22 deg (ambient) should give about 2% in CRR difference
Quote Reply
Re: Platypus Thread: Aero Virtual Elevation Testing Protocol [marcag] [ In reply to ]
Quote | Reply
So you are using 1%/C. You only saw a 2C difference between tire and air on a sunny day? I get way higher differences.
Quote Reply
Re: Platypus Thread: Aero Virtual Elevation Testing Protocol [rruff] [ In reply to ]
Quote | Reply
  
I use a formula that gives % of a reference CRR based on temperature. It's actually closer to 3% if I compare 20 and 22 deg celcius.
Last edited by: marcag: Oct 5, 19 3:52
Quote Reply
Re: Platypus Thread: Aero Virtual Elevation Testing Protocol [rruff] [ In reply to ]
Quote | Reply
rruff wrote:
So you are using 1%/C. You only saw a 2C difference between tire and air on a sunny day? I get way higher differences.


Also, I wonder if you may be seeing three things

Imagine

a) your air density is skewed/innaccurate....from day to day
b) your PM is fluctuating with temp
c) your Crr is fluctuating with temp

I am immune to A because I don't need air density in my calculations
Last edited by: marcag: Oct 5, 19 5:40
Quote Reply
Re: Platypus Thread: Aero Virtual Elevation Testing Protocol [marcag] [ In reply to ]
Quote | Reply
I'm measuring temperature and pressure, so air density shouldn't be an issue.


Regardless, it's a fact that on a sunny day the tire temperature will be a lot hotter than the air. Just checked near my house today after I got back from a ride. Air was 70F, road was 103F, tire was 86F... while going ~15mph. So if you are adjusting Crr for temperature, just using air temp doesn't cut it.
Quote Reply
Re: Platypus Thread: Aero Virtual Elevation Testing Protocol [RChung] [ In reply to ]
Quote | Reply
RChung wrote:
OK, so those undulations look to be about 400m apart. Since the velodrome is 400m, I'd expect peaks at 200m unless you're getting something that happens only once per lap -- and the most likely thing is, as you suspected, wind.

For some reason I can't see that image very well so I'm not commenting on that specifically.

Another possibility is the track itself is not flat.

Don't know which track this is but many of the ~400m cycle tracks around country town cricket ovals in Australia have a height differential. There's one in Queanbeyan for instance with a pronounced variance in elevation from one side to the other. Gosford isn't flat, neither is Lidcombe. Goulburn has a slight variance. It's not uncommon for there to be a faster and slower side of an outdoor track unrelated to wind.

http://www.cyclecoach.com
http://www.aerocoach.com.au
Quote Reply
Re: Platypus Thread: Aero Virtual Elevation Testing Protocol [rruff] [ In reply to ]
Quote | Reply
  


rruff wrote:
I'm measuring temperature and pressure, so air density shouldn't be an issue.


Regardless, it's a fact that on a sunny day the tire temperature will be a lot hotter than the air. Just checked near my house today after I got back from a ride. Air was 70F, road was 103F, tire was 86F... while going ~15mph. So if you are adjusting Crr for temperature, just using air temp doesn't cut it.


Go out and measure CRR against ambient temp. Plot it and you will get an equation good enough to adjust CRR. Tom A had done something similar I think it's somewhere on ST.

While I didn't do the exercise for temp or road temp, I did measure them and see a correlation between ambient temp. I suspect if I did the exact same thing I could get equations for those. I didn't because it is not practical for me to use those during testing.

Now if I had a ladida tire pressure/temp sensor, maybe I would.

But right now you and I have much bigger sources of error to worry about.

My comment on air density is that I also get much better consistency in my results when I don't use air density. This may be partially due to the fact I measure over very long loops (15km) where barometric pressure, temperature and relative humidity vary more. I am pretty sure I can find two points on the course that are more than 2% difference in air density at a given time. If your CRR is varying, your PM is varying (due to temp) and air density is varying, that isa lot of varying. My point, poorly made was the fewer variables, the better.

The reason I test over 15km loops comes to comments made in the future of testing thread, I don't have time to do 15 measurements every 3km loop when I am out riding. I want to train and get aero data at the same time. If a device allows me to get better or marginally better data with less futsing, that's a win. Very much a personal opinion.
Last edited by: marcag: Oct 6, 19 6:53
Quote Reply
Re: Platypus Thread: Aero Virtual Elevation Testing Protocol [marcag] [ In reply to ]
Quote | Reply
marcag wrote:
But right now you and I have much bigger sources of error to worry about.

I must confess, I really don't know what you are talking about...

It's impossible to get good results if you ignore important variables. Assuming that Crr is only dependent on ambient temperature (rather than tire temperature) can be a 6% error in CdA as I showed earlier. I'm measuring temperature and pressure in real time with CdACrr, so density isn't an issue. And my PM is zeroed before and in the middle of every run (Powertap). The temperature variation on my course is quite small anyway. This would generally be the case when testing. It's sounds like you are just using your TT data as a CdA test? That's obviously going to have greater challenges and error.
Quote Reply
Re: Platypus Thread: Aero Virtual Elevation Testing Protocol [rruff] [ In reply to ]
Quote | Reply
rruff wrote:
marcag wrote:
But right now you and I have much bigger sources of error to worry about.


I must confess, I really don't know what you are talking about...

It's impossible to get good results if you ignore important variables. Assuming that Crr is only dependent on ambient temperature (rather than tire temperature) can be a 6% error in CdA as I showed earlier. I'm measuring temperature and pressure in real time with CdACrr, so density isn't an issue. And my PM is zeroed before and in the middle of every run (Powertap). The temperature variation on my course is quite small anyway. This would generally be the case when testing. It's sounds like you are just using your TT data as a CdA test? That's obviously going to have greater challenges and error.


I am not sure how/where you showed the 6%.

Here is the thread where Tom A talks about correcting CRR with ambient temp.
https://forum.slowtwitch.com/...%20temp%20q#p3916843

Too bad some of the charts aren't there anymore.

I am curious how your app corrects air density as you move around the course. I suspect it reads the closest weather station ? If so, how often does it refresh and how does it correct as you roll around the course

I do not use my TT exclusively. I use my TT, I do velodrome, I have done Alphamantis velodrome testing, I do small loops using Aerolab,, , I have been to the wind tunnel to confirm numbers....

Nobody is ignoring variables. What I said was some devices do not need air density, therefore eliminating a source of error/noise.

If you are gtting very different numbers from day to day I suspect there is more to it than temp impact on CRR
Last edited by: marcag: Oct 6, 19 10:53
Quote Reply
Re: Platypus Thread: Aero Virtual Elevation Testing Protocol [marcag] [ In reply to ]
Quote | Reply
Post #469. Tire temperature relative to ambient can vary enough to cause a big error.

Temperature, pressure, and humidity are measured on the bike, and density is calculated from these. I assume your probe measures dynamic pressure, so density is included in that. The WF meter might also be measuring that actually, which is why the calibration factor on airspeed varies. It would be nice if that's the case.

I was getting very consistent numbers until I started testing in the morning rather than the afternoon...
Quote Reply
Re: Platypus Thread: Aero Virtual Elevation Testing Protocol [marcag] [ In reply to ]
Quote | Reply
marcag wrote:


Go out and measure CRR against ambient temp. Plot it and you will get an equation good enough to adjust CRR. Tom A had done something similar I think it's somewhere on ST.

How do you measure CRR? Is it so easy to get reliable and precise values for CRR?
Quote Reply
Re: Platypus Thread: Aero Virtual Elevation Testing Protocol [rruff] [ In reply to ]
Quote | Reply
rruff wrote:

Post #469. Tire temperature relative to ambient can vary enough to cause a big error.


This ?

rruff wrote:

What I'm wondering is what you got for the relationship between the temperature of air, road, and tire in different conditions.

1%/F is a 20% difference in Crr if the tire is 20F hotter than the air. With my data that's about a 6% difference in CdA... way too much to ignore.


I do not know how you got at 1% is a 20%....if tire is hotter than air....

the correction does not look at ambient vs tire temp/


rruff wrote:

temperature, pressure, and humidity are measured on the bike, and density is calculated from these.


Measured by the phone ?

rruff wrote:

I assume your probe measures dynamic pressure, so density is included in that.


kind of.

rruff wrote:

The WF meter might also be measuring that actually, which is why the calibration factor on airspeed varies. It would be nice if that's the case.


Calibration would be required wether a pitot or a traditional anemometer.
Last edited by: marcag: Oct 6, 19 14:13
Quote Reply
Re: Platypus Thread: Aero Virtual Elevation Testing Protocol [BergHugi] [ In reply to ]
Quote | Reply
BergHugi wrote:
marcag wrote:


Go out and measure CRR against ambient temp. Plot it and you will get an equation good enough to adjust CRR. Tom A had done something similar I think it's somewhere on ST.


How do you measure CRR? Is it so easy to get reliable and precise values for CRR?

There are protocols for doing on the road. Personally I only got good results under very constrained conditions. The idea is that by riding a various speeds you can figure out CDA and CRR because they . track differenttly with speed. But other factors sometimes get in the way.

I do test rolling resistance with a protocol laid out by Tom A on rollers. I get very good results. 2 years ago I tested a bunch of tires and the results were confirmed by a lab in Norway.

I use that as my base CRR and correct it. I also have pothole detection which must be disabled in Quebec :-)

I do believe we can get to very good road testing of CRR as some of the tech out there improves and removes some of the constraints I mentioned above.
Quote Reply
Re: Platypus Thread: Aero Virtual Elevation Testing Protocol [RChung] [ In reply to ]
Quote | Reply
I probably missed this, but how is the entering speed of a lap accounted for? E.g., it seems like folks often throw out the first lap, so they would be starting a run at some non-zero speed which could vary from run to run. Is it in practice insignificant, or am I missing something?
Quote Reply
Re: Platypus Thread: Aero Virtual Elevation Testing Protocol [brbbiking] [ In reply to ]
Quote | Reply
brbbiking wrote:
I probably missed this, but how is the entering speed of a lap accounted for? E.g., it seems like folks often throw out the first lap, so they would be starting a run at some non-zero speed which could vary from run to run. Is it in practice insignificant, or am I missing something?
Ah. Well, depending on the length of the lap, no, it might not be insignificant. So I take the initial speed into account to calculate the kinetic energy component of the equation, and also the second before the start of the lap so I can calculate the acceleration.
Quote Reply
Re: Platypus Thread: Aero Virtual Elevation Testing Protocol [marcag] [ In reply to ]
Quote | Reply
I'll try an example. If you are using Tom's factor that's 1.4%/C. So you adjust Crr based on ambient air temperature. Say you are testing on a cloudy day and the tire temperature is the same as the air temperature. No problem then. The next day you test on a sunny afternoon in summer. The road temperature is 30C hotter than the air and the tire temperature is 12C hotter than the air. These are realistic numbers. Your ambient air temperature correction for Crr is going to be off by 12C*1.4% or 16.8%. That would result in ~5% error in CdA. I don't see an alternative to actually measuring the tire temperature (or at least the road) unless you restrict testing to conditions where the road and air temperature are the same. Or if you are testing A vs B with lots of swapping and don't care about the raw number.

The app uses pressure from the phone. The WF meter measures pressure, temperature, and humidity. You can also use a Garmin temperature sensor if you wish.
Quote Reply
Re: Platypus Thread: Aero Virtual Elevation Testing Protocol [rruff] [ In reply to ]
Quote | Reply
rruff wrote:
IThe road temperature is 30C hotter than the air and the tire temperature is 12C hotter than the air. These are realistic numbers.


30C ? really ? So for example outdoor temp is 25C and road is 55C ?

Have you actually measured the impact on CRR or is this theoretical ? Do you have data that correlates tire temperature to CRR ?

I can tell you what I did. I ride for 4-5 hours (IM Training). I start at 8AM and finish at noon-1PM or 10am to 3PM, same road, some position.If I don't correct, my "CDA" slowly decreases.In fact it's my CRR that is improving. I adjust as per Tom A's formula (or something very close) and CDA is constant.

If you have data that show better ways of correcting, I;d be more than happy to try.

BTW, I am getting pretty close to good on road CRR estimation. If I get there, my previous way of adjusting may go out the window, but for now, it's been pretty consistent
Quote Reply
Re: Platypus Thread: Aero Virtual Elevation Testing Protocol [marcag] [ In reply to ]
Quote | Reply
I've measured that the tire temperature tends to run ~1/3 between the road and air temperature at high speed. Isn't tire temperature the thing that is actually affecting the Crr? Air temperature is a poor proxy for that if you are riding on a sunlit road.
Quote Reply
Re: Platypus Thread: Aero Virtual Elevation Testing Protocol [rruff] [ In reply to ]
Quote | Reply
rruff wrote:
I've measured that the tire temperature tends to run ~1/3 between the road and air temperature at high speed. Isn't tire temperature the thing that is actually affecting the Crr? Air temperature is a poor proxy for that if you are riding on a sunlit road.


In the thread I referenced earlier, Tom A says

"if you look earlier in that wattagetraining.com forum thread, you'll see some data I took that basically shows that tire temperature ends up being a fixed amount above the ambient air temp."

Have you seen different ?
Quote Reply
Re: Platypus Thread: Aero Virtual Elevation Testing Protocol [marcag] [ In reply to ]
Quote | Reply
Wasn't that roller testing in his garage?
Quote Reply
Re: Platypus Thread: Aero Virtual Elevation Testing Protocol [rruff] [ In reply to ]
Quote | Reply
rruff wrote:
Wasn't that roller testing in his garage?

I don't know but probably

This is what I do know. I've measured ambient temperature vs CRR and got pretty consistent results.

However I have never tried or seen conditions where road temp is 30deg higher than ambient. I have always seen ambient/road/and tire track together more or less.

Maybe road temp or tire temp would have a better correlation with CRR. It would have to be measured to see. Without mesasuring we're speculating.

Ambient to CRR is easy to measure and I saw good correlation.

I'd be more than happy to collect it but it's not something very practical to do and especially to correlate. I believe there are bigger fish to fry in the determination/correction of CRR.
Quote Reply
Re: Platypus Thread: Aero Virtual Elevation Testing Protocol [RChung] [ In reply to ]
Quote | Reply
Did some testing today, and this was pretty interesting (at least to me 😃).

In the below, we have ABAB (2,4,6,8). You see the same undulations from the wind as before (coincides with the laps of the velodrome). But you see them more prominently for B. B was a higher position, and it looks to be more susceptible to the effects from the wind (worse in head wind, better in tailwind, overall a bit worse).


Quote Reply
Re: Platypus Thread: Aero Virtual Elevation Testing Protocol [brbbiking] [ In reply to ]
Quote | Reply
Very nice. Yeah, it looks like B is, overall, not as good as A.

As Fred Mosteller was fond of saying, "although the data speak for themselves, their voices can be soft and sly." I think VE is sort of an amplifier to raise the volume.
Quote Reply
Re: Platypus Thread: Aero Virtual Elevation Testing Protocol [AndyF] [ In reply to ]
Quote | Reply
I've submitted a Golden Cheetah feature request, after a difficulty I found recently doing some off-road CRR testing. I'm not sure how many people use the Aerolab chart for off-road testing. I'm sure the vast majority of users are doing CdA analyses for TT/Tri bikes.

The problem I encountered is that the CRR slider only goes to a maximum of 0.01, whereas my analysis needed to set a CRR greater than 0.01 (see chart below). Even on rough chipseal, the CRR for knobbly cyclocross tyres was around 0.01. This limitation in GC meant that I had to do the VE calculation outside of GC, in Excel. That gave the same result, but takes quite a bit more time.

If this is a very niche application, it's obviously not worth modifying GC. Perhaps a good option would be to create an alternative "off-road" version of the Aerolab Chung Analysis Chart, allowing CRRs up to at least 0.03. That would allow the fine scale of the current chart to be retained for the majority of road applications. By the way, "0.03" isn't a mistake, it's not missing a zero! My testing suggested it really could be that high. It's incredible to think rolling resistance losses off-road are an order of magnitude more than on the road, with about 150W (~half the losses) going into overcoming rolling resistance on a flat grass course.



I wanted to do this test to see if there is an optimum tyre pressure off road, in terms of CRR, for the purposes of my local summer cyclocross race series (which probably won't happen this year!). The conventional wisdom amongst CX racers is to set pressures as low as possible, but I couldn't find data to support this. It was also unclear to me how much this low pressure recommendation is coming from traction considerations. I found the results of this test quite interesting and surprising. There seems to be no minima for best usable pressure. The traditional practice of setting pressure as low as possible seems like a good one, even when only considering CRR. The differences seen in the session 3 repeats I think could be due to the grass becoming somewhat flattened from the multiple laps during the session 2 runs.

All this suggests suspension losses dominate over tyre deformation hysteresis losses for this kind of off-road situation.
Last edited by: NickD1: Apr 27, 20 13:51
Quote Reply
Re: Platypus Thread: Aero Virtual Elevation Testing Protocol [NickD1] [ In reply to ]
Quote | Reply
 

What does your test protocol look like ?
Quote Reply
Re: Platypus Thread: Aero Virtual Elevation Testing Protocol [NickD1] [ In reply to ]
Quote | Reply
Nice. Your finding of "the lower the pressure, the faster" matches up with some old MTB studies done by the Swiss MTB team (IIRC) that found the same thing. My suspicion is that this is the case because off-road, the loss properties of the surface become relatively more important than the tire loss properties. In other words, the ground "squish" is the dominant factor.

This also shows why tubulars are still such a big deal in CX. Due to the fact that lower pressures are "faster", ideally they should be using tires significantly wider than 34mm...but, they can't. So, in order to make lower pressure "work", they rely on the fact that narrow tubulars aren't going to roll off a rim and/or "burp", plus a bit of lower pinch flat occurance.

I'm a bit surprised at the .01 CRR for the Schwalbe on chipseal...although maybe I shouldn't be. The only tire I've roller tested so far with a similar knob structure in the center has been the Conti Terra Trail, and those knobs don't look to be as large as the ones on the X-Ones, and the Terra Trail was predicted to run ~.006 on smooth pavement.

Interesting stuff. I too would love to see more description of your protocol. Thanks for sharing!

http://bikeblather.blogspot.com/
Quote Reply
Re: Platypus Thread: Aero Virtual Elevation Testing Protocol [rruff] [ In reply to ]
Quote | Reply
rruff wrote:
Wasn't that roller testing in his garage?

I didn't catch this back in October, but no, my temp readings were of actual tire temperature outside while riding using a handheld IR thermometer. Even on sunny days, the tire temperature tracked the air temp.

Oh yeah, and to get the air temp reading, I placed a small plastic "placard" on the bike, hung by a string that basically "tumbled" in the air in a shaded spot on the bike. I took an IR reading of that to get the air temp just so I'd be using the same instrument for both the tire and air temp.

It appeared that due to the large amount of convective cooling, the tire temp basically tracked the air temp (at an offset of course...I forget the amount). I had already done the trials of roller Crr vs. ambient temperature on a Conti GP4K, and so decided to just correct for ambient air temp in the reported results. The fact that when I've run my "control" tire at varying ambient temps on the rollers and the results are basically identical tends to confirm it's a reasonable approach :-)

http://bikeblather.blogspot.com/
Quote Reply
Re: Platypus Thread: Aero Virtual Elevation Testing Protocol [Tom A.] [ In reply to ]
Quote | Reply
Tom A. wrote:
Interesting stuff. I too would love to see more description of your protocol. Thanks for sharing!

Thanks Tom. That's interesting and all make sense. I was also surprised by the 0.01 CRR on chipseal, but the loop I use is very rough and broken. It's local and traffic-free though, hence why I use it. When I've used my TT bike on the same loop, with Conti GP5Ks and Conti GPTTs, I need to use a CRR of around 0.006. I do sets of fast and slow laps, to try to separate aero and rolling resistance effects as much as possible.

I was thinking more about it today. Road surfaces, whether smooth or rough, don't yield at all under the pressure of bike tyres, whereas even quite dry off-road surfaces will deform if enough pressure is applied. I'm thinking about if someone walks across grass with either flat-soled shoes, or alternatively with high heels. Even a dry grass surface has a kind or plasticity, with the deformation related to the pressure applied. Since any plastic deformation doesn't return any energy, high pressure applications should be subject to more losses through this mechanism. I wonder if low tyre pressures causes less deformation of the underlying surface and therefore experiences smaller losses, as well as reducing the rider suspension losses.

Here is a description of the protocol I used:

- Stages G2 LH power meter. I realise this is not ideal, but it's all I've got.
- Tyre pressures measured with a digital Topeak pressure gauge. Possibly not accurate, but hopefully consistent.
- Garmin speed sensor. I realised after posting the chart this morning that my protocol has a slight flaw, because I didn't change the wheel circumference when I dropped the tyre pressure. Today, I measured the circumference changes, and there is almost a 2% reduction, going from 45psi to 15psi, so I need to correct the measured speeds and see how much that changes the CRR results. A slower speed for the lower pressures should give a higher CRR values for the lower pressures I think. I'll re-post the corrected chart once I do it.
- Air density: Pressure from the weather forecast app. Temperature from the Garmin head unit.
- 0.97 transmission efficiency assumed throughout.
- Bike + rider weighing before and after the ride.
- No adjustment for wind. Sessions 1-3 in the chart were done with the forecast wind being 10-15mph. From what I've read, the ground level wind speed is less that forecast wind speed by about half. My hope is that it would be consistent enough to give good enough increments between the pressures, even if the absolute numbers might be affected by the wind.

Tarmac runs
1) Tyres inflated to 45 psi.
2) 6 x laps of a tarmac oval loop, each lap 1 mile in length. First 3 laps done at ~230W, next 3 laps done at ~130W. No traffic.
3) VE analysis done in Golden Cheetah and Excel to check they give the same result, to check I haven't made a mistake in my Excel equations.
4) CdA and CRR determined post-ride so there is no elevation loss or gain over the six laps, trying also to keep the same flatness for the sets of fast and slow laps. The CdA derived from this analysis, 0.393, was then used for the VE analysis for the grass runs.

Grass runs
Straight from tarmac runs, I cycled about 1 mile to a local grass field, roughly the size of a football pitch.
1) I checked the pressure before starting at 45 psi.
2) Accelerated up to speed before the maximum elevation point of the lap. Pressed the start/stop on the Garmin about 5-10 seconds before the max elevation point.
3) 3 laps at ~230W, followed by 3 laps at ~130W. I changed gear only once at the transition between fast and slow sets of laps, to keep the cadence reasonable. The time to do six laps was 7-8 minutes. I tried to follow a consistent line, but I had to avoid an occasional dog walker, approximately once every 5 laps (and these days trying to give people at least 5 metres of space!)
4) After the max elevation point at the end of the 6th lap, I continued for ~10 seconds, and pressed start stop on the Garmin.
5) Stopped in the shade. I avoided direct sunlight when stopped to prevent the sun warming the tyres. I checked the pressures, before then reducing the pressure by 5psi ready for the next run. I could get it within 0.5psi of the target. If I overshot the reduction for the first tyre (e.g. 39.5psi), I compensated by leaving the other tyre half a psi higher (e.g. 40.5psi). I chose to reduce pressure, rather than increase it, because I was concerned that pumping the tyre up might increase the internal air temperature and possibly the tyre wall temperature. Letting pressure out was also easier.
6) Step 2 onwards was repeated for 45 psi down to 15 psi in steps of 5 psi.
7) I then went home (<1 mile away), pumped the tyres back to 40 psi with a track pump, returned and followed the same protocol, but in 10 psi steps (40, 30, 20 psi). I wanted to do these repeats because I hadn't done an ABAB type test, and also because the grass was becoming increasingly flattened, which I think might have affected the CRR.
8) I also did a few repeats two days later, on a less windy day (~5mph wind according to the forecast)
9) CRR values were obtained to give no elevation gain/loss over the 6 laps, using the fixed CdA of 0.393. I obviously tried to keep the same kit and position on the bike throughout.

There may be other things that I've forgotten to mention. If anything is unclear, please ask. Any suggestions or criticisms about the protocol also very welcome, of course.
Quote Reply
Re: Platypus Thread: Aero Virtual Elevation Testing Protocol [NickD1] [ In reply to ]
Quote | Reply
NickD1 wrote:
I've submitted a Golden Cheetah feature request .. The problem I encountered is that the CRR slider only goes to a maximum of 0.01, whereas my analysis needed to set a CRR greater than 0.01 (see chart below).

Hi Nick,

The Crr slider goes from 0.001 thru 0.015, are you using the latest release v3.5?
The maximum was fixed at the end of November 2016 literally days after we released 3.4, so was a long time coming !

Mark
Quote Reply
Re: Platypus Thread: Aero Virtual Elevation Testing Protocol [liversedge] [ In reply to ]
Quote | Reply
Hi Mark,

I just checked and, yeah, I'm using v3.4. I installed it a few years ago. The new upper limit of 0.015 will be enough for road purposes, for sure, but for off-road I think CRRs even large than 0.015 are needed. On the other hand, if I'm the only person using the Aerolab chart for off-road conditions, then it's not worth changing it just for one user.

Nick
Quote Reply
Re: Platypus Thread: Aero Virtual Elevation Testing Protocol [NickD1] [ In reply to ]
Quote | Reply
Will increase it, its trivial to do, even if just for one user :)

Cheers
Mark
Quote Reply
Re: Platypus Thread: Aero Virtual Elevation Testing Protocol [NickD1] [ In reply to ]
Quote | Reply
NickD1 wrote:
- Garmin speed sensor. I realised after posting the chart this morning that my protocol has a slight flaw, because I didn't change the wheel circumference when I dropped the tyre pressure. Today, I measured the circumference changes, and there is almost a 2% reduction, going from 45psi to 15psi, so I need to correct the measured speeds and see how much that changes the CRR results. A slower speed for the lower pressures should give a higher CRR values for the lower pressures I think. I'll re-post the corrected chart once I do it.

I just updated the chart in my original post, after correcting the speeds for reduced wheel circumference at lower pressures. Overall, it doesn't change the conclusion that lowest pressure is best. The gradient of the trendline through the red points has reduced by a factor of 0.85.
Quote Reply
Re: Platypus Thread: Aero Virtual Elevation Testing Protocol [liversedge] [ In reply to ]
Quote | Reply
liversedge wrote:
Will increase it, its trivial to do, even if just for one user :)

Cheers
Mark

Very nice. Thanks!
Quote Reply
Re: Platypus Thread: Aero Virtual Elevation Testing Protocol [RChung] [ In reply to ]
Quote | Reply
This is an example do it in Anadia velodrome. Wooden surface. There are many options for Crr and Cda values.

Any link where see specific protocol for indoor velodrome for calculate Cda and Crr values?

Is require to know when and where start the test?
Quote Reply
Re: Platypus Thread: Aero Virtual Elevation Testing Protocol [cyclistgo] [ In reply to ]
Quote | Reply
This is the same example.
Quote Reply
Re: Platypus Thread: Aero Virtual Elevation Testing Protocol [cyclistgo] [ In reply to ]
Quote | Reply
cyclistgo wrote:
This is an example do it in Anadia velodrome. Wooden surface. There are many options for Crr and Cda values.

Any link where see specific protocol for indoor velodrome for calculate Cda and Crr values?

Is require to know when and where start the test?

I’ve worked there, what tyres and pressures were you using?

AeroCoach UK
http://www.aero-coach.co.uk
Quote Reply
Re: Platypus Thread: Aero Virtual Elevation Testing Protocol [Xavier] [ In reply to ]
Quote | Reply
Vitoria Pista Speed. 9 front 14 rear.

My question is about if it´s possible to determine in stable test Cda and Crr or is necessary change velocity.
And with it we can get lot of combination numbers for Crr and Cda.
Quote Reply
Re: Platypus Thread: Aero Virtual Elevation Testing Protocol [cyclistgo] [ In reply to ]
Quote | Reply
cyclistgo wrote:
My question is about if it´s possible to determine in stable test Cda and Crr or is necessary change velocity.
And with it we can get lot of combination numbers for Crr and Cda.

Is it heresy? I was never able to perform a single stable test run on a wooden indoor track (200m, 45°, 17.75m curve radius) in order to determine Cda and Crr simultaneously.

It is often stated, that because power to overcome aero drag scales with the cube of speed and power to overcome rolling resistance scales linearly with speed it is possible to separate Cda and Crr. I was never successful to separate them with actual power data from an aero test on an indoor track. And I tried it often, with varying speeds, with a “live†system like the Garmin Track Aero System, with the Chung method, with multi variable nonlinear global fit methods … . Therefore I have built a Crr test rig with a big wooden drum to determine Crr for the aero tested wheels + tires + inner tubes combinations.
Quote Reply
Re: Platypus Thread: Aero Virtual Elevation Testing Protocol [BergHugi] [ In reply to ]
Quote | Reply
Interesting BergHugi. In this case which could be your best option?

I´m thinking in check Crr in https://www.bicyclerollingresistance.com/road-bike-reviews, and control all variables to mantain stable Crr or adjust. It will be possible for example to adjust Crr with pressure tyre and temperature?

And only use aerolab for calculate Cda.
Quote Reply
Re: Platypus Thread: Aero Virtual Elevation Testing Protocol [cyclistgo] [ In reply to ]
Quote | Reply
For aero testing of TT positions I would take a reasonably Crr value for example from https://www.bicyclerollingresistance.com/road-bike-reviews (Crr on a wooden track are on the lower end), do not change the wheels, try to do you runs at the same speed and use aerolab.For aero testing of wheels, try to do the runs at the same speed, same lap times, with equal tires and inner tubes. What takes less Watts is faster.
Quote Reply
Re: Platypus Thread: Aero Virtual Elevation Testing Protocol [BergHugi] [ In reply to ]
Quote | Reply
And if I will try to calculate exact cda value and Crr it will be possible with this methodology?
Quote Reply
Re: Platypus Thread: Aero Virtual Elevation Testing Protocol [cyclistgo] [ In reply to ]
Quote | Reply
Fix Crr and let CdA be the only variable in aerolab. You don't get the correct absolut value for CdA (How to measure a true absolut CdA? Does it even exist?), but it should be ok to compare different setups.
Quote Reply
Re: Platypus Thread: Aero Virtual Elevation Testing Protocol [BergHugi] [ In reply to ]
Quote | Reply
Ok I understand.

Then which could be the most accuracy protocol for calculate Crr isolted in velodrome?

I´m going again in July for more test and I want to try to get accuracy data for both, Crr and Cda.

For calculate Cda I want to do 3 test per setup at stable velocity, concretly at competition velocity, for compare repeatability. Each test around 3-4 minutes.
Quote Reply
Re: Platypus Thread: Aero Virtual Elevation Testing Protocol [cyclistgo] [ In reply to ]
Quote | Reply
cyclistgo wrote:
My question is about if it´s possible to determine in stable test Cda and Crr or is necessary change velocity.
And with it we can get lot of combination numbers for Crr and Cda.

Estimating CdA and Crr from the same data set is possible but it's pretty demanding of good data and good experimental technique. The short answer is it's necessary to change velocity. The fuller answer will require a little dip into statistical estimation. I'll try to keep it short and understandable.

In order to estimate two unknowns, you need to have at least two equations. If all your data are taken at a "stable test" at a single speed or power, you'll only have one equation so the system is undetermined. What's also true is that if the data vary but only by a little bit, you you can solve for estimates of CdA and Crr but the data are *nearly* collinear so although you were able to do the estimation, they're estimated poorly.

So, if you're trying to estimate both CdA and Crr from the same data set, you have to have a pretty wide range of speed and power--and it's good to have a lot of equations so you can check the precision of the estimates (there's a bunch of statistical mumbo-jumbo embedded in the last part of that sentence). A secondary issue is that you'd like the speed and power to be pretty accurate and precise, and a third issue is that you don't want there to be wild swings in speed and power because some power meters are a little sensitive and laggy in responding to big changes in power.

All together, if you want to separate CdA and Crr, you need accurate data and a wide range in speed and power.

Andy Shen once suggested a monotonically increasing speed protocol for velodrome testing: start slow and increase speed a little bit each lap. There are other ways to ensure that you get a pretty wide range in speed and power, but this will work. Find the top power you can sustain for a couple of laps, then start at perhaps half of that power, then each lap increase speed smoothly so that after 10 laps or so you're at your max that you can sustain without ruining your position. If you can, do a couple of extra laps slowing down in speed and power. A protocol like this ensures both a wide range in speed and power, and also keeps sudden changes in them relatively small.
Quote Reply
Re: Platypus Thread: Aero Virtual Elevation Testing Protocol [RChung] [ In reply to ]
Quote | Reply
RChung wrote:
Estimating CdA and Crr from the same data set is possible but it's pretty demanding of good data and good experimental technique. The short answer is it's necessary to change velocity. The fuller answer will require a little dip into statistical estimation. I'll try to keep it short and understandable.

In order to estimate two unknowns, you need to have at least two equations. If all your data are taken at a "stable test" at a single speed or power, you'll only have one equation so the system is undetermined. What's also true is that if the data vary but only by a little bit, you you can solve for estimates of CdA and Crr but the data are *nearly* collinear so although you were able to do the estimation, they're estimated poorly.

So, if you're trying to estimate both CdA and Crr from the same data set, you have to have a pretty wide range of speed and power--and it's good to have a lot of equations so you can check the precision of the estimates (there's a bunch of statistical mumbo-jumbo embedded in the last part of that sentence). A secondary issue is that you'd like the speed and power to be pretty accurate and precise, and a third issue is that you don't want there to be wild swings in speed and power because some power meters are a little sensitive and laggy in responding to big changes in power.

All together, if you want to separate CdA and Crr, you need accurate data and a wide range in speed and power.

Andy Shen once suggested a monotonically increasing speed protocol for velodrome testing: start slow and increase speed a little bit each lap. There are other ways to ensure that you get a pretty wide range in speed and power, but this will work. Find the top power you can sustain for a couple of laps, then start at perhaps half of that power, then each lap increase speed smoothly so that after 10 laps or so you're at your max that you can sustain without ruining your position. If you can, do a couple of extra laps slowing down in speed and power. A protocol like this ensures both a wide range in speed and power, and also keeps sudden changes in them relatively small.



In theory yes, under the assumption that both CdA and Crr are not dependent on any other variable and especially not dependent on speed.

But:

Both assumptions are questionable.

The normal force varies with speed on a track due to the centrifugal force in the turns


It is difficult to get a wide range in speed on a track without altering the position. One needs a minimum speed (> ~25 km/h) in the turns in order to stay on the track. To go over 50 km/h for some time is not given to everyone.

Overall one has to be very lucky to get such good data to separate CdA and Crr. I never had this luck.
Quote Reply
Re: Platypus Thread: Aero Virtual Elevation Testing Protocol [BergHugi] [ In reply to ]
Quote | Reply
BergHugi wrote:
In theory yes, under the assumption that both CdA and Crr are not dependent on any other variable and especially not dependent on speed.

But:

Both assumptions are questionable.

The normal force varies with speed on a track due to the centrifugal force in the turns


It is difficult to get a wide range in speed on a track without altering the position. One needs a minimum speed (> ~25 km/h) in the turns in order to stay on the track. To go over 50 km/h for some time is not given to everyone.

Overall one has to be very lucky to get such good data to separate CdA and Crr. I never had this luck.

The normal force varies within the lap so I calculate the average Crr over a lap, and I also calculate CdA and Crr over lap-length intervals. Since in this particular protocol you're varying speed in a monotonic fashion, it's easy to see if the estimates are speed-dependent.

But, I agree, estimating both from CdA and Crr from a single run is more demanding than assuming one value and turning the problem into a single parameter estimation problem.
Quote Reply
Re: Platypus Thread: Aero Virtual Elevation Testing Protocol [RChung] [ In reply to ]
Quote | Reply
RChung wrote:
cyclistgo wrote:

My question is about if it´s possible to determine in stable test Cda and Crr or is necessary change velocity.
And with it we can get lot of combination numbers for Crr and Cda.


Estimating CdA and Crr from the same data set is possible but it's pretty demanding of good data and good experimental technique. The short answer is it's necessary to change velocity. The fuller answer will require a little dip into statistical estimation. I'll try to keep it short and understandable.

In order to estimate two unknowns, you need to have at least two equations. If all your data are taken at a "stable test" at a single speed or power, you'll only have one equation so the system is undetermined. What's also true is that if the data vary but only by a little bit, you you can solve for estimates of CdA and Crr but the data are *nearly* collinear so although you were able to do the estimation, they're estimated poorly.

So, if you're trying to estimate both CdA and Crr from the same data set, you have to have a pretty wide range of speed and power--and it's good to have a lot of equations so you can check the precision of the estimates (there's a bunch of statistical mumbo-jumbo embedded in the last part of that sentence). A secondary issue is that you'd like the speed and power to be pretty accurate and precise, and a third issue is that you don't want there to be wild swings in speed and power because some power meters are a little sensitive and laggy in responding to big changes in power.

All together, if you want to separate CdA and Crr, you need accurate data and a wide range in speed and power.

Andy Shen once suggested a monotonically increasing speed protocol for velodrome testing: start slow and increase speed a little bit each lap. There are other ways to ensure that you get a pretty wide range in speed and power, but this will work. Find the top power you can sustain for a couple of laps, then start at perhaps half of that power, then each lap increase speed smoothly so that after 10 laps or so you're at your max that you can sustain without ruining your position. If you can, do a couple of extra laps slowing down in speed and power. A protocol like this ensures both a wide range in speed and power, and also keeps sudden changes in them relatively small.

Thanks RChung. Great explanation.

My doubt about this is if Cda is velocity dependent, and if we are doing many test at different velocities for estimate one value of Cda and one for Crr, could be that only Crr value is correct? Or neither?

I understand that we need 1 Crr but many Cda´s for each velocity.
Quote Reply
Re: Platypus Thread: Aero Virtual Elevation Testing Protocol [cyclistgo] [ In reply to ]
Quote | Reply
cyclistgo wrote:
My doubt about this is if Cda is velocity dependent, and if we are doing many test at different velocities for estimate one value of Cda and one for Crr, could be that only Crr value is correct? Or neither?

I understand that we need 1 Crr but many Cda´s for each velocity.

So, the important question for a cyclist isn't "are CdA and Crr speed-dependent?" The important question is "how speed-dependent are they over the range of speeds we experience as cyclists?" This has to do, in part, with the Reynolds number and how quickly it changes with speed. Over *most* of the ranges of speed we can go (that is, up to close to 50 km/h) the Reynolds number isn't *quite* constant but it changes very slowly. This may be different at much faster speeds, but it turns out that we ride at pretty low speeds. This is why we can test in a wind tunnel at an air speed of 50 km/h and use those measurements to predict CdA and thus drag at 40 km/h (or 35, or 30); and why our predictions from wind tunnels (and velodrome tests) get borne out at other speeds.

And, in a protocol like the one above we can actually observe how much speed-dependence there is in CdA and Crr.
Quote Reply
Re: Platypus Thread: Aero Virtual Elevation Testing Protocol [BergHugi] [ In reply to ]
Quote | Reply
BergHugi wrote:
It is often stated, that because power to overcome aero drag scales with the cube of speed and power to overcome rolling resistance scales linearly with speed it is possible to separate Cda and Crr. I was never successful to separate them with actual power data from an aero test on an indoor track.

Based on outdoor testing I'm pretty sure Crr increases with speed, making the relationship with power non-linear. At least that is the only way I could get curves to match.

There is also a more modest *reduction* of CdA with speed for most people.
Quote Reply
Re: Platypus Thread: Aero Virtual Elevation Testing Protocol [RChung] [ In reply to ]
Quote | Reply
Cda is dependent for velocity only for Reynolds number?

I´m trying to get most accuracy data for both, Crr and Cda in velodrome protocolo.

For regression method if Cda is not accuracy (for Reynolds number), can report Crr not accuracy, is this correct? Because one variable depend on the other.
Quote Reply
Re: Platypus Thread: Aero Virtual Elevation Testing Protocol [rruff] [ In reply to ]
Quote | Reply
rruff wrote:
Based on outdoor testing I'm pretty sure Crr increases with speed, making the relationship with power non-linear. At least that is the only way I could get curves to match.

If this were true, how would you explain not seeing it on indoor roller tests ?
Quote Reply
Re: Platypus Thread: Aero Virtual Elevation Testing Protocol [cyclistgo] [ In reply to ]
Quote | Reply
cyclistgo wrote:
Cda is dependent for velocity only for Reynolds number?
Um, maybe I made things more complicated than I should have. The essential piece is: over the speeds at which we usually ride, CdA is not dependent on speed. If it were, we wouldn't be able to predict pwer for speed based on wind tunnel tests that are done at a single speed.

Quote:
For regression method if Cda is not accuracy (for Reynolds number), can report Crr not accuracy, is this correct? Because one variable depend on the other.
In simple regression (and sometimes the CdA/Crr estimation problem can be set up as a simple regression problem) you're trying to find a line with a slope and an intercept. In the usual estimation problem, the slope is related to CdA and the intercept is related to Crr. If a data point is off, it will (usually) affect both the estimated slope and the estimated intercept -- so it will affect both CdA and Crr. Alternatively, if you think about fitting a regression line through a bunch of points, if the estimated intercept is too high, then the slope will be too shallow; and vice versa.
Quote Reply
Re: Platypus Thread: Aero Virtual Elevation Testing Protocol [marcag] [ In reply to ]
Quote | Reply
marcag wrote:
rruff wrote:

Based on outdoor testing I'm pretty sure Crr increases with speed, making the relationship with power non-linear. At least that is the only way I could get curves to match.


If this were true, how would you explain not seeing it on indoor roller tests ?

I do though not as much as for the outdoor tests, where there is an increase of ~50% between 10km/hr and 40km/hr.

It's important to remember that wee rollers are in imperfect representation of riding on even a perfectly smooth track. The same place where I got the roller scaling equations (Bicycling Science) also has a section on Crr testing that shows a dependence on V.
Quote Reply
Re: Platypus Thread: Aero Virtual Elevation Testing Protocol [RChung] [ In reply to ]
Quote | Reply
RChung wrote:
The essential piece is: over the speeds at which we usually ride, CdA is not dependent on speed. If it were, we wouldn't be able to predict pwer for speed based on wind tunnel tests that are done at a single speed.


When Dan Bigham did skinsuit tests in the velodrome he'd typically test at a range of speeds and showed CdA dropping with speed (typically, not always). https://www.cyclingweekly.com/...s-for-cycling-360975

If Crr increases with speed (as I believe it does) then the reduction in CdA with speed would be even higher than shown here:


Last edited by: rruff: Jun 4, 20 12:22
Quote Reply
Re: Platypus Thread: Aero Virtual Elevation Testing Protocol [marcag] [ In reply to ]
Quote | Reply
marcag wrote:
rruff wrote:

Based on outdoor testing I'm pretty sure Crr increases with speed, making the relationship with power non-linear. At least that is the only way I could get curves to match.


If this were true, how would you explain not seeing it on indoor roller tests ?

Did not do many tests with my test rig yet, but I saw a slight increase of Crr for a Schwalbe pro one TT from 0.0016 to 0.0018 increasing speed of the wooden drum (d = 90cm) from 20 km/h to 60 km/h

Loooking at tests of the recumbent community, they often observe an increase of Crr with speed
Quote Reply
Re: Platypus Thread: Aero Virtual Elevation Testing Protocol [rruff] [ In reply to ]
Quote | Reply
rruff wrote:
When Dan Bigham did skinsuit tests in the velodrome he'd typically test at a range of speeds and showed CdA dropping with speed (typically, not always). https://www.cyclingweekly.com/...s-for-cycling-360975
I was quite interested in those results when they were first published and I asked Wattshop if they would be willing to share the raw data. I never heard back from them. I guess they figured I wouldn't know how to analyze the data.
Quote Reply
Re: Platypus Thread: Aero Virtual Elevation Testing Protocol [BergHugi] [ In reply to ]
Quote | Reply
BergHugi wrote:
Looking at tests of the recumbent community, they often observe an increase of Crr with speed

Yeah. I've seen those claims, too. I'm sure that at very high speeds it does matter. The question is whether on a velodrome at more usual speeds whether the speed dependence is large or small.

I have a couple of data files from streamliner speed runs at Battle Mountain. There are a couple of anomalies but, as a whole, it appears that the speed dependence of CdA and Crr isn't huge in speeds from ~40 to ~75 mph (~65 to ~120 km/h).
Quote Reply
Re: Platypus Thread: Aero Virtual Elevation Testing Protocol [RChung] [ In reply to ]
Quote | Reply
I´m going to test with top cyclists between 45-50km/h.

Copy text from this article "Simulation Model for Road Cycling Time Trials with a Non-constant Drag Area
"
: "The Martin model can be modified to account for variation in CDA with variations in the Reynolds number of the air flow. To do this, the model must use the effective wind velocity parallel to the riding direction given a certain yaw angle, to return the correct drag area for those conditions. For this model, these values were obtained through wind tunnel testing"

I understand for this that Cda calculated is only valid for the same velocity. I can read in other papers that is one of the limitation of wind tunel test. Cda is high at low velocity and low at high velocity. Then we need to report cda value allways at specific velocity.

About Crr is also dependent of velocity I should test Crr at target velocity.

Anyone can explain or link how do accuracy test of Crr in velodrome?
Quote Reply
Re: Platypus Thread: Aero Virtual Elevation Testing Protocol [cyclistgo] [ In reply to ]
Quote | Reply
cyclistgo wrote:
I´m going to test with top cyclists between 45-50km/h.

"Simulation Model for Road Cycling Time Trials with a Non-constant Drag Area"

Thanks. That's an interesting paper. I see they did their field tests with speed (and gradient) measured by GPS (and the power meter was a Stages).

Quote:
I understand for this that Cda calculated is only valid for the same velocity. I can read in other papers that is one of the limitation of wind tunel test. Cda is high at low velocity and low at high velocity. Then we need to report cda value allways at specific velocity.

They report a dependence of CdA on wind tunnel speed that's huge: there's about a 5% difference (for both riders) in CdA between 9 and 13 m/s (about 32 to 47 km/h). That's puzzling.

Quote:
Anyone can explain or link how do accuracy test of Crr in velodrome?
I can understand now why you're worried.
Quote Reply
Re: Platypus Thread: Aero Virtual Elevation Testing Protocol [BergHugi] [ In reply to ]
Quote | Reply
BergHugi wrote:
Did not do many tests with my test rig yet, but I saw a slight increase of Crr for a Schwalbe pro one TT from 0.0016 to 0.0018 increasing speed of the wooden drum (d = 90cm) from 20 km/h to 60 km/h .Loooking at tests of the recumbent community, they often observe an increase of Crr with speed

Cool... is your test rig posted somewhere?

Very low Crr... I've been getting ~.0025 with Vittoria Pistas at slow speed. That's on a road though.
Quote Reply
Re: Platypus Thread: Aero Virtual Elevation Testing Protocol [rruff] [ In reply to ]
Quote | Reply
rruff wrote:

Cool... is your test rig posted somewhere?


Not yet. I will write a paper when every thing is fine i.e. when the results are bullet proof and when I have the time to write. In the mean time look at the picture.

rruff wrote:

Very low Crr... I've been getting ~.0025 with Vittoria Pistas at slow speed. That's on a road though.


Yes, I measure generally low Crr values. But tests are on a smooth wooden drum (I want to be as close as possible to a wooden track surface), results are corrected for drag to spin the drum and the wheel, and results are recalculated / corrected for a flat surface.

Last edited by: BergHugi: Jun 5, 20 0:08
Quote Reply
Re: Platypus Thread: Aero Virtual Elevation Testing Protocol [rruff] [ In reply to ]
Quote | Reply
I understand RChung, that the best option is not try to calculate Crr on velodrome, is get data from roller test, or from data tables from https://www.bicyclerollingresistance.com/road-bike-reviews?

If I decide to get data from other experiments, how should I convert or adjust this factor of Crr to my test? For temperature?

I´ve been reading about aerodynamic very different things...
Quote Reply
Re: Platypus Thread: Aero Virtual Elevation Testing Protocol [RChung] [ In reply to ]
Quote | Reply
RChung wrote:
cyclistgo wrote:
Cda is dependent for velocity only for Reynolds number?

Um, maybe I made things more complicated than I should have. The essential piece is: over the speeds at which we usually ride, CdA is not dependent on speed. If it were, we wouldn't be able to predict pwer for speed based on wind tunnel tests that are done at a single speed.

I would add that in terms of pressure drag yes (eg. components, bike frames, wheels), but friction drag the CdA will change (skinsuits etc.) even over 35-50kph.

Regarding Crr round a velodrome you can do it with the TAS kit but as mentioned above it's really hard and you have to devote entire sessions to doing just that. We did some for a recent bit of data correlating things with wind tunnel and Crr data (see herehttps://www.aero-coach.co.uk/...mics-of-racing-tyres[/url] ).

Low 0.002s for Anadia is the correct value. Local temperature can vary quite a bit - gets really really hot there in the summer.

AeroCoach UK
http://www.aero-coach.co.uk
Quote Reply
Re: Platypus Thread: Aero Virtual Elevation Testing Protocol [Xavier] [ In reply to ]
Quote | Reply
Xavier wrote:
RChung wrote:
cyclistgo wrote:
Cda is dependent for velocity only for Reynolds number?

Um, maybe I made things more complicated than I should have. The essential piece is: over the speeds at which we usually ride, CdA is not dependent on speed. If it were, we wouldn't be able to predict pwer for speed based on wind tunnel tests that are done at a single speed.


I would add that in terms of pressure drag yes (eg. components, bike frames, wheels), but friction drag the CdA will change (skinsuits etc.) even over 35-50kph.

Regarding Crr round a velodrome you can do it with the TAS kit but as mentioned above it's really hard and you have to devote entire sessions to doing just that. We did some for a recent bit of data correlating things with wind tunnel and Crr data (see herehttps://www.aero-coach.co.uk/...mics-of-racing-tyres[/url] ).

Low 0.002s for Anadia is the correct value. Local temperature can vary quite a bit - gets really really hot there in the summer.

Thanks for your answer Xavier. ¿What are you mean with TAS kit? ¿Aerodynamic system TAS? I understand that TAS is also regression on real time.

We are going to stay also in Valencia in August-September and I´m thinking in get data from test roller, one for concrete and another for wooden, and control stable all variables along test for get the most accuracy Cda in velodrome and Crr in test roller. Same pressure, same tyres and same velocity, and adjust for temperature and weight.¿Could be this a good idea? ¿Which limiting factors could have this methodology?
Quote Reply
Re: Platypus Thread: Aero Virtual Elevation Testing Protocol [cyclistgo] [ In reply to ]
Quote | Reply
cyclistgo wrote:
I understand RChung, that the best option is not try to calculate Crr on velodrome, is get data from roller test, or from data tables from https://www.bicyclerollingresistance.com/road-bike-reviews?

If I decide to get data from other experiments, how should I convert or adjust this factor of Crr to my test? For temperature?

I´ve been reading about aerodynamic very different things...


No, I'm not sure that's the *best* option. Crr differs across velodromes, so whether that's the best option depends on if you can get away with transferring Crr values from another testing situation, and that depends on how precise you need to be.

The purpose of models isn't to fit data, but the test of a model is. If you think that Crr (and CdA) vary with speed, the thing to do is to test it. Our current model of drag forces (slightly simplified to get rid of the potential and kinetic energy terms and assuming no wind) looks like

Watts = Crr * m* g * v + 0.5 * rho* CdA * v^3
or
Force = Crr * m * g + 0.5 * rho * CdA * v^2

So the test to determine dependence of Crr on speed is to estimate the coefficients of a model that looks like

Force = A + B*m*g*v + C* v^2

and see whether the coefficient B is different from zero. The problem is that you also think that C is speed dependent, so interpreting B may be hard -- but at least you'd know if dependence was an issue. You might also be able to vary m to separately estimate a Crr dependence and a CdA dependence, but I have to think on that a bit more.
Last edited by: RChung: Jun 5, 20 7:27
Quote Reply
Re: Platypus Thread: Aero Virtual Elevation Testing Protocol [RChung] [ In reply to ]
Quote | Reply
Thanks RChung. I need to think in your answer, interesting.

Which variables change on Crr measure in roller for the same material of the track to be different?

If from my point of view regression method is not valid for consider that we have one Cda for one specific velocity, also for Crr, which could be other alternative method for measure Cda and Crr with high accuracy?
Quote Reply
Re: Platypus Thread: Aero Virtual Elevation Testing Protocol [RChung] [ In reply to ]
Quote | Reply
RChung wrote:
cyclistgo wrote:
I understand RChung, that the best option is not try to calculate Crr on velodrome, is get data from roller test, or from data tables from https://www.bicyclerollingresistance.com/road-bike-reviews?

If I decide to get data from other experiments, how should I convert or adjust this factor of Crr to my test? For temperature?

I´ve been reading about aerodynamic very different things...


No, I'm not sure that's the *best* option. Crr differs across velodromes, so whether that's the best option depends on if you can get away with transferring Crr values from another testing situation, and that depends on how precise you need to be.

The purpose of models isn't to fit data, but the test of a model is. If you think that Crr (and CdA) vary with speed, the thing to do is to test it. Our current model of drag forces (slightly simplified to get rid of the potential and kinetic energy terms and assuming no wind) looks like

Watts = Crr * m* g * v + 0.5 * rho* CdA * v^3
or
Force = Crr * m * g + 0.5 * rho * CdA * v^2

So the test to determine dependence of Crr on speed is to estimate the coefficients of a model that looks like

Force = A + B*m*g*v + C* v^2

and see whether the coefficient B is different from zero. The problem is that you also think that C is speed dependent, so interpreting B may be hard -- but at least you'd know if dependence was an issue. You might also be able to vary m to separately estimate a Crr dependence and a CdA dependence, but I have to think on that a bit more.

what would it be in this case A, B and C?

I can find here https://www.tiresciencetechnology.org/....2346/tire.20.190207 that Crr have non-linear relation for velocity above 45 km/h.
Quote Reply
Re: Platypus Thread: Aero Virtual Elevation Testing Protocol [cyclistgo] [ In reply to ]
Quote | Reply
cyclistgo wrote:
RChung wrote:

So the test to determine dependence of Crr on speed is to estimate the coefficients of a model that looks like

Force = A + B*m*g*v + C* v^2

and see whether the coefficient B is different from zero. The problem is that you also think that C is speed dependent, so interpreting B may be hard -- but at least you'd know if dependence was an issue. You might also be able to vary m to separately estimate a Crr dependence and a CdA dependence, but I have to think on that a bit more.


what would it be in this case A, B and C?

Well, I was simplifying. In the usual Martin model, A is an estimate of the quantity Crr*m*g and C is an estimate of the quantity 0.5*rho*CdA. In this case, you'd be testing to see whether B is non-zero. If it is, you'd have to do another test to determine whether it's non-zero because of speed dependence of Crr, of CdA, or of both. I was thinking that would require some variation in m, since rolling drag is affected by mass but CdA isn't.

And, of course, VE is actually designed as a diagnostic for these kinds of things -- and it's pretty sensitive.

Quote:
I can find here https://www.tiresciencetechnology.org/....2346/tire.20.190207 that Crr have non-linear relation for velocity above 45 km/h.

That's interesting. I'd like to see how they tested. As I mentioned above, I have some data on actual speed runs at Battle Mountain and if the dependence of Crr on speed were large I think it would've shown up. (I was actually kind of surprised when I first saw the data because I was expecting to see a "regime" change in Crr and CdA but I didn't).
Last edited by: RChung: Jun 5, 20 9:10
Quote Reply
Re: Platypus Thread: Aero Virtual Elevation Testing Protocol [RChung] [ In reply to ]
Quote | Reply
 

We really need a "Paper Police".

Not saying their paper is invalid but I would love for someone to check it out

I recently had to take a paper, take the raw data and dissect how they came to such flagrantly wrong results. Which they published. All user error.

There has to be a better way to review/comment get some of this stuff retracted

Again, I am not targeting this specific paper or saying it is wrong, I just now question every paper that I read.
Quote Reply
Re: Platypus Thread: Aero Virtual Elevation Testing Protocol [marcag] [ In reply to ]
Quote | Reply
marcag wrote:
Again, I am not targeting this specific paper or saying it is wrong, I just now question every paper that I read.

I thought the paper several posts above that did field tests with GPS speed and gradient and a Stages power meter was kinda fun.
Quote Reply
Re: Platypus Thread: Aero Virtual Elevation Testing Protocol [RChung] [ In reply to ]
Quote | Reply
RChung wrote:
...GPS speed and gradient and a Stages power meter...

I noticed you noted that. :-)

Damon Rinard
Engineering Manager,
CSG Road Engineering Department
Cannondale & GT Bicycles
(ex-Cervelo, ex-Trek, ex-Velomax, ex-Kestrel)
Quote Reply
Re: Platypus Thread: Aero Virtual Elevation Testing Protocol [cyclistgo] [ In reply to ]
Quote | Reply
cyclistgo wrote:
Thanks for your answer Xavier. ¿What are you mean with TAS kit? ¿Aerodynamic system TAS? I understand that TAS is also regression on real time.

TAS is the real-time Track Aero System developed by AndyF for Alphamantis/Garmin.
Quote Reply
Re: Platypus Thread: Aero Virtual Elevation Testing Protocol [damon_rinard] [ In reply to ]
Quote | Reply
damon_rinard wrote:
I noticed you noted that. :-)

Do you know me, or what?
Quote Reply
Re: Platypus Thread: Aero Virtual Elevation Testing Protocol [BergHugi] [ In reply to ]
Quote | Reply
BergHugi wrote:
Yes, I measure generally low Crr values. But tests are on a smooth wooden drum (I want to be as close as possible to a wooden track surface), results are corrected for drag to spin the drum and the wheel, and results are recalculated / corrected for a flat surface.

Nice! I don't know what instrumentation you are using, but I wondered if it would be best to determine the inertia of the system and derive Crr from the rate of change in speed. Would be better than some hacks at least (like measuring motor inputs) and would be simple and consistent.
Quote Reply
Re: Platypus Thread: Aero Virtual Elevation Testing Protocol [rruff] [ In reply to ]
Quote | Reply
rruff wrote:
I wondered if it would be best to determine the inertia of the system and derive Crr from the rate of change in speed. Would be better than some hacks at least (like measuring motor inputs) and would be simple and consistent.
It could be simple and consistent--unless you think Crr varies with speed.
Quote Reply
Re: Platypus Thread: Aero Virtual Elevation Testing Protocol [rruff] [ In reply to ]
Quote | Reply
rruff wrote:
Nice! I don't know what instrumentation you are using, but I wondered if it would be best to determine the inertia of the system and derive Crr from the rate of change in speed. Would be better than some hacks at least (like measuring motor inputs) and would be simple and consistent.

Actio = reactio, with a wheel hub motor no need to measure motor inputs, just get the reaction torque with a lever and a load cell (grade A)
Quote Reply
Re: Platypus Thread: Aero Virtual Elevation Testing Protocol [rruff] [ In reply to ]
Quote | Reply
rruff wrote:
marcag wrote:
rruff wrote:

Based on outdoor testing I'm pretty sure Crr increases with speed, making the relationship with power non-linear. At least that is the only way I could get curves to match.


If this were true, how would you explain not seeing it on indoor roller tests ?


I do though not as much as for the outdoor tests, where there is an increase of ~50% between 10km/hr and 40km/hr.

Does it mean you saw a 50% increase of Crr between 10 and 40 km/h according to your outdoor tests ?
Thanks

Large variation of Crr is true for car tires:
https://www.researchgate.net/...vehicle/figures?lo=1

RChung wrote:
BergHugi wrote:

Looking at tests of the recumbent community, they often observe an increase of Crr with speed


Yeah. I've seen those claims, too. I'm sure that at very high speeds it does matter. The question is whether on a velodrome at more usual speeds whether the speed dependence is large or small.

I have a couple of data files from streamliner speed runs at Battle Mountain. There are a couple of anomalies but, as a whole, it appears that the speed dependence of CdA and Crr isn't huge in speeds from ~40 to ~75 mph (~65 to ~120 km/h).


In velodrome, instead of varying speed to differentiate Crr and CdA, is varying mass at targeted speed could be a solution ;-) ?

Blog | Twitter| Bike CdaCrr app
Last edited by: bugno: Jun 6, 20 4:47
Quote Reply
Re: Platypus Thread: Aero Virtual Elevation Testing Protocol [bugno] [ In reply to ]
Quote | Reply
bugno wrote:
In velodrome, instead of varying speed to differentiate Crr and CdA, is varying mass at targeted speed could be a solution ;-) ?
That's a very good idea. Maybe you could do runs with empty and loaded water bottles. Maybe fill one water bottle with something heavier than water, to get a larger delta in mass. Hmmm.
Quote Reply
Re: Platypus Thread: Aero Virtual Elevation Testing Protocol [RChung] [ In reply to ]
Quote | Reply
RChung wrote:
bugno wrote:

In velodrome, instead of varying speed to differentiate Crr and CdA, is varying mass at targeted speed could be a solution ;-) ?

That's a very good idea. Maybe you could do runs with empty and loaded water bottles. Maybe fill one water bottle with something heavier than water, to get a larger delta in mass. Hmmm.

In the turns one already get‘s a significant normal force increase depending on the speed and the curve radius. However this effect was not big enough in my tests to separate Crr from CdA.

By the way, what publication could I cite if I want to make a reference to the „Chung“ or „virtual elevation“ method in a scientific paper?
Quote Reply
Re: Platypus Thread: Aero Virtual Elevation Testing Protocol [RChung] [ In reply to ]
Quote | Reply
RChung wrote:
cyclistgo wrote:

My question is about if it´s possible to determine in stable test Cda and Crr or is necessary change velocity.
And with it we can get lot of combination numbers for Crr and Cda.


Estimating CdA and Crr from the same data set is possible but it's pretty demanding of good data and good experimental technique. The short answer is it's necessary to change velocity. The fuller answer will require a little dip into statistical estimation. I'll try to keep it short and understandable.

In order to estimate two unknowns, you need to have at least two equations. If all your data are taken at a "stable test" at a single speed or power, you'll only have one equation so the system is undetermined. What's also true is that if the data vary but only by a little bit, you you can solve for estimates of CdA and Crr but the data are *nearly* collinear so although you were able to do the estimation, they're estimated poorly.

So, if you're trying to estimate both CdA and Crr from the same data set, you have to have a pretty wide range of speed and power--and it's good to have a lot of equations so you can check the precision of the estimates (there's a bunch of statistical mumbo-jumbo embedded in the last part of that sentence). A secondary issue is that you'd like the speed and power to be pretty accurate and precise, and a third issue is that you don't want there to be wild swings in speed and power because some power meters are a little sensitive and laggy in responding to big changes in power.

All together, if you want to separate CdA and Crr, you need accurate data and a wide range in speed and power.

Andy Shen once suggested a monotonically increasing speed protocol for velodrome testing: start slow and increase speed a little bit each lap. There are other ways to ensure that you get a pretty wide range in speed and power, but this will work. Find the top power you can sustain for a couple of laps, then start at perhaps half of that power, then each lap increase speed smoothly so that after 10 laps or so you're at your max that you can sustain without ruining your position. If you can, do a couple of extra laps slowing down in speed and power. A protocol like this ensures both a wide range in speed and power, and also keeps sudden changes in them relatively small.

Andy Shen's description is still out there on the interwebs: https://nyvelocity.com/...ess/the-shen-method/

http://bikeblather.blogspot.com/
Quote Reply
Re: Platypus Thread: Aero Virtual Elevation Testing Protocol [rruff] [ In reply to ]
Quote | Reply
rruff wrote:
BergHugi wrote:
It is often stated, that because power to overcome aero drag scales with the cube of speed and power to overcome rolling resistance scales linearly with speed it is possible to separate Cda and Crr. I was never successful to separate them with actual power data from an aero test on an indoor track.


Based on outdoor testing I'm pretty sure Crr increases with speed, making the relationship with power non-linear. At least that is the only way I could get curves to match.

There is also a more modest *reduction* of CdA with speed for most people.

Is it possible you could have been bumping up against "impedance breakpoint" in those tests? The breakpoint is not only affected by pressure, but also speed, load, and surface roughness.

I only ask, because if there was a dramatic increase in Crr with speed, then I highly doubt I would've seen such "clean" plots when I was playing around with a "work per lap" spreadsheet Adam Haile had sent me quite a long time ago. As an example, here's one of the plots below:


Speed varied within the laps from 7kph to 55kph, with the overlapping lap segments averaging from 25-41 kph.

http://bikeblather.blogspot.com/
Quote Reply
Re: Platypus Thread: Aero Virtual Elevation Testing Protocol [rruff] [ In reply to ]
Quote | Reply
rruff wrote:
BergHugi wrote:
Yes, I measure generally low Crr values. But tests are on a smooth wooden drum (I want to be as close as possible to a wooden track surface), results are corrected for drag to spin the drum and the wheel, and results are recalculated / corrected for a flat surface.


Nice! I don't know what instrumentation you are using, but I wondered if it would be best to determine the inertia of the system and derive Crr from the rate of change in speed. Would be better than some hacks at least (like measuring motor inputs) and would be simple and consistent.

You're basically describing the Computrainer "spin-down" function for calibrating the rolling resistance.

Here's a fun fact I discovered when playing around with a second-hand CT setup gifted to me, and something I read in some old CT documentation: the number output by the CT head unit is actually the tangential force of the roller calculated during the spin down.

So...if one had a way to measure the force the CT roller is being pressed into the tire, a CT spin-down would be a pretty easy way to Crr of various tires. One would need to do the roller-to-flat calculations still, but it would be a fairly quick and easy test setup after that.

http://bikeblather.blogspot.com/
Quote Reply
Re: Platypus Thread: Aero Virtual Elevation Testing Protocol [BergHugi] [ In reply to ]
Quote | Reply
BergHugi wrote:
rruff wrote:
Nice! I don't know what instrumentation you are using, but I wondered if it would be best to determine the inertia of the system and derive Crr from the rate of change in speed. Would be better than some hacks at least (like measuring motor inputs) and would be simple and consistent.


Actio = reactio, with a wheel hub motor no need to measure motor inputs, just get the reaction torque with a lever and a load cell (grade A)

Excellent approach...now you've got me re-thinking the rig I've slowly been trying to put together...I was going to use an old Quarq prototype spider I had lying around as a power measurement, but the reaction arm measurement is a much more elegant solution.

http://bikeblather.blogspot.com/
Quote Reply
Re: Platypus Thread: Aero Virtual Elevation Testing Protocol [BergHugi] [ In reply to ]
Quote | Reply
BergHugi wrote:
In the turns one already get‘s a significant normal force increase depending on the speed and the curve radius. However this effect was not big enough in my tests to separate Crr from CdA.
Oh, Pierre and I had discussed a method to validate and assess the precision of his estimates, and that's what he was referring to.

Quote:
By the way, what publication could I cite if I want to make a reference to the „Chung“ or „virtual elevation“ method in a scientific paper?
Different publications follow different standards, so most publications will give examples of how they prefer website citations and references to be formatted. There have already been a few scientific papers that reference my work. A typical citation (but check your specific publication's style) might look like:

Author's Last Name, First Name Middle Name or Initial. “Title of Article (or section if using only part of the website.)†Name of Website, Name of organizational sponsor (not advertising sponsor), date published or updated, URL. Date of access (needed if no date is found.).
Quote Reply
Re: Platypus Thread: Aero Virtual Elevation Testing Protocol [Tom A.] [ In reply to ]
Quote | Reply
Tom A. wrote:
Is it possible you could have been bumping up against "impedance breakpoint" in those tests? The breakpoint is not only affected by pressure, but also speed, load, and surface roughness.

Conti SS20 front and Vit CS23 rear both at 90psi. The road is asphalt but pretty low grade, lumpy, with tar and gravel patches. At low speed I'd get a Crr of ~.0027 and a little over .004 at high speed (40km/hr+). The low speed runs were done using my own protocol and Pierre's app with good agreement. The course has a 1.2% slope and there were a couple days when I had a very strong tailwind on the uphill leg. This allowed me to check Crr at high speeds because I could go fast on the climb and still have low aero drag. Otherwise it's tough to tell because if Crr rises with speed it tends to mimic aero drag (increasing CdA matches the data well enough), and it's harder to separate the two.
Quote Reply
Re: Platypus Thread: Aero Virtual Elevation Testing Protocol [BergHugi] [ In reply to ]
Quote | Reply
BergHugi wrote:
Actio = reactio, with a wheel hub motor no need to measure motor inputs, just get the reaction torque with a lever and a load cell (grade A)

Sounds good! I was referring to a popular Crr tester. Don't think his setup is as good as it could be.
Quote Reply
Re: Platypus Thread: Aero Virtual Elevation Testing Protocol [bugno] [ In reply to ]
Quote | Reply
bugno wrote:
Does it mean you saw a 50% increase of Crr between 10 and 40 km/h according to your outdoor tests ?

Ya, roughly that amount. .0027 to .0042. As I mentioned, uphill with a tailwind was how I could reduce aero drag to a low enough amount to see this. It could be something else of course... but everything else I could think of checked out. This was a year ago. I quit using that road because of too many close calls with motorists not looking, and dogs cutting me off.

I guess you were couped up for a long time? Happy to be out now? I would have gone crazy if I was prevented from riding outside for a couple months...
Quote Reply
Re: Platypus Thread: Aero Virtual Elevation Testing Protocol [rruff] [ In reply to ]
Quote | Reply
rruff wrote:
Tom A. wrote:
Is it possible you could have been bumping up against "impedance breakpoint" in those tests? The breakpoint is not only affected by pressure, but also speed, load, and surface roughness.


Conti SS20 front and Vit CS23 rear both at 90psi. The road is asphalt but pretty low grade, lumpy, with tar and gravel patches. At low speed I'd get a Crr of ~.0027 and a little over .004 at high speed (40km/hr+). The low speed runs were done using my own protocol and Pierre's app with good agreement. The course has a 1.2% slope and there were a couple days when I had a very strong tailwind on the uphill leg. This allowed me to check Crr at high speeds because I could go fast on the climb and still have low aero drag. Otherwise it's tough to tell because if Crr rises with speed it tends to mimic aero drag (increasing CdA matches the data well enough), and it's harder to separate the two.

How where you measuring air speed ?
Quote Reply
Re: Platypus Thread: Aero Virtual Elevation Testing Protocol [rruff] [ In reply to ]
Quote | Reply
rruff wrote:
Tom A. wrote:
Is it possible you could have been bumping up against "impedance breakpoint" in those tests? The breakpoint is not only affected by pressure, but also speed, load, and surface roughness.


Conti SS20 front and Vit CS23 rear both at 90psi. The road is asphalt but pretty low grade, lumpy, with tar and gravel patches. At low speed I'd get a Crr of ~.0027 and a little over .004 at high speed (40km/hr+). The low speed runs were done using my own protocol and Pierre's app with good agreement. The course has a 1.2% slope and there were a couple days when I had a very strong tailwind on the uphill leg. This allowed me to check Crr at high speeds because I could go fast on the climb and still have low aero drag. Otherwise it's tough to tell because if Crr rises with speed it tends to mimic aero drag (increasing CdA matches the data well enough), and it's harder to separate the two.

Hmmm...yeah...that's quite a large apparent increase for not really that fast of a ground speed. I'm thinking if I saw something like that I would be poking around at the particular protocol and calculations.

http://bikeblather.blogspot.com/
Quote Reply
Re: Platypus Thread: Aero Virtual Elevation Testing Protocol [marcag] [ In reply to ]
Quote | Reply
marcag wrote:
How where you measuring air speed ?

Anemometer.
Quote Reply
Re: Platypus Thread: Aero Virtual Elevation Testing Protocol [rruff] [ In reply to ]
Quote | Reply
rruff wrote:
marcag wrote:
How where you measuring air speed ?


Anemometer.

Not saying it's the same thing but I had funny experiences with a device I used to use in very specific wind conditions, ie very very strong tailwind and some specific yaw conditions.

I do have a weatherflow anemometer I need to get around to testing against another device to see how it behaves.
Quote Reply
Re: Platypus Thread: Aero Virtual Elevation Testing Protocol [marcag] [ In reply to ]
Quote | Reply
marcag wrote:
I do have a weatherflow anemometer I need to get around to testing against another device to see how it behaves.

It's an out-back and I ride near the center of the road. The calibration is adjusted post testing based on distance averaged wind, to remove any bias.
Quote Reply
Re: Platypus Thread: Aero Virtual Elevation Testing Protocol [rruff] [ In reply to ]
Quote | Reply
 
rruff wrote:
bugno wrote:
Does it mean you saw a 50% increase of Crr between 10 and 40 km/h according to your outdoor tests ?

Ya, roughly that amount. .0027 to .0042. As I mentioned, uphill with a tailwind was how I could reduce aero drag to a low enough amount to see this. It could be something else of course... but everything else I could think of checked out. This was a year ago. I quit using that road because of too many close calls with motorists not looking, and dogs cutting me off.
I guess you were couped up for a long time? Happy to be out now? I would have gone crazy if I was prevented from riding outside for a couple months...

Happy to be out, yeah. The first bike ride was a rebirth: after that we know even more how much we love cycling.

I am in Ron's camp and believe there is quite a big variation of Crr with speed, even if Tom test with “the work per lap†approach makes me doubt: I have also a lot of tests with Adam's sheet (what a great tool) with also a straight line... But, a straight line doesn't imply that Crr and CdA are constants….

Take what follows with a grain of salt, it may be hasardous science, suppose:
  • we give us a model for rolling resistance, for instance Crr(V in kmh)=0.003*(1+(V-10)/30) according to Ron testimony with a variation of 50% between 10 and 40 kmh.
  • we take a CdA correlation found in wind tunnel (“Aerodynamic drag in cycling: methods of assessment†, by changing the constant to match Tom's CdA@40 kmh (0.316m2): CdA(V in kmh)=0.442*(1-0.0043*V+3e-5*V*V)



If we apply the model and plot Y=f(X), with Y=Total drag=mgCrr+CdA*X according to X=wind pressure (=0.5*rho*V^2) and compare with the data of Tom test:



As you can see, in the 20-40 kmh test range, there is a straigth line wheareas CdA and Crr in the model are speed dependent. In other words, may be that the speed dependency in rolling resistance term and in the aero drag cancel out into the equation... I add my sheet for verification.

In my mind, we can't have accurate numbers for Crr and CdA by using the equation behind the virtual elevation method. We can only have very precise number for CdA once you guess Crr at targeted speed and keep the average speed on the lap +/-1 km/h (the model says a variation of 2km/h gives a change of 1% for CdA. 1% is typically the precision you may reach with a good protocol by using VE method).

If you really want accurate numbers for CdA at different speeds, you would need to discover the law Crr=f(speed, temperature, your tires for a given pressure, your road quality). Good luck.

Blog | Twitter| Bike CdaCrr app
Last edited by: bugno: Jun 8, 20 13:58
Quote Reply
Re: Platypus Thread: Aero Virtual Elevation Testing Protocol [bugno] [ In reply to ]
Quote | Reply
bugno wrote:
rruff wrote:
bugno wrote:
Does it mean you saw a 50% increase of Crr between 10 and 40 km/h according to your outdoor tests ?

Ya, roughly that amount. .0027 to .0042. As I mentioned, uphill with a tailwind was how I could reduce aero drag to a low enough amount to see this. It could be something else of course... but everything else I could think of checked out. This was a year ago. I quit using that road because of too many close calls with motorists not looking, and dogs cutting me off.
I guess you were couped up for a long time? Happy to be out now? I would have gone crazy if I was prevented from riding outside for a couple months...

Happy to be out, yeah. The first bike ride was a rebirth: after that we know even more how much we love cycling.

I am in Ron's camp and believe there is quite a big variation of Crr with speed, even if Tom test with “the work per lap†approach makes me doubt: I have also a lot of tests with Adam's sheet (what a great tool) with also a straight line... But, a straight line doesn't imply that Crr and CdA are constants….

Take what follows with a grain of salt, it may be hasardous science, suppose:
  • we give us a model for rolling resistance, for instance Crr(V in kmh)=0.003*(1+(V-10)/30) according to Ron testimony with a variation of 50% between 10 and 40 kmh.
  • we take a CdA correlation found in wind tunnel (“Aerodynamic drag in cycling: methods of assessment†, by changing the constant to match Tom's CdA@40 kmh (0.316m2): CdA(V in kmh)=0.442*(1-0.0043*V+3e-5*V*V)



If we apply the model and plot Y=f(X), with Y=Total drag=mgCrr+CdA*X according to X=wind pressure (=0.5*rho*V^2) and compare with the data of Tom test:



As you can see, in the 20-40 kmh test range, there is a straigth line wheareas CdA and Crr in the model are speed dependent. In other words, may be that the speed dependency in rolling resistance term and in the aero drag cancel out into the equation... I add my sheet for verification.

In my mind, we can't have accurate numbers for Crr and CdA by using the equation behind the virtual elevation method. We can only have very precise number for CdA once you guess Crr at targeted speed and keep the average speed on the lap +/-1 km/h (the model says a variation of 2km/h gives a change of 1% for CdA. 1% is typically the precision you may reach with a good protocol by using VE method).

If you really want accurate numbers for CdA at different speeds, you would need to discover the law Crr=f(speed, temperature, your tires for a given pressure, your road quality). Good luck.

Hmmm...I see what you're saying about how the plot I showed above might not be a good "diagnostic" of if the effects being discussed exist.

But, I also looked for the 2009 Grappe article (book?) referenced in that paper you linked to get details of the data collection for that plot shown above...can't find anything.

In the process though, I DID find other cycling aerodynamics papers that also had wind tunnel measurements varying with wind speed. For example, here's one that varied from 20-70 kph (~6-20 m/s), with basically little variation in the calculated Cd



From: https://www.researchgate.net/...bicycle_aerodynamics

So...at this point, I'm having a hard time accepting the Grappe plot without knowing more about it.

http://bikeblather.blogspot.com/
Quote Reply
Re: Platypus Thread: Aero Virtual Elevation Testing Protocol [bugno] [ In reply to ]
Quote | Reply
bugno wrote:
rruff wrote:
bugno wrote:
Does it mean you saw a 50% increase of Crr between 10 and 40 km/h according to your outdoor tests ?

Ya, roughly that amount. .0027 to .0042. As I mentioned, uphill with a tailwind was how I could reduce aero drag to a low enough amount to see this. It could be something else of course... but everything else I could think of checked out. This was a year ago. I quit using that road because of too many close calls with motorists not looking, and dogs cutting me off.
I guess you were couped up for a long time? Happy to be out now? I would have gone crazy if I was prevented from riding outside for a couple months...

Happy to be out, yeah. The first bike ride was a rebirth: after that we know even more how much we love cycling.

I am in Ron's camp and believe there is quite a big variation of Crr with speed, even if Tom test with “the work per lap†approach makes me doubt: I have also a lot of tests with Adam's sheet (what a great tool) with also a straight line... But, a straight line doesn't imply that Crr and CdA are constants….

Take what follows with a grain of salt, it may be hasardous science, suppose:

  • we give us a model for rolling resistance, for instance Crr(V in kmh)=0.003*(1+(V-10)/30) according to Ron testimony with a variation of 50% between 10 and 40 kmh.
  • we take a CdA correlation found in wind tunnel (“Aerodynamic drag in cycling: methods of assessment†, by changing the constant to match Tom's CdA@40 kmh (0.316m2): CdA(V in kmh)=0.442*(1-0.0043*V+3e-5*V*V)



If we apply the model and plot Y=f(X), with Y=Total drag=mgCrr+CdA*X according to X=wind pressure (=0.5*rho*V^2) and compare with the data of Tom test:



As you can see, in the 20-40 kmh test range, there is a straigth line wheareas CdA and Crr in the model are speed dependent. In other words, may be that the speed dependency in rolling resistance term and in the aero drag cancel out into the equation... I add my sheet for verification.

In my mind, we can't have accurate numbers for Crr and CdA by using the equation behind the virtual elevation method. We can only have very precise number for CdA once you guess Crr at targeted speed and keep the average speed on the lap +/-1 km/h (the model says a variation of 2km/h gives a change of 1% for CdA. 1% is typically the precision you may reach with a good protocol by using VE method).

If you really want accurate numbers for CdA at different speeds, you would need to discover the law Crr=f(speed, temperature, your tires for a given pressure, your road quality). Good luck.


I am in this position too. Here a link in this case of the dependency of the cda with the speed: https://repository.tudelft.nl/...76-9908-b23dd6f035d8


"In aerodynamic research, the critical condition is typically characterized by the critical Reynolds number, where the Reynolds number is a flow similarity parameter depending on the size of the object, the flow velocity and the viscosity of the fluid. For a cyclist, the body size and the viscosity of the air are largely fixed and, hence, in this work the critical velocity, VC is considered a more practical parameter to indicate the condition that minimizes the cyclist’s drag area. If the critical velocity exceeds the race speed of the rider (VC > VR), surface roughness application can reduce the aerodynamic drag. Instead, when VC < VR the suit is better designed with a smooth fabric."
I think that we need to get only one unknown in the equation. Calculating real Crr and control all around it, we can calculate Cda with less error at a target velocity.
We should have one value of crr and cda for one specific velocity.
Quote Reply
Re: Platypus Thread: Aero Virtual Elevation Testing Protocol [cyclistgo] [ In reply to ]
Quote | Reply
Hi all- I'm very late to this thread and don't have much to add but finding the discussion very interesting. I too have tried to separate CdA and CRR in field tests and had mixed results but was never sure exactly why. I've defaulted to testing them separately -- test CdA with known Crr, or Crr with known CdA, all benchmarked by a careful joint test but these are generally quite noisy.

On the Crr testing issue, if CdA and Crr are changing with speed, how about testing at identical speeds but adding/subtracting weight? Has anyone tried this approach? Once my shoulder heals I could give it a go with water bottles filled with lead. (Thinking out loud: lead would add significant weight so thinking that I would need to adjust tire pressure to hold Crr constant.)
Quote Reply
Re: Platypus Thread: Aero Virtual Elevation Testing Protocol [Tom A.] [ In reply to ]
Quote | Reply
Tom A. wrote:

But, I also looked for the 2009 Grappe article (book?) referenced in that paper you linked to get details of the data collection for that plot shown above...can't find anything.
It's a pretty nice chapter in a book, but it's in French. As the caption said, those are figures measured in a wind tunnel. Interestingly, the very next figure in that chapter is for similar track cyclists on a velodrome, including one of the same riders as in the figure above. Unfortunately, the details of how the CdA (SCx) was measured aren't given. Here's that figure.



A couple of things:
1) I hate when people put in smooth curves.
2) It's pretty impressive that they went out to 65 km/h.
3) One of the riders (C3) used two different bikes. The data for rider C3 and velo 2 look pretty noisy.


Tom wrote:
In the process though, I DID find other cycling aerodynamics papers that also had wind tunnel measurements varying with wind speed. For example, here's one that varied from 20-70 kph (~6-20 m/s), with basically little variation in the calculated Cd
Quote Reply
Re: Platypus Thread: Aero Virtual Elevation Testing Protocol [lanierb] [ In reply to ]
Quote | Reply
lanierb wrote:
On the Crr testing issue, if CdA and Crr are changing with speed, how about testing at identical speeds but adding/subtracting weight? Has anyone tried this approach? Once my shoulder heals I could give it a go with water bottles filled with lead. (Thinking out loud: lead would add significant weight so thinking that I would need to adjust tire pressure to hold Crr constant.)

That's exactly what I've been proposing for a while as a validation and precision check (and what Pierre (bugno) and I were chuckling about a few posts above). I've done a couple of these "delta mass" tests with empty and full water bottles. I used to use sand but then switched to small nails. I didn't want to use lead weights both because I wanted to re-use my water bottles and also because lead shot is kinda expensive. (On the other hand, a penny weighs 3 grams so $5 of pennies weighs 1.5kg). For me, with my other parameters, 1.5kg in mass increases rolling resistance force by the equivalent of ~.0001 in Crr, or around 10cm in virtual elevation per km. So over a 3 km run on a windless day, I was expecting to see a change in VE of ~30 cm between empty and loaded tests, which is pretty noticeable. So I did that, but at varying speeds, and was observing a VE difference close to that. But then the wind came back up, so I didn't get to do more tests.
Quote Reply
Re: Platypus Thread: Aero Virtual Elevation Testing Protocol [cyclistgo] [ In reply to ]
Quote | Reply
cyclistgo wrote:

I am in this position too. Here a link in this case of the dependency of the cda with the speed: https://repository.tudelft.nl/...76-9908-b23dd6f035d8


"In aerodynamic research, the critical condition is typically characterized by the critical Reynolds number, where the Reynolds number is a flow similarity parameter depending on the size of the object, the flow velocity and the viscosity of the fluid. For a cyclist, the body size and the viscosity of the air are largely fixed and, hence, in this work the critical velocity, VC is considered a more practical parameter to indicate the condition that minimizes the cyclist’s drag area. If the critical velocity exceeds the race speed of the rider (VC > VR), surface roughness application can reduce the aerodynamic drag. Instead, when VC < VR the suit is better designed with a smooth fabric."
I think that we need to get only one unknown in the equation. Calculating real Crr and control all around it, we can calculate Cda with less error at a target velocity.
We should have one value of crr and cda for one specific velocity.


That summary is referring to small areas on the body of the cyclist, and doesn't show any values for a systemic change in the CdA with velocity.

I found the following from the same authors, where they are comparing their PIV (Particle Image Velocimetry) technique to actual wind tunnel balance measurements: https://link.springer.com/...07/s00348-019-2677-6

They didn't test over a very wide range of speed (only ~12.5-15 m/s free stream velocity), but it still looks fairly flat (with if anything, a "hump" in the middle)...also, even they admit the PIV technique is a "rather coarse instrument" for the job.



http://bikeblather.blogspot.com/
Quote Reply
Re: Platypus Thread: Aero Virtual Elevation Testing Protocol [RChung] [ In reply to ]
Quote | Reply
RChung wrote:
lanierb wrote:

On the Crr testing issue, if CdA and Crr are changing with speed, how about testing at identical speeds but adding/subtracting weight? Has anyone tried this approach? Once my shoulder heals I could give it a go with water bottles filled with lead. (Thinking out loud: lead would add significant weight so thinking that I would need to adjust tire pressure to hold Crr constant.)


That's exactly what I've been proposing for a while as a validation and precision check (and what Pierre (bugno) and I were chuckling about a few posts above). I've done a couple of these "delta mass" tests with empty and full water bottles. I used to use sand but then switched to small nails. I didn't want to use lead weights both because I wanted to re-use my water bottles and also because lead shot is kinda expensive. (On the other hand, a penny weighs 3 grams so $5 of pennies weighs 1.5kg). For me, with my other parameters, 1.5kg in mass increases rolling resistance force by the equivalent of ~.0001 in Crr, or around 10cm in virtual elevation per km. So over a 3 km run on a windless day, I was expecting to see a change in VE of ~30 cm between empty and loaded tests, which is pretty noticeable. So I did that, but at varying speeds, and was observing a VE difference close to that. But then the wind came back up, so I didn't get to do more tests.

Is this a case where you'd want to use Gatorskins or Tufos? (To get a bigger "signal")...the larger the Crr, the larger the absolute increase in rolling resistance force per kg, no?

http://bikeblather.blogspot.com/
Quote Reply
Re: Platypus Thread: Aero Virtual Elevation Testing Protocol [RChung] [ In reply to ]
Quote | Reply
RChung wrote:
Tom A. wrote:


But, I also looked for the 2009 Grappe article (book?) referenced in that paper you linked to get details of the data collection for that plot shown above...can't find anything.

It's a pretty nice chapter in a book, but it's in French. As the caption said, those are figures measured in a wind tunnel. Interestingly, the very next figure in that chapter is for similar track cyclists on a velodrome, including one of the same riders as in the figure above. Unfortunately, the details of how the CdA (SCx) was measured aren't given. Here's that figure.



A couple of things:
1) I hate when people put in smooth curves.
2) It's pretty impressive that they went out to 65 km/h.
3) One of the riders (C3) used two different bikes. The data for rider C3 and velo 2 look pretty noisy.


Tom wrote:

In the process though, I DID find other cycling aerodynamics papers that also had wind tunnel measurements varying with wind speed. For example, here's one that varied from 20-70 kph (~6-20 m/s), with basically little variation in the calculated Cd

With that little detail, I sure wouldn't hang my hat on those charts...

http://bikeblather.blogspot.com/
Quote Reply
Re: Platypus Thread: Aero Virtual Elevation Testing Protocol [Tom A.] [ In reply to ]
Quote | Reply
Tom A. wrote:
RChung wrote:
lanierb wrote:

On the Crr testing issue, if CdA and Crr are changing with speed, how about testing at identical speeds but adding/subtracting weight? Has anyone tried this approach? Once my shoulder heals I could give it a go with water bottles filled with lead. (Thinking out loud: lead would add significant weight so thinking that I would need to adjust tire pressure to hold Crr constant.)


That's exactly what I've been proposing for a while as a validation and precision check (and what Pierre (bugno) and I were chuckling about a few posts above). I've done a couple of these "delta mass" tests with empty and full water bottles. I used to use sand but then switched to small nails. I didn't want to use lead weights both because I wanted to re-use my water bottles and also because lead shot is kinda expensive. (On the other hand, a penny weighs 3 grams so $5 of pennies weighs 1.5kg). For me, with my other parameters, 1.5kg in mass increases rolling resistance force by the equivalent of ~.0001 in Crr, or around 10cm in virtual elevation per km. So over a 3 km run on a windless day, I was expecting to see a change in VE of ~30 cm between empty and loaded tests, which is pretty noticeable. So I did that, but at varying speeds, and was observing a VE difference close to that. But then the wind came back up, so I didn't get to do more tests.


Is this a case where you'd want to use Gatorskins or Tufos? (To get a bigger "signal")...the larger the Crr, the larger the absolute increase in rolling resistance force per kg, no?

Friends don't let friends ride Gatorskins or Tufos.
Quote Reply
Re: Platypus Thread: Aero Virtual Elevation Testing Protocol [marcag] [ In reply to ]
Quote | Reply
marcag wrote:
rruff wrote:
marcag wrote:
How where you measuring air speed ?


Anemometer.


Not saying it's the same thing but I had funny experiences with a device I used to use in very specific wind conditions, ie very very strong tailwind and some specific yaw conditions.

I do have a weatherflow anemometer I need to get around to testing against another device to see how it behaves.

Please do and report. You may be amazed by the device. Even if, with strong wind and high yaw, there are some oddities.

Blog | Twitter| Bike CdaCrr app
Quote Reply
Re: Platypus Thread: Aero Virtual Elevation Testing Protocol [Tom A.] [ In reply to ]
Quote | Reply
Tom A. wrote:

Hmmm...I see what you're saying about how the plot I showed above might not be a good "diagnostic" of if the effects being discussed exist.

But, I also looked for the 2009 Grappe article (book?) referenced in that paper you linked to get details of the data collection for that plot shown above...can't find anything.

In the process though, I DID find other cycling aerodynamics papers that also had wind tunnel measurements varying with wind speed. For example, here's one that varied from 20-70 kph (~6-20 m/s), with basically little variation in the calculated Cd



From: https://www.researchgate.net/...bicycle_aerodynamics

So...at this point, I'm having a hard time accepting the Grappe plot without knowing more about it.

The choosen scale on the graph does not reveal the difference well, but it seems there is a small decrease on the Cd road position between 20-40 kmh (~2.5%) which is much smaller indeed than the reduction in the Grappe graph (-15% in 20-40kmh range).

In the same time, the TT position has a constant Cd in the two studies.

But, recent wind tunnel tests (no details though) done by skinsuit/sock vendors in the 11-17 m/s range showed the same trend, Cd decreases with speed on TT position:
  • 2-3% in the 40-50 kmh range during velodrome tests for skinsuits (as reported by rruff, with data plotted):








So... It may depend on the rider position, and some other things too (bike, gear). But I keep thinking, with a limited confidence, that a small variation of Cd with speed is enough to hide much larger variation of Crr in regression/VE methods.

It will be nice if Xavier or Damon could give us a glimpse of what they know better than us on the subject about relationship between Cd and wind speed.

Blog | Twitter| Bike CdaCrr app
Last edited by: bugno: Jun 9, 20 4:31
Quote Reply
Re: Platypus Thread: Aero Virtual Elevation Testing Protocol [bugno] [ In reply to ]
Quote | Reply
I'll try and find some helpful graphs on all the wind tunnel testing we did on fabrics as part of the new Nopinz Flow skinsuit/clothing range. Friction drag is affected by airspeed far more than pressure drag, and we did have some fabrics we made that were good at some airspeeds but slower at others, so had to make decisions on what the best overall option was.

As more people focus on clothing I think you'll get two schools of thought (which can make it difficult when you're doing self aero testing and not as in control of your speed as you would be in a tunnel) - those that focus on a specific airspeed for their protocol and optimise around that, or those who optimise for a wider range. The new Zone3 suit is a good example, we tested it and overall over a wide range of speed it's better than everything, but it is possible to pick out 1 or 2 competitors that are as quick/quicker in very specific scenarios. I can't publish data on that though as it's all owned by Nopinz/Zone3 but will see what we have for the AeroCoach/Nopinz Flow stuff.

ps. when we've been doing our testing we haven't seen large changes in Crr based on rider speed.

AeroCoach UK
http://www.aero-coach.co.uk
Quote Reply
Re: Platypus Thread: Aero Virtual Elevation Testing Protocol [Xavier] [ In reply to ]
Quote | Reply
Xavier wrote:
I'll try and find some helpful graphs on all the wind tunnel testing we did on fabrics as part of the new Nopinz Flow skinsuit/clothing range. Friction drag is affected by airspeed far more than pressure drag, and we did have some fabrics we made that were good at some airspeeds but slower at others, so had to make decisions on what the best overall option was.

As more people focus on clothing I think you'll get two schools of thought (which can make it difficult when you're doing self aero testing and not as in control of your speed as you would be in a tunnel) - those that focus on a specific airspeed for their protocol and optimise around that, or those who optimise for a wider range. The new Zone3 suit is a good example, we tested it and overall over a wide range of speed it's better than everything, but it is possible to pick out 1 or 2 competitors that are as quick/quicker in very specific scenarios. I can't publish data on that though as it's all owned by Nopinz/Zone3 but will see what we have for the AeroCoach/Nopinz Flow stuff.

ps. when we've been doing our testing we haven't seen large changes in Crr based on rider speed.

Thanks, for your last sentence, and confirming, if I understand correctly, that we need to aero test at different speeds for a hilly or windy TT and at a specific speed for a non windy flat TT (or for track racing), cause Cd is speed dependent.

Blog | Twitter| Bike CdaCrr app
Quote Reply
Re: Platypus Thread: Aero Virtual Elevation Testing Protocol [RChung] [ In reply to ]
Quote | Reply
RChung wrote:
Tom A. wrote:
RChung wrote:
lanierb wrote:

On the Crr testing issue, if CdA and Crr are changing with speed, how about testing at identical speeds but adding/subtracting weight? Has anyone tried this approach? Once my shoulder heals I could give it a go with water bottles filled with lead. (Thinking out loud: lead would add significant weight so thinking that I would need to adjust tire pressure to hold Crr constant.)


That's exactly what I've been proposing for a while as a validation and precision check (and what Pierre (bugno) and I were chuckling about a few posts above). I've done a couple of these "delta mass" tests with empty and full water bottles. I used to use sand but then switched to small nails. I didn't want to use lead weights both because I wanted to re-use my water bottles and also because lead shot is kinda expensive. (On the other hand, a penny weighs 3 grams so $5 of pennies weighs 1.5kg). For me, with my other parameters, 1.5kg in mass increases rolling resistance force by the equivalent of ~.0001 in Crr, or around 10cm in virtual elevation per km. So over a 3 km run on a windless day, I was expecting to see a change in VE of ~30 cm between empty and loaded tests, which is pretty noticeable. So I did that, but at varying speeds, and was observing a VE difference close to that. But then the wind came back up, so I didn't get to do more tests.


Is this a case where you'd want to use Gatorskins or Tufos? (To get a bigger "signal")...the larger the Crr, the larger the absolute increase in rolling resistance force per kg, no?


Friends don't let friends ride Gatorskins or Tufos.

Not for pleasure...but, this is for SCIENCE! :-)

http://bikeblather.blogspot.com/
Quote Reply
Re: Platypus Thread: Aero Virtual Elevation Testing Protocol [bugno] [ In reply to ]
Quote | Reply
Interesting...but, I have to point out, in all of those additional examples you show, the apparent changes are significantly less than what is seen on that Grappe chart originally used as an example.

Also, speaking of the TT position being less change...having done quite a number of field tests, and having been in the wind tunnel as a rider, I would be hesitant to look at non-TT position data over wide variations in speed.

First off, in my own field tests I've observed that the results are much more consistent when testing with a TT position (where the rider is more "locked" in place...with a good position, that is ;-) than when testing with a road "on the hoods" or "in the drops" position.

Second, unless the wind tunnel testing was with a mannequin, I know there's a tendency for a rider to "brace" against increasing air speed, or even make subtle movements like ducking a head more, or decreasing torso angle as the wind speed comes up. I've found myself doing it at times, and although subtle, it can affect the results, especially with road positions.

For those 2 reasons, I try to do any of my field testing in an aero position...even if it means mounting aerobar extensions on a "gravel" bike ;-)

http://bikeblather.blogspot.com/
Quote Reply
Re: Platypus Thread: Aero Virtual Elevation Testing Protocol [Tom A.] [ In reply to ]
Quote | Reply
Tom A. wrote:
...I would be hesitant to look at non-TT position data over wide variations in speed.

Agreed, and I would expect noisier data for non-TT positions even at constant speeds. With a mannequin in the wind tunnel we've found noisier data with hands on the hoods, and cleaner data with torso closer to horizontal. Our suspicion is the flow over the rider may be more stable with the torso closer to horizontal.

Damon Rinard
Engineering Manager,
CSG Road Engineering Department
Cannondale & GT Bicycles
(ex-Cervelo, ex-Trek, ex-Velomax, ex-Kestrel)
Quote Reply
Re: Platypus Thread: Aero Virtual Elevation Testing Protocol [damon_rinard] [ In reply to ]
Quote | Reply
damon_rinard wrote:
Tom A. wrote:
...I would be hesitant to look at non-TT position data over wide variations in speed.


Agreed, and I would expect noisier data for non-TT positions even at constant speeds. With a mannequin in the wind tunnel we've found noisier data with hands on the hoods, and cleaner data with torso closer to horizontal. Our suspicion is the flow over the rider may be more stable with the torso closer to horizontal.

That's right! You mentioned that issue with flow steadiness relative to torso angle when you talked to josh@silca on his podcast.

http://bikeblather.blogspot.com/
Quote Reply
Re: Platypus Thread: Aero Virtual Elevation Testing Protocol [damon_rinard] [ In reply to ]
Quote | Reply
damon_rinard wrote:
Tom A. wrote:
...I would be hesitant to look at non-TT position data over wide variations in speed.


Agreed, and I would expect noisier data for non-TT positions even at constant speeds. With a mannequin in the wind tunnel we've found noisier data with hands on the hoods, and cleaner data with torso closer to horizontal. Our suspicion is the flow over the rider may be more stable with the torso closer to horizontal.

That was a good insight from your podcast with Josh.
Quote Reply
Re: Platypus Thread: Aero Virtual Elevation Testing Protocol [Tom A.] [ In reply to ]
Quote | Reply
Tom A. wrote:
Interesting...but, I have to point out, in all of those additional examples you show, the apparent changes are significantly less than what is seen on that Grappe chart originally used as an example.

Also, speaking of the TT position being less change...having done quite a number of field tests, and having been in the wind tunnel as a rider, I would be hesitant to look at non-TT position data over wide variations in speed.

First off, in my own field tests I've observed that the results are much more consistent when testing with a TT position (where the rider is more "locked" in place...with a good position, that is ;-) than when testing with a road "on the hoods" or "in the drops" position.

Second, unless the wind tunnel testing was with a mannequin, I know there's a tendency for a rider to "brace" against increasing air speed, or even make subtle movements like ducking a head more, or decreasing torso angle as the wind speed comes up. I've found myself doing it at times, and although subtle, it can affect the results, especially with road positions.

For those 2 reasons, I try to do any of my field testing in an aero position...even if it means mounting aerobar extensions on a "gravel" bike ;-)

Agreed on the above points and many others raised here.
- We recently mounted aerobar extensions to a 'gravel' bike for ALL of our Crr testing conducted in Houston TX in March. It worked really well. Then COVID hit and we had to wait for snow to melt in Alberta.
- Not only do you have challenges with maintaining position in drops or hoods, you also have experienced riders whose trials at low wattage are positionally changing when compared to high wattage (essentially they are tensed vs relaxed or have more/less sway in their shoulders and this has a change in CdA that makes repeatability a major issue).
- When it comes to the 'bluff body' and unsteady flow effects of an upright rider, this is on much shorter timescales than a full trial (say 1km loop). So one would expect that the effects would average out over a trial and not be a major issue for data variability. In my view, the major issue is the uncontrolled positional changes as noted above.
- I worked with Scarano at TU Delft doing Tomographic PIV during my PhD (about 8 years ago!). There are many challenges in extracting drag estimates (real-time or time-averaged) from the flow field alone and application of control volume approaches. The present state of the art in this type of flow measurement and force estimation still requires substantial refinement before it could become a mainstream tool. I think they named it the "ring of fire" concept originally. Cool name, needs more comprehensive validation studies.
- As the cycling industry started to use technology that generated airflow development effects which were sensitive to Reynolds number (laminar airfoil type shapes with separation and hysteresis effects, skin suits, etc.), I threw the "CdA of a cyclist is perfectly constant with Reynolds number" out the window. Is it close enough to constant over a typical range of speeds a rider would experience? In many cases, yes!

Chris Morton, PhD
Associate Professor, Mechanical Engineering
co-Founder and inventor of AeroLab Tech
For updates see Instagram
Quote Reply
Re: Platypus Thread: Aero Virtual Elevation Testing Protocol [AeroTech] [ In reply to ]
Quote | Reply
AeroTech wrote:

- As the cycling industry started to use technology that generated airflow development effects which were sensitive to Reynolds number (laminar airfoil type shapes with separation and hysteresis effects, skin suits, etc.), I threw the "CdA of a cyclist is perfectly constant with Reynolds number" out the window. Is it close enough to constant over a typical range of speeds a rider would experience? In many cases, yes!


Right, I think the important question isn't "are CdA and Crr speed-dependent?" We think they are. The important question is "how speed-dependent are they over the range of speeds we experience as cyclists?" That's an empirical question. It's handy to have a way to test and assess speed dependence.
Last edited by: RChung: Jun 9, 20 12:24
Quote Reply
Re: Platypus Thread: Aero Virtual Elevation Testing Protocol [RChung] [ In reply to ]
Quote | Reply
I agree with Robert: Few parameters that appear in modelling within Continuum Mechanics are fundamental constants. Commonly, we treat them as constants since such a convenient approximation leads to empirically adequate results.
Quote Reply
Re: Platypus Thread: Aero Virtual Elevation Testing Protocol [damon_rinard] [ In reply to ]
Quote | Reply
damon_rinard wrote:
Tom A. wrote:
...I would be hesitant to look at non-TT position data over wide variations in speed.


Agreed, and I would expect noisier data for non-TT positions even at constant speeds. With a mannequin in the wind tunnel we've found noisier data with hands on the hoods, and cleaner data with torso closer to horizontal. Our suspicion is the flow over the rider may be more stable with the torso closer to horizontal.

And we can imagine there the only possible use case of aero sensors during a ride. Not to measure a position or a piece of equipment, cause very possibly too unprecise (because of Crr/position/speed changes) for real-time CdA, but nevertheless enough to monitor and train the rider to keep a more aero position during a ride. An average CdA on the whole ride will be a new metric, and a reward if day after day, the number decreases. Only for road racers, where CdA range during long ride is large (IME, +/-0.06) and more trainable, not for TT racers, where it is normally very limited for short durations if well trained (IME, +/-0.005).

Blog | Twitter| Bike CdaCrr app
Last edited by: bugno: Jun 9, 20 14:04
Quote Reply
Re: Platypus Thread: Aero Virtual Elevation Testing Protocol [mslawins] [ In reply to ]
Quote | Reply
mslawins wrote:
I agree with Robert: Few parameters that appear in modelling within Continuum Mechanics are fundamental constants. Commonly, we treat them as constants since such a convenient approximation leads to empirically adequate results.
Another consideration is to view CdA, Crr, etc., as distributions, not as specific values. Thus, we might say that--with a given probability--a<CdA<b; e.g., Fig. 11 of https://arxiv.org/pdf/2005.04229.pdf .
Quote Reply
Re: Platypus Thread: Aero Virtual Elevation Testing Protocol [bugno] [ In reply to ]
Quote | Reply
Hi guys, Dan Bigham here. I'm not a regular poster on ST but I got sent this thread and found it pretty interesting! I have a few things to throw out there that I'm sure you'll enjoy digging in to.

I've seen CdA vary with speed pretty much since I started aero testing back at university. Have a google on "drag crisis" and you'll see pretty quickly why cyclist's CdAs are sensitive to speed. I've measured it on track, as you've seen from the Cycling Weekly test data posted in here from 2017, but also in the wind tunnel. See below for a speed sweep we did on one of our track team riders last year, using a "rough" suit.



As velocity increases surface roughness (skinsuit fabric) helps to transition the boundary layer to turbulent, and therefore increases it's resistance to separation in negative pressure gradients, reducing pressure drag. This is the critical Re range, above this there is no further benefit and CdA starts to increase again as velocity increases further. Plenty to read here for those interested: https://www.sciencedirect.com/...167610520300532#fig1

It's even more clear in fabric testing. I'm not at liberty to share any of our (HUUB's) test data but luckily enough Rule28 Clothing have shared theirs publicly, which was nice of them! For full disclosure, I don't work for or have involvement with Rule28. They used to sponsor both my road and track teams (Ribble Weldtite & HUUB Wattbike), and I tested their original aero sock back in 2017 for them. Link to their testing overview here: https://www.rule28.com/...2020-product-testing and to download their fabric testing data off their website here: https://drive.google.com/...X_USiyV90mYbWSZ/view

Just one of their fabric's graphs.



Have a look through all their fabric data and you'll see how varied each fabric's performance is, even when it is just simply flipped or rotated. It's why I've always found it funny when "aero stripe" is talked about like it's one fabric that performs the same, when there is probably >40 "striped" fabrics on the market all with their own Cd-Re curves that are wildly different. Obviously, this data applies to a cylinder (arm or a leg), but the principle still stands for a cyclist that is effectively a collection of different sizes cylinders (~ish). I've tested a lot of suits that clearly "drop in" at different speeds, depending on the fabric chosen. This aligns well with fabric testing. You can run the numbers on the size of a rider's lower leg to get frontal area, multiply up by the Cd at your chosen Reynolds number (speed) and see pretty quickly how big of a CdA reduction you are likely to get.

Hope that adds a bit to the discussion, even if it presents a few headaches for those doing variable speed runs to separate out CdA and Crr. The Crr-speed sensitivity is a whole other can of worms!
Last edited by: Biggles22: Jun 10, 20 1:58
Quote Reply
Re: Platypus Thread: Aero Virtual Elevation Testing Protocol [Biggles22] [ In reply to ]
Quote | Reply
With this could say that regression method has a limitation.

We have a critical point from it Cda increase again. I think that is the same for Crr.
Quote Reply
Re: Platypus Thread: Aero Virtual Elevation Testing Protocol [Biggles22] [ In reply to ]
Quote | Reply
Biggles22 wrote:
. See below for a speed sweep we did on one of our track team riders last year, using a "rough" suit.

Dan, thanks for chiming in.

Do you have more data for the left of that chart. How does the curve look left of 50km/h ?
Quote Reply
Re: Platypus Thread: Aero Virtual Elevation Testing Protocol [damon_rinard] [ In reply to ]
Quote | Reply
damon_rinard wrote:
RChung wrote:
...GPS speed and gradient and a Stages power meter...

I noticed you noted that. :-)

This is why I love this forum...

Eric Reid AeroFit | Instagram Portfolio
Aerodynamic Retul Bike Fitting

“You are experiencing the criminal coverup of a foreign backed fascist hostile takeover of a mafia shakedown of an authoritarian religious slow motion coup. Persuade people to vote for Democracy.â€
Quote Reply
Re: Platypus Thread: Aero Virtual Elevation Testing Protocol [mslawins] [ In reply to ]
Quote | Reply
mslawins wrote:
mslawins wrote:
I agree with Robert: Few parameters that appear in modelling within Continuum Mechanics are fundamental constants. Commonly, we treat them as constants since such a convenient approximation leads to empirically adequate results.

Another consideration is to view CdA, Crr, etc., as distributions, not as specific values. Thus, we might say that--with a given probability--a<CdA<b; e.g., Fig. 11 of https://arxiv.org/pdf/2005.04229.pdf .

Michael, thanks. Yup, I've done some distributions of the drag parameters too, though not in a formal Bayesian sense. Getting parameter distributions is easier on the velodrome than out on the road but it's possible (though more of a pain in the butt to do).
Quote Reply
Re: Platypus Thread: Aero Virtual Elevation Testing Protocol [Biggles22] [ In reply to ]
Quote | Reply
Biggles22 wrote:
I've seen CdA vary with speed pretty much since I started aero testing back at university. Have a google on "drag crisis" and you'll see pretty quickly why cyclist's CdAs are sensitive to speed. I've measured it on track, as you've seen from the Cycling Weekly test data posted in here from 2017, but also in the wind tunnel. See below for a speed sweep we did on one of our track team riders last year, using a "rough" suit.

Dan, thanks for joining the discussion.

You're seeing ~3% decrease in CdA with an increase in speed from 14 to 18 m/s (= 50 to 65 km/h, or 30 to 40 mph). I presume this was in the tunnel? I think we all agree that CdA is speed-dependent, and that we can trip through a drag crisis -- the question is at what speeds and for which shapes.

I think one of the things which I've perhaps under-emphasized (since it doesn't come up very ofen) is that I can detect speed-dependence in velodrome tests. It's more work but generally when the answer is important I bite the bullet and do it. That said, on the occasions when it's been important enough to do that, I was mostly interested in total drag from both CdA and Crr together and not so much interested in the separate parts.
Quote Reply
Re: Platypus Thread: Aero Virtual Elevation Testing Protocol [RChung] [ In reply to ]
Quote | Reply
BTW: One of my coauthors, and a former postdoc, Tomasz Danek is very much a "Baysian"
Quote Reply
Re: Platypus Thread: Aero Virtual Elevation Testing Protocol [mslawins] [ In reply to ]
Quote | Reply
mslawins wrote:
BTW: One of my coauthors, and a former postdoc, Tomasz Danek is very much a "Bayesian"
(To be fair, we should perhaps credit Pierre-Simon Laplace more than Thomas Bayes ... .)
Quote Reply
Re: Platypus Thread: Aero Virtual Elevation Testing Protocol [Biggles22] [ In reply to ]
Quote | Reply
Biggles22 wrote:
Hi guys, Dan Bigham here. I'm not a regular poster on ST but I got sent this thread and found it pretty interesting! I have a few things to throw out there that I'm sure you'll enjoy digging in to.

I've seen CdA vary with speed pretty much since I started aero testing back at university. Have a google on "drag crisis" and you'll see pretty quickly why cyclist's CdAs are sensitive to speed. I've measured it on track, as you've seen from the Cycling Weekly test data posted in here from 2017, but also in the wind tunnel. See below for a speed sweep we did on one of our track team riders last year, using a "rough" suit.



As velocity increases surface roughness (skinsuit fabric) helps to transition the boundary layer to turbulent, and therefore increases it's resistance to separation in negative pressure gradients, reducing pressure drag. This is the critical Re range, above this there is no further benefit and CdA starts to increase again as velocity increases further. Plenty to read here for those interested: https://www.sciencedirect.com/...167610520300532#fig1

It's even more clear in fabric testing. I'm not at liberty to share any of our (HUUB's) test data but luckily enough Rule28 Clothing have shared theirs publicly, which was nice of them! For full disclosure, I don't work for or have involvement with Rule28. They used to sponsor both my road and track teams (Ribble Weldtite & HUUB Wattbike), and I tested their original aero sock back in 2017 for them. Link to their testing overview here: https://www.rule28.com/...2020-product-testing and to download their fabric testing data off their website here: https://drive.google.com/...X_USiyV90mYbWSZ/view



Just one of their fabric's graphs.



Have a look through all their fabric data and you'll see how varied each fabric's performance is, even when it is just simply flipped or rotated. It's why I've always found it funny when "aero stripe" is talked about like it's one fabric that performs the same, when there is probably >40 "striped" fabrics on the market all with their own Cd-Re curves that are wildly different. Obviously, this data applies to a cylinder (arm or a leg), but the principle still stands for a cyclist that is effectively a collection of different sizes cylinders (~ish). I've tested a lot of suits that clearly "drop in" at different speeds, depending on the fabric chosen. This aligns well with fabric testing. You can run the numbers on the size of a rider's lower leg to get frontal area, multiply up by the Cd at your chosen Reynolds number (speed) and see pretty quickly how big of a CdA reduction you are likely to get.

Hope that adds a bit to the discussion, even if it presents a few headaches for those doing variable speed runs to separate out CdA and Crr. The Crr-speed sensitivity is a whole other can of worms!


Thank you Dan for taking the time to share your experience with us. The Rule28 database is impressive. I aero tested several socks, but never saw the claimed gains, while the advantage brought by the management of the separation of the flow is proven by science for a long time. I guess the Reynolds number for my legs was too low, too often :-) Really need to check carefully next times, and plot airspeed histograms as for my venue, it varies from 15 to 50 kmh.

Blog | Twitter| Bike CdaCrr app
Last edited by: bugno: Jun 10, 20 12:51
Quote Reply
Re: Platypus Thread: Aero Virtual Elevation Testing Protocol [Biggles22] [ In reply to ]
Quote | Reply
Biggles22 wrote:
I've measured it on track, as you've seen from the Cycling Weekly test data posted in here from 2017, but also in the wind tunnel. See below for a speed sweep we did on one of our track team riders last year, using a "rough" suit.

Dan, how were you measuring CdA on the track?
Quote Reply
Re: Platypus Thread: Aero Virtual Elevation Testing Protocol [RChung] [ In reply to ]
Quote | Reply
Is this method for calculate Crr any similar to GC? Or it could be more accuracy?

https://www.researchgate.net/..._on_aerodynamic_drag

"Firstly, the cyclists performed a discontinuous incremental exercise at different V to determine the rolling resistance coefficient (Cr) from the RT-V2 linear regression method (Grappe et al. 1997)"
Quote Reply
Re: Platypus Thread: Aero Virtual Elevation Testing Protocol [cyclistgo] [ In reply to ]
Quote | Reply
cyclistgo wrote:
Is this method for calculate Crr any similar to GC? Or it could be more accuracy?

https://www.researchgate.net/..._on_aerodynamic_drag

"Firstly, the cyclists performed a discontinuous incremental exercise at different V to determine the rolling resistance coefficient (Cr) from the RT-V2 linear regression method (Grappe et al. 1997)"

Ah, I was there at that conference and spoke with the authors. So, that's what I've been calling the "classic regression" method, which is a special case of what I do. That is, in that method you do runs at different speeds but each run is done at constant speed and power. So it, too, assumes that your speeds are in a range where Crr and CdA don't change with speed. It's a special case because in their experiment they have to hold speed and power constant so they can assume acceleration is zero; I take acceleration into account so you don't have to make that assumption. If you *can* hold acceleration to zero, my method calculates all the accelerations to be zero so it simplifies to theirs. If you can't, my method is more accurate because they omit an important variable while I include it. In statistical terms, they're subject to what's called "omitted variable bias."
Quote Reply
Re: Platypus Thread: Aero Virtual Elevation Testing Protocol [RChung] [ In reply to ]
Quote | Reply
Ok, undertand it.

If I want to control Crr (Coeficient), without calculate it, which variables I need to control? Air temperature and wheel pressure? Or perhaps wheel width also?
Quote Reply
Re: Platypus Thread: Aero Virtual Elevation Testing Protocol [cyclistgo] [ In reply to ]
Quote | Reply
cyclistgo wrote:
Ok, undertand it.

If I want to control Crr (Coeficient), without calculate it, which variables I need to control? Air temperature and wheel pressure? Or perhaps wheel width also?

If all you want to do is compare CdA, just use the same tires at the same tire pressure. Measure (or estimate) air density and use a fixed constant value for Crr. That won't be exactly correct, but it will get you close. Then you'll be able to get an approximate value for CdA for that particular assumed value of Crr. You can use that to estimate speeds at different powers. That's what I did for a couple of hour record attempts: we couldn't have known what the air density was going to be on the day of the attempt, nor what power the rider would actually be able to maintain so I put together a table that said, "with these values for Crr and CdA, if the air density was *this* and you could average *that* power, then here's how far you will go." After the attempts, we knew what the air density had been, and what power the rider had produced so we could see whether the predictions were correct. Pretty damn close.
Quote Reply
Re: Platypus Thread: Aero Virtual Elevation Testing Protocol [RChung] [ In reply to ]
Quote | Reply
RChung wrote:
If all you want to do is compare CdA, just use the same tires at the same tire pressure. Measure (or estimate) air density and use a fixed constant value for Crr. That won't be exactly correct, but it will get you close. Then you'll be able to get an approximate value for CdA for that particular assumed value of Crr. You can use that to estimate speeds at different powers. That's what I did for a couple of hour record attempts: we couldn't have known what the air density was going to be on the day of the attempt, nor what power the rider would actually be able to maintain so I put together a table that said, "with these values for Crr and CdA, if the air density was *this* and you could average *that* power, then here's how far you will go." After the attempts, we knew what the air density had been, and what power the rider had produced so we could see whether the predictions were correct. Pretty damn close.
Yeah a corollary to the result that it's hard to tell the difference between Crr and CdA is that, for most purposes, you don't need precise estimates of them separately to get useful predictions. As long as they are consistent with each other and ball park correct you're good.
Quote Reply
Re: Platypus Thread: Aero Virtual Elevation Testing Protocol [lanierb] [ In reply to ]
Quote | Reply
lanierb wrote:

Yeah a corollary to the result that it's hard to tell the difference between Crr and CdA is that, for most purposes, you don't need precise estimates of them separately to get useful predictions. As long as they are consistent with each other and ball park correct you're good.


Yeah, it's sort of like separating Cd and A. For most of us who ride bikes, we don't really have to get separate estimates of Cd and A. All we need is their product, CdA. Likewise, Crr comes into the equation as Crr*mass*g, but g isn't actually constant across the surface of the earth. The earth is actually kinda squashed in shape and there are mountains so on the surface of the earth in the Andes near the equator g is about 0.7% lower than at sea level at the North Pole. But most velodromes aren't quite that big, so we just treat g as if it were a global constant.
Last edited by: RChung: Jun 18, 20 15:08
Quote Reply
Re: Platypus Thread: Aero Virtual Elevation Testing Protocol [AndyF] [ In reply to ]
Quote | Reply
I am new to VE testing and did a set today. It is a saddle with the out being a bit more uphill and then on the turn coming back to the start it was more downhill than I thought so I had to soft pedal it. I did sit up at each turn but it was consistent each time.

The first set I did was my current setup but I pushed stopped at a bit different spot than when I started to the beginning and end aren't the same.

The second set I did I lowered my bars 15mm. I just had a bike fit and the fitter thought based on my position that I could ride a bit higher and not suffer an aero penalty. I was hoping I could have some VE gurus take a look here.

I used a speed sensor and had GPS turned off on my head unit. I did 5-6 laps on the saddle for each setup.
Quote Reply
Re: Platypus Thread: Aero Virtual Elevation Testing Protocol [lonniecdams] [ In reply to ]
Quote | Reply
Try to find a way to share the fit files.

Also post your weight, power meter type, tire type, location date and time of day (or even better yet weather station data you collected).
Quote Reply
Re: Platypus Thread: Aero Virtual Elevation Testing Protocol [marcag] [ In reply to ]
Quote | Reply
Weird I attached the files but they didn't show up. Hmmmm?

Setup weight 181 lbs. (82.1kg)
Tire: GP Force 700x25
Location: Lander, WY 8:30 AM
Weather Station: Used Weather Underground facility that measures was .75 miles away
Quote Reply
Re: Platypus Thread: Aero Virtual Elevation Testing Protocol [lonniecdams] [ In reply to ]
Quote | Reply
Power meter type ?
Quote Reply
Re: Platypus Thread: Aero Virtual Elevation Testing Protocol [marcag] [ In reply to ]
Quote | Reply
Powertap P1
Quote Reply
Re: Platypus Thread: Aero Virtual Elevation Testing Protocol [lonniecdams] [ In reply to ]
Quote | Reply
That wasn't to shame you if you used a single side powermeter :-)
It was to know to use a 0.97 ETA for a PM at the crank or 1.0 for a PM at the hub.
Quote Reply
Re: Platypus Thread: Aero Virtual Elevation Testing Protocol [marcag] [ In reply to ]
Quote | Reply
Ya, I got that, lol. It is dual sided. I did my best to research the eta portion of it and I figured that is what you wanted.
Quote Reply
Re: Platypus Thread: Aero Virtual Elevation Testing Protocol [lonniecdams] [ In reply to ]
Quote | Reply
If you all PM me I can email you my spreadsheet for VE.

You may need to do some edits or pastes or small updates to make it work for your file, but it's enough to get the idea. You can paste in the rider info (weight, CRR, etc...).

I did this a while back for folks. I accept no liability of errors. Just be good enough at Excel to catch errors when you're working with it.
Quote Reply
Re: Platypus Thread: Aero Virtual Elevation Testing Protocol [lonniecdams] [ In reply to ]
Quote | Reply
Here are some screenshots
I did them quickly in GC, you can fiddle with the data but these are the fields you enter
I attached the weather data and RHO calculator
This is not normally how I do it personally.
Last edited by: marcag: Jul 15, 20 13:32
Quote Reply
Re: Platypus Thread: Aero Virtual Elevation Testing Protocol [marcag] [ In reply to ]
Quote | Reply
marcag wrote:
Here are some screenshots
I did them quickly in GC, you can fiddle with the data but these are the fields you enter
I attached the weather data and RHO calculator
This is not normally how I do it personally.


Marc, lonniecdams,

The rho calculator in GC uses "station" barometric pressure. Unfortunately for us, official weather stations like those at airports standardize to sea level. Lander WY is at an altitude of 1600m, so if you're using an official barometric reading rather than "station" pressure, you need to adjust for that.

What this means is that air density in Lander was close to 1.00 rather than 1.219. Since the density was lower, it unfortunately means that lonniecdams CdA was higher. rho multiplies the CdA, so if rho is lower by 1%, then CdA is higher by 1%. In this case, rho appears to be about 17% lower, so CdA will be 17% higher.

(As an aside, a quick rule of thumb is that air density decreases by about 1% for every 100m in elevation gain, so since Lander is at 1600m ASL, the rule of thumb is that rho would be about 16% lower. The rule of thumb isn't bad).

In any event, the difference in the CdA between the two tests is about .008 m^2. That much difference in drag area is roughly half way between the drag of a standard business card and a 3x5 index card; or, using Coggan's rule of thumb, at racing speed that's close to 30 seconds in a 40km TT.
Last edited by: RChung: Jul 15, 20 15:03
Quote Reply
Re: Platypus Thread: Aero Virtual Elevation Testing Protocol [RChung] [ In reply to ]
Quote | Reply
RChung wrote:
marcag wrote:
Here are some screenshots
I did them quickly in GC, you can fiddle with the data but these are the fields you enter
I attached the weather data and RHO calculator
This is not normally how I do it personally.


Marc, lonniecdams,

The rho calculator in GC uses "station" barometric pressure. Unfortunately for us, official weather stations like those at airports standardize to sea level. Lander WY is at an altitude of 1600m, so if you're using an official barometric reading rather than "station" pressure, you need to adjust for that.

What this means is that air density in Lander was close to 1.00 rather than 1.219. Since the density was lower, it unfortunately means that lonniecdams CdA was higher. rho multiplies the CdA, so if rho is lower by 1%, then CdA is higher by 1%. In this case, rho appears to be about 17% lower, so CdA will be 17% higher.

(As an aside, a quick rule of thumb is that air density decreases by about 1% for every 100m in elevation gain, so since Lander is at 1600m ASL, the rule of thumb is that rho would be about 16% lower. The rule of thumb isn't bad).


Thanks

I don't normally use weather station data.
a) I use air pressure in the air component of the VE
b) I do measure barometric pressure

So the weather station is giving PA at sea level ?
Quote Reply
Re: Platypus Thread: Aero Virtual Elevation Testing Protocol [marcag] [ In reply to ]
Quote | Reply
marcag wrote:
So the weather station is giving PA at sea level ?

Official ones do, and then they tell you what altitude they're at. Alternatively, if you have a portable handheld one (like I do) then I set it at my home (which happens to be at sea level) and then when I get to the top of the ridge behind my house I can just read off the proper rho.
Quote Reply
Re: Platypus Thread: Aero Virtual Elevation Testing Protocol [lonniecdams] [ In reply to ]
Quote | Reply
Here's what I got... I used darksky's historical weather data and adjusted for altitude. I wasn't so generous with crr :) I don't think you'll get better than 0.005 on average asphalt with those tires, but I could be wrong.





lonniecdams wrote:
Weird I attached the files but they didn't show up. Hmmmm?
Setup weight 181 lbs. (82.1kg)
Tire: GP Force 700x25
Location: Lander, WY 8:30 AM
Weather Station: Used Weather Underground facility that measures was .75 miles away

What's your CdA?
Quote Reply
Re: Platypus Thread: Aero Virtual Elevation Testing Protocol [RChung] [ In reply to ]
Quote | Reply
RChung wrote:
Alternatively, if you have a portable handheld one (like I do)

which one do you use ?
Quote Reply
Re: Platypus Thread: Aero Virtual Elevation Testing Protocol [G. Belson] [ In reply to ]
Quote | Reply
G. Belson wrote:
I used darksky's historical weather data and adjusted for altitude.

What do you plan to use when darksky goes away ?
Quote Reply
Re: Platypus Thread: Aero Virtual Elevation Testing Protocol [G. Belson] [ In reply to ]
Quote | Reply
do you adjust for ETA ?
Quote Reply
Re: Platypus Thread: Aero Virtual Elevation Testing Protocol [marcag] [ In reply to ]
Quote | Reply
marcag wrote:
RChung wrote:
Alternatively, if you have a portable handheld one (like I do)


which one do you use ?


I have the Kestrel 5100. I don't actually use it very much for the anemometer function any more. I got it mostly so I could learn and "calibrate" my sense of windspeed, and figure out how much difference there is in wind at bicycle height and up a little higher. The coolest use was to verify windspeed inside the velodrome.
Last edited by: RChung: Jul 15, 20 16:10
Quote Reply
Re: Platypus Thread: Aero Virtual Elevation Testing Protocol [RChung] [ In reply to ]
Quote | Reply
RChung wrote:
marcag wrote:
RChung wrote:
Alternatively, if you have a portable handheld one (like I do)


which one do you use ?


I have the Kestrel 5100. I don't actually use it very much for the anemometer function any more. I got it mostly so I could learn and "calibrate" my sense of windspeed, and figure out how much difference there is in wind at bicycle height and up a little higher. The coolest use was to verify windspeed inside the velodrome.

So the Kestrel gives you barometric pressure at the point you are standing or you have to do some kind of calibration like sitting in your living room to 0m :-)
Quote Reply
Re: Platypus Thread: Aero Virtual Elevation Testing Protocol [marcag] [ In reply to ]
Quote | Reply
Hah, I had no idea it was going away. Looks like the API will still be online until the end of 2021. I guess I'll be going back to using OpenWeatherMap. Sucks because darsky's API was so much better.

marcag wrote:
G. Belson wrote:
I used darksky's historical weather data and adjusted for altitude.

What do you plan to use when darksky goes away ?

What's your CdA?
Quote Reply
Re: Platypus Thread: Aero Virtual Elevation Testing Protocol [marcag] [ In reply to ]
Quote | Reply
marcag wrote:
RChung wrote:
marcag wrote:
which one do you use ?


I have the Kestrel 5100. I don't actually use it very much for the anemometer function any more. I got it mostly so I could learn and "calibrate" my sense of windspeed, and figure out how much difference there is in wind at bicycle height and up a little higher. The coolest use was to verify windspeed inside the velodrome.


So the Kestrel gives you barometric pressure at the point you are standing or you have to do some kind of calibration like sitting in your living room to 0m :-)

So, it gives you "station pressure" if you know your altitude -- and then automatically calculates rho. Alternatively, if you're trying to use it as an altimeter to measure change in elevation, you need to enter your starting baseline baro pressure. But I hardly ever use it this way. Mostly, I'm at a particular location and I have a pretty good idea what its altitude is. Then it measures the pressure, temperature, humidity, and tells me rho.
Quote Reply
Re: Platypus Thread: Aero Virtual Elevation Testing Protocol [RChung] [ In reply to ]
Quote | Reply
I guess I was looking more for was my course a good course, but thanks for all the other information.
Quote Reply
Re: Platypus Thread: Aero Virtual Elevation Testing Protocol [Biggles22] [ In reply to ]
Quote | Reply
The Rule 28 data that Dan posted shows the same Cd-Re characteristics, not surprisingly perhaps, as the characteristics of a cylinder or sphere with roughness that is often illustrated in fluid mechanics text books. For example:



http://brennen.caltech.edu/fluidbook/externalflows/drag/dragonasphere.pdf[/url]

This shows, if it wasn’t already obvious, that these aerostripe fabrics are working by tripping the boundary layer, and that you’d want to choose a fabric with protuberances that are just large enough to cause transition for the Reynolds number of interest, but not larger than is necessary (otherwise that’ll just overly thicken the turbulent boundary layer).

I have a couple of thoughts and questions, having just read the posts on this thread from the last few months about speed dependence on CdA (and possibly Crr):

1) Many of the things that people would want to test with the Chung method will affect in some way the points of flow separation on the bike or rider (e.g. socks, skinsuits, torso angles). Should the protocol recommended in this thread suggest that the person targets the speed range that is relevant to their race/event/discipline? That might affect the location that somebody chooses for testing. For example (a real example for me), if I want to check the benefit of trip socks, and my usual event is a flat-ish TT done at 40-45 kph, doing a VE test where half of the lap is uphill at 25kph may introduce uncertainties about whether the trips are working at the low speed sections. A velodrome would be a better choice. Of course, our choice of test location is usually a compromise, with several considerations.

2) For the Tom Compton Challenge, I’ve always wondered whether a sphere is a good object to use, in view of it’s Reynolds sensitivity. Personally, I’ve never found the time to do the test. However, the polystyrene ball, that has been patiently sitting in my garage for a few years, does not have a smooth surface. I’m not sure which side of the drag crisis it would sit. I wonder if it would be better to instead use an object that is less Reynolds-sensitive, such as a flat disc perpendicular to the flow.


Quote Reply
Re: Platypus Thread: Aero Virtual Elevation Testing Protocol [NickD1] [ In reply to ]
Quote | Reply
Nick:

Nice to see you back.

Yes, in general you should try to test at the speeds and under the conditions you'll be racing -- though that's not always easy for practical reasons. In addition, if you *are* concerned about speed dependence and you want to identify that, you're certainly going to have to test at varying speeds.

For the Compton Challenge, I tried to use a wooden cube on a stick. It was actually a wood block my kid played with when he was a year old but once he graduated from school I figured he wasn't going to play with it anymore. To get to clean air and out of the bow wave, you can either go out to the side, or way way in front, or up high. I mounted a dowel vertically to the back of my saddle, and figured out how to mount the block to the top of it. Then to "tare" the dowel, on a calm day I went on a test run with just the bare dowel, varying my speed. But when the test run was done I forgot the dowel was back there so when I dismounted I snapped it off and stabbed myself in the butt. Don't do that.


If what you're trying to do is to determine how small of an effect you can reliably detect, I think a simpler test is the delta mass test. I've mentioned "delta mass" a couple of times in this thread before but I don't think I explained why I prefer it. Now you know. All you're really trying to do is to see how small of a drag force you can measure reliably, and it doesn't matter whether that drag force is aero drag or rolling drag. So do test runs with an empty water bottle and then the bottle filled with something heavy. I've used sand and small nails but an alternative is to use pennies. You can stuff a kilo of mass into a water bottle without risking your bottle cages.
Quote Reply
Re: Platypus Thread: Aero Virtual Elevation Testing Protocol [RChung] [ In reply to ]
Quote | Reply
Thanks Robert. I’ve seen your suggestion of the delta mass technique in previous posts, but I haven’t tried that yet. I suspect most people haven't gone for that variant of the Compton Challenge because the most obvious way to check a method for determining CdA is to change the CdA and see what can be detected (I‘m assuming the majority of people that are using your method are doing it to get a CdA estimate).

Thinking about it though, the delta mass test is probably easier to perform than rigging up support to hold a dragging object in undisturbed flow (as well as avoid any potential injuries!). I have a feeling my test technique and choice of low-wind days is not good enough to detect a kilogram of extra rolling resistance though, so I’d probably have to go for two bottles or heavier contents to be successful. I also think a lot can be learnt about the method precision from the observed differences in ABAB repeats.

The idea to tare the support is also a really neat idea. When I’ve read other people’s accounts of their Compton Challenge attempts, I think they calculated the incremental CdA of the support instead, which must be tricky because part of the support will always be in disturbed air.
Quote Reply
Re: Platypus Thread: Aero Virtual Elevation Testing Protocol [NickD1] [ In reply to ]
Quote | Reply
NickD1 wrote:
I suspect most people haven't gone for that variant of the Compton Challenge because the most obvious way to check a method for determining CdA is to change the CdA and see what can be detected (I‘m assuming the majority of people that are using your method are doing it to get a CdA estimate).
Yeah, I'm sure that's true. It seems backwards to measure precision in CdA by looking at precision in measurement of mass -- but in all these cases we're just measuring differences in drag. In fact, if we had a truly accurate way to measure height you could measure how small of a difference in elevation you could detect, so an alternative I'd been thinking of was building a little ramp of known height, maybe 15 cm high, and rolling over that. If the data and method estimated the ramp as X cm, that would be a way to assess precision. But once again you run into the problem that people think they should be altering CdA, not ramp height. So I haven't done that experiment. But I'm reasonably sure it'd work.
Quote Reply
Re: Platypus Thread: Aero Virtual Elevation Testing Protocol [RChung] [ In reply to ]
Quote | Reply
How does mass affect drag? Through inertia and gravity and friction but not shape of a body. What is gained from altering mass?
Last edited by: BergHugi: Aug 21, 20 14:33
Quote Reply
Re: Platypus Thread: Aero Virtual Elevation Testing Protocol [BergHugi] [ In reply to ]
Quote | Reply
BergHugi wrote:
How does mass affect drag? Through inertia and gravity and friction but not shape of a body. What is gained from altering mass?

You're altering mass by a known amount without changing the shape of the body so the drag should change by a known amount. So we measure the amount it does change and compare it to the amount it should change.
Quote Reply
Re: Platypus Thread: Aero Virtual Elevation Testing Protocol [RChung] [ In reply to ]
Quote | Reply
And if you alter the mass by the amount 0 you actually know how drag should change and compare it to the amount drag does change.

There are easier ways to measure mass, just compare it with a known mass.
Quote Reply
Re: Platypus Thread: Aero Virtual Elevation Testing Protocol [RChung] [ In reply to ]
Quote | Reply
Not replying to anything in this thread in particular but just want to check a few things before I start my own testing for the first time ever. I have a lot of things I want to try.

1. How important is a separate speed sensor vs GPS? Don't currently have one but don't mind buying one if it's going to drastically improve results.
2. I know the rule is absolutely no braking and hold position, but does that also apply to the turnaround if doing a half-pipe? If I'm testing in aero position, do I need to find a course with a spot wide enough to turn around in aero or better yet, a loop? Or is the turn around slow enough that it shouldn't affect the data.
3. Is there a minimum elevation gain/loss required for the course? I can think of a fairly nice stretch of road but the dips are very minimal.

Thanks all.

Benjamin Deal - Professional - Instagram - TriRig - Lodi Cyclery
Deals on Wheels - Results, schedule, videos, sponsors
Quote Reply
Re: Platypus Thread: Aero Virtual Elevation Testing Protocol [realbdeal] [ In reply to ]
Quote | Reply
realbdeal wrote:
Not replying to anything in this thread in particular but just want to check a few things before I start my own testing for the first time ever. I have a lot of things I want to try.

1. How important is a separate speed sensor vs GPS? Don't currently have one but don't mind buying one if it's going to drastically improve results.
Depends on how good the GPS signal is. I prefer test venues that have some shelter from trees to dissipate the wind, but trees can block the GPS signal. If your test venue is a straight road, the signal is less important than if there's a curve (especially if the tree cover is right at the point where the curve is located). In addition, some older head units are smaller, so the size of the GPS antenna is smaller, so the positioning isn't quite as good. From a practical perspective, I'd do a quick non-critical ride on the course and come back and look at the GPS trace and especially the speed changes from second to second. If the trace is good and the speed changes look smooth rather than jumpy, you might be okay without a dedicated wheel sensor. If not, you're probably going to have to get one if you want acceptable precision.

Quote:
2. I know the rule is absolutely no braking and hold position, but does that also apply to the turnaround if doing a half-pipe? If I'm testing in aero position, do I need to find a course with a spot wide enough to turn around in aero or better yet, a loop? Or is the turn around slow enough that it shouldn't affect the data.
Sometimes you have no other choice than to use brakes (not just for the turnaround, but for cars or dogs or other obstacles). The #1 rule is don't get hit, and don't hit anyone else. That's also rules 2 and 3. That said, I've used test venues where I had to brake at the turnaround but I'm sorta used to snipping out that part of the data and stitching the parts back together. That might be too advanced for most people, at least with current tools. I would say that *if* you are going to use the brakes, don't feather them, hit them hard so that it's clear where you did use them. What you don't want is to wonder where you used the brakes.


Quote:
3. Is there a minimum elevation gain/loss required for the course? I can think of a fairly nice stretch of road but the dips are very minimal.
Not really. People do this on velodromes, where the change in elevation is maybe a few inches. The real reason why a half pipe course is handy isn't because the elevation change is necessary, it's because it's handy to get a wide range of speeds and the climb at the ends slows you down enough so that you don't have to use the brakes (much) at each end.
Quote Reply
Re: Platypus Thread: Aero Virtual Elevation Testing Protocol [RChung] [ In reply to ]
Quote | Reply
Appreciate it Robert. Thank you.

Last question because I couldn't find a solid answer anywhere, should the start of each run be rolling or from a standstill?

I realized the best thing for me to do will just be go out there and give it attemps and start learning, but I just want to make sure I'm not making any obvious mistakes.

Benjamin Deal - Professional - Instagram - TriRig - Lodi Cyclery
Deals on Wheels - Results, schedule, videos, sponsors
Quote Reply
Re: Platypus Thread: Aero Virtual Elevation Testing Protocol [realbdeal] [ In reply to ]
Quote | Reply
realbdeal wrote:
should the start of each run be rolling or from a standstill?


It doesn't matter all that much, but I usually do rolling so I can already be locked into position when I hit the lap button rather than fiddle around getting into position. For a half-pipe course, Tom A. has talked about hitting the lap button a few seconds before the lap "start" as he approaches the first turnaround, and he hits the lap button again a few seconds after the crest of the last turnaround. He doesn't hit the lap button during the test so he can stay in position all the test without moving his hands. I do the same, even when the course isn't a half-pipe: I hit the lap button once before the point where I'm going to start, and then after the very end. Usually it's pretty easy to spot the laps so you don't have to mark them explicitly with the button. Hitting the button before the "official" start of the lap and then after the end gives you two extra well-defined peaks to line up.

An oddity that I've had is that the data from my very first lap is often noisier than subsequent laps. I used to worry about this a lot and tried to track down why that was but, in the end, I decided it was more practical just to plan on doing an extra lap at the start (for example, if I planned on 3 laps for each test, I'd do 4 laps instead for the very first one). Then, if the data are noisy, I just toss that first lap. This is one of the reasons why I try not to make my laps 2 or 3 miles long; shorter laps let you do more of them, and if you have to toss one lap, not only for noisiness but also for a passing car or a chasing dog, it's not so painful.
Quote Reply
Re: Platypus Thread: Aero Virtual Elevation Testing Protocol [realbdeal] [ In reply to ]
Quote | Reply
Question for the group:

For half pipe testing can I get out of aero for the turnarounds? So few course options around me but if I'm allowed to do that for a tighter turn around I think I have a spot.

Benjamin Deal - Professional - Instagram - TriRig - Lodi Cyclery
Deals on Wheels - Results, schedule, videos, sponsors
Quote Reply
Re: Platypus Thread: Aero Virtual Elevation Testing Protocol [realbdeal] [ In reply to ]
Quote | Reply
realbdeal wrote:
Question for the group:

For half pipe testing can I get out of aero for the turnarounds? So few course options around me but if I'm allowed to do that for a tighter turn around I think I have a spot.

That's what I do. Since you're travelling slowly (or should be) at the turnarounds on a "half-pipe" course, the effects on the total run of getting out of aero are extremely small, so being able to quickly sit up, look around, and make sure your turn is safe to do is what is paramount.

http://bikeblather.blogspot.com/
Quote Reply
Re: Platypus Thread: Aero Virtual Elevation Testing Protocol [realbdeal] [ In reply to ]
Quote | Reply
I concur with Tom A.... slow down, sit up, look behind, then turn.
Quote Reply
Re: Platypus Thread: Aero Virtual Elevation Testing Protocol [RChung] [ In reply to ]
Quote | Reply
I have a course that is a straight road with a cul-de-sac/lollipop at one end. It doesn't have enough elevation change to really slow down using only gravity so I coast for a bit and then I sometimes turn aggressively if I haven't slowed as much as anticipated at the lollipop. It seems that the aggressive turn is scrubbing off quite a bit of speed almost as if I were lightly applying the brakes through the corner. When I thought about the original set of equations in the presentation, there isn't anything to account for cornering forces or lateral acceleration. Are there any general rules about how much "cornering" is too much or is it really important to limit any hard cornering?
Quote Reply
Re: Platypus Thread: Aero Virtual Elevation Testing Protocol [grumpier.mike] [ In reply to ]
Quote | Reply
You can generally see the hard corners. I have a venue that is sort of like what you're describing, with a wider turnaround at one end and a narrow turnaround at the other. I coast at a softpedal as I approach, then often have to feather my brakes. I try to do that in the same spot each time and then either snip or "re-tare" the VE profile at that point. It's kind of a pain so I don't do that in Aerolab and instead use my own analytical routines.
Quote Reply
Re: Platypus Thread: Aero Virtual Elevation Testing Protocol [ In reply to ]
Quote | Reply
I wanted to contribute some data, particularly in relation to what i think was successful application of the Shen approach to pry apart CDA and CRR given there have been a few comments about not being able to get it to work

Power meter: Powertap
Tires - GP5000, one latex one butyl. - pumped to 90PSI
Test conditions
Temp -17.9c
Rho calculated as 1.206
Unfortunately not windstill but seems to have still produced reasonable data.
Used Speed sensor from Powertap
Weighed myself with all gear at 83.7kg

The main part of the run was 6 laps, the track is about 460m, rode the black line as best as my skill allowed. Slowest lap was about 25km/h, and fastest was about 42km/h

Used Golden Cheetah Aerolab to do the analysis. I started by putting in unrealistically low CRRs and unrealistically high CRR - this exaggerates the "bow" shape of the virtual elevation plot when CRR/CDA combination is not the "true" elevation. I found this to be key to observing the convergence of the solution and being able to identify more subtle under or over estimates. For example, see below and a few GC chart images

CRR CDA Comment
0.002 0.28 Highly Concave virtual elevation
0.009 0.178 Highly Convex virtual elevation
0.004 0.25 Concave still clearly visible
0.007 0.2065 Convex still clearly visible
0.005 0.2356 Close, but still slightly concave
0.006 0.2213 Close but very slightly convex
0.055 0.228 Very very close to a straight line.....

I found the Shen method and approach very valuable. While the surface is far from "glass" smooth, I would have assumed lower CRRs and overall this has me thinking that i have probably setting CRR assumptions too low.

What would have been helpful is for the GC y-axis scale to be more adjustable - as i think would have assisted in amplifying the concave or convex bow shape even better to allow more fine-tuning.
Quote Reply
Re: Platypus Thread: Aero Virtual Elevation Testing Protocol [ryinc] [ In reply to ]
Quote | Reply
ryinc wrote:
I wanted to contribute some data, particularly in relation to what i think was successful application of the Shen approach to pry apart CDA and CRR given there have been a few comments about not being able to get it to work
[..]
Rho calculated as 1.206

Your first post after 5 years? Very nice.

Yes, this is a good example of how to use Andy Shen's protocol. There are other ways to pry apart Crr and CdA but they require some math and this is a nice explanation.

Was rho really that high? Were you using GC's rho calculator? Remember that it assumes that you're using "station" baro pressure, not "offical" baro pressure that is standardized to sea level.
Quote Reply
Re: Platypus Thread: Aero Virtual Elevation Testing Protocol [RChung] [ In reply to ]
Quote | Reply
 
Was rho really that high? Were you using GC's rho calculator? Remember that it assumes that you're using "station" baro pressure, not "offical" baro pressure that is standardized to sea level.

Mmmm, i used the value directly from "MyWindsock.com" which integrates weather data but now you have me second guessing. whether that site has somehow calculated it incorrectly? A bit of a problem if that is the case!
Quote Reply
Re: Platypus Thread: Aero Virtual Elevation Testing Protocol [ryinc] [ In reply to ]
Quote | Reply
ryinc wrote:
The main part of the run was 6 laps, the track is about 460m, rode the black line as best as my skill allowed. Slowest lap was about 25km/h, and fastest was about 42km/h

Thanks, I hadn’t come across that method from Andy Shen before, although in the past I have in also noticed the same convex and concave shapes of the VE profiles in the testing and analysis that I’ve done, when trying to find the correct combination of CdA and CRR.

Perhaps one thing to clarify is how you are varying the speed? I noticed in Andy Shen’s article that he mentions a “steadily accelerating rideâ€. I guess you’re doing the same, slow laps initially and finishing fast?

When I’ve done testing in the past, I’ve done the opposite - for no particular reason - started fast for the first lap and gradually slowed down. If you do it in this decelerating way instead, the VE profiles would have the opposite relationship with CRR compared with the plot in Andy Shen’s article. This could be useful to note, in case other people use a decelerating protocol.

Also, when you said that a too low CRR gives a “highly concave VE profileâ€, your plot seems to show a convex profile instead, i.e. a VE profile that rises, peaks, then falls. I would call that convex personally, so could it be a mistake in your post perhaps, or could there be some ambiguity in those concave and convex terms?
Quote Reply
Re: Platypus Thread: Aero Virtual Elevation Testing Protocol [NickD1] [ In reply to ]
Quote | Reply
NickD1 wrote:
ryinc wrote:

The main part of the run was 6 laps, the track is about 460m, rode the black line as best as my skill allowed. Slowest lap was about 25km/h, and fastest was about 42km/h


Thanks, I hadn’t come across that method from Andy Shen before, although in the past I have in also noticed the same convex and concave shapes of the VE profiles in the testing and analysis that I’ve done, when trying to find the correct combination of CdA and CRR.

Perhaps one thing to clarify is how you are varying the speed? I noticed in Andy Shen’s article that he mentions a “steadily accelerating rideâ€. I guess you’re doing the same, slow laps initially and finishing fast?

When I’ve done testing in the past, I’ve done the opposite - for no particular reason - started fast for the first lap and gradually slowed down. If you do it in this decelerating way instead, the VE profiles would have the opposite relationship with CRR compared with the plot in Andy Shen’s article. This could be useful to note, in case other people use a decelerating protocol.

Also, when you said that a too low CRR gives a “highly concave VE profileâ€, your plot seems to show a convex profile instead, i.e. a VE profile that rises, peaks, then falls. I would call that convex personally, so could it be a mistake in your post perhaps, or could there be some ambiguity in those concave and convex terms?


Yes, i increased speed each lap.

Yes, if you switched the order of the protocol (i.e. fast speeds first), then if your CRR is too low (and CDA too high) to solve for zero net elevation - then at fast speeds the VE model assumes you must be going downhill to make the equation work (i.e. compensation for a CDA that is too high), and at slow speeds (when CRR is a bigger percentage contributor than at fast speeds), the curve would start to slope up again as the model predicts an incline to compensate for the CRR that is too low).

It wasn't a typo, i did interpret that as concave shape, but apologies for any potentially confusing/ambiguous language which is not necessary. In short, yes - rising, peaking and the falling when CRR is too low, and an increasing speed Shen protocol is followed and what i am referring to.




Quote Reply
Re: Platypus Thread: Aero Virtual Elevation Testing Protocol [ryinc] [ In reply to ]
Quote | Reply
Thanks
Quote Reply
Re: Platypus Thread: Aero Virtual Elevation Testing Protocol [NickD1] [ In reply to ]
Quote | Reply
NickD1 wrote:
Thanks, I hadn’t come across that method from Andy Shen before, although in the past I have in also noticed the same convex and concave shapes of the VE profiles in the testing and analysis that I’ve done, when trying to find the correct combination of CdA and CRR.

I discussed in my presentation, around slides 40-44 (or alternatively, slides 96-100). The key is varying speed -- I had been looking at varying speed within and across laps since I knew that variations in speed affect aero and rolling drag differently, but I had gotten so used to how they vary that I'd trained my brain to look for distinctive patterns even if the speed didn't change monotonically. I just sorted the laps in speed order. (You can see an example just before I talk about Andy's protocol where I was doing hill climbs at different speeds and power, then sorted the runs by speed and looked to see if the VE profiles also sorted by speed). Andy had the idea to try monotonically changing speed so that you all wouldn't have to do all that. It's really quite clever.

(And, as I've said, there are analytical ways to do this, but this visual fitting is much easier for people to understand than a bunch of equations).
Quote Reply
Re: Platypus Thread: Aero Virtual Elevation Testing Protocol [RChung] [ In reply to ]
Quote | Reply
Sorry, I hadn’t noticed those plots on slide 44 when I read your slides a few years ago (despite having read them a couple of times!). The information can’t have sunk in properly. What I should have done is gone back and re-read them, after using your method in anger. There are lots of little tips and tricks explained throughout, that I only notice and understand properly now that I’m more familiar with the method.
Quote Reply
Re: Platypus Thread: Aero Virtual Elevation Testing Protocol [NickD1] [ In reply to ]
Quote | Reply
NickD1 wrote:
Sorry, I hadn’t noticed those plots on slide 44 when I read your slides a few years ago (despite having read them a couple of times!). The information can’t have sunk in properly. What I should have done is gone back and re-read them, after using your method in anger. There are lots of little tips and tricks explained throughout, that I only notice and understand properly now that I’m more familiar with the method.

I'm the one who's sorry. I should've done a series of explanatory posts or videos or seminars or rewritten that thing to make it clearer years ago to help people understand the subtler bits. Prying apart CdA and Crr is one of them. (Many people still seem to think you have to assume a value of Crr.)
Quote Reply
Re: Platypus Thread: Aero Virtual Elevation Testing Protocol [RChung] [ In reply to ]
Quote | Reply
Forgive me for asking without reviewing any papers, but why would programmers need guidance to implement a least-squared error fit using your energy model?

Provided road and wind conditions are constant, time series data with arbitrary velocities and altitudes should fit the model and can be found with old, standard methods.

I’ve suggested this in a recent post, but I’d like to see a running convergence of Cda and Crr on a cycling computer using this method. Start a new test, bike, compute the best fit and variance, use the variance to flag the values green or something visual to denote convergence below a certain value. Perhaps with an additional check that there is not a step change in conditions (asphalt change or gusts, or rider position, or braking). This way, one can perform a-b-a type tests on reasonable roads and wind conditions. See the student-T distribution and estimating the “true meanâ€, relevant section in Low-Speed Wind Tunnel Testing (Barlow et al.). This would be something like a Kalman Filter with fading memory or explicit resetting of memory under chosen tolerances.
Last edited by: codygo: Jan 12, 21 13:21
Quote Reply
Re: Platypus Thread: Aero Virtual Elevation Testing Protocol [codygo] [ In reply to ]
Quote | Reply
codygo wrote:
Forgive me for asking without reviewing any papers, but why would programmers need guidance to implement a least-squared error fit using your energy model?

Provided road and wind conditions are constant, time series data with arbitrary velocities and altitudes should fit the model and can be found with old, standard methods.

I’ve suggested this in a recent post, but I’d like to see a running convergence of Cda and Crr on a cycling computer using this method. Start a new test, bike, compute the best fit and variance, use the variance to flag the values green or something visual to denote convergence below a certain value. Perhaps with an additional check that there is not a step change in conditions (asphalt change or gusts, or rider position, or braking). This way, one can perform a-b-a type tests on reasonable roads and wind conditions. See the student-T distribution and estimating the “true meanâ€, relevant section in Low-Speed Wind Tunnel Testing (Barlow et al.). This would be something like a Kalman Filter with fading memory or explicit resetting of memory under chosen tolerances.

So, you seem pretty familiar with statistical modeling, and that's good. The underlying main issue is that in field testing where you don't get to control every variable, errors are typically not well behaved with zero mean, fixed variance and, critically, they're not iid. So the Gauss-Markov theorem doesn't apply and the least squares estimator is neither unbiased nor efficient. In real tests on real roads, a gust of wind in one direction isn't usually balanced by an equal and opposite gust, and a passing car or a dip in the road or a jiggle in your position don't balance out. VE takes into account that the errors aren't iid (just as in time series analysis the errors aren't iid -- however in TS, we can often do an empirical correlogram to get an idea of some ARIMA-type model so even though the errors aren't iid, they're well-behaved). So anyway, VE was kind of a robust diagnostic for deviations from modeled fit where the objective function isn't the standard Martin power-for-speed model but an elaboration of a work-for-duration model (which you can get to from the Martin model). That said, the Track Aero System that Alphamantis developed does use Kalman filters to get its near real-time estimates of CdA. I don't know enough about how the Notio/Aerolab Tech/Velocomp/etc. models work but I *suspect* they try to do something similar. The bottom line is that convergence to a solution isn't the issue, the issue is whether it converges to the *right* solution.
Quote Reply
Re: Platypus Thread: Aero Virtual Elevation Testing Protocol [RChung] [ In reply to ]
Quote | Reply
Hi, thanks for responding. What you said makes sense, but I’m suggesting that a real time metric for gusts or other disturbances can be developed and used to invalidate or reinitialize a run that contains such deviations. Essentially, if the convergence isn’t Cauchy after some minimal period of time, we can assume something “not nice†happened during the run that would invalidate the data even if it were calculated in a “robust†manner. That is, we could get a value but that value is tainted by an unquantified gust/position change, etc. mid run.

Perhaps this requires directly using what you refer to as “Martin’s power-for-speed modelâ€, but I’d assume that a good test at least implies absence of these disturbances, so why not build in checks that practically guarantee their absence?
Quote Reply
Re: Platypus Thread: Aero Virtual Elevation Testing Protocol [codygo] [ In reply to ]
Quote | Reply
codygo wrote:
Hi, thanks for responding. What you said makes sense, but I’m suggesting that a real time metric for gusts or other disturbances can be developed and used to invalidate or reinitialize a run that contains such deviations. Essentially, if the convergence isn’t Cauchy after some minimal period of time, we can assume something “not nice†happened during the run that would invalidate the data even if it were calculated in a “robust†manner. That is, we could get a value but that value is tainted by an unquantified gust/position change, etc. mid run.

Perhaps this requires directly using what you refer to as “Martin’s power-for-speed modelâ€, but I’d assume that a good test at least implies absence of these disturbances, so why not build in checks that practically guarantee their absence?

So, you have good intuition about this problem. There are three components: the first, statistical to deal with "random" errors, second, functional to deal with "systematic" errors, and the third to do the calculations in "real-time" (or near real-time). Years ago we realized that in order to deal with the systematic errors, we'd need at least one additional sensor to measure air speed and yaw; though we also discussed back then an improved sensor to determine multi-axis tilt and possibly to detect accelerations related to changes in road surface. The second issue is statistical to deal with random errors where the error distribution isn't Gaussian (for example, wind speeds follow a Weibull). But I think we had a solution for that. So, we thought (and I think this has been borne out) the larger issue is getting the right sensor inputs, whence the Aerostick project (which *might* still be the only aero sensor that will detect yaw, though I'm not current with all of the newer implementations). The third part of that is the combination of all of that with the statistical bits into a real-time solution. Marcag might be able to tell you more about the issues with bringing a real-time device to market, but I suspect a key part of it is an occasional "anchoring" so you can reset and "zero" the estimate without, as you say, invalidating the entire run. In my original protocol I suggested using laps to anchor, but a subtlety that may have escaped some people was that I wasn't anchoring at just the start (or finish) of a lap: since you were going over the same damn road each time, I was using the entirety of the lap profile, as an anchor. That works for out-and-backs, too, which are degenerate laps. Since you seem familiar with control theory, you know that an occasional anchor makes the estimation a *lot* simpler. I could use the whole road as an anchor, and the Track Aero System sits in a velodrome so you get a constant anchor there, too. In a real-time device where you weren't going over the same road, you have to use sensor input (like from an altimeter or a gradiometer or an accelerometer or all three) and then you have to worry about error in those sensors, too. So that problem made my head hurt; and I have a day job, so I decided to put that off until I retire. But if you have ideas about it (and you seem to) then I encourage you to work on this problem and you can bounce ideas off me.
Quote Reply
Re: Platypus Thread: Aero Virtual Elevation Testing Protocol [RChung] [ In reply to ]
Quote | Reply
Thanks for summarizing the problem Dr. Chung.

I have to focus my time on aerodynamics, but I may tackle this project if I manage my publication goals before summer. When I do, I’ll be sure to share any progress or questions :)
Quote Reply
Re: Platypus Thread: Aero Virtual Elevation Testing Protocol [codygo] [ In reply to ]
Quote | Reply
codygo wrote:
Thanks for summarizing the problem Dr. Chung.

I have to focus my time on aerodynamics, but I may tackle this project if I manage my publication goals before summer. When I do, I’ll be sure to share any progress or questions :)

Around here I'm "Robert." And, usually, people want to know the "how to do it" so it's nice every once in a while to be asked about the "why does it work."

One last thing about the real-time CdA problem. The first big use of the Kalman filter was for real-time tracking and control of a moving object. Before GPS, cruise missiles (especially ship-launched cruise missiles) had not-great accuracy and precision. Over water, they typically used an inertial guidance system and then when they got to the coast, they'd switch to a terrain-sensing and terrain-matching system to guide them to their target (as you can imagine, a lot of early effort in pattern recognition was related to this problem of figuring out how to kill people with flying weapons). The inertial guidance system over water was close enough to get them into the right approximate strip of coast (depending on how far away the launch was) then they had to do pattern-recognition to figure out exactly where they were (then they had to navigate over to where they wanted to be). So, in real-time CdA, if we're traveling over a previously unknown terrain, we can use sensors (including inertial ones) to get close but unless you have a unique anchor point you have to worry about drift. That's why real-time CdA on an arbitrary route is hard. However, by doing laps, the first lap is like going over unknown and featureless water, but every subsequent lap is now over a known and recognizable path. So that makes the real-time CdA problem much much simpler. The first lap is a "burn-in" and every second after that for every subsequent lap can be used for CdA and Crr estimation. At least, that's the way I do it. Maybe you can figure out something better, and that would be fantastic.
Quote Reply
Re: Platypus Thread: Aero Virtual Elevation Testing Protocol [RChung] [ In reply to ]
Quote | Reply
Interesting historical context.

I attended a talk just prior to the Covid lockdowns where the speaker (Prof. Michael S. Braasch, Ohio University) discussed control systems particular to maritime navigation. My question for him relates to the drifting problem, and I asked why not measure a system with known dynamics in a body-fixed reference frame (presumably with frequencies much faster than the drift error timescales). Their response was that such a method is coined “carrouseling,†and it has been effective for correcting inertial drift. Perhaps there is a non-silly adaption for this in cycling.

Sometimes on a long ride into a headwind, I’ll question what position is most efficient and by how much? I end up mentally calculating 30s avg power/velocity to make a guess, while trying different positions. In those cases I might not care what the true CdA is, only that it is locally minimal for my current conditions. So in my mind, I’d be happy to manually initiate a run on a stretch of road where I hope to have constant conditions, naively implying that any drift is error.
Quote Reply
Re: Platypus Thread: Aero Virtual Elevation Testing Protocol [codygo] [ In reply to ]
Quote | Reply
Very cool. I'd never heard of carouseling before but it looks like a way to perturb the gyros in a known direction by a known amount to check how the data are perturbed, and thus to calibrate the instruments on the fly? If so, that's very cool. We do essentially that with designed experiments. It's also related to the delta mass test I suggested a couple dozen posts above.
Quote Reply
Re: Platypus Thread: Aero Virtual Elevation Testing Protocol [RChung] [ In reply to ]
Quote | Reply
RChung wrote:
That's why real-time CdA on an arbitrary route is hard. However, by doing laps, the first lap is like going over unknown and featureless water, but every subsequent lap is now over a known and recognizable path. So that makes the real-time CdA problem much much simpler. The first lap is a "burn-in" and every second after that for every subsequent lap can be used for CdA and Crr estimation. At least, that's the way I do it. Maybe you can figure out something better, and that would be fantastic.


Those recent exchanges about filtering techniques and statistics were a bit beyond me, I’m afraid, but the discussions about real time CdA estimations reminded me of some attempts I made a couple of years ago to extract real-time CdA from a 10-mile time trial. I think it’s worth sharing what I did, even though it was unsuccessful, because it helped me to understand why the VE method works so well. In addition, I think it’s sometimes useful to share what doesn’t work, as well as what does.

It probably doesn’t need explaining to the people that follow this thread, but calculating real time (instantaneous) CdA is done simply by solving the power equation on slide 14 of Robert’s VE presentation to solve CdA using a measured elevation, instead of the usual procedure of guessing a value for CdA and then solving elevation. It did this every second, using the data recorded by my Garmin (barometric pressure and wheel speed sensor).

I didn’t have high hopes that it would be successful, but I was curious anyway and wanted to give it a go. The noise in the resulting CdA values was even worse than I expected though, with real time CdA values ranging from -1.4 to +1.0 m2! (see plots below). The average of the real time CdA data, over the 10 miles, was actually relatively good, agreeing with the CdA from my virtual elevation analysis to within 0.01m^2 (0.220 vs 0.213). The noise in the drag clearly makes it unusable as a real time drag extraction method though (with my setup and sensors).

What I realised is that the noise in the CdA calculations, to a large extent, comes from the poor precision of my Garmin’s elevation measurements, coupled with sensitivity of the CdA calculation to elevation errors. My Garmin elevation data has a precision of 0.4m (or at least I see 0.4m increments in its output). The high sensitivity of the real time drag to elevation precision is best explained with an example, assuming: Mass = 80 kg rider+bike, Speed = 45 kph, CdA = 0.217 m^2, CRR = 0.004, Power = 300W, Rho = 1.2 kg/m^3

In this situation, 252W is overcoming aerodynamic drag. An arbitrary 10cm increase (or error) in elevation over a 1 second period equates to a slope of 0.8%, is 78 Joules of potential energy (80*9.81*0.1) and is therefore 78 Watts that gets injected into the power balance equation. This results in a 31% reduction in the real time CdA ((252-78)/252) if speed remains fixed. Of course, if the elevation really did increase by 10cm, there would be an associated reduction in speed for a constant power, which would offset the potential energy change, and the CdA would remain the same. However, the precision of the Garmin barometer means that large elevation steps (40 cm in my data) were introduced into the real-time CdA calculation, causing the CdA spikes.

This sensitivity to elevation data can be mitigated by using longer sampling periods. Alternatively, or in addition, more accurate elevation data will help, and I know there are some folks like Pierre (Bugno) that are using more precise barometric sensors to help with this. The example above, though, shows it’s a tough problem. Even a really small 1cm elevation error would be a 3% drag change over 1 second.

As an aside, as part of my day job, I’m involved in predicting and measuring aircraft drag. For our flight test aircraft, mainly due to their higher speeds, the drag is one or two orders of magnitude less sensitive to elevation changes, so this is much less of a problem. But for us cyclists, it's really a challenge.

The beauty of Robert’s method, the way I see it, is that it disregards this instantaneous elevation data that CdA is so sensitive too, and instead calibrates to known elevation information over a longer time period, thereby elegantly avoiding this difficulty. Another alternative, of course, would be to ride a perfectly flat road like a velodrome. However, I’m lazy and would prefer to do my testing close to home.

For the people that have been involved in this community much longer than me, this may be nothing new, and I’m sure it has been tried by other people in the past, so please forgive me if this has been covered elsewhere.

P.S. I also looked at the sensitivity to speed errors, and there are errors coming from my lack of a wind sensor too, but this post is already too long!







Quote Reply
Re: Platypus Thread: Aero Virtual Elevation Testing Protocol [NickD1] [ In reply to ]
Quote | Reply
Nice post Nick!

My understanding is that your 1s and 30s “real time†values are not employing any filtering techniques, Kalman or otherwise, but I’d say the 30s values are about as good as I’d expect in that case.

What I suggested (and you can run this on your existing data) is imagine you are TT’ing, and you initialize your averaging at the 100s mark where things seem more settled, but instead of 30s averaging let it accumulate indefinitely, and if no significant gusts (or position changes) arise, maybe by 1 minute you could see that the predicted value stays within a tight error band of what you may consider the “true meanâ€.

Try plotting the running average of CdA, starting from various points after 100s, along with something like abs(CdA_avg(i) - CdA_avg(i-1))... How close to zero can this get for your data, and does it behave nicely?

What I am not claiming is that it would be appropriate in varying conditions, but I think in such cases the value you get has a questionable definition either way.

Kalman filtering would help provide better, more rapid convergence by correcting the raw “estimate of states†given sensor errors (it figures out the most likely actual values, provided some assumptions aren’t too grievous, as Robert mentioned above).

I’m not sure how common it is for cyclists to review the time series data from wind tunnel tests, as what people receive tends to be up to what you request in commercial tunnels. But, the averaged values you get in a given “run†are derived in a similar (naive) fashion... the wind tunnel operators run a typical test article benchmark and see how long of a sample period needs to be taken to achieve a certain amount of “repeatabilityâ€. The time series data itself can be (read: will be) very noisy, with large variance as a percent of the mean value that clients get on a nice spreadsheet, even in a “steady-state†wind tunnel test. I have a feeling people think wind tunnel data is absent of this noise.
Quote Reply
Re: Platypus Thread: Aero Virtual Elevation Testing Protocol [NickD1] [ In reply to ]
Quote | Reply
Very nice.

Yes, I think Pierre (bugno) uses a Blue Fly variometer, which has a nominal accuracy of 10cm but I suspect is much more consistent than that in second-to-second to reporting.

As I said, I kinda stopped working on "real-time" estimation because I would have needed additional sensors and my day job was beckoning -- but laps help there, too. If you take each second's estimated CdA and do the conversion so you can plot it by distance instead of time, you can get an estimated CdA for each point along the loop or lap. When I did this, one of the things I noticed was that for the test course I was using the estimated CdA was systematically high on certain parts of the loop and systematically low on other parts. What was amazing to me at the time was that there was a section of the loop where a couple of different things were happening: one was that there was a part of the loop that was less protected and more "open" to the wind, and a place where there was a corner and I slowed down a bit to make the turn (and thus, small errors in speed may have crept in). So I was getting a consistent bias in the measured CdA in the same places. That made me think that if I could ever find time to get back to this problem, this kind of systematic error pattern could be a good place to start.
Last edited by: RChung: Jan 22, 21 15:13
Quote Reply
Re: Platypus Thread: Aero Virtual Elevation Testing Protocol [codygo] [ In reply to ]
Quote | Reply
codygo wrote:
Nice post Nick!

My understanding is that your 1s and 30s “real time†values are not employing any filtering techniques, Kalman or otherwise, but I’d say the 30s values are about as good as I’d expect in that case.

What I suggested (and you can run this on your existing data) is imagine you are TT’ing, and you initialize your averaging at the 100s mark where things seem more settled, but instead of 30s averaging let it accumulate indefinitely, and if no significant gusts (or position changes) arise, maybe by 1 minute you could see that the predicted value stays within a tight error band of what you may consider the “true meanâ€.

Try plotting the running average of CdA, starting from various points after 100s, along with something like abs(CdA_avg(i) - CdA_avg(i-1))... How close to zero can this get for your data, and does it behave nicely?

Many thanks to both of you for those replies and suggestions. You're right, that I'm not using any filtering techniques, for no reason other than I don't know how to! There's a bit of reading I need to do about techniques like Kalman filtering I think.

I will try to have a play around with different averaging techniques like you suggested if I have time this weekend. As it is, at the moment the "30s average data" is simply obtained from the change of speed over the previous 30s, the change of elevation over the previous 30s, then with speeds and powers are the mean values over that previous 30s. So nothing fancy, and lots of scope to improve that I'm sure. You're right, I should have thrown away the data for the first 10-20s when I was standing up and accelerating on the base bars.

I'm in the same position as Robert though, that I'm not too optimistic about getting to a point when real time CdA can be obtained on a random road, where the forces are determined in this manner from a power meter. I did this more for curiosity. It'd be great to look down and have CdA updating every second or so on my head unit, but I'm not optimistic that's achievable with a method like this. Having said that, I don't want to be too closed-minded either, and maybe there is something that can be done with filtering, better sensors, or perhaps some way to accurately survey a road to gather very precise elevation data (as a function of longitude and latitude).

The plotting of CdA versus distance, instead of vs time, was something easy to do though, so I've just done that. You do indeed see some features in the CdA trace that seem to happen at a once per lap frequency. I was expecting to see some gradual oscillations in apparent CdA, due to my lack of an airspeed sensor, but there seems to be regular spikes and features on top of that (although it's possible I'm now looking too hard at it!).


Quote Reply
Re: Platypus Thread: Aero Virtual Elevation Testing Protocol [NickD1] [ In reply to ]
Quote | Reply
NickD1 wrote:
codygo wrote:
Nice post Nick!

I'm in the same position as Robert though, that I'm not too optimistic about getting to a point when real time CdA can be obtained on a random road, where the forces are determined in this manner from a power meter. I did this more for curiosity. It'd be great to look down and have CdA updating every second or so on my head unit, but I'm not optimistic that's achievable with a method like this.



If you had accurate elevation and wind you'd be order of magnitude better. Your barometer is horrible and you have some wind in there.

I have tried 5 barometers in the last few months and some pretty funky ways of testing them. There is a huge variation in quality on multiple fronts. But even keeping that in mind, a barometer is not enough to get accurate altitude. However the quaility of the barometer makes a huge difference in what other techniques can do with it.

Not sure this is the right thread to discuss barometers, or if we need another, but glad to share some of my findings
Last edited by: marcag: Jan 23, 21 4:03
Quote Reply
Re: Platypus Thread: Aero Virtual Elevation Testing Protocol [marcag] [ In reply to ]
Quote | Reply
Thanks! I knew there'd be somebody that has looked at this in the past, and in much more detail than me. Yes, perhaps it needs a separate thread, so sorry If I've taken things off on a bit of a tangent, but I thought it's interesting to highlight some difficulties of alternatives to the VE method.

Elevation data from barometers would be affected by, to some degree, the local airspeed at it's location. I'm sure you know this already and it might be what your were eluding to. I haven't worked out how significant this would be at the speeds we cycle at. Unless the barometer's pressure port is located at a position where the pressure coefficient is zero in all wind (yaw) conditions, which is probably difficult to achieve, it would need a calibration factor or equation to account for the suction or stagnation pressure increment with speed. On aircraft, it's not a trivial task to calibrate the static pressure measurements to give accurate ambient pressure data for all incidences, yaw angles, slat/flap settings etc.
Quote Reply
Re: Platypus Thread: Aero Virtual Elevation Testing Protocol [NickD1] [ In reply to ]
Quote | Reply
NickD1 wrote:
Thanks! I knew there'd be somebody that has looked at this in the past, and in much more detail than me. Yes, perhaps it needs a separate thread, so sorry If I've taken things off on a bit of a tangent, but I thought it's interesting to highlight some difficulties of alternatives to the VE method.

I have no problem discussing it here if others agree. Or we can move it elsewhere. There is also an aerometers for dummies thread somewhere

Take an anomoly of the barometer say at 540s (see the dip?). Now go 30s later. When you calculate your average CDA, you will be using those 2 points, will get a very bad delta Elevation and your CDA will be way off. The very noisy part of your signal is mostly the barometer problem. The slower moving more cyclical error is wind. That is at a 100 feet level.

NickD1 wrote:
Elevation data from barometers would be affected by, to some degree, the local airspeed at it's location. I'm sure you know this already and it might be what your were eluding to. I haven't worked out how significant this would be at the speeds we cycle at. Unless the barometer's pressure port is located at a position where the pressure coefficient is zero in all wind (yaw) conditions, which is probably difficult to achieve, it would need a calibration factor or equation to account for the suction or stagnation pressure increment with speed. On aircraft, it's not a trivial task to calibrate the static pressure measurements to give accurate ambient pressure data for all incidences, yaw angles, slat/flap settings etc.

Bingo!

However if you know wind speed, wind direction and a few other data points, there are things you can do to improve it. If you don't rely entirely on the barometer you can do even more.

I mounted all these sensors on a drone, use sonar to get uber accurate elevation, and fly around the neighbourhood. Canadian winters, covid lockdowns and an amazon prime account make us do weird things.
Quote Reply
Re: Platypus Thread: Aero Virtual Elevation Testing Protocol [marcag] [ In reply to ]
Quote | Reply
It sounds like you’re doing some really cool stuff with the extra spare time we all have available at the moment.

Yeah, I noticed that too with my crappy elevation data. In my excel spreadsheet, it’s really obvious that those big changes in measured elevation are what’s causing the biggest spikes in CdA.
Quote Reply
Re: Platypus Thread: Aero Virtual Elevation Testing Protocol [marcag] [ In reply to ]
Quote | Reply
marcag wrote:
Bingo!

However if you know wind speed, wind direction and a few other data points, there are things you can do to improve it. If you don't rely entirely on the barometer you can do even more.

I mounted all these sensors on a drone, use sonar to get uber accurate elevation, and fly around the neighbourhood. Canadian winters, covid lockdowns and an amazon prime account make us do weird things.

I've occasionally thought that combining accelerometers with brake sensors could be handy so you could separate out the parts of deceleration due to increasing drag that were intentionally produced.
Quote Reply
Re: Platypus Thread: Aero Virtual Elevation Testing Protocol [RChung] [ In reply to ]
Quote | Reply
RChung wrote:
marcag wrote:

Bingo!

However if you know wind speed, wind direction and a few other data points, there are things you can do to improve it. If you don't rely entirely on the barometer you can do even more.

I mounted all these sensors on a drone, use sonar to get uber accurate elevation, and fly around the neighbourhood. Canadian winters, covid lockdowns and an amazon prime account make us do weird things.


I've occasionally thought that combining accelerometers with brake sensors could be handy so you could separate out the parts of deceleration due to increasing drag that were intentionally produced.

We did put strain guages on a brake line. More maintenance headaches than value.
Quote Reply
Re: Platypus Thread: Aero Virtual Elevation Testing Protocol [marcag] [ In reply to ]
Quote | Reply
Cool. I said "occaisonally" because I think it possible that braking might be detectable in other ways, but I hadn't thought about the maintenance aspects. That's cuz I'm a theoretician so I don't actually build things. Hhmmm. To be more accurate, I should say "I don't build things that absolutely positively need to work."
Quote Reply
Re: Platypus Thread: Aero Virtual Elevation Testing Protocol [RChung] [ In reply to ]
Quote | Reply
I've been idly following news from BrakeAce, who are offering a brake power meter focused on the downhill and enduro market. If/when they ever go to a public release, if it can be mounted to a road or TT bike (disc brake only, though), and if they have enough interoperability to plug the data into AeroLab or a similar tool (big caveats, I know), I'd love to see if that opens up more possibilities for incorporating braking events as a known input. That'd mostly be a bonus, since my main hope is to use it for handling practice to be less bad at cyclocross!
Quote Reply
Re: Platypus Thread: Aero Virtual Elevation Testing Protocol [RunningChoux] [ In reply to ]
Quote | Reply
I've tried to use the VE method to get some idea about the Crr and CdA of my setup before, but finding a suitable place and there not being much wind was tricky. But now I found a nice spot, in the woods, between two hills, with little traffic, and I spent some time during my last ride getting a baseline. This was in winter kit, with a pair of Decathlon tires that have 5000km on them, and a drivetrain full of mud, so obviously I wasn't expecting good numbers, just a baseline to compare against when I start swapping in nicer things.





This was a comparison of two positions. The valleys aren't perfectly level, but if I increase or decrease CdA by 0.01, their line ends up going clearly up or down, so that seems to be about the precision I can get. Would it be fair to conclude the difference between the two positions must then be less than this?

Teasing apart Crr doesn't seem to be possible from this, guess I'll need much bigger speed differences or a known elevation test.
Quote Reply
Re: Platypus Thread: Aero Virtual Elevation Testing Protocol [Garff] [ In reply to ]
Quote | Reply
Quote Reply
Re: Platypus Thread: Aero Virtual Elevation Testing Protocol [Garff] [ In reply to ]
Quote | Reply
Garff wrote:
This was a comparison of two positions. The valleys aren't perfectly level, but if I increase or decrease CdA by 0.01

Sorry, I didn't see your post earlier.

Yes, pretty much, if you increase or decrease CdA by .01 you should be able to tell the difference. However, CdA and Crr are related so when one goes up the other goes down. That means if you want to know the absolute values of CdA and Crr you have to be pretty careful about test protocols. If you just want to know if position 1 is slipperier than position 2, you can do as you've been doing.
Quote Reply
Re: Platypus Thread: Aero Virtual Elevation Testing Protocol [cyclistgo] [ In reply to ]
Quote | Reply
cyclistgo wrote:
Someone read it?

https://pubmed.ncbi.nlm.nih.gov/33590804/

I haven't read it yet.
Quote Reply
Re: Platypus Thread: Aero Virtual Elevation Testing Protocol [RChung] [ In reply to ]
Quote | Reply
RChung wrote:
cyclistgo wrote:
Someone read it?

https://pubmed.ncbi.nlm.nih.gov/33590804/


I haven't read it yet.
I can't access full text but if anyone does I would be interested in reading it.
Quote Reply
Re: Platypus Thread: Aero Virtual Elevation Testing Protocol [s5100e] [ In reply to ]
Quote | Reply
I skimmed through it. It seems to correlate ok according to their test, but they could not account for some rider specific offset, which probably makes sense if the probe is installed anywhere near the rider. It’s not a thorough study.

I don’t see what justifies this as a product for $600...

Interesting side note. I was thinking the other day that it should be possible to detect wind speed using acoustic analysis from a smartphone’s microphone, basically find peak frequency from the shedding off of a small diameter wire (use Strouhal number, and Fourier analysis), but it may be easier than that since there are microphone based anemometers that don’t require extra hardware, even some apps for ios and android.

I bet it would work well enough so that a simple stock android phone could do more than this device.

So get this... wind speed from microphone, camera-based wind direction from a simple weathercock device, we can get also get camera-based ground speed simultaneously (and steering angle if you’re ambitious). phones have gps already and inertial sensors, all we need is time, money, and will :) Also, remember this as prior art in case anyone tries to patent these things lol.
Quote Reply
Re: Platypus Thread: Aero Virtual Elevation Testing Protocol [codygo] [ In reply to ]
Quote | Reply
codygo wrote:
Interesting side note. I was thinking the other day that it should be possible to detect wind speed using acoustic analysis from a smartphone’s microphone, basically find peak frequency from the shedding off of a small diameter wire (use Strouhal number, and Fourier analysis),

Nice. I've seen hot wire anemometers but this could be cool.
Quote Reply
Re: Platypus Thread: Aero Virtual Elevation Testing Protocol [codygo] [ In reply to ]
Quote | Reply
codygo wrote:
I skimmed through it. It seems to correlate ok according to their test, but they could not account for some rider specific offset, which probably makes sense if the probe is installed anywhere near the rider. It’s not a thorough study.

I don’t see what justifies this as a product for $600...

Interesting side note. I was thinking the other day that it should be possible to detect wind speed using acoustic analysis from a smartphone’s microphone, basically find peak frequency from the shedding off of a small diameter wire (use Strouhal number, and Fourier analysis), but it may be easier than that since there are microphone based anemometers that don’t require extra hardware, even some apps for ios and android.

I bet it would work well enough so that a simple stock android phone could do more than this device.

So get this... wind speed from microphone, camera-based wind direction from a simple weathercock device, we can get also get camera-based ground speed simultaneously (and steering angle if you’re ambitious). phones have gps already and inertial sensors, all we need is time, money, and will :) Also, remember this as prior art in case anyone tries to patent these things lol.

In the paper, they referred to another study that didn't get stellar results. That previous study had issues, mostly related to they configured and processed the data.

This study looks a lot better. But, they also refer to something they call velodrome mode. They mention it sets altitude to 0 which makes things a lot easier. They mention measurement of banking which would improve precision of results. I suspect, but do not know for sure, they probably turn off air speed as well, or at least can do some calibration. This makes the velodrome use case MUCH easier to get accurate results. Nothing "earth shattering" here. You would probably get similar results with Aerolab. Aerolab doesn't take banking into consideration. I suspect they made some features to make testing a little easier.

Turn back on altitude and airspeed, outdoor and it's a whole different ballgame. IF they get that right, it's worth $600 IMO.
Quote Reply
Re: Platypus Thread: Aero Virtual Elevation Testing Protocol [marcag] [ In reply to ]
Quote | Reply
I would love to hear the feedback on this technology and how it was applied in this study that they say is soon to be published... from Cycling Weekly How sailing technology could lead to a new wave of aero design: https://www.cyclingweekly.com/news/product-news/how-sailing-technology-could-lead-to-a-new-wave-of-aero-491644? utm_medium=social&utm_source=facebook.com&utm_campaign=socialflow&fbclid=IwAR23PHFPxEf0imm2mRVO2VlCIqTzaRAx-LiKsoV9oe0KTF60D0o6rftCvSg
it looks like they used ultrasonic anemometer. They applied the devices at the axle on only one side from what it looks like? Thoughts from the paltypus expert.
Quote Reply
Re: Platypus Thread: Aero Virtual Elevation Testing Protocol [s5100e] [ In reply to ]
Quote | Reply
Nice idea using a new type of small sensor. Dual sensors is cute.
Quote Reply
Re: Platypus Thread: Aero Virtual Elevation Testing Protocol [RChung] [ In reply to ]
Quote | Reply
That is part of the question but as we know the Chung method can easily determine a ball of that size on an object as an increase in CDA. Also why not 4? 2 each side for determining yaw? or if 2 one on right and 1 on left? Having both on the same side seems odd if that is what they did. Then I assume a good data scientist like Robert would take into account the sensor drag?

Because it is not yet published data I wonder... and hope some smart individuals read and interpret the paper for us regular folks.
Quote Reply
Re: Platypus Thread: Aero Virtual Elevation Testing Protocol [s5100e] [ In reply to ]
Quote | Reply
more interesting stuff... they actually reference the virtual elevation methods in their response to how they work... so now one more CdA estimator on the market: Body Rocket
Road.cc article: https://road.cc/...t1zJxUWqzqskLUHdnj50

one point they seem to think is important is that weight varies over a ride. So they put this in as another estimate along with rolling resistance etc.

not cheap either "£1499 to 1999 is the envisaged unit price," seems this area of development is starting to heat up, Aero Lab is rolling their system out as we speak etc... Whether the Velocomp device is reliable?

I still think in the real world that the Chung method is probably one way to see if these devices provide good measurements.

Aerodynamics and bikes seems to be the next frontier.


Here is a link tothe Body Rocket patent: https://pdfpiw.uspto.gov/...nput=View+first+page
Last edited by: s5100e: Feb 28, 21 8:05
Quote Reply
Re: Platypus Thread: Aero Virtual Elevation Testing Protocol [s5100e] [ In reply to ]
Quote | Reply
Interesting.

A lot of testing I do is with a drone and i did look at an utlrasonic anemometer as a reference. It was not cheap and it was not small, so I found alternatives. They are available for UAVs.

If it can be placed at multiple points on the bike that may provide interesting data. The question is what data and who is it useful for ? It's kind of like the 'rake' that swiss-side uses. If measuring airspeed at various points around the rider is useful, this could be interesting. I need to check if prices are coming down.

If the goal is to measure a joe-triathlete's CDA (with yaw), a pitot is certainly very good. And it's dirt cheap to make. It's not the airspeed sensor that makes measuring real time CDA a challenge.

If the goal is to make something less "in your face" than a pitot, a) the equivalent of a pitot can be reworked to be more egonomic b) I'm not sure the ultrasonic is much smaller overall. The one I was looking at was a touch smaller than a tennis ball. I have experimented with a few cockpit integrated systems with some interesting results.

But IMO, there are bigger problems to resolve than the anemometer
Quote Reply
Re: Platypus Thread: Aero Virtual Elevation Testing Protocol [marcag] [ In reply to ]
Quote | Reply
Was this for a research project or were they using these for a real-time CdA sensor? As a research project, I like the idea of multiple sensors to validate CFD. For real-time CdA? I agree with you that this wouldn't be the right way to go.
Quote Reply
Re: Platypus Thread: Aero Virtual Elevation Testing Protocol [RChung] [ In reply to ]
Quote | Reply
A house move has brought me close to a 1 mile pedestrian and cycling tunnel. The ground surface is tarmac but not particularly smooth. Any suggestions for the best protocol to make the best use of this? I imagine I'll have to be there late/early to avoid passing anyone.
Quote Reply
Re: Platypus Thread: Aero Virtual Elevation Testing Protocol [specialist] [ In reply to ]
Quote | Reply
specialist wrote:
A house move has brought me close to a 1 mile pedestrian and cycling tunnel. The ground surface is tarmac but not particularly smooth. Any suggestions for the best protocol to make the best use of this? I imagine I'll have to be there late/early to avoid passing anyone.
Sounds intriguing. Out-and-backs, obviously, with monotonic speed increasing from each end (i.e., start off slow then increase speed.The return doesn't have to start at the speed you ended the outbound leg--you can start and end each leg at the same speeds). Also, if you're worried about the roughness of the pavement, you could do a delta mass test: a run in each direction with an empty water bottle, then a water bottle filled with pennies or small nails. I can get a kg of US pennies in a bottle; I don't know what your pennies weigh. That'll give you a known delta in mass so you can get a better handle on the Crr.

Haven't seen you around for a while. What've you been doing?
Quote Reply
Re: Platypus Thread: Virtual Elevation Protocol [AndyF] [ In reply to ]
Quote | Reply
Andy, thanks for the beta. I have a couple of questions that I think you can answer or perhaps someone else can chime in on. I have scoured the pages on this thread and have not found a definitive answer(s)

1. Do I need to be doing race speeds when doing this? I have a half pipe route that will occasionally have traffic so it is good but not great. I can hit high speeds and then lower speeds as well. I have access so a massive parking lot that has elevation change. I could do laps here but not hit race speeds.

2. I am using a pedal power meter that is ANT+. Can I coast at all or do I need to be soft pedaling? The forum has some unclear answers on this that I couldn't find.

Any help would be much appreciated!
Quote Reply
Re: Platypus Thread: Aero Virtual Elevation Testing Protocol [RChung] [ In reply to ]
Quote | Reply
Thanks. Hopefully with no wind there should be the chance for good data. Still been around lurking and racing. Just not so much time for posting.
Quote Reply
Re: Platypus Thread: Virtual Elevation Protocol [lonniecdams] [ In reply to ]
Quote | Reply
lonniecdams wrote:
1. Do I need to be doing race speeds when doing this? I have a half pipe route that will occasionally have traffic so it is good but not great. I can hit high speeds and then lower speeds as well. I have access so a massive parking lot that has elevation change. I could do laps here but not hit race speeds.
The short answer is, if you have an otherwise good place to test but you can't get up to race speeds without risking your safety then use it but don't risk your safety. The wider the range of speeds, the more stable your estimate of drag will be. That said, if you're really really fast (like, 48+ km/h fast) then you will probably want to test at race speed because when you get that fast there may be a change in flow that you'll want to capture.

Quote:
2. I am using a pedal power meter that is ANT+. Can I coast at all or do I need to be soft pedaling? The forum has some unclear answers on this that I couldn't find.
I find that if I coast, I sometimes forget to put my legs in the same position, so sometimes my right leg is at 3 o'clock, sometimes it's at 6 o'clock, sometimes it's at 12 o'clock. So for me, it's more consistent if I soft pedal -- but you may have more mental acuity than I and you may remember to coast in a consistent position.
Quote Reply
Re: Platypus Thread: Aero Virtual Elevation Testing Protocol [specialist] [ In reply to ]
Quote | Reply
I did a tiny bit of poor quality testing in a tunnel but wondered if there was a venturi effect with a noticeable draft in the tunnel
It was then closed ,but has reopened ,so I might go back and try it out again
I'd be interested to know how you get on
Quote Reply
Re: Platypus Thread: Aero Virtual Elevation Testing Protocol [kevinkeegan] [ In reply to ]
Quote | Reply
kevinkeegan wrote:
I did a tiny bit of poor quality testing in a tunnel but wondered if there was a venturi effect with a noticeable draft in the tunnel

If you go both ways and vary your speed you ought to be able to see how strong that effect is -- and maybe correct for it.
Last edited by: RChung: Mar 3, 21 14:29
Quote Reply
Re: Platypus Thread: Aero Virtual Elevation Testing Protocol [RChung] [ In reply to ]
Quote | Reply
RChung wrote:
kevinkeegan wrote:
I did a tiny bit of poor quality testing in a tunnel but wondered if there was a venturi effect with a noticeable draft in the tunnel

If you go both ways and vary your speed you ought to be able to see how strong that effect is -- and maybe correct for it.

Has this been posed as an “optimal control†problem? That is, if our goal is to design a test with a known course (constraint) and unknown wind conditions, can we determine an input u(x) that minimizes uncertainty in fitting CdA and Crr?

I suppose a boring solution is to go so slow for several out-and-back runs that most of the variation is due to wind (riding much slower than any disturbance would be ridiculously slow). It seems to me that pedaling very low cadence and good “pedal smoothness†would also reduce noise in power data. Then by such assumptions, and some smoothing, and a lot of wishful thinking, one could attribute all the noise above a certain frequency to wind, which might allow for a spectral type of analysis from full speed data, where corresponding frequencies are are more heavily weighted/ associated with aerodynamic gusts.
Quote Reply
Re: Platypus Thread: Aero Virtual Elevation Testing Protocol [codygo] [ In reply to ]
Quote | Reply
codygo wrote:
RChung wrote:
kevinkeegan wrote:
I did a tiny bit of poor quality testing in a tunnel but wondered if there was a venturi effect with a noticeable draft in the tunnel

If you go both ways and vary your speed you ought to be able to see how strong that effect is -- and maybe correct for it.


Has this been posed as an “optimal control†problem? That is, if our goal is to design a test with a known course (constraint) and unknown wind conditions, can we determine an input u(x) that minimizes uncertainty in fitting CdA and Crr?

I suppose a boring solution is to go so slow for several out-and-back runs that most of the variation is due to wind (riding much slower than any disturbance would be ridiculously slow). It seems to me that pedaling very low cadence and good “pedal smoothness†would also reduce noise in power data. Then by such assumptions, and some smoothing, and a lot of wishful thinking, one could attribute all the noise above a certain frequency to wind, which might allow for a spectral type of analysis from full speed data, where corresponding frequencies are are more heavily weighted/ associated with aerodynamic gusts.

I haven't done that but maybe someone else has. Early on, I looked not just at virtual elevation but also "virtual wind." You probably know that wind is approximately distributed as a Weibull so I wondered if I could check or validate the estimated CdA and Crr by seeing whether the implied wind distribution was Weibull. In the end, I decided that it was simpler just to use the road profile. Of course, it would have been simpler with a bike-mounted anemometer but I didn't have one back then.
Quote Reply
Re: Platypus Thread: Aero Virtual Elevation Testing Protocol [RChung] [ In reply to ]
Quote | Reply
Yeah, a lot of problems have nice solutions for large budgets, but lower-budget solutions are more fun to develop. That is why I think microphone based anemometry would be cool, everyone has one on their phone, whereas hotwires are usually a small fortune, (and tend to be extremely delicate).
Quote Reply
Re: Platypus Thread: Aero Virtual Elevation Testing Protocol [codygo] [ In reply to ]
Quote | Reply
codygo wrote:
Yeah, a lot of problems have nice solutions for large budgets,
Have you seen the announcement from Body Rocket? They're offering a pre-order discount to 1800 gbp (at current exchange rate s that's about $2500 US). Best of luck to them, I hope they succeed, but that's a lot of cash.
Quote Reply
Re: Platypus Thread: Aero Virtual Elevation Testing Protocol [RChung] [ In reply to ]
Quote | Reply
I hadn’t seen that until now. At least they include a power meter in that price, so it’s not completely outrageous.

On mobile their site is sparse on details, seems like they intend to take pressure measurements at handlebars , front axle and seatpost to divine something, but it’s odd they could try to claim some patent on that alone.

I would be most interested in an intelligently arranged distribution of pressure sensors and inclinometers (current body posture devices track this) to get local pressure and surface normals, which can be used to estimate longitudinal forces on the torso.

When I worked in racing I designed sparse arrays of pressure sensors with associated weighted areas to get a sense of real-time local forces in wind tunnel and track tests, so it’s not a fantasy, just pricey due to being a custom solution... and it would help to have wind tunnel and cfd data to correlate and validate it for cyclists. But, I think the trend estimates should be fairly robust even if they don’t give you CdA itself. I say this because I think choices like face angle into yawed winds, are the questions I’d most want answers to, whereas equipment choices are easier to extract from the Chung method.

We should only need to find positions which create the least pressure loss at the rear facing surfaces, and what the front is doing to achieve that is not likely as important. I can only think of helmet shields on/off as a case that may affect stagnation pressures with thrust or drag, which isn’t mostly due to avoiding contributing to a large, rear-facing lossy, stagnation pressure.

I’ve been thinking about this recently and wonder if what people call “sailing†is actually the shifting of the stagnation on the rider’s body in yaw (I looked up some of the papers that claim this is from discs, but their own data shows rider on also had a similar trend, even with shallow standard wheels... seems like hasty reasoning) so that the longitudinal pressure delta is improved. Think of flow on a sphere and take the drag axis to be rotated by some amount... at 90 degrees it would be “zero drag,†not to mention that I suspect some people report tunnel wind speed without correcting for yaw, so there may be a separate, inherent ~1/cos^2 error which inflates “drag improvement.â€
Quote Reply
Re: Platypus Thread: Aero Virtual Elevation Testing Protocol [codygo] [ In reply to ]
Quote | Reply
codygo wrote:
I suspect some people report tunnel wind speed without correcting for yaw, so there may be a separate, inherent ~1/cos^2 error which inflates “drag improvement.â€
I think the "major" low speed wind tunnels that test bikes do correct for yaw in their wind speed--at least, when asked about it, they've said they do.
Quote Reply
Re: Platypus Thread: Aero Virtual Elevation Testing Protocol [RChung] [ In reply to ]
Quote | Reply
RChung wrote:
codygo wrote:
I suspect some people report tunnel wind speed without correcting for yaw, so there may be a separate, inherent ~1/cos^2 error which inflates “drag improvement.â€

I think the "major" low speed wind tunnels that test bikes do correct for yaw in their wind speed--at least, when asked about it, they've said they do.

Can confirm...at least for the San Diego LSWT, and the Specialized Win Tunnel (the 2 I've personally been in and seen the data output). I'm fairly certain that the data from the A2 wind tunnel makes that correction as well.

http://bikeblather.blogspot.com/
Quote Reply
Re: Platypus Thread: Aero Virtual Elevation Testing Protocol [Tom A.] [ In reply to ]
Quote | Reply
Thanks for the info guys.

It’s a small detail, but there’s nuance in what is meant by correcting for the yaw. It could be that since their sensors are body-frame aligned, then the loads are automatically in the bicycle’s frame of reference, and they consider this the “yaw correction,†since by aerospace standards, the drag and lift axis are always in the wind’s reference frame, i.e, drag is in the direction of the wind while lift/sideforce are orthogonal to it.

At least for automobile testing, no such adjustments are made automatically, at Aerodyne and Windshear, or the half-scale tunnels I’ve worked in. The raw data shows freestream speeds and pressures and the data includes sensor loads, and using their specifications and measurements, desired forces are computed in the wind-aligned coordinates by the client.

I would think cyclists would want to know not what a 50kph riding speed + additional sideways component means for their drag, when quoting “50kph at 10 degrees yaw,†and not a “50kph resultant wind speed at 10 degrees yaw while riding 49.24 kph.â€

From your responses, it seems that the former is the case, but I’d personally want to see raw freestream field and body frame loads and do any corrections myself, or see the explicit conversion in whatever document they provide, since it could be considered a choice of practice. I’m also an oddball in that I tend to request raw time series data, which isn’t often provided by default (basically never unless asked for).

PS: I’m also curious what the advanced aero nerds here think about my drag on sphere with rotated axis of drag comment. The description should be enough to visualize it, but since I have a 3d scan of my p3 i may try to make a crude humanoid to see how the yaw affects the stagnation points on the body in CFD. Asymmetry tends to be favorable relative to a cyclic/unstable flow.

PPS: How many people aim to “feel†flow attachment during aero testing? Personally, I move my helmet and shoulders around until I feel a distinct increase in flow far down my lower back: shear stress -> attachment -> higher rear stagnation pressure -> less drag.
Quote Reply
Re: Platypus Thread: Aero Virtual Elevation Testing Protocol [codygo] [ In reply to ]
Quote | Reply
You may be right, that not all tunnels do the correction (or perhaps, do them correctly). Here are a couple of comments from Damon:

https://forum.slowtwitch.com/...ost=3705971#p3705971
https://forum.slowtwitch.com/...ost=5030185#p5030185
https://forum.slowtwitch.com/...ost=6581484#p6581484
Quote Reply
Re: Platypus Thread: Aero Virtual Elevation Testing Protocol [codygo] [ In reply to ]
Quote | Reply
codygo wrote:
Thanks for the info guys.

It’s a small detail, but there’s nuance in what is meant by correcting for the yaw. It could be that since their sensors are body-frame aligned, then the loads are automatically in the bicycle’s frame of reference, and they consider this the “yaw correction,†since by aerospace standards, the drag and lift axis are always in the wind’s reference frame, i.e, drag is in the direction of the wind while lift/sideforce are orthogonal to it.

At least for automobile testing, no such adjustments are made automatically, at Aerodyne and Windshear, or the half-scale tunnels I’ve worked in. The raw data shows freestream speeds and pressures and the data includes sensor loads, and using their specifications and measurements, desired forces are computed in the wind-aligned coordinates by the client.

I would think cyclists would want to know not what a 50kph riding speed + additional sideways component means for their drag, when quoting “50kph at 10 degrees yaw,†and not a “50kph resultant wind speed at 10 degrees yaw while riding 49.24 kph.â€

From your responses, it seems that the former is the case, but I’d personally want to see raw freestream field and body frame loads and do any corrections myself, or see the explicit conversion in whatever document they provide, since it could be considered a choice of practice. I’m also an oddball in that I tend to request raw time series data, which isn’t often provided by default (basically never unless asked for).

PS: I’m also curious what the advanced aero nerds here think about my drag on sphere with rotated axis of drag comment. The description should be enough to visualize it, but since I have a 3d scan of my p3 i may try to make a crude humanoid to see how the yaw affects the stagnation points on the body in CFD. Asymmetry tends to be favorable relative to a cyclic/unstable flow.

PPS: How many people aim to “feel†flow attachment during aero testing? Personally, I move my helmet and shoulders around until I feel a distinct increase in flow far down my lower back: shear stress -> attachment -> higher rear stagnation pressure -> less drag.

This is why I've always said that wind tunnel results should be reported in CxA (i.e. drag area component in the direction of travel), since that's the component of force you "push" against (the right angle component is resisted by the tires on the ground).

I imagine that automotive tunnels don't correct for yaw because speeds in the direction of travel are typically quite high, and thus yaw effects, even with a stiff crosswind are lessened (apparent wind turns out to be nearly zero anyway).

http://bikeblather.blogspot.com/
Quote Reply
Re: Platypus Thread: Aero Virtual Elevation Testing Protocol [RChung] [ In reply to ]
Quote | Reply
RChung wrote:
You may be right, that not all tunnels do the correction (or perhaps, do them correctly). Here are a couple of comments from Damon:

https://forum.slowtwitch.com/...ost=3705971#p3705971
https://forum.slowtwitch.com/...ost=5030185#p5030185
https://forum.slowtwitch.com/...ost=6581484#p6581484

Wow, I'm impressed you were able to dig up those quotes Robert! I wish I remembered today what I knew back then, LOL (or should that be sadface...?)!

I really did derive the cosine beta squared correction for myself one afternoon. It was a trick to wrap my head around it, but in the end I was able to prove it to myself.

Damon Rinard
Engineering Manager,
CSG Road Engineering Department
Cannondale & GT Bicycles
(ex-Cervelo, ex-Trek, ex-Velomax, ex-Kestrel)
Quote Reply
Re: Platypus Thread: Aero Virtual Elevation Testing Protocol [Tom A.] [ In reply to ]
Quote | Reply
I agree Tom, and it especially makes sense from a racer's perspective.
Though I can understand a from an experimentalist's perspective it might be comforting to know, see and understand (or do!) all the corrections yourself.

Damon Rinard
Engineering Manager,
CSG Road Engineering Department
Cannondale & GT Bicycles
(ex-Cervelo, ex-Trek, ex-Velomax, ex-Kestrel)
Quote Reply
Re: Platypus Thread: Aero Virtual Elevation Testing Protocol [damon_rinard] [ In reply to ]
Quote | Reply
damon_rinard wrote:

I really did derive the cosine beta squared correction for myself one afternoon. It was a trick to wrap my head around it, but in the end I was able to prove it to myself.

I'll admit I did the same thing as well, after I somehow thought the LSWT data wasn't corrected...I confirmed it was.

We're both so weird ;-)

http://bikeblather.blogspot.com/
Quote Reply
Re: Platypus Thread: Aero Virtual Elevation Testing Protocol [Tom A.] [ In reply to ]
Quote | Reply
Not a direct reply to anyone, but just a general question. Would someone like to take a shot at compiling a "best practices" list for this method? I've read almost the whole thread, but don't want to reinvent the wheel etc.

I finally have a power meter and looking to do some aero testing this year.

Protocols?
Lap length and distance?
Types of things that work well to test?
Software?
Equipment?

Thanks in advance,
Kyle
Quote Reply
Re: Platypus Thread: Aero Virtual Elevation Testing Protocol [Tom A.] [ In reply to ]
Quote | Reply
I agree that (CdA)_x is the most appropriate component to report.

For fun, consider that to balance a side gust, a cyclist must lean towards the wind until m*g*dy= D_y*dz= (CdA)_y*dz*(1/2 rho (U cos(Beta))^2) ... and the lateral tire force will equal D_y.

I only typed it out but didn’t sketch it so correct me if it’s wrong lol. I feel the angle can be significant in cross winds from experience, and i’d guess the magnitude is a something like cornering friction increases at the same angle (measured from center of mass to contact patch in dy and dz horizontally and vertically).
Quote Reply
Re: Platypus Thread: Aero Virtual Elevation Testing Protocol [KWTri] [ In reply to ]
Quote | Reply
Best practices vary a little depending on what sensors you have, the type of test course you're using, and your racing speed. VE is pretty flexible so versions of it will work pretty widely, but sometimes you want to hone in on one or two things specifically so your protocol may differ.

That said, it's always good practice to use a dedicated speed sensor with the proper wheel rollout, to weigh yourself and all your equipment, and to track air density. If you're using a power meter, you want it to be accurate, not just consistent, so you'll want to have checked its calibration ahead of time. Then you'll want to make sure to let the PM match ambient temperature and zero the torque between runs. Wherever you choose to test, check for traffic and try not to use your brakes. If you're doing laps, make the laps short and vary your speed not only within laps but also across laps. For your baseline, find a position that you can hold well and that's easy to replicate. Practice, a lot.
Quote Reply
Re: Platypus Thread: Aero Virtual Elevation Testing Protocol [RChung] [ In reply to ]
Quote | Reply
Ugh, I am finally back to testing after a couple years off and had glitches in the virtual elevation and speed. Sigh, I realized I completely forgot to use add the speed sensor to the new bike I am testing.

Is all of the data suspect as a result or is something salvageable in the results? Just trying to make some rough decisions on angle of extensions and stack.


Screen shot of the results from Golden Cheetah (Looks like it uses the baseline - laps 2/3 and Lap 5 are same position).

Runs are all 3 laps on a loop:

Run 1 Lap 2/3
Run 2 Lap 5 (same position as run #1)
Run 3 Lap 8
Run 4 Lap 12
Run 5 Lap 18
Run 6 Lap 20

EDIT: I forgot to adjust ETA, so updating the screen shot. the CRR looks fairly close with the revised estimate. Running vittoria corsa speed (decent wear to it), latex tubes, smooth surface on the loop

Another EDIT: pretty convinced the data is junk, did another run with the speed sensor. still analyzing....


Last edited by: gbtrinride: Mar 17, 21 17:01
Quote Reply
Re: Platypus Thread: Aero Virtual Elevation Testing Protocol [codygo] [ In reply to ]
Quote | Reply
Below is what we did for some wheel testing in a small scale tunnel back in 2017. At the time it made sense to me, but I could probably be proven wrong or change my mind in the future!


Chris Morton, PhD
Associate Professor, Mechanical Engineering
co-Founder and inventor of AeroLab Tech
For updates see Instagram
Last edited by: AeroTech: Mar 17, 21 15:59
Quote Reply
Re: Platypus Thread: Aero Virtual Elevation Testing Protocol [AeroTech] [ In reply to ]
Quote | Reply


Chris Morton, PhD
Associate Professor, Mechanical Engineering
co-Founder and inventor of AeroLab Tech
For updates see Instagram
Quote Reply
Re: Platypus Thread: Aero Virtual Elevation Testing Protocol [s5100e] [ In reply to ]
Quote | Reply
s5100e wrote:
more interesting stuff... they actually reference the virtual elevation methods in their response to how they work... so now one more CdA estimator on the market: Body Rocket
Road.cc article: https://road.cc/...t1zJxUWqzqskLUHdnj50

one point they seem to think is important is that weight varies over a ride. So they put this in as another estimate along with rolling resistance etc.

not cheap either "£1499 to 1999 is the envisaged unit price," seems this area of development is starting to heat up, Aero Lab is rolling their system out as we speak etc... Whether the Velocomp device is reliable?

I still think in the real world that the Chung method is probably one way to see if these devices provide good measurements.

Aerodynamics and bikes seems to be the next frontier.


Here is a link tothe Body Rocket patent: https://pdfpiw.uspto.gov/...nput=View+first+page

My take:
- multiple strain/force sensors at every contact point between the rider and the bike enables you to determine the drag force (and lift or side force) in real units (say Newtons) of the rider themselves (not the bike).
- Thus, you have the drag produced by the rider, but not the drag on the bike.
- I can see a rider making changes to their position in close to real-time and directly seeing changes to the drag forces acting on them, which is neat.
- Unfortunately you do not have a normalization you can use for this drag force without measurement of the wind vector, i.e., you need to infer or directly measure the wind vector so that you can normalize by the dynamic pressure and produce a CdA value for the rider (not the bike).
- Once you have that (all these force sensors + wind sensor), you still do not know the drag produced by the frame, wheels, water bottles, or anything that is not carried by the rider. So you do not exactly know the total system drag (bike + rider).
- Interactions between the bike and rider are not captured directly here - perhaps a specific hand position reduces the rider drag but exposes the bike and increases the bike drag and hence total system drag remains unchanged or perhaps worse!
- You can infer the drag using an assumed Crr and re-arrange the force/energy balance, but then you are right back where we started, using virtual elevation, Chung method, other methods to infer drag. Which are great. I like them :)

- More sensors does not always mean better information, it often just means more information... which can complicate things further.

Chris Morton, PhD
Associate Professor, Mechanical Engineering
co-Founder and inventor of AeroLab Tech
For updates see Instagram
Quote Reply
Re: Platypus Thread: Aero Virtual Elevation Testing Protocol [AeroTech] [ In reply to ]
Quote | Reply
As you say Chris, more is not always better. In my experience with multivariate modelling it is the same thing, one can think that more model components looks better until the data is over fitted.... so more is not always better and as in some cases actually worse. I suspect in this sort of modelling it will be similar. Everyone is trying to find the holy grail of real time aero and it sounds like a tough nut to crack. I have been following your progress and it looks interesting, but I gather that you feel that it is necessary that the user be trained to be effective so "not mass market" yet.... Do you think that it will be "mass market, plug and play" any time soon? I was an early adopter of the second generation velocomp newton "power" meter. What I still like about it is some (be it as limited as it might be) idea of the head/tail wind effect. There are days when it just felt nice to be validated when I looked at the wind effect and it verified how I felt. I don't have that aspect any longer since I went dual sided 4iiii. Too bad there wasn't just a simple add on wind gauge one could use and the software to indicate the wind vector force over the ride if for nothing more than entertainment value and validation of those days when the wind really was the dominant force during the ride.
Quote Reply
Re: Platypus Thread: Aero Virtual Elevation Testing Protocol [s5100e] [ In reply to ]
Quote | Reply
s5100e wrote:
Everyone is trying to find the holy grail of real time aero and it sounds like a tough nut to crack.

A good measure of how close/far we are from real time is the number of constraints people place on protocols and the quality of the data being produced. It would be nice if more people posted their data so we could see the evolution of these devices. Pierre (Bugno) is one of the best for sharing his data. Have you seen data from any other device on ST ?

s5100e wrote:
Do you think that it will be "mass market, plug and play" any time soon?
IMO, it won't be mass market until they get the price significantly down. These devices need to be sub $200 which is hard given the economics to develop them. There is potential for big things happening here.
Quote Reply
Re: Platypus Thread: Aero Virtual Elevation Testing Protocol [s5100e] [ In reply to ]
Quote | Reply
s5100e wrote:
Do you think that it will be "mass market, plug and play" any time soon? I was an early adopter of the second generation velocomp newton "power" meter. What I still like about it is some (be it as limited as it might be) idea of the head/tail wind effect. Too bad there wasn't just a simple add on wind gauge one could use and the software to indicate the wind vector force over the ride if for nothing more than entertainment value and validation of those days when the wind really was the dominant force during the ride.

If the purpose of the sensor is for entertainment value and basic understanding if you are in a head vs tail wind, yes, such a device could manufactured relatively cheap (it would be a small scale wind sensor only, contain no other internal sensors aside from something for ANT+ or Bluetooth communication and perhaps the basic stuff needed for an air density estimation). Thus, the wind sensor is not doing any complex calculations, it is not taking in data from auxiliary sensors, it doesn't have any intuitive 'training' on what is happening in the surroundings. So now you have a situation where a hardware + wind sensor company is making these sensors for dirt cheap, but they rely entirely on head unit companies to adopt them and make them useful for a consumer. When about 5% (possibly less) of the consumer market wants these things, the motivation of the head unit companies to move on something like this becomes less attractive and the wind sensor company is left waiting... burning cash!

If things work out for the wind sensor company, what gets calculated algorithmically and displayed to the rider based on this data is then up to the head unit manufacturer (or the 3rd party that adopts the collection of the data, like Strava or some others). The reliance of the wind sensor on other sensors to back out drag forces and coefficients leads to the following conclusion in this situation: The quality of the data you get is now dictated by the head unit sensors, auxiliary sensors, and some fancy algorithms, the ability of the algorithms account for everything needed to make the device "plug-and-play".

There is a lot more to it than just what I have above since I did not even get into the details on what it will take to make the device "plug-and-play". Its sufficient to say that yes, I do think its possible to make it mass market and plug and play based on my experience in developing our sensor. Are enough consumers at the stage where they will see value and make use of such as sensor on their own? Do I think it is economically feasible for a wind sensor company to have a successful business model based on what I described above? The answers to these questions are left as a fun exercise for us all to ponder :)

Chris Morton, PhD
Associate Professor, Mechanical Engineering
co-Founder and inventor of AeroLab Tech
For updates see Instagram
Quote Reply
Re: Platypus Thread: Aero Virtual Elevation Testing Protocol [AeroTech] [ In reply to ]
Quote | Reply
thanks for the insightful answer. I know that my newton was a fun device with some certain intelligence built in. I still use it as a add on when riding my road bike because I still take the 4iiii as the power device but the air resistance part is interesting... so I did not toss it when I went DFPM. If they dropped their price further on the pod I would be tempted to use it as an add on, but I always felt it was a limited use device at best. The fun part was seeing how close their estimate was to the 4iiii data and truthfully for my use case it was in a general sense not too bad. When I went to my gravel bike though it lost its basic utility since there is no real way for it to deal with changing rolling resistance going from pavement, to smooth dirt, to fine gravel... etc over and over again and well wind is much less of an issue when you are enclosed with trees for the most part.
Quote Reply
Re: Platypus Thread: Aero Virtual Elevation Testing Protocol [AeroTech] [ In reply to ]
Quote | Reply
AeroTech wrote:


Hi Chris,

Thanks for the response and apoligies for taking a bit to reply.

My main objection is regarding the normalization, classically "dynamic pressure at infinity," Q_inf = 1/2 rho Vr^2.

Lets consider a cyclist riding at Vc=Vx, and relative to earth, there is a perpendicular wind velocity Vw=Vy, such that Vy/Vx = tan(beta), and Vr = Vx/cos(beta), Vy = Vx tan(beta).

Our wind, as defined, does not add a tailwind or headwind component to the rider, so Fd = -Fx in your Equation (3).

To properly apply Equation (6), we should use Vr = Vx/cos(beta), making it:

Fd = (CdA)_x 1/2 rho Vx^2 /cos(beta)^2

So far nothing has changed from your equations, we just ignore the complication of law of cosines. But many people, particularly those without sensors, incorrectly think of the data as representing

"If I'm riding at 50kph, and the wind appears to me as coming from an angle beta, then my drag is

Fd = (CdA)_x 1/2 rho Vx^2

which should emphasize that Equation (6) hides its inherent beta angle in Vr, but the data was acquired under one specific beta angle... so if we instead choose to be explicit in defining (CdA)_x = (CdA)_{x,beta_i}/cos(beta_i)^2, then the end user merely digests the formula as they imagine it, and further, (CdA)_{x,beta_i} is self documenting as being valid at a specific beta angle. I don't think anyone meaningfully digests the data as side wind + head/tail winds, so analysis and aero specialists can use whatever they like since they're less likely to develop a false intuition from the equations.

One thing I've personally witnessed, is people being surprised by the disconnect between coefficients and the forces they think they represent. Drag force will not be zero for a rider at 50kph and an extreme side gust, and I believe considering CdA_{x,beta_i}/cos(beta_i)^2 communicates that better than the alternative does.
Last edited by: codygo: Apr 4, 21 13:30
Quote Reply
Re: Platypus Thread: Aero Virtual Elevation Testing Protocol [codygo] [ In reply to ]
Quote | Reply
Hi, I have noticed through some of the treads asking when the AeroLab sys would be available for US Fitters. Yes, we have formally launched in Europe but we are taking orders from US Fitters as I’m seeing a couple Fitter sensors going to the US.

If you have interest I encourage you to check out the YouTube channel which has a boat load of technical goodies. https://youtube.com/...DP9LRmT4szD3_6QaTjQg

Also, the website https://shop.aerolab.tech/ will give you some options for leasing.

Thanks for letting me flag a couple postings request.
Last edited by: AeroTechCEO: Apr 5, 21 13:44
Quote Reply
Re: Platypus Thread: Aero Virtual Elevation Testing Protocol [codygo] [ In reply to ]
Quote | Reply
Completely agree with you there Cody. This is part of the reason the wind vector was so important to me in developing the AeroLab sensor.
If you are not normalizing by the right dynamic pressure (your cosine beta squared correction), then you run into a challenge of not knowing how to interpret your data because you are simply missing key information.

Chris Morton, PhD
Associate Professor, Mechanical Engineering
co-Founder and inventor of AeroLab Tech
For updates see Instagram
Quote Reply
Re: Platypus Thread: Aero Virtual Elevation Testing Protocol [AeroTech] [ In reply to ]
Quote | Reply
AeroTech wrote:
Completely agree with you there Cody. This is part of the reason the wind vector was so important to me in developing the AeroLab sensor.
If you are not normalizing by the right dynamic pressure (your cosine beta squared correction), then you run into a challenge of not knowing how to interpret your data because you are simply missing key information.

Yup. People thought the errors were random, so if you had wide variance you could just enlarge the sample size. That works when the errors are random but not when they're systematic. Extra sensors (properly used) give you a way to separate the random and the systematic.
Quote Reply
Re: Platypus Thread: Aero Virtual Elevation Testing Protocol [RChung] [ In reply to ]
Quote | Reply
RChung wrote:
AeroTech wrote:
Completely agree with you there Cody. This is part of the reason the wind vector was so important to me in developing the AeroLab sensor.
If you are not normalizing by the right dynamic pressure (your cosine beta squared correction), then you run into a challenge of not knowing how to interpret your data because you are simply missing key information.


Yup. People thought the errors were random, so if you had wide variance you could just enlarge the sample size. That works when the errors are random but not when they're systematic. Extra sensors (properly used) give you a way to separate the random and the systematic.

Wait...you mean if I have unmodeled and/or unmeasured variables that might change systematically, that I can't just take a bunch of samples and then evaluate the results using statistical tools designed to judge the effects of random errors...and then claim "no difference" when the null hypothesis can't be rejected?

Who knew? ;-)

http://bikeblather.blogspot.com/
Quote Reply
Re: Platypus Thread: Aero Virtual Elevation Testing Protocol [Tom A.] [ In reply to ]
Quote | Reply
That's the "if I don't know what causes it, I can assume it's random cuz that's SCIENCE!" way to analyze things.

A corollary is the "if I don't know what causes it, then you can't possibly know it either" argument.
Quote Reply
Re: Platypus Thread: Aero Virtual Elevation Testing Protocol [RChung] [ In reply to ]
Quote | Reply
RChung wrote:
That's the "if I don't know what causes it, I can assume it's random cuz that's SCIENCE!" way to analyze things.

A corollary is the "if I don't know what causes it, then you can't possibly know it either" argument.


One thing that had peeved me throughout my academic and professional life, is the inevitable and pervasive “we already tried X and the result was Y,†where upon investigation X was nothing like an actual X, and there could hardly be a “result,†much less a Y. The devil is in the details, and good science comes from scrutinizing these details, and making the conclusions as narrow as possible, which sometimes means there are no conclusions that can be made.

Actually, this a good spot for an Einstein quote:

Quote:
The scientific theorist is not to be envied. For Nature, or more precisely experiment, is an inexorable and not very friendly judge of his work. It never says "Yes" to a theory. In the most favorable Cases it says "Maybe," and in the great majority of cases simply "No." If an experiment agrees with a theory it means for the latter "Maybe," and if it does not agree it means "No." Probably every theory will some day experience its "No"-most theories, soon after conception.
Last edited by: codygo: Apr 23, 21 9:11
Quote Reply
Re: Platypus Thread: Aero Virtual Elevation Testing Protocol [codygo] [ In reply to ]
Quote | Reply
Reminds me of a similar quote my dad, an experimental physiologist, told me decades ago:

“No one believes a theory — except the theorist. Everyone believes an experiment — except the experimenter.â€


I don't remember if he attributed it to anyone then, but Google now suggests this might also have been Einstein.

Damon Rinard
Engineering Manager,
CSG Road Engineering Department
Cannondale & GT Bicycles
(ex-Cervelo, ex-Trek, ex-Velomax, ex-Kestrel)
Quote Reply
Re: Platypus Thread: Aero Virtual Elevation Testing Protocol [damon_rinard] [ In reply to ]
Quote | Reply
I am diving into the world of Aero field testing and came across this great thread and spend the last day reading through it. While some of it is over my head it seems there is really helpful and talented group of people involved. I would really appreciate some feedback on my baseline run I have done to make sure I am on the right track.

I performed and ABAB test, where A was me riding in the Aerobars with completely relaxed shoulders and my head relaxed looking up the road, and B was me shrugging and holding the shoulders in and keeping the head as low as possible.

My set was as follows:
Cervelo P5 three
Training wheels with Aerojacket rear, and Bontrager R3 clinchers and butyl tubes
Giro Aerohead with visor
Bibs and Jersey (fitted but not aero)
No shoe covers.
Rear speed sensor & wahoo Gps
Favero Assioma dual sided powermeter pedals .

I found a 550m loop that has no traffic at that time of the morning and is pretty much completely flat with smooth pavement. There was no strong wind, and I did 5 laps A (laps 3 - 7), 5 laps B (laps 9 - 13), 5 laps A (Laps 15 - 19), and another 5 laps in the B configuration ( laps 21 - 25).

Using CRR 0.005 (a guess), total mass 90kg, RTA .98 and RHO 1.146 (from mywindsock).

From my analysis in GC I get the results I expected, that B is faster. From my analysis I get the following CDAs: A - 0.288, B - 0.255, A -0.274, B - 0.255. I suspect the first A run was worse due to an oncoming school bus on one of the straights during one lap, but can't remember which lap. All other runs were clean, no braking or coasting needed on any run.

I would appreciate any comments on my protocol? or if anyone wants to take a look at my file to see if I calculated correct that would be great. I just want to make sure I have the basics right before I start testing more subtle changes.
Quote Reply
Re: Platypus Thread: Aero Virtual Elevation Testing Protocol [mdlyons] [ In reply to ]
Quote | Reply
FWIW, all my laps in the first 20minutes or so will have a higher CDA. Is it me and a less relaxed position, the need to warm up or my tire or.....but it's always the slowest lap.
Quote Reply
Re: Platypus Thread: Aero Virtual Elevation Testing Protocol [mdlyons] [ In reply to ]
Quote | Reply
That's an okay protocol. Next time try to remember when a bus or car passes, but you can usually see an anomaly on one of the laps.

I don't always get higher CdA on the first lap, but I *almost* always do. I used to worry about why that was but eventually I gave up and usually I just do an extra lap (or, if the laps are very short, sometimes two) for the first run of the day and then I snip that out.
Quote Reply
Re: Platypus Thread: Aero Virtual Elevation Testing Protocol [RChung] [ In reply to ]
Quote | Reply
I guess if I just want to compare A vs B for the purposes of which one is faster, using a fixed, made up Crr works (unless I am comparing different wheels with different tires). But I understand that if I want to arrive at a very accurate correct CDA, I need an accurate CRR.

I am struggling to find the CRR for my training tires (Bontrager R3, with Butyl tubes), but a very similar model the R4 I see was tested at 0.0036 per bicycle rolling resistance.com. Am I correct that I would just double that number to arrive at the total crr? 0.0072 Seems kind of high when I see people for similar tests using crr numbers of 0.005 and it impacts the CDA by more than I had realized.
Quote Reply
Re: Platypus Thread: Aero Virtual Elevation Testing Protocol [RChung] [ In reply to ]
Quote | Reply
RChung wrote:
That's an okay protocol. Next time try to remember when a bus or car passes, but you can usually see an anomaly on one of the laps.

I don't always get higher CdA on the first lap, but I *almost* always do. I used to worry about why that was but eventually I gave up and usually I just do an extra lap (or, if the laps are very short, sometimes two) for the first run of the day and then I snip that out.

I am sure you have thought this conundrum over before and have a far better idea than me for sure, but is there any chance that it may be the tires achieving equilibrium state and arriving at a stable CRR? I know that Chris Morton mentioned that they had to control for tire pressure by using the ANT+ tire pressure monitors in their system.
Quote Reply
Re: Platypus Thread: Aero Virtual Elevation Testing Protocol [mdlyons] [ In reply to ]
Quote | Reply
mdlyons wrote:
I guess if I just want to compare A vs B for the purposes of which one is faster, using a fixed, made up Crr works (unless I am comparing different wheels with different tires). But I understand that if I want to arrive at a very accurate correct CDA, I need an accurate CRR.

I am struggling to find the CRR for my training tires (Bontrager R3, with Butyl tubes), but a very similar model the R4 I see was tested at 0.0036 per bicycle rolling resistance.com. Am I correct that I would just double that number to arrive at the total crr? 0.0072 Seems kind of high when I see people for similar tests using crr numbers of 0.005 and it impacts the CDA by more than I had realized.

There are ways to solve for Crr but you need to be pretty careful about data collection in order to get good estimates because Crr is relatively "smaller" than CdA. The overall rule is this: the smaller the effect you're trying to find, the more careful you need to be in testing. A consequence of that is that it's easy to spot the difference between hands on hoods and hands in drops but if you're trying to spot the difference between two different front brakes you need to be pretty careful.

Crr is multiplied by weight, so what you're estimating is the overall average Crr for both front and rear tires. So don't double it.

If all you're doing is "Is A better than B?" then, yeah, you don't really need to get an exact estimate on Crr. If, however, you want to use this to know "*how much* better is A than B?" then you'll want to get a good estimate of Crr.
Quote Reply
Re: Platypus Thread: Aero Virtual Elevation Testing Protocol [s5100e] [ In reply to ]
Quote | Reply
s5100e wrote:
I am sure you have thought this conundrum over before and have a far better idea than me for sure, but is there any chance that it may be the tires achieving equilibrium state and arriving at a stable CRR? I know that Chris Morton mentioned that they had to control for tire pressure by using the ANT+ tire pressure monitors in their system.

Perhaps, but the oddity is that if I stop for a couple of minutes to change something and then re-start another test, I don't always get higher drag for the second set of tests. So after a while I just gave up and added some sacrificial laps at the start. It also gave me a chance to practice my line through corners and settle into a position and remember that I was going to take of selfie of exactly what I was wearing and to make a note to avoid that pothole.
Quote Reply
Re: Platypus Thread: Aero Virtual Elevation Testing Protocol [RChung] [ In reply to ]
Quote | Reply
Do you think it could be due to heat in the tires?

Maybe they get up to temp after some time rolling and become more supple relative to the beginning of a run.
Quote Reply
Re: Platypus Thread: Aero Virtual Elevation Testing Protocol [RChung] [ In reply to ]
Quote | Reply
RChung wrote:
s5100e wrote:

I am sure you have thought this conundrum over before and have a far better idea than me for sure, but is there any chance that it may be the tires achieving equilibrium state and arriving at a stable CRR? I know that Chris Morton mentioned that they had to control for tire pressure by using the ANT+ tire pressure monitors in their system.


Perhaps, but the oddity is that if I stop for a couple of minutes to change something and then re-start another test, I don't always get higher drag for the second set of tests. So after a while I just gave up and added some sacrificial laps at the start. It also gave me a chance to practice my line through corners and settle into a position and remember that I was going to take of selfie of exactly what I was wearing and to make a note to avoid that pothole.
Interesting, just a thought but it might just be the flexing of the tire body frees it up and makes it more supple, sort of like something such as maybe leather or blue jeans after they are washed (I know totally different things, just trying to generate ideas) where you move it a bit and it becomes more supple but when left to sit it changes back to being in a less supple state. I am not a materials scientist but I have seen materials that when they sit for a while the suppleness changes (ie they become more stiff) but once they are flexed they return to that supple nature. It takes time though for the change back and forth and might be exacerbated by temperatures and humidity?

Anyhow if it is rather random maybe that is just one of those unknowns.
Quote Reply
Re: Platypus Thread: Aero Virtual Elevation Testing Protocol [s5100e] [ In reply to ]
Quote | Reply
s5100e wrote:
RChung wrote:
s5100e wrote:

I am sure you have thought this conundrum over before and have a far better idea than me for sure, but is there any chance that it may be the tires achieving equilibrium state and arriving at a stable CRR? I know that Chris Morton mentioned that they had to control for tire pressure by using the ANT+ tire pressure monitors in their system.


Perhaps, but the oddity is that if I stop for a couple of minutes to change something and then re-start another test, I don't always get higher drag for the second set of tests. So after a while I just gave up and added some sacrificial laps at the start. It also gave me a chance to practice my line through corners and settle into a position and remember that I was going to take of selfie of exactly what I was wearing and to make a note to avoid that pothole.

Interesting, just a thought but it might just be the flexing of the tire body frees it up and makes it more supple, sort of like something such as maybe leather or blue jeans after they are washed (I know totally different things, just trying to generate ideas) where you move it a bit and it becomes more supple but when left to sit it changes back to being in a less supple state. I am not a materials scientist but I have seen materials that when they sit for a while the suppleness changes (ie they become more stiff) but once they are flexed they return to that supple nature. It takes time though for the change back and forth and might be exacerbated by temperatures and humidity?

Anyhow if it is rather random maybe that is just one of those unknowns.


That is a ridiculous idea.
Quote Reply
Re: Platypus Thread: Aero Virtual Elevation Testing Protocol [s5100e] [ In reply to ]
Quote | Reply
s5100e wrote:

Anyhow if it is rather random maybe that is just one of those unknowns.


We need to all chip in and getting Robert one of these

http://www.izzeracing.com/...nitoring-system.html
Quote Reply
Re: Platypus Thread: Aero Virtual Elevation Testing Protocol [marcag] [ In reply to ]
Quote | Reply
In motorsports people check with physical probes (say after a pit stop). I’d be tempted to use either one that connects to a multimeter or a kitchen meat thermometer probe or infrared (like Thermapen).
Quote Reply
Re: Platypus Thread: Aero Virtual Elevation Testing Protocol [codygo] [ In reply to ]
Quote | Reply
codygo wrote:
In motorsports people check with physical probes (say after a pit stop). I’d be tempted to use either one that connects to a multimeter or a kitchen meat thermometer probe or infrared (like Thermapen).

They measure the outside temperature of the tire ?
Quote Reply
Re: Platypus Thread: Aero Virtual Elevation Testing Protocol [s5100e] [ In reply to ]
Quote | Reply
s5100e wrote:
I am sure you have thought this conundrum over before and have a far better idea than me for sure, but is there any chance that it may be the tires achieving equilibrium state and arriving at a stable CRR? I know that Chris Morton mentioned that they had to control for tire pressure by using the ANT+ tire pressure monitors in their system.


At least on a drum CRR test-rig the surface temperature of a bicycle tire heats up fast in about 30 to 60 sec upon loading, but not more than 5K above room temperature. After fast heat up surface temperature is almost constant. During the heat up I can not observe a significant change of CRR (i.e. any potential change has to be below about 3%).

I guess environment temperature and road temperature play a bigger role for the tire temperature than the heat from the rolling losses.
Last edited by: BergHugi: May 15, 21 13:31
Quote Reply
Re: Platypus Thread: Aero Virtual Elevation Testing Protocol [marcag] [ In reply to ]
Quote | Reply
marcag wrote:
codygo wrote:
In motorsports people check with physical probes (say after a pit stop). I’d be tempted to use either one that connects to a multimeter or a kitchen meat thermometer probe or infrared (like Thermapen).

They measure the outside temperature of the tire ?

The devices probe beyond the surface with a needle, sometimes after scraping off the very melted rubber.

https://m.youtube.com/watch?v=Blcij45sLus

However, since bicycle tire temps are closer to ambient temps and not super high like race tires , the need to probe into the (very thin) rubber is probably not necessary or useful.
Quote Reply
Re: Platypus Thread: Aero Virtual Elevation Testing Protocol [BergHugi] [ In reply to ]
Quote | Reply
BergHugi wrote:
s5100e wrote:
I am sure you have thought this conundrum over before and have a far better idea than me for sure, but is there any chance that it may be the tires achieving equilibrium state and arriving at a stable CRR? I know that Chris Morton mentioned that they had to control for tire pressure by using the ANT+ tire pressure monitors in their system.


At least on a drum CRR test-rig the surface temperature of a bicycle tire heats up fast in about 30 to 60 sec upon loading, but not more than 5K above room temperature. After fast heat up surface temperature is almost constant. During the heat up I can not observe a significant change of CRR (i.e. any potential change has to be below about 3%).

I guess environment temperature and road temperature play a bigger role for the tire temperature than the heat from the rolling losses.

My experience on small drum roller testing is quite different.

I can detect the lowering Crr effects of increasing tire temperature lasting over quite a few minutes in the power trace of a roller test. That's how I ended up with my testing protocol of first doing a 5 minute tire "warm-up" at a higher wheel speed, followed by a 4 minute test run (at a slightly lower wheel speed), where the average wheel speed and average power is taken from the last 2 minutes of that run. Even then, depending on the tire (e.g thick casing or tread) I'll still see a slight downward power drift from the start to the end of the 4 minute test run.

http://bikeblather.blogspot.com/
Quote Reply
Re: Platypus Thread: Aero Virtual Elevation Testing Protocol [Tom A.] [ In reply to ]
Quote | Reply
I’m not sure what the standards are for crr testing, but the temperature change should depend on load and velocity even though the crr value itself is considered to be independent of these parameters.

So even though one could in theory find crr with a light load and low velocities, the temperature deltas to the “steady state†value would change, which ultimately (apparently) may have some small effect on crr.
Quote Reply
Re: Platypus Thread: Aero Virtual Elevation Testing Protocol [codygo] [ In reply to ]
Quote | Reply
codygo wrote:
I’m not sure what the standards are for crr testing, but the temperature change should depend on load and velocity even though the crr value itself is considered to be independent of these parameters.

So even though one could in theory find crr with a light load and low velocities, the temperature deltas to the “steady state†value would change, which ultimately (apparently) may have some small effect on crr.


All of that is correct, but from an engineering standpoint, there are ways to "work around" those variables. In the end, it's really about making sure the tires are tested in an equilibrium state for the conditions. That way, the results can be better applied to race conditions (or field testing).

What I've found is that for both drum testing and field testing, the tire temperature closely tracks the ambient air temperature near the tire/wheel. Considering the quite large convective heat transfer effects on the tire of even just spinning a wheel in the air, this observation is expected. Knowing this, quite a long time ago I ran a series of drum tests over a wide range of ambient temperatures, and then calculated an approximate temperature compensation for Crr vs. ambient temperature. Applying that compensation (1.36% per degree C, see http://bikeblather.blogspot.com/...ollers-chartand.html) to the drum testing data dramatically improved the repeatability of the results for the same tire across test sessions (I now "normalize" the results to predicted Crr at 20C ambient.)

I also "baked" this temperature compensation into my personal VE spreadsheet, where there too it has greatly improved the repeatability across test runs at varying temps.

http://bikeblather.blogspot.com/
Last edited by: Tom A.: May 17, 21 9:53
Quote Reply
Re: Platypus Thread: Aero Virtual Elevation Testing Protocol [marcag] [ In reply to ]
Quote | Reply
marcag wrote:
s5100e wrote:

Anyhow if it is rather random maybe that is just one of those unknowns.


We need to all chip in and getting Robert one of these

http://www.izzeracing.com/...nitoring-system.html

Or, just a set of these: https://www.sks-germany.com/en/products/airspy-sv/

(BTW, I just picked up a set of these for myself...haven't played with them yet, though)

http://bikeblather.blogspot.com/
Quote Reply
Re: Platypus Thread: Aero Virtual Elevation Testing Protocol [Tom A.] [ In reply to ]
Quote | Reply
Tom A. wrote:
marcag wrote:
We need to all chip in and get Robert one of these

http://www.izzeracing.com/...nitoring-system.html


Or, just a set of these: https://www.sks-germany.com/en/products/airspy-sv/

Or, just a 20 year old bottle of armagnac.
Quote Reply
Re: Platypus Thread: Aero Virtual Elevation Testing Protocol [Tom A.] [ In reply to ]
Quote | Reply
Tom A. wrote:
My experience on small drum roller testing is quite different.

I can detect the lowering Crr effects of increasing tire temperature lasting over quite a few minutes in the power trace of a roller test. That's how I ended up with my testing protocol of first doing a 5 minute tire "warm-up" at a higher wheel speed, followed by a 4 minute test run (at a slightly lower wheel speed), where the average wheel speed and average power is taken from the last 2 minutes of that run. Even then, depending on the tire (e.g thick casing or tread) I'll still see a slight downward power drift from the start to the end of the 4 minute test run.

My drum has a diameter of 0.9m and is made of wood to be closer to a wooden indoor track. A test run is from 55kmh down to 25kmh in 7 steps. Every step is first 3min almost unloaded (around 1N, tire just touching the drum in order to get the moment to spin the wheel). Than 3min with load (between 300 and 500N) for warm up (I do it just for protocolary reasons, experience tells that it wouldn't be necessary) followed by 5min actual test run and unloading.

Tire surface temperature increases with speed and load and with crr, but up to now it was never more than 5K above room temperature. After around 100 7 steps test runs I could never observe a variation of crr during the usual 8min with load.
Quote Reply
Re: Platypus Thread: Aero Virtual Elevation Testing Protocol [BergHugi] [ In reply to ]
Quote | Reply
This makes sense, but the large drum and its smoothness probably reduces the contact patch deflection and the amount of heat that remains in the tire versus heating the wooden drum.

On actual roads, the asphalt can be much hotter than ambient air, along with causing larger displacements and slipping on the contact patch.

Again, not suggesting these are giant points, just bringing them up for discussion. I agree with Tom A. that convection somewhat compensates for velocity in a manner that may be modeled away, when moderate ambient temps are close to ground temps, but I think there is, plausibly, a decent effect of hot road surfaces.
Quote Reply
Re: Platypus Thread: Aero Virtual Elevation Testing Protocol [RChung] [ In reply to ]
Quote | Reply
RChung wrote:
Tom A. wrote:
marcag wrote:
We need to all chip in and get Robert one of these

http://www.izzeracing.com/...nitoring-system.html


Or, just a set of these: https://www.sks-germany.com/en/products/airspy-sv/

Or, just a 20 year old bottle of armagnac.

If all you want is the bottle, I might be able to make that happen :)
Quote Reply
Re: Platypus Thread: Aero Virtual Elevation Testing Protocol [codygo] [ In reply to ]
Quote | Reply
codygo wrote:
This makes sense, but the large drum and its smoothness probably reduces the contact patch deflection and the amount of heat that remains in the tire versus heating the wooden drum.

On actual roads, the asphalt can be much hotter than ambient air, along with causing larger displacements and slipping on the contact patch.

Again, not suggesting these are giant points, just bringing them up for discussion. I agree with Tom A. that convection somewhat compensates for velocity in a manner that may be modeled away, when moderate ambient temps are close to ground temps, but I think there is, plausibly, a decent effect of hot road surfaces.

I did a bunch of rides outside with an IR thermometer, and I compared tire temp to the temp of a small plastic piece that was shaded, located at ~axle level on the bike. Even in bright sunshine, tire temp and the temp of the test piece were nearly identical when taking a temp reading immediately upon stopping the bike. It was those observations that made me confident in just using a Crr temperature compensation based on ambient temps.

http://bikeblather.blogspot.com/
Quote Reply
Re: Platypus Thread: Aero Virtual Elevation Testing Protocol [codygo] [ In reply to ]
Quote | Reply
codygo wrote:
RChung wrote:
Tom A. wrote:
marcag wrote:

We need to all chip in and get Robert one of these

http://www.izzeracing.com/...nitoring-system.html


Or, just a set of these: https://www.sks-germany.com/en/products/airspy-sv/


Or, just a 20 year old bottle of armagnac.


If all you want is the bottle, I might be able to make that happen :)



What about this: https://www.tubolito.com/tech/
Quote Reply
Re: Platypus Thread: Aero Virtual Elevation Testing Protocol [Tom A.] [ In reply to ]
Quote | Reply
Tom maybe you, Josh or others can comment on a statement from the paper on rolling resistance estimation:
https://journals.sagepub.com/...177/0954407018802733
"Tyre hysteretic loss has been the main essential issue in numerical prediction of rolling resistance. In other words, the rolling resistance force is a measure of the hysteretic losses. In all of the popular numerical methods used for this reason, the time histories of strains must be approximated to calculate the hysteretic loss and rolling resistance during one revolution. These methods are classified based on the technique by which strain cycles are approximated during the cycle."
as you have so well noted as has Josh, hysteresis is the main reason for rolling resistance break point. In the above they mention time histories of strains. Would this have any impact on initial VE trials? This is outside my scope so I am interested in a hysteresis for dummies explanation. Does this mean that there is a time domain change in hysteresis that requires knowing what happened before to predict the effect?
Quote Reply
Re: Platypus Thread: Aero Virtual Elevation Testing Protocol [BergHugi] [ In reply to ]
Quote | Reply
BergHugi wrote:
codygo wrote:
RChung wrote:
Tom A. wrote:
marcag wrote:

We need to all chip in and get Robert one of these

http://www.izzeracing.com/...nitoring-system.html


Or, just a set of these: https://www.sks-germany.com/en/products/airspy-sv/


Or, just a 20 year old bottle of armagnac.


If all you want is the bottle, I might be able to make that happen :)




What about this: https://www.tubolito.com/tech/
Those have a pretty large resolution (+/- 3 psi) for the purpose...I think he'd enjoy the armagnac more ;-)

http://bikeblather.blogspot.com/
Quote Reply
Re: Platypus Thread: Aero Virtual Elevation Testing Protocol [s5100e] [ In reply to ]
Quote | Reply
s5100e wrote:
Tom maybe you, Josh or others can comment on a statement from the paper on rolling resistance estimation:
https://journals.sagepub.com/...177/0954407018802733
"Tyre hysteretic loss has been the main essential issue in numerical prediction of rolling resistance. In other words, the rolling resistance force is a measure of the hysteretic losses. In all of the popular numerical methods used for this reason, the time histories of strains must be approximated to calculate the hysteretic loss and rolling resistance during one revolution. These methods are classified based on the technique by which strain cycles are approximated during the cycle."
as you have so well noted as has Josh, hysteresis is the main reason for rolling resistance break point. In the above they mention time histories of strains. Would this have any impact on initial VE trials? This is outside my scope so I am interested in a hysteresis for dummies explanation. Does this mean that there is a time domain change in hysteresis that requires knowing what happened before to predict the effect?

No...when they talk about "time history of strains", they're basically describing the process by which one would quantify/calculate the hysteresis of a material.

And, I think you might be misunderstanding the "breakpoint" concept. In the total bike+rider system, at pressures below the breakpoint pressure for the conditions/use, the majority of losses are due to hysteresis in the tire carcass (i.e. due to flexing of the tire material in response to movement AND to surface irregularities). Good tires with low hysteresis properties end up returning most of that flexing input to the road surface in the trailing half of the contact patch. That's why pneumatic tires work so well.

However, the tire is containing an air spring (which has quite low hysteresis) which makes up a big part of the "suspension" (i.e. nearly all of the spring rate) and if that air spring is inflated to too high of a spring rate (too stiff for the conditions/use) then the energy imparted into that tire by the surface irregularities isn't used to flex the tire as much, and more of it is transmitted through the tire and into the rest of the system, where it can be dissipated in the "squishy bits" of the rider.

Does that make sense?

http://bikeblather.blogspot.com/
Quote Reply
Re: Platypus Thread: Aero Virtual Elevation Testing Protocol [Tom A.] [ In reply to ]
Quote | Reply
Thanks Tom, what I read from the quote is to be able to model rolling resistance of a tire they needed to take into account the material characteristics. Now I assume that because this is a model for automotive tires it may be more important than in bicycle tires for exactly the reasons you state, that the material hysteresis is not significant to the over all effect of the bike rider system. thanks for the explanation.
Quote Reply
Re: Platypus Thread: Aero Virtual Elevation Testing Protocol [s5100e] [ In reply to ]
Quote | Reply
Im not sure if this has popped up in previous pages but I occasionally get a noticeable drift that makes some tests useless. It usually ends with position B almost always being faster than A. I know the easy answer is to go ABBA but I usually save those for recovery weeks.

Does temperature effect the VE calculation or possibly my Quarq numbers? Here is an example where the temp dropped more than what is likely (Starts at 34 before stabilizing at 28) - https://www.strava.com/activities/4682092261. I also went out today on an endurance ride and noticed the temp started around 61 and dropped until it stabilized at 52. The actual temperature was 60. The funny thing is that I dual recorded using a Garmin 520 and a Wahoo Bolt and both had the same temp drop. Full disclosure - I rode with GPS on both but even still the cda drift is pretty significant. I would have to move the density slider from 1.22 to 1.16 to get the start and end to show similar numbers.


Quote Reply
Re: Platypus Thread: Aero Virtual Elevation Testing Protocol [carrag340] [ In reply to ]
Quote | Reply
Possibly, but temp affects air density the wrong way: a 9 degree F. drop in temperature should *increase* air density a little. So I'd be looking at tires or your power meter.
Quote Reply
Re: Platypus Thread: Aero Virtual Elevation Testing Protocol [carrag340] [ In reply to ]
Quote | Reply
 
You could do a couple of things. I would try to get hourly weather data and see if things are changing over the 2+ hours. Look at barometric pressure which will greatly impact air density.

Also look at wind. You may have more of tail wind contribution in the 2nd part of the ride. I am not sure what your ride look looks like. Is it out and back or some kind of loop ?

Maybe look if there has been a big change in zero offset of the Quarq at the beginning and end of ride. You used to be able to do this with a Quarq, not sure you still can. Can you zero during the ride ?

Is this pattern reproducible ? Knowing that would help narrow things down.

That is a low CRR you are using.
Quote Reply
Re: Platypus Thread: Aero Virtual Elevation Testing Protocol [marcag] [ In reply to ]
Quote | Reply
Im using a 3 mile loop with decent tree coverage. I shorten them to half laps when I do proper testing.

I'll try to do ABA with my pedal power meter added to compare with my Quarq and see if I can tease anything out. I wish it were reproducible but some days I get really clean data and other days the last position is ~10 watts faster.

The CRR was just a random number. I usually use around .005 for my training setup.
Quote Reply
Re: Platypus Thread: Aero Virtual Elevation Testing Protocol [carrag340] [ In reply to ]
Quote | Reply
I am not certain if this really matters but I notice you have constant elevation velodrome checked as on. What happens if you check the auto correct and the constant elevation check boxes to off?
Quote Reply
Re: Platypus Thread: Aero Virtual Elevation Testing Protocol [RChung] [ In reply to ]
Quote | Reply
Robert, do you use Golden Cheetah for you analysis? I can't get it to run on my MAC and I have the operating system updated, but just won't load. Any suggestions other than Golden Cheetah?
Quote Reply
Re: Platypus Thread: Aero Virtual Elevation Testing Protocol [lonniecdams] [ In reply to ]
Quote | Reply
lonniecdams wrote:
Robert, do you use Golden Cheetah for you analysis? I can't get it to run on my MAC and I have the operating system updated, but just won't load. Any suggestions other than Golden Cheetah?

What version of the OS (Catalina, Big Sur...) and what version of GC ?
When you say "won't load", what happens ? Do you get something like the GC icon appearing as if it was running but nothing on the screen ?
Quote Reply
Re: Platypus Thread: Aero Virtual Elevation Testing Protocol [marcag] [ In reply to ]
Quote | Reply
I am running Big Sur 11.4. I am using the recommended GC that it detects the 64 bit one. I download it and open the dmg file to open it. I click on the icon and click on open. The GC icon just bounces on the left hand side and then after about 5 minutes it says it is not responding.
Quote Reply
Re: Platypus Thread: Aero Virtual Elevation Testing Protocol [marcag] [ In reply to ]
Quote | Reply
 
Quote Reply
Re: Platypus Thread: Aero Virtual Elevation Testing Protocol [lonniecdams] [ In reply to ]
Quote | Reply
I build GC myself, but did have some problems on Big Sur which I never fully investigated.

Maybe try the 3.6 development build ?
https://github.com/...ses/tag/v3.6-DEV2101
Quote Reply
Re: Platypus Thread: Aero Virtual Elevation Testing Protocol [lonniecdams] [ In reply to ]
Quote | Reply
lonniecdams wrote:
I am running Big Sur 11.4. I am using the recommended GC that it detects the 64 bit one. I download it and open the dmg file to open it. I click on the icon and click on open. The GC icon just bounces on the left hand side and then after about 5 minutes it says it is not responding.


I tried the 3.5 and 3.6 builds on Big Sur and they did not work. Same thing as you, bouncing of icon.

I went to the google group (golden-cheetah-users) where all the smart guys hang out.

Ale, one of the main developers put a link to this build
http://goldencheetah-binaries.s3-website-us-east-1.amazonaws.com/

I tried it on Big sur and it worked. It did the standard apple bitching about malware.

There is talks of versions of Qt (one of the main components they use to build). The conversation matches my experience. The new QT required a new XCode. The new Xcode works on old machines, but the old Xcode doesn't work on new machines........
Quote Reply
Re: Platypus Thread: Aero Virtual Elevation Testing Protocol [marcag] [ In reply to ]
Quote | Reply
Thank you so much. What was weird is last night it bounced and then about 15 minutes later it just opened. It seems to sit there for a while saying, "Application is not responding". Then it opens right up, but I will try those other versions. You guys are amazing thanks for all of your help.
Quote Reply
Re: Platypus Thread: Aero Virtual Elevation Testing Protocol [lonniecdams] [ In reply to ]
Quote | Reply
No problem, glad it worked

And to answer your original question, maybe it's an urban legend, but Robert does not use GC/Aerolab. Us mere mortals can do mental addition and subtraction. Robert does mental VE.
Quote Reply
Re: Platypus Thread: Aero Virtual Elevation Testing Protocol [lonniecdams] [ In reply to ]
Quote | Reply
lonniecdams wrote:
Thank you so much. What was weird is last night it bounced and then about 15 minutes later it just opened. It seems to sit there for a while saying, "Application is not responding". Then it opens right up, but I will try those other versions. You guys are amazing thanks for all of your help.

Very strange. I went back and retried 3.5 versions that did the same "bouncing" as you. They opened up immediately this morning. As if there is some type of "initialization" that had to be done, and now that's it's done, everything is fine.
Quote Reply
Re: Platypus Thread: Aero Virtual Elevation Testing Protocol [marcag] [ In reply to ]
Quote | Reply
Other than the train option not working Golden Cheetah seems to be working just fine. Question about the VE testing. Can I just use any home weather station that measures barometric pressure? I am thinking the home ones that you see that measure inside and outside temperature and then humidity and pressure. Those that do a lot of VE testing thoughts?
Quote Reply
Re: Platypus Thread: Aero Virtual Elevation Testing Protocol [ In reply to ]
Quote | Reply
I'm hoping to get a little help troubleshooting my protocol. I am currently setup using a wahoo elemnt bolt as my ride recorder, garmin vector 3s as my power meter, and a garmin speed sensor 2 as my speed sensor.

My course is an out and back with an initial climb and then a short downhill and immediate uphill, both of which I coast to lose enough speed to turn around on the uphill without using any brakes. I've got my start/finish position chalked on the road as well as the start, apex, and finish of my turnaround point. I use the lap button on each start and finish and use that to cut out the turnaround back (in red) to the start as I have to break hard to turnaround on the start/finish portion of my test area.

I've been out testing a single position on 3 different days so far and have yet to come up with consistent results from any of them. Each day of testing has had very little wind. I recognize that I'm on a single sided powermeter which isn't the best, but is I would think that having a muscle imbalance would skew the cda results and that I wouldn't have an inconsistent enough imbalance to make the results as unreliable as they are.

Any ideas on what could be making my lap not symmetrical comparing pre-turnaround to after turnaround? My first guess would be maybe some wind but each lap being non-symmetrical in almost the same way makes me doubt it. Could I have missed a recording setting that smells like smart recording? I've got my speed sensor set to use the specific wheel circumference but haven't found any settings for the powermeter that would suggest fishy recording. Or does it all come down to using a single sided powermeter?

Any help would be greatly appreciated. Happy New Year.
Last edited by: arkwebb: Dec 31, 21 22:20
Quote Reply
Re: Platypus Thread: Aero Virtual Elevation Testing Protocol [arkwebb] [ In reply to ]
Quote | Reply
arkwebb wrote:
I'm hoping to get a little help troubleshooting my protocol. I am currently setup using a wahoo elemnt bolt as my ride recorder, garmin vector 3s as my power meter, and a garmin speed sensor 2 as my speed sensor.

My course is an out and back with an initial climb and then a short downhill and immediate uphill, both of which I coast to lose enough speed to turn around on the uphill without using any brakes. I've got my start/finish position chalked on the road as well as the start, apex, and finish of my turnaround point. I use the lap button on each start and finish and use that to cut out the turnaround back (in red) to the start as I have to break hard to turnaround on the start/finish portion of my test area.

I've been out testing a single position on 3 different days so far and have yet to come up with consistent results from any of them. Each day of testing has had very little wind. I recognize that I'm on a single sided powermeter which isn't the best, but is I would think that having a muscle imbalance would skew the cda results and that I wouldn't have an inconsistent enough imbalance to make the results as unreliable as they are.

Any ideas on what could be making my lap not symmetrical comparing pre-turnaround to after turnaround? My first guess would be maybe some wind but each lap being non-symmetrical in almost the same way makes me doubt it. Could I have missed a recording setting that smells like smart recording? I've got my speed sensor set to use the specific wheel circumference but haven't found any settings for the powermeter that would suggest fishy recording. Or does it all come down to using a single sided powermeter?

Any help would be greatly appreciated. Happy New Year.

Happy new Year too.

In you precise description, you didn't mention if you ride on the middle of the road, which is a necessary condition (but potentialy unsafe one) to have symmetrical elevation profile.

I also have non-symmetrical elevation profile here (red curve: use of a barometer with a +/-10 cm precision) during a low wind day (virtual elevations corrected by airspeed from an anenometer). It may be explained cause a road is not perfectly level from a side to other (or some other reason that I am also interested to know too).



Blog | Twitter| Bike CdaCrr app
Quote Reply
Re: Platypus Thread: Aero Virtual Elevation Testing Protocol [arkwebb] [ In reply to ]
Quote | Reply
Just to clarify, it looks like the 2nd image was a Golden Cheetah screenshot? What was used for the first image?
Quote Reply
Re: Platypus Thread: Aero Virtual Elevation Testing Protocol [RChung] [ In reply to ]
Quote | Reply
The first one was mycda.app. Golden Cheetah doesn't seem to import my laps in the correct spot and mycda.app does while also automatically isolating the laps. Using mycda just makes it so I don't have to manipulate my data to remove the between laps section.
Quote Reply
Re: Platypus Thread: Aero Virtual Elevation Testing Protocol [bugno] [ In reply to ]
Quote | Reply
Oh, I didn't realize that I was supposed to be going center but that makes sense for the asymmetry, thank you. As far as the lack of precision in results, I am beginning to suspect either my speed sensor accuracy or how the elemnt bolt uses the speed sensor. I have the elemnt set to use the wheel circumference instead of the "auto" setting which still uses some gps. However, my lap distances still vary by up to 26 feet in a set. What sensor do you use and/or is there a gold standard that people tend to use for aero testing? I've seen a lot of mentions for the gsc 10 but was having trouble getting my hands on one so I had settled for the garmin speed sensor 2.
Last edited by: arkwebb: Jan 1, 22 8:21
Quote Reply
Re: Platypus Thread: Aero Virtual Elevation Testing Protocol [arkwebb] [ In reply to ]
Quote | Reply
I personally could never get remotely decent data with a single sided power meter, but that may just have been me!
Quote Reply
Re: Platypus Thread: Aero Virtual Elevation Testing Protocol [arkwebb] [ In reply to ]
Quote | Reply
arkwebb wrote:
Oh, I didn't realize that I was supposed to be going center but that makes sense for the asymmetry, thank you. As far as the lack of precision in results, I am beginning to suspect either my speed sensor accuracy or how the elemnt bolt uses the speed sensor. I have the elemnt set to use the wheel circumference instead of the "auto" setting which still uses some gps. However, my lap distances still vary by up to 26 feet in a set. What sensor do you use and/or is there a gold standard that people tend to use for aero testing? I've seen a lot of mentions for the gsc 10 but was having trouble getting my hands on one so I had settled for the garmin speed sensor 2.

What speed sensor are you using?
  • Do not use magnet-less speed sensor.
  • PowerTap G3 hub may have some (rare) oddities (velocity spikes).
  • Gsc 10 is an old speed sensor.
  • I am using this cheap one (magnet sensor) with good success: https://www.amazon.com/...aps%2C163&sr=8-3


Blog | Twitter| Bike CdaCrr app
Quote Reply
Re: Platypus Thread: Aero Virtual Elevation Testing Protocol [bugno] [ In reply to ]
Quote | Reply
Unfortunately I have been using a magnet less sensor. Garmin Speed Sensor 2.
https://www.garmin.com/en-US/p/641230

I’ve now got a magnet one in the mail. Arrives Tuesday. Thanks for the help. Hopefully the next round of testing has me closer to quality results.
Quote Reply
Re: Platypus Thread: Aero Virtual Elevation Testing Protocol [arkwebb] [ In reply to ]
Quote | Reply
arkwebb wrote:

Any ideas on what could be making my lap not symmetrical comparing pre-turnaround to after turnaround?


All happy aero tests are alike, all unhappy aero tests are unhappy in their own way. There are so many ways that failure to fit can occur that you need to dive into the actual data to see what happened. It's hard to diagnose just from a VE profile. That is, VE is a very sensitive diagnostic but because so many things go into it, it's hard just from the profile alone to figure out which of those many things went wrong.

Usually when there's a lack of fit, I have to go through a checklist of things that may have gone wrong. Unfortunately, right now, diagnosing lack of fit is sort of like drawing an owl.



At some point those of us who know what to do have to fill in a bit more about step 2.
Last edited by: RChung: Jan 6, 22 0:40
Quote Reply
Re: Platypus Thread: Aero Virtual Elevation Testing Protocol [RChung] [ In reply to ]
Quote | Reply
Robert, tow quick questions for you.

1. Can I use a hub mounted speed sensor. Some have said yes, some have said no.
2. I have a Garmin Edge 130, I did a route with the GPS and I just got a straight line for elevation. There was about 6ft of gain/loss in the 250ish Meter loop I did. Is this enough elevation or do I need more? Will that computer work?

Thank you.
Quote Reply
Re: Platypus Thread: Aero Virtual Elevation Testing Protocol [lonniecdams] [ In reply to ]
Quote | Reply
lonniecdams wrote:
Robert, tow quick questions for you.

1. Can I use a hub mounted speed sensor. Some have said yes, some have said no.
2. I have a Garmin Edge 130, I did a route with the GPS and I just got a straight line for elevation. There was about 6ft of gain/loss in the 250ish Meter loop I did. Is this enough elevation or do I need more? Will that computer work?

Thank you.

I'm no Dr. Chung, so take what I say with a grain of salt, but I would try multiple loops of that track. You should see the elevation rise and fall periodically. The 130 has a barometer for barometric elevation so should work OK. As for the hub sensor I have used one and it worked for me but make sure you set the correct wheel circumference (use a weighted roll out meaning sit on the bike full weight and roll out 1 wheel revolution measure the distance).
Quote Reply
Re: Platypus Thread: Aero Virtual Elevation Testing Protocol [s5100e] [ In reply to ]
Quote | Reply
Awesome, thanks!! I did 4 laps in a high school parking lot that has about 6ft'. Thanks again!
Quote Reply
Re: Platypus Thread: Aero Virtual Elevation Testing Protocol [RChung] [ In reply to ]
Quote | Reply
I wrote some simple code to implement the VE method. And tested whether it revealed the difference with a visor (and without). I rode a lumpy 1km "half-pipe" loop about 30-odd times, varying the speeds a bit. I do have a braking zone at one end as I turn around. So I hit the Lap button each time on my Garmin. My code inspects the .tcx file and throws out brake zone laps and keeps the "loop".

My code can flatten the graph automatically etc. Seems very straightforward to code up and I get a family of solutions (Crr, cdA).
I also find a difference without/with visor. (Not a tri-bike or regular bike but still method applies.) So far, so good.

Then, because I have varying speed runs, see histogram, I graph all the (Crr, cdA) pair solutions over a range of Crr.
I pick the pair that has the least overall deviation for the top3 fastest and slowest runs.
Problem is, the best Crr I get is perhaps unrealistically low, around 0.0035, 0,004.
(Continental GP 5000 S TR 32-622 tubeless with Vittoria Airliner on the back and Contact Urban 32-406 with super thin butyl in front. Not a regular bike.)

Hmm, I have good rho data from our university's dept of Hydrology and Atmospheric Sciences weather station.
(I live at elevation and rho < 1 usually, so it's a good sign it's station pressure.)
I use a wireless Garmin Speed Sensor 2, and don't rely on GPS speed.
The data is recorded one per second by my Garmin computer.
I do not correct for the initial data point, as it requires the data point 1 sec before my start, but I rely on hitting Lap.
I do use the velocity correction for the lag detailed in the slides.
I have the Assioma powermeter pedals. I modify the watts reported, multiplying by a factor bit less than one to account for drivetrain inefficiency.
I didn't detect significant wind during my run, but perhaps I'm mistaken and there was some wind.
(So last week, I bought the Bluetooth windmeter mentioned in the other thread and threw together 5 min code to extract the wind speed. Next time, I can mount the windmeter in front and get V_air.)

Anyway, I have a simple question about the slope equation formula. I notice the Crr part doesn't take slope into account for simplicity.

Given an incline, Crr is conventionally defined with respect to force normal to the incline, so shouldn't we multiply by the cosine of the slope?
If I do that, the VE curves look significantly different. So I must be missing something.

See handwritten picture with f(s) = 0 and f'(s) for the revised formula. I solve numerically for s (slope).
Plotted, the deviations are initially small, but as you can see in the last picture, they add up and the VE graph looks different, formula vs. formula2.
Garmin GPS profile is also shown here, but of course, I don't use it in my calculations.
Last edited by: malaigo: Jul 12, 23 11:04
Quote Reply
Re: Platypus Thread: Aero Virtual Elevation Testing Protocol [malaigo] [ In reply to ]
Quote | Reply
Sorry, I forgot to append the slope formula and modified with cosine slope formula to the previous post.
Here's the code in Python, I can write it in any programming language, but Python is accessible to anyone and easy to read.
Just in case I made a silly error.
Last edited by: malaigo: Jul 12, 23 11:10
Quote Reply
Re: Platypus Thread: Aero Virtual Elevation Testing Protocol [malaigo] [ In reply to ]
Quote | Reply
CdA values are not in the expected range for a cyclist, what unities do you use?
Last edited by: BergHugi: Jul 12, 23 12:49
Quote Reply
Re: Platypus Thread: Aero Virtual Elevation Testing Protocol [BergHugi] [ In reply to ]
Quote | Reply
Not that it's relevant, but I'm using something a bit more aerodynamic than my road bikes.
It's the same principle at work.
I'm testing the effectiveness of the visor in this picture.
Last edited by: malaigo: Jul 12, 23 14:32
Quote Reply
Re: Platypus Thread: Aero Virtual Elevation Testing Protocol [malaigo] [ In reply to ]
Quote | Reply
can you post the .fit file?

What's your CdA?
Quote Reply
Re: Platypus Thread: Aero Virtual Elevation Testing Protocol [G. Belson] [ In reply to ]
Quote | Reply
I have the .tcx file. That's what I download from my Garmin Connect. Will that do?
Quote Reply
Re: Platypus Thread: Aero Virtual Elevation Testing Protocol [malaigo] [ In reply to ]
Quote | Reply
malaigo wrote:
I have the .tcx file. That's what I download from my Garmin Connect. Will that do?


What is the vehicle ? Where/how is power measured ?
Last edited by: marcag: Jul 13, 23 4:10
Quote Reply
Re: Platypus Thread: Aero Virtual Elevation Testing Protocol [malaigo] [ In reply to ]
Quote | Reply
malaigo wrote:
Not that it's relevant, but I'm using something a bit more aerodynamic than my road bikes.
It's the same principle at work.
I'm testing the effectiveness of the visor in this picture.


Ok, such fully faired recumbents can have really low cdA (for example see attached paper, unfortunatelly in German).

Crr of 0.0035 - 0.0040 is possible.
Last edited by: BergHugi: Jul 13, 23 6:32
Quote Reply
Re: Platypus Thread: Aero Virtual Elevation Testing Protocol [marcag] [ In reply to ]
Quote | Reply
Dear Maracag, I believe I posted a picture of the vehicle above after my initial message. It's in an attachment. If you can't see it, I can email it. And I mentioned I'm using Assioma pedals. And front wheel alignment is accurate to the mm level. Thanks.


Last edited by: malaigo: Jul 13, 23 9:47
Quote Reply
Re: Platypus Thread: Aero Virtual Elevation Testing Protocol [BergHugi] [ In reply to ]
Quote | Reply
BergHugi wrote:
Ok, such fully faired recumbents can have really low cdA (for example see attached paper, unfortunatelly in German).

Crr of 0.0035 - 0.0040 is possible.

Nice find! thank you.

How about my question about a modification to the formula for Crr? :-)
Quote Reply
Re: Platypus Thread: Aero Virtual Elevation Testing Protocol [malaigo] [ In reply to ]
Quote | Reply
Even at 10% slope the Crr is still 99.5% of Crr on flat ground.

I would do separate testing of Crr and CdA improvements since neither is very likely to be constant across speed anyway.
Last edited by: MTM: Jul 13, 23 11:28
Quote Reply
Re: Platypus Thread: Aero Virtual Elevation Testing Protocol [MTM] [ In reply to ]
Quote | Reply
MTM wrote:
Even at 10% slope the Crr is still 99.5% of Crr on flat ground.

I would do separate testing of Crr and CdA improvements since neither is very likely to be constant across speed anyway.

And at 10% the contribution of rolling resistance is probably very low.
Quote Reply
Re: Platypus Thread: Aero Virtual Elevation Testing Protocol [MTM] [ In reply to ]
Quote | Reply
MTM wrote:
Even at 10% slope the Crr is still 99.5% of Crr on flat ground.
I computed the cosine factor here. So 0.999 etc., so it looks right. Thank you so much for confirming.

But although it tracks the same initially, it does cause a discrepancy eventually in my VE (See profiles in the graph below - formula = standard, formula2 = formula with cosine factor.)
Scratch my head... maybe there is an error in my code I didn't see.

>>> profile(runs[1])
discrepancy: cos(-0.0372) = 0.9993 (-0.0386)
discrepancy: cos(-0.0609) = 0.9981 (-0.0632)
discrepancy: cos(-0.0557) = 0.9984 (-0.0588)
discrepancy: cos(-0.0648) = 0.9979 (-0.0689)
discrepancy: cos(-0.1003) = 0.9950 (-0.1062)
discrepancy: cos(-0.0937) = 0.9956 (-0.1013)
discrepancy: cos(-0.0762) = 0.9971 (-0.0855)
discrepancy: cos(-0.0587) = 0.9983 (-0.0696)
discrepancy: cos(-0.0583) = 0.9983 (-0.0706)
discrepancy: cos(-0.0533) = 0.9986 (-0.0670)
discrepancy: cos(-0.0163) = 0.9999 (-0.0305)
discrepancy: cos(0.0073) = 1.0000 (-0.0066)
discrepancy: cos(0.0193) = 0.9998 (0.0059)
discrepancy: cos(0.0167) = 0.9999 (0.0038)
discrepancy: cos(0.0356) = 0.9994 (0.0235)
discrepancy: cos(0.0502) = 0.9987 (0.0392)
discrepancy: cos(0.0577) = 0.9983 (0.0478)
discrepancy: cos(0.0270) = 0.9996 (0.0176)

Quote Reply
Re: Platypus Thread: Aero Virtual Elevation Testing Protocol [malaigo] [ In reply to ]
Quote | Reply
I found today that Charles Henry conducted tests back in 2015 on a tarmac velodrome in Switzerland. His graph confirms the Crr1 and Crr2 where Cr1 is a constant and Cr2 a tiny speed dependent factor for bicycle tires.

Quote Reply
Re: Platypus Thread: Aero Virtual Elevation Testing Protocol [malaigo] [ In reply to ]
Quote | Reply
I too think that independence of Crr from speed and load is an approximation, however it may often be justified.

Tests on my "big" drum test rig usually show increasing Crr with increasing speed and / or load or normal Force respectively.


Last edited by: BergHugi: Jul 14, 23 0:13
Quote Reply
Re: Platypus Thread: Aero Virtual Elevation Testing Protocol [BergHugi] [ In reply to ]
Quote | Reply
BergHugi wrote:
Tests on my "big" drum test rig usually show increasing Crr with increasing speed and / or load or normal Force respectively.
Thanks for sharing! What tire is that? Is there an appropriate conversion factor from the Crr on your drum to smooth tarmac? Maybe just wishful thinking.
Quote Reply
Re: Platypus Thread: Aero Virtual Elevation Testing Protocol [malaigo] [ In reply to ]
Quote | Reply
malaigo wrote:
Thanks for sharing! What tire is that? Is there an appropriate conversion factor from the Crr on your drum to smooth tarmac? Maybe just wishful thinking.

I have to check, but I think it was a Conti Supersonic 622-23 with latex tube at 8 bar on a Citec 8008 ultra.

An appropriate conversion factor? I don‘t know how smooth a smooth tarmac is in the US. I think here a good rolling smooth tarmac is not that much worse than my drum. I guess the conversion factor is definitely smaller than 1.5.
Quote Reply
Re: Platypus Thread: Aero Virtual Elevation Testing Protocol [BergHugi] [ In reply to ]
Quote | Reply
I added the windmeter for testing. It is mounted rigidly but a distance above the vehicle, just like with Solar car testing.

Here is the Speed vs. AirSpeed on an almost calm night. Looks quite good to me.
I wrote code to Merge the recorded windspeed data on my iPhone with the Garmin .tcx file.

Quote Reply
Re: Platypus Thread: Aero Virtual Elevation Testing Protocol [malaigo] [ In reply to ]
Quote | Reply
malaigo wrote:
I added the windmeter for testing. It is mounted rigidly but a distance above the vehicle, just like with Solar car testing.

Here is the Speed vs. AirSpeed on an almost calm night. Looks quite good to me.
I wrote code to Merge the recorded windspeed data on my iPhone with the Garmin .tcx file.


Is that on an "out and back" or loop ?
Last edited by: marcag: Jul 22, 23 7:42
Quote Reply
Re: Platypus Thread: Aero Virtual Elevation Testing Protocol [marcag] [ In reply to ]
Quote | Reply
marcag wrote:
malaigo wrote:
I added the windmeter for testing. It is mounted rigidly but a distance above the vehicle, just like with Solar car testing.

Here is the Speed vs. AirSpeed on an almost calm night. Looks quite good to me.
I wrote code to Merge the recorded windspeed data on my iPhone with the Garmin .tcx file.


Is that on an "out and back" or loop ?
Out and back on the same road with a cul-de-sac for a non-braking turnaround.
After midnight, no traffic.
I use the lap button to start and stop the recording at the same location.
There is braking required to go around a rotary at the end before returning to the start, but that section is excluded by software.
Quote Reply
Re: Platypus Thread: Aero Virtual Elevation Testing Protocol [malaigo] [ In reply to ]
Quote | Reply
malaigo wrote:
marcag wrote:
malaigo wrote:
I added the windmeter for testing. It is mounted rigidly but a distance above the vehicle, just like with Solar car testing.

Here is the Speed vs. AirSpeed on an almost calm night. Looks quite good to me.
I wrote code to Merge the recorded windspeed data on my iPhone with the Garmin .tcx file.


Is that on an "out and back" or loop ?

Out and back on the same road with a cul-de-sac for a non-braking turnaround.
After midnight, no traffic.
I use the lap button to start and stop the recording at the same location.
There is braking required to go around a rotary at the end before returning to the start, but that section is excluded by software.


So it looks like the air speed needs a small factor applied to it (maybe an offset, but probably a multiplier)
The difference between airSpeed and speed is basically wind
In theory the wind on the out = -1 * wind on the back
So if the yellow line comes up a bit, you will have a tailwind on the out and a headwind on the back

If I am reading your chart properly
Last edited by: marcag: Jul 22, 23 16:39
Quote Reply
Re: Platypus Thread: Aero Virtual Elevation Testing Protocol [marcag] [ In reply to ]
Quote | Reply
marcag wrote:
So it looks like the air speed needs a small factor applied to it (maybe an offset, but probably a multiplier)
The difference between airSpeed and speed is basically wind
In theory the wind on the out = -1 * wind on the back
So if the yellow line comes up a bit, you will have a tailwind on the out and a headwind on the back
So how to determine a value for the multiplier? Perhaps when the end points match up (same elevation)? Would that be reasonable?

Thanks!
Quote Reply
Re: Platypus Thread: Aero Virtual Elevation Testing Protocol [malaigo] [ In reply to ]
Quote | Reply
malaigo wrote:
marcag wrote:

So it looks like the air speed needs a small factor applied to it (maybe an offset, but probably a multiplier)
The difference between airSpeed and speed is basically wind
In theory the wind on the out = -1 * wind on the back
So if the yellow line comes up a bit, you will have a tailwind on the out and a headwind on the back

So how to determine a value for the multiplier? Perhaps when the end points match up (same elevation)? Would that be reasonable?

Thanks!

Different aero sensors/apps have a protocol to determine this. The level of "sophistication" from app to app varies.

I noticed you are posting in the Cda/Crr app so if using that I am pretty sure they have one.
Quote Reply
Re: Platypus Thread: Aero Virtual Elevation Testing Protocol [marcag] [ In reply to ]
Quote | Reply
The windmeter manufacturer uses a linear ax+b formula to convert from impeller rpm to m/s wind speed. So I read impeller rpm and just use the values of the constants a and b that they provide.

Doing k(ax+b) where k is a fudge/calibration factor doesn’t seem so easy to do. There is always a bit of wind outside. Seems it’d have to be done indoors (no wind), ride at a selection of fixed speeds down some long corridor. Then one might as forget k and just use the new empirically determined a’ and b’ values.
Last edited by: malaigo: Jul 23, 23 4:10
Quote Reply
Re: Platypus Thread: Aero Virtual Elevation Testing Protocol [malaigo] [ In reply to ]
Quote | Reply
malaigo wrote:
The windmeter manufacturer uses a linear ax+b formula to convert from impeller rpm to m/s wind speed. So I read impeller rpm and just use the values of the constants a and b that they provide.


Doing k(ax+b) where k is a fudge/calibration factor doesn’t seem so easy to do. There is always a bit of wind outside. Seems it’d have to be done indoors (no wind), ride at a selection of fixed speeds down some long corridor. Then one might as forget k and just use the new empirically determined a’ and b’ values.


Yes, the rpm to speed formula is published by the manufacturer. I have one and have tested it a few times. Good for what it costs, but not stellar. But Let's say for a minute that number is right.

The issue is, the airSpeed measured at the windMeter is not the airSpeed if, for example, you placed the windmeter a few feet out in front. There is a correction that must be applied to the wind speed.

If there is 0 wind, and I put the meter 10feet out in front of me, and I go 36km/h I will probably see 36km/h. If I put the meter 1m in front of my torso, I will probably see 33km/h, however 36km/h is the number I want to be using in my calcs.

Windmeter calibration is not trivial. Very coarse calibration is easy, very precise calibration is not.
Last edited by: marcag: Jul 23, 23 15:53
Quote Reply
Re: Platypus Thread: Aero Virtual Elevation Testing Protocol [marcag] [ In reply to ]
Quote | Reply
marcag wrote:
The issue is, the airSpeed measured at the windMeter is not the airSpeed if, for example, you placed the windmeter a few feet out in front. There is a correction that must be applied to the wind speed.

If there is 0 wind, and I put the meter 10feet out in front of me, and I go 36km/h I will probably see 36km/h. If I put the meter 1m in front of my torso, I will probably see 33km/h, however 36km/h is the number I want to be using in my calcs.

Windmeter calibration is not trivial. Very coarse calibration is easy, very precise calibration is not.
In my case, the windmeter is mounted on an extension stick. I'm not sure it's completely in free air, but the windspeed there should be close to that of free air.

In the eco challenge machine, they mounted it even closer to the body. The book doesn't mention a correction factor.

Quote Reply
Re: Platypus Thread: Aero Virtual Elevation Testing Protocol [malaigo] [ In reply to ]
Quote | Reply
 

you might want to do a little experimenting
Quote Reply
Re: Platypus Thread: Aero Virtual Elevation Testing Protocol [marcag] [ In reply to ]
Quote | Reply
marcag wrote:
you might want to do a little experimenting
Yes, good to see if it's right.

I'm trying to think of a building that has enough room or a sheltered-enough parking garage,
Unfortunately, no underground parking garage at work.
Quote Reply
Re: Platypus Thread: Aero Virtual Elevation Testing Protocol [marcag] [ In reply to ]
Quote | Reply
There is a low pressure "bubble" above a train. So, if high pressure means a lower reading and low pressure means a higher reading for the windmeter, it could be overestimating the "true" airspeed (green). I raised the windmeter up but maybe it's better to raise it even higher.

Quote Reply
Re: Platypus Thread: Aero Virtual Elevation Testing Protocol [RChung] [ In reply to ]
Quote | Reply
Hi, Robert I am having some trouble with Golden Cheetah. Hoping you could help or point me in the right direction. I am using a Garmin Edge 130. I turn off the GPS on the unit, I am using a magnet speed sensor. I feel like my route is good no brakes consistent lines. I do not get any elevation data, am I using the wrong head unit? Should I leave GPS on?
Quote Reply
Re: Platypus Thread: Aero Virtual Elevation Testing Protocol [lonniecdams] [ In reply to ]
Quote | Reply
lonniecdams wrote:
Hi, Robert I am having some trouble with Golden Cheetah. Hoping you could help or point me in the right direction. I am using a Garmin Edge 130. I turn off the GPS on the unit, I am using a magnet speed sensor. I feel like my route is good no brakes consistent lines. I do not get any elevation data, am I using the wrong head unit? Should I leave GPS on?


A 130 should have a barometer for altitude. However, maybe it needs GPS to initialize, really not sure.
I would do this. Turn on GPS. Put a speed field on the display, lift the wheel and spin it. If speed registers you know speed is being picked up by the speed sensor and you should be good.


Also, verify there is no altitude in the "performance chart" not in the Aerolab chart
Last edited by: marcag: Oct 22, 23 13:37
Quote Reply