I would like to get your opinions on the FTP model I developed

[RIDUCK]

Hello!

I’ve wanted to discuss this from a long time ago. I think this forum is suitable and I post it.

I think estimating FTP is the most important in recent cycling training programs.
The question I have is why they don’t differentiate between training levels when estimating FTP.
Strava and WKO probably use a critical power model and a method of linear regression analysis of kJ graphs. I think this is a legacy technology.
These days, the number of users of power meters has increased, and data is available through the Strava API.
But why not make advanced machine learning (deep learning) modeling?

So I developed it myself.
If the cyclist’s training level is different, the duration of the same power is different.
In other words, w/kg is highly correlated with the degree of aerobic training.
This is Joe Friel’s insight, and I trust it.
So, I made a modeling that introduced weight as a correlation to the existing FTP estimation method.

First, I collected data from about 26 major segments around the world and generated statistical data using the GAN algorithm.
To put it simply, it is assumed that the record of Strava is the peak power, and the data with power is used as the correct answer data.
It is a competitive learning method for virtual physics engines.
(This virtual physics engine was made based on the Chung method, and if you are curious, I can open it later.)

And on Strava, the weight is divided into 10kg units. Here you can get the variance data of the weight.
If you know deep learning like this, anyone can make stereo power curve modeling without experimenting with professional players. How easy is it?
It wasn’t easy for me. It took months to adjust the data.

result,
It is distributed data of 5 minutes power.
I have power curves and variance data for 600,000 people created by this modeling.

And the simplified modeling can be checked through this link.

https://koreancycling.network/strava/e_curve.php

(There are no ads or sign-up.)

There is simple example.
There are two players, 300 seconds, 300 watts.
By the way, the weight is different at 60kg and 70kg.
Existing models have the same 300 sec and 300 watts, so most of them will calculate the same FTP and power curve.
The modeling I made is different weights, different FTP.
Like this.

-60kg

-70kg

I have shorter experience in cycling training and cycling science than many of you here.
So, I would like to receive a lot of opinions and feedback.
I’m curious about David’s opinion of developing intervals.icu, and I’m also curious about the opinions of several coaches.

I welcome critical comments.

Thank you.

[William_Barnes]

Thanks for sharing @RIDUCK, really interesting and you’ve clearly put a lot of work into this. I wonder though if you’re selling it short as an FTP model, since it is generating a “full” (out to 1hr) power curve and not just a single threshold power number from a single power test. From the user perspective it seems to me to have some parallels to David’s default / fastfitnesstips power curve model.

Since it generates the power curve from a single effort though, I don’t see how it can be more useful than a rider’s own power curve for prescribing training / intensity levels though, as it has no input to take account of rider type (eg anaerobically biased). Do you intend to refine such that it can accept multiple user inputs / power tests to better cater for that? And maybe extend the maximum time duration? (Although you would probably struggle to find suitable strava segments for longer durations!)

And in general, I’d ask what you see the use case of this being? Since generated from population data, is it primarily to see how an individual compares to an “average” rider (of given weight and effort of interest) across the power duration curve?

Thanks again for sharing!

[RIDUCK]

Yes.

WKO or STRAVA method requires a lot of peak power data to be accurate.
However, most users don’t have that much peak power data.
So, the method of estimating FTP with one peak power is important for UX.

I think there are two main differences between my model and the intervals model.
The first is that the sample of user data is Strava.
The second is that modeling according to the weight distribution is included in the Pd-curve estimation.

Here is a list of Strava segments that I have referenced.
//New York, River Road Circle to Ranger Station
//San Francisco, Hawk Hill
//Canada, Camillien Houde
//Colombia, Rio teusaca-Patios
//Brazil, Grota Funda (lado Guaratiba)
//Oslo, Grefsenkollen
//England, Box Hill
//England, Ditchling Beacon
//Swiss, Albispass East
//France, Col du verdun-course de cote
//France, L’Homme Mort
//Austria, Der wahre Exelberg
//Italy, Salita Panoramica
//Spain, Tu mejor ORONET
//Netherlands, Keutenberg
//Belgium, Rosier
//Australia, Bobbin Head West
//Australia, Mount Gravatt
//South Korea, Namsan
//South Korea, Bukak
//Japan, 大垂水峠TT（信?「東山下橋」～頂上）
//Taiwan, 中科松鼠坡
//Hongkong, Bride’s Pool Road
//Philippines, Sumulong Hwy up to Manga
//Thailand, สวนสัตว์-ที่พักริมทาง (ชมวิว1)
//South Africa, Suikerbossie (South Side)

