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.

I think you can learn a lot about the nature of variability by looking at the VE profiles of a delta mass test.

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/

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/

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?

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?

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?

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

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?

---

What's your CdA?

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

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?

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

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.

---

What's your CdA?

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?

Very nice. I'll check it out.

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.

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.

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.

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.

Sounds like a good idea. Wish there was some test data on real world Vs. roller crr for different surfaces.

---

What's your CdA?

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.

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.

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.