CDA ESTIMATION

FROM CYCLINGPOWERLAB

The Chung method is an excellent way to estimate a riders CdA using power data collected on the road. It doesnt require a velodrome or even a flat course, and if you use a circuit then light winds are unlikely to have a significant impact on the result. But it is not the only way to estimate CdA with a power meter. Before the Chung method came the regression method and the model here implementents the methodology of Martin et al (2006) 

So how does it differ? Well this a test which must be done on a velodrome, a flat piece of road, or else a nearly flat road for which the gradient is known with some precision. An outdoor test also requires recording of the wind conditions (strength and bearing) experienced at that location when the test is being run. Unfortunately these are not things you can discern with amazing accuracy from a simple weather report, however basic hand-held anemometers (wind speed meters) go for small change on ebay. 

Carrying out the test on a road requries that you first locate a straight stretch of tarmac long enough to ride at a smooth pace for ideally a minute or more. You need to know the compass heading or bearing of the road (eg North = 0 degrees, South = 180 degrees), followed by the wind strength and bearing. As with the Chung method it's also essential to record the data that will be used to calculate the relevant air density (temperature, pressure, humidity) although these can come straight from a weather report. 

The test methodology is to ride up and down the road, at least 6 times is recommended, using a range of different speeds. Somewhere in middle of the stretch e.g. the middle 1 minute if the road is taking about 2 minutes to cover and just when the riders speed and power at at their smoothest the applicable speed and power data will be used to estimate CdA. How you decide to identify these critical sections of power meter data is upto you, but this model tries to make things as easy as possible because you feed it with a 3 column file where columns 1 & 2 are speed and power data. In column 3 you simply "tag" the important sections of you data (eg 1-6) while any other data is ignored. There is an example of a suitable 6 sector test file here  although in a real test the power and speed numbers would not be constant through each sector as they are in this simplified example which also uses just 10 second sectors. 