-Selected uphills are located around the city center and there are many attempts.
-Various collections have been made to cover various races and cultures.
-If the slope is more than 5%, there will be less wind effect.
-The KOM record must be at least 3 minutes and not longer than 20 minutes.
-There are various differences such as altitude and rolling resistance, so it is necessary to correct the terrain information. (Random Contrast Simulation)

-error range
The error range of the power meter and recording was set at 2.5%.
For example, to collect data that is 300 sec, I treated 307.5 sec or 292.5 sec as the same 300 sec column value. This error is ignored because it is to find the probability variance.

-Data Cleaning and Supervised Learning are required
Records of longer than 20 mins in real data cannot be used as they are. Because people give up quickly compared to short durations.
However, it can be estimated. If you know the declining slope of the kJouls averaged at 5 and 10 mins, 10 and 20 mins, you can roughly estimate the slopes of 20 and 40 mins as well.
In this process, the segmented regression method was used.

-Estimation of more than 1 hour
For more than 1 hour, it is calculated by continuously multiplying the value of ‘60 mins / 20mins’.
It is similar to the conventional method.

-FTP
I surveyed about 200 WKO users and amateur athletes who knew their proper FTP.
The most appropriate FTP was the 37-42 mins peak power of this modeling.
So, the FTP is estimated by 40mins peak power.

-Use case
First, it is possible to expand the market of cycling training apps via FTP, which is suitable for untrained people.
For people with a lot of fat, traditional FTP modeling offers really ridiculous guide FTP.
People with a lot of fat can use Coggan’s TSB model by this FTP model.

Second, if you know this large amount of data variance, you’ll know your global record (in Strava’s worldview).
I roughly see this modeling and actual test error of about 3% in the aerobic zone (4min~40min). (Results compared to actual data of over 1000 people)
Regardless of the user’s training level, if the 35-minute power was estimated at 300 watts, that user would ride 291 to 309 watts.

The error percent of the power meter on the market is more than 2%, and the error of the Smart Trainer is more than 5%. I think it is less than the error of smart trainer.

Finally, I would like to tell you the case of an overweight beginner rider who weighs 120 kg.
When this beginner first ran the RAMP test, it estimated 260 to 270 FTP in zwifts and intervals.
But my model directed FTP to 200w.
In fact, this beginner measured TTE at 260 watts, and he said he only lasted 7 minutes.
And, he lasted more than 30 minutes with 200W.

In terms of user experience, this estimated power curve is working quite well. However, I have various concerns about whether it fits well with NP and TSB systems.

Thanks for your attention.

[david]

Thats quite an interesting approach. I have to admit that I am more “practical software developer” and less scientist or machine learning expert so I can’t comment too much!

[Ion-Lee_Kuiper]

@RIDUCK
Last summer I’ve been introduced by some Chinese cycling riders with Riduck.
Really interesting and valuable app you’ve build! Especially the metabolism chart is very useful.

Why this topic bump? Well, as Strava has taken a different approach on data sharing, your app might be affected.
My question, would it be possible to create an API with intervals.icu? It a central hub for many and it could be beneficial for a lot of people.

Thank you!

[Gerald]

@RIDUCK

Finally, I would like to tell you the case of an overweight beginner rider who weighs 120 kg.
When this beginner first ran the RAMP test, it estimated 260 to 270 FTP in zwifts and intervals.
But my model directed FTP to 200w.
In fact, this beginner measured TTE at 260 watts, and he said he only lasted 7 minutes.
And, he lasted more than 30 minutes with 200W.

For an old post, this is music to my ears. Thanks @Ion-Lee_Kuiper for posting here today, otherwise I may have missed the original discussion.

I’ve seen a lot of athletes in a similar situation, and not just beginners, where the ramp test heavily skews the FTP on the excessive side. That means endurance rides end up being tempo and sometimes threshold, and threshold workouts are most likely VO2.

[Ion-Lee_Kuiper]

Just got a response from @RIDUCK

We would like to clarify that Riduck has been seamlessly integrated with Strava, and last year’s Strava API update had no impact on our service. Since the announcement, there have been no changes or malfunctions related to our Strava integration.
However, we have noticed that some users mistakenly associate their errors in linking their Strava accounts with API-related issues. This appears to be a misunderstanding, and we are actively assisting them in resolving any account connection difficulties. You can verify our real-time member activity updates in the Strava club description.
From our perspective, expanding integrations with Garmin and Wahoo would be a more strategic move than prioritizing Intervals integration. Given that Riduck is now approaching 50,000 users, we are mindful of the potential server load our service may impose. Therefore, any additional integrations would require careful coordination with the respective companies.
Thank you for your time and consideration. Please feel free to reach out if you have any questions.

Unfortunate, no Riduck ↔ Intervals integration on their roadmap.