A quick attempt at real-time CdA measurement

 

This post describes my attempt to calculate the real-time (instantaneous) drag that I'm experiencing when I'm on my time trial bike, using data from my power meter, altimeter and speed sensors.

For several years now, I've been measuring and trying to improve the aerodynamic drag of my time trial bike.  For time trials, the aerodynamic drag is critical to how fast you can go, because on a flat road most of your power (~80% of it) is expended to overcome the aerodynamic drag.  Put simply, if you can improve your aerodynamic efficiency (your "CdA") by let's say 10%, you can reduce the power needed by around 10% while maintaining the same speed.  Alternatively, you will go faster for the same power.

What is CdA?

Aerodynamic efficiency is defined for cyclist using a parameter called CdA.  In fact CdA is two parameters, multiplied together: Drag coefficient (Cd) and frontal area (A).  The drag coefficient defines how aerodynamically efficient a certain shape is, regardless of its physical size.  For example, a beach ball and a baseball will both have the same drag coefficient*, Cd, because they have the same shape (a sphere), even though they are obviously different in  size.  If both balls are subjected to the same air speed though, the larger beach ball will experience a larger drag force in Newtons, because it has a larger frontal area (A).  In fact, the drag force will be ten times greater, for example, if it's frontal area is ten times greater than the baseball.  Therefore, it's convenient when we are adjusting both the shape of a bike/rider (Cd), and also the frontal area (A), as we usually do when adjusting a time trial set-up, to combine both of these parameters.  It is the product of these two parameters (CdA) that we want to minimize in order to go faster.

* There are a few caveats to this statement, but I won't go into those details here.

The Virtual Elevation Method (aka The Chung Method)

In the last decade, the excellent virtual elevation method, invented by Robert Chung, has become the standard method for triathletes and time trialists to measure their CdA in the field (i.e. on standard roads, not in wind tunnels or velodromes).  Additional information about the method can be found on the Slowtwitch Platypus Thread.

I have been successfully using this method for several years to measure and improve my CdA.  The trouble with it is, though, it's quite time-consuming to collect and analyse the data.  The way I do testing, to test two bike setups, back-to-back, then to repeat them to be sure ('ABAB' testing), takes about 40 minutes of riding time, with about 10 minutes per setup. The analysis of the results probably then takes another 30 minutes to 1 hour, once I'm back home. 

Real-time CdA

I wanted to see how feasible it would be to extract the CdA value in 'real-time'.  That is, at 1 second intervals, could you extract the CdA based on the measured power, elevation and speed?  All of that data is used by the Chung method, but it is processed in a different way, to give you the 'average' CdA over the run.  To extract real-time CdA, you simply solve the power equation on slide 14 of Robert Chung’s VE presentation to solve CdA, using the instantaneous measured elevation, instead of the usual procedure of guessing a value for CdA and then solving elevation.

I attempted to extract real-time CdA using data from a 10-mile time trial I did in 2019.  I didn’t have high hopes that it would be successful, but I was curious anyway and wanted to give it a go.

My findings? Well, the noise in the resulting real-time CdA values was even worse than I expected, with real time CdA values ranging from -1.4 to +1.0 m^2!  (the green trace in the Figure 2).  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, as shown in Figure 1).  However, the noise in the real-time drag clearly makes it unusable as a drag extraction method though.

Figure 1: Virtual elevation (Chung method) CdA calculation

Figure 2: Real Time (instantaneous) CdA calculation

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 is best explained with an example, assuming the following:

Mass = 80 kg rider+bike, Speed = 45 kph, CdA = 0.217 m^2, CRR = 0.004, Power = 300W, Rho = 1.2 kg/m^3, 97% transmission efficiency.

In this example, 252W is overcoming aerodynamic drag.  A 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, for example 30 seconds, as shown in the dark green curve in Figure 2.  Alternatively, or in addition, more accurate elevation data would help, and I know there are some folks (for example, see here) that are using more precise barometric sensors to help with this.  The example above, though, shows it’s a tough problem to crack.  Even a really small 1cm elevation error would be a 3% drag change over 1 second.

The beauty of the Chung 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 to avoid this elevation sensitivity, of course, would be to ride a perfectly flat road like a velodrome.  However, I’m lazy and would prefer to do my testing 5 minutes away from my home!

Conclusion 

This exercise, although it was generally unsuccessful, was useful in showing why the Chung Method works so well, by avoiding the use of inaccurate elevation data that would otherwise cause difficulties.

It also shows that it's incredibly difficult to extract your instantaneous CdA value, using the power data from your power meter.  On a perfectly flat road it would be feasible, but not on a random road where you have to rely on measured elevation.  The idea of looking down at your head unit, and to see your CdA displayed (as you do for your power or speed), would be brilliant.  Unfortunately it seems that would be very difficult to achieve.