[request] Stop sending speed data to strava

You’re right – the equations above are solving for steady state speed. That’s the quickest and easiest way to get a reasonable value no matter what gearing the rider was using.

But you did make me curious – if it was modeled using forward integration how different would it be…certainly the basic steady state efforts (threshold workouts) wouldn’t change much, but as I mentioned earlier in the thread I did Gendarme the other night so I looked at that as well.

With typical workouts (sweetspot intervals) that aren’t 30s on / 30s off the difference was less than 1%. With Gendarme the difference was a 0.4 mph difference, in that the steady state model over estimated by about 2% for me. Which does make sense - you would take time in the real world to get up to your higher speed.

Thanks for the encouragement to sit down and look at this – a fun diversion.

I’m posting the code as well if you have any other suggestions - this time a python notebook converted to html as the graphs weren’t rendering correctly using the online notebook viewer.

http://www.robertoneil.com/TrainerRoad/Example_ParseFit2.html

This example also parses tcx files as well as fit files - since I only had the tcx file from TR for this latest workout (I didn’t record it separately on my bike’s computer).

I also updated the code in the link above to show two different ways to do the forward integration - the basic method has issues if the speed goes to 0 (the issue being a divided by 0) - it also tends to get erratic if you get close to zero.

But if you use this equation you can do all the forward integration bits with one equation and not have that divide by 0 and other issues:

See the code in the link above to see it used and compared with the basic steps for forward integration as well.

2 Likes