This was was the first piece of cycling performance analysis that I did, back in 2016. A few months before that, in late 2015, I had bought a power meter for my road bike. I really liked the data that it provided, allowing me to pace my rides with more precision. I quickly began to question, though, how should I pace a ride to achieve the fastest time, i.e. the highest average speed? Should I try to keep my power constant, regardless of the terrain and wind conditions, or would it be quicker to increase the power on some sections of the route? We often hear that for time trials the fastest time is achieved by holding the highest possible fixed power, instead of going 'too hard' at the start. However, most time trials are held on flat routes, and I had a feeling that the constant power approach may not be best for hilly routes.

This is question is essentially an optimisation problem: What is the optimal way to deliver the power to minimise ride time (i.e. maximise average speed) for a set of constraints. I decided to see whether Microsoft Excel's built-in optimiser could solve this kind of optimisation problem.

I should point out that, at this time, I wasn't aware of BestBikeSplit.com. A couple of years after I did this work I heard about BestBikeSplit on the TrainerRoad podcast and discovered that it does something very similar to my Excel spreadsheet, albeit in a slicker commercial package. In fact, I'm not sure which year BestBikeSplit was originally developed, but I wasn't aware of it when I developed this Excel-based bike power optimiser. A future blog post will show comparisons between my my Excel optimiser and BestBikeSplit, showing that they both give similar optimisation results.

**Bicycle Power Modelling**

The starting point of my Excel based power optimiser was to build a model that calculates the required power to propel a bike. The equations of motion that describe the forces on a bike, and hence the power required to move it, are shown below.

This is another situation where I derived something myself, the equations below, and then some years later discovered that this model of the forces acting on a bicycle had been derived previously (not surprisingly). See here for Jim Martin's paper.

*Power = (Fa + Fg + Fr + Fi)*V*

Where:

Fa = Aerodynamic drag force (N)Fg = Gravitational component force (N)Fr = Rolling resistance force (N)Fi = Inertia force (N)V = Velocity (m/s)

and:

*CdA = Drag area of the bike+rider (m^2)*

*Cr = Coefficient of rolling resistance*

*rho = Air density (kg/m^3)*

*m = Mass of bike+rider (kg)*

*t = time (s)*

*g = Acceleration due to gravity (=9.81m/s^2)*

This power model was validated by comparing the power predicted by this model against the measured powers that I recorded during three Strava segments; 2 flat segments and an uphill segment:

__1) Weston Hill, near Bath, South West England:__

**Real life:**18/07/15, 7 mins 35 secs (8.0 mph), 20 degC, 80.6 kg,

**313 W**average power

**Model:**8.0 mph gives a power requirement of

**314W**using CdA=0.36m^2, Cr=0.0045

__2) U102 out and back time trial segments, near Bristol:__

**Real life:**18/08/15, 8 mins 32 secs (24.5mph), 17 degC, 80 kg, 2 mph estimated tailwind,

**267**

**W**average power

**Model:**24.5 mph (with 2 mph tailwind) gives a power requirement of

**273 W**using CdA=0.36m^2, Cr=0.0045

**Real life:**18/08/15, 13 mins 1 secs (21.3mph), 17 degC, 80 kg, 2 mph estimated headwind,

**267**

**W**average power

**Model:**21.3 mph (with 2mph headwind) gives a power requirement of

**260W**using CdA=0.36m^2, Cr=0.0045

The agreement between the model and measured (real life) powers agree within a few percent. For the hilly segment, the model predicts the power requirement very well (a 1W or 0.3% discrepancy). For the two flat segments, the model overpredicts the power requirement for the 'out' leg of the TT course and and underpredicts it for the return leg, due to the estimated wind effects. If I were to tweak the headwind by just 0.3 mph (bearing in mind that I had to guess the headwind speed of 2 mph) then the model is spot on, within a few tenths of a percent for both out and return legs. Therefore, it can be concluded that overall the model and the values selected for CdA and Crr (drag area and coefficient of rolling resistance, 0.36m^2 and 0.0045 respectively) accurately simulate real life riding.

This model validation step was an important precursor to any subsequent use of the model for further investigations, as described in the next section.

**Optimal power delivery**

