What We Do
Sign Up For Free
Create An Event
Models & Calculators
Create An Event
About Performance Modelling
CPL Premium & Bespoke
Pro Race Analytics
Training & Testing Days
Scientific Performance Testing
Power Models  :  Coastdown Method CdA Estimation
Temp (Deg C)
Kilos (Rider + Bike)
Rel. Humidity (%)
Elevation loss (metres)
There was an unexpected error or your calculations exceeded the allowed time. Either one or more of your parameters is beyond the realms of probability or the server is extremely busy right now. Double check the parameters and try again.
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 (
) and rolling resistance (
). 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
. 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:
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
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.
CPL & company are members of
Copyright © 2008-2016 Cycling Power Lab