Carrying out the test on a velodrome is easier because you can assume a flat "road" and zero wind. In this case you might collect data every 4 laps of 8, using the time in between the test sections to adjust speed. Remember that maintaining a smooth speed and power through the test sections is just as important so in the track case you might want to stay on the black line throughout.  Anybody who has seen "The Final Hour" (a documentary about Chris Boardman's preparation for the Athletes Hour Record) will have seen Boardman & Peter Keen using a very similar procedure to evaluate the aerodynamic merits of various equipment choices and this is, of course, an excellent application of this kind of testing.

So how is the data converted into a CdA? Basically the model uses a form of the same theoretical power model used elsewhere on this site to decompose the forces affecting the rider into components representing acceleraton, climb, rolling reistance, and aerodynamic drag. Arrranging this model in a clever way and feeding it with speed and power data allows the riders CdA to be estimated from a regression on all the different observations.

Ride Data File

Data File. Create and select a text (.txt) or comma separated values (.csv) file having three comma separated columns of ride data in the same format as the example. Column 1 should be the speed data, column 2 the wattage data, and in column 3 you should tag the critical sections of the test. For example if you rode a 6 sector test tag all of the rows representing sector 1 data with "1", "s1" or similar in column 3, then do the same for all other sectors. Rows that are not tagged will simply be ignored. A "txt" file can be created easily on most computers while the "Save As" menu in Excel is the easiest way to create a "csv" file from 3 simple columns of spreadsheet data.

Parameters

1. Speed In. Select the unit of speed applicable to the recorded data (KPH or MPH).

2. Interval (Sec). Select the recording interval of your power data in seconds.

3. Rider + Bike Weight (Kilos). Input total weight in kilos (e.g. 80).

4. Pressure (Millibars). Input the ambient air pressure in Millibars (e.g. 1013). You can get this number from any good weather forecast.

5. Temprature (Deg C). Input a temperature in degrees Celcius (e.g. 20)

6. Relative Humidity (%). Input the ambient air humidity in percent (e.g. 20). Again you can get this number from a weather forecast.

7. CRR (Rolling Resistance). Select the coefficient of rolling resistance applicable to the course. Typical values are .004 (Asphalt) and .008 (Rough Tarmac).

8. The following inputs can all be left as "0" or the default values in the case of a test on a velodrome.

9. Wind Speed (KPH). Input the wind speed in Kilometes per hour (e.g. 5).

10. Wind Bearing. Select the applicable wind direction as a heading (e.g. NW) or else input a wind bearing between 0 and 255 degrees. This is the direction the wind is blowing from, not to.

11. Course Bearing. Select the bearing of the course consistent with your choice of "Bearing Refers To"

12. Bearing Refers To. Is the bearing you provided the direction you were riding in on the odd numbered sectors, the even numbered sectors, or if you always covered the road in the same direction select "All Sectors"

13. Average Grade (%). Specify the average grade of the road, in the direction of the course bearing, as a percentage. eg 1.5 = 1.5%
    
    

Outputs – Sanity Checks

• Before focussing on the CdA estimated by the model it is important to check that the ride data file fed into the model has been read in a way that makes sense. Based on the contents of the file and your parameter inputs each of the summary numbers in this section should make sense. If not, double check everything and try again.

Outputs - CdA & R^2

• CdA is the metric of aerodynamic drag (Coefficient of drag x frontal Area) calculated in respect of the rider and bike combined. The figure is expressed in metres squared. Typical but not exceptional cycling values are in the range .25 to .40 and you should expect to see a value within or close to this range, otherwise the validity of the test may be questionable. To see some typical CdA values have a look a the Aerodynamics Primer. R^2 (R squared) expresses the explanatory power of the regression used to estiamte CdA in the range 0-1 where 1 is ideal and significantly lower values may suggest an unreliable test.

• Power-Speed Relationship

This test is all about relating the riders realised speeds with the power outputs applied to achieve those speeds and then "backing out" the applicable CdA. If the data is good then there will be a clear relationship between the speed and power averages collected from the 6 or more test sectors and you should check for this here in a visual sense. Each test sector is represented by a diamond, hopefully all close to the the blue trend line. On a theoretical level aerodynamic drag force increases at the square of speed so this is the relationship you should observe on this graph.

The great thing about the use of power in cycling is that it’s a unifying metric. A rider with a certain VO2max, with a certain efficiency and lactate threshold who is in a certain state of nutrition will be able to maintain a certain power output. And on a certain course, give certain environmental conditions and of course dependent on that rider’s weight and aerodynamic drag he will race at a certain speed. It’s as simple and unavoidable as that. Somewhere along the line riders and coaches who shun the use of power meters have missed this very enlightening point. 

There are mathematics that link the riders physiology with his power output, and there are mathematics (founded in Newton’s laws) which link his power output with speed on a certain road of a certain gradient, dependent always on aerodynamic drag (CdA) and rolling resistance (Crr). It follows that if we know a riders power output and every other variable but CdA and Crr, then we can estimate those, just as we do when estimating CdA with the Virtual Elevation (Chung) Method or the Regression Method . In fact there is no reason why we cant do exactly the same, using the same mathematics, when power is zero such as when coasting down a hill. This is exactly what the coastdown method does. 

The idea of a “coastdown” method for drag evaluation has been around for some time. In a crude interpretation a cyclist freewheels down a hill several times from a fairly consistent starting speed and then concludes that the equipment choices made on the runs that got him furthest were the ones with the least drag. It can also be evaluated in a mathematically precise way using speed data in the context of a known elevation loss, as a special zero-power case of the Virtual Elevation (Chung) method , such that CdA and Crr can be estimated with high precision. That’s what this model allows you to do.

Coastdown Test Protocol

The basic requirements for a good coastdown test are:

• A hill on which you can mark start and end points defining a test section which has a known loss of elevation, 5 metres for example. A test section in the region of 200-300 metres works well because it’s long enough to collect a good few seconds of speed data but short enough that the test is easily repeated multiple times. The greatest difficulty in this method is the need to know precisely the loss of elevation on the hill.

• Some way of accurately recording bike speed at intervals (e.g. once per second) at and between those two points. You’ll need a bike computer with a wheel mounted speed sensor (GPS speed estimates are less ideal) and it must be a device from which you can download a time-series of the speed data.

• Windless conditions. Wind is the enemy of aerodynamic field testing unless it is known and measurable – for most of us it isn’t.

• The suggested way to execute the test is to mark 4 points on a hill. Mark the beginning and end of the real test section, then mark a run-in section of known length before the test section as well as a run-out section of known length. The run-in and run-out sections serve 2 purposes. 1) You can start and stop recording data outside of the real test section so there is no button pressing or aerodynamic interference when the data matters, and 2) given their known length our model can simply ignore speed data recorded before the bike travelled X meters and after it travelled Y meters so you don’t have to identify and extract the key stretch of speed data. 

Given those 4 points on the hill the test requires that you coast the bike through the key section at a range of different entry speeds. The range of speeds is important because this is what enables the mathematics to identify both a CdA (coefficient of aerodynamic drag) and Crr (coefficient of rolling resistance). Ideally the range of speeds will vary from the very slow to the very fast (but safe). There is no problem pedalling through some of the run-in section but the bike most be coasting with zero pedal power through the key section.

Some suggestions (requirements) that improve the quality of the test:

• To recap - there should be no wind.

• To recap – the bike should be coasting through the key test section. Turning the pedals can be desirable because it more accurately simulates the drag profile of an active rider but power should be zero.

• The test depends greatly on a known loss of elevation. Since speed is only being recorded at intervals (e.g. 1 second) the accuracy of the test is improved if the key test section starts and ends on flat sections of road which will not be traversed in less than the recording interval (e.g. 1 second) at any test speed.

• The more runs the better. The minimum required is 2, the maximum supported by this model implementation is 10.

• Find a quiet road. Scrap / do not use the data from any runs which featured other cyclists or traffic in the vicinity.

• Do not use any sort of “smart recording” on your computer. Disable this setting if you have to because the test requires a good, continuous flow of speed data recorded at identical intervals.

Finally we provide specific notes on the use of, inputs to and outputs from our model:

Inputs

• Ride File. The model is fed with recorded speed data in a file of “CSV” format, 1 column per test run. CSV files can be created using Excel (CSV is one of the available file types in the “Save As” dialog) or a text editing application such as Notepad. The easiest way to understand the required shape of the file is to look at the example.

• Interval (Sec). Select the recording interval of your speed data in seconds.

• Rider + Bike Weight (Kilos). Input total weight in kilos (e.g. 80).

• Elevation Loss (Metres). Specify the known loss of elevation between both ends of the test section. Specify a positive number - the model knows its a negative.

• Run-In (metres). Specify the length of the "run-in" section discussed above. The model will assume that data recording started at the beginning of this section and ignore speed recordings determined to have been made in this section.

• Run-Out (metres). Specify the length of the "run-out" section discussed above. As with the rubn-in section data will be ignored.

• Weather – Pressure (Millibars). Input the ambient air pressure in Millibars (e.g. 1013). You can get this number from any good weather forecast.

• Weather – Temprature (Deg C). Input a temperature in degrees Celcius (e.g. 20)

• Weather - Relative Humidity (%). Input the ambient air humidity in percent (e.g. 20). Again you can get this number from a weather forecast.
  
  

Outputs - The Table

• Run Number: Identifies the numbered test runs fed into the model.

• CdA. The CdA computed for the rider (as a result of analysing all the test runs).

• Crr. The Crr computed for the rider (as a result of analysing all the test runs).

• Initial speed. The speed of the rider when entering the key test section.

• Final speed. The speed of the rider when leaving the key test section.

• Average speed. Applies throughout the test section in Kph or Mph depending on the measure of the input speed data.

• Distance (m). The length of the key test section as computed from the speed data. This number will differ slightly across runs highlighting one of the issues in recording exactly the right section of ride and the reason why flat starting and finishing sections are recommended.

Outputs - The Virtual Elevation Chart

This is the Virtual Elevation of the hill, graphed for each test run, implied by the CdA & Crr estimates. If the test protocol has been executed well the slopes on this chart will closely match the actual hill used for the test. If one of the runs appears significantly different to the rest there may have been some error - we suggest deleting it from the test data and running again.