My Excel-based power model simulates a bike ride by splitting it up into several 'segments'. For each segment, which has a specified distance and gradient, the speed is set either by the user or by the Excel optimiser. Then, the model calculates the power for each segment for the chosen speeds, assuming steady-state conditions. Essentially, this neglects speed and acceleration transients between segments, which I understand is the same assumption made also by BestBikeSplit.

The powers for all of the segments can be time-averaged to calculate the overall average power for the ride, and this is the result that the optimiser is trying to minimise (or to look at it another way, it tries to maximise the average speed for a fixed average power).

I also included an approximate estimate for normalised power, since it's often that case that normalised power is the metric that we want to minimise or control instead of average power, to reflect the physiological cost of the ride. My spreadsheet calculates only *approximate *normalised power though, because instead of using the 30-second average power to derive normalised power, it effectively uses 1-second power. This is not too much of an issue, though, because most segments I used for these studies were much longer than 30 seconds, so there were no short segments where the time would be less that 30 seconds, where the normalised power calculation would have been significantly impacted. Therefore, the approximate calculation of normalised power is fit for purpose.

The optimiser can be used to either target an average power number or a normalised power number, whichever is preferred. In the subsequent example I chose to target a given normalised power.

__Routes for optimiser__

I created three fictional routes, to see how the optimised power would differ for different types of rides:

**Route 1: Typical short/medium sportive** - 80km route, 1000m of climbing, 200W normalised power.

**Route 2: 40km TT **- 40km perfectly flat route, 250W normalised power.

**Route 3: Hilly route:** 40km route with 900m of climbing, 250W normalised power

The profile for Route 1 (80km, 1000m of climbing) is shown below:

The profile for Route 3 (40km, 900m of climbing) is shown below:

__Results: Constant power versus optimised power__

**For Route 1 (80km, 1000m climbing)**, the optimised power profile, targeting 200W normalised power is shown below (upper chart), compared with the fixed power profile (lower chart). It is clear the that optimiser has determined that it is optimal to increase the power when ascending hills and reduce the power when descending hills.

**Optimised Power**192.6 W 200.0 W 2 hrs 51.1 mins 2.0%

**For Route 2 (40km, ****perfectly flat route****)**, the optimised power profile, targeting 250W normalised power is *exactly the same as the constant power profile, i.e. it is optimal to ride at at a fixed power of 250W. *This is not surprising, because the optimum power profile is a result of changes to the riding conditions. No changes in terrain or wind mean the optimum is a constant power profile. If the terrain or wind were to change along the route, the optimal power at any particular point in a ride would change also, as can be seen for Route 1 above and Route 3 below.

**For Route 3 (****Hilly route:** **40km route with 900m of climbing****)**, the optimised power profile, targeting 250W normalised power is shown below (upper chart), compared with the fixed power profile (lower chart). As for Route 1, the optimiser has again determined that it is optimal to increase the power when ascending hills and reduce the power when descending hills.

**Average Power Normalised Power Time Improvement**

**Constant Power**250.0 W 250.0 W 1 hr 30.0 mins -

**Optimised Power**237.5 W 250.0 W 1 hr 27.6 mins 2.7%

**'Too hard' power**

**224.7 W 250.0 W 1 hr 28.0 mins 2.2%**

*even*harder on the hills (labelled the "Too hard" case above)? I took the optimised power profile shown in the plot above and increased the amplitude of the speed variation (fixed power versus optimised power) by 50%, then made a 0.2 mph global adjustment to the speed to keep the normalised power at exactly 250W. For example, for the steep 10% gradient climb in the middle of the route, the climb is done at 6.64 mph for the constant 250W power profile, 7.48 mph at the optimum power of 283W, and 7.72 mph at the 'too hard' power of 293W.

**Conclusion**

__Finally__: Observant people will notice that that my power modelling doesn't have a correction for transmission losses, so it implicitly models a perfectly efficient transmission, or the power required at the rear hub, not power at the pedals. This was an oversight on my part. However, although it will affect the absolute predicted powers/speeds and therefore the CdA and CRR tuning, I don't believe it will affect the overall conclusions of this study.

## 0 comments:

## Post a Comment