**What is CdA?**

*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.

**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__

*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.

https://AeroStar.app successfully calculates the realtime Cda (and Crr) that you attempted. AeroStar is a generalization of the Virtual Elevation (VE) method which is an energy-based method to calculate your CdA popularized by Prof. Robert Chung. VE calculates the average CdA for a lap, while AeroStar calculates the instantaneous CdA for your entire ride. The website explains how it works.

ReplyDeleteHi Peter, Yes, I've seen with interest a few of the plots from your software on Twitter. It looks interesting and very promising. I'd be interested to know more, so I'll check out your website when I have time. In particular, I'd be interested to know what hardware you use to capture elevation changes, because the studies I did showed that my real time CdA was incredibly sensitive to small changes in measured elevation. The altitude precision coming from Garmin Edge altimeter just wasn't good enough for that.

ReplyDelete