Dynamic pacing has little to do it, you can see it on Tempus Fugit all the time as well, and even the dynamic pacing power changes are too minute to cause the kinds of effects I’m talking about. Somehow the draft just seems to creates these strange wormholes where two riders’ positions relative to one another change by 10–20 m as a matter of seconds. In a large pack, of course, these things add up, and make life unnecessarily difficult at the back of the pack (for anyone), unless you react to these things as early as possible (i.e. the aforementioned racecraft/drafting ability).
2 Likes
I wouldn’t dismiss dynamic pacing as the culprit… At least not as an exacerbating force. If you remember back to original Coco (then Cara) on Tempus Fugit, it was much more smooth. I could lock into a10 watt range and hang there endlessly. Yes lower wattage than my Yumi example, but the surges were limited.
I take your point that the power readout doesn’t seem to reflect those surges so it doesn’t seem to be correlated, but how else is this disparity between pace partners and robopacers explained?
I don’t remember the timeline of PD3, though so I might be making a faulty conclusion.
I do remember such a time as well, but I think it was because that was back in PD2 days. The surging started before dynamic pacing was introduced.
I’ll cede that point, I couldn’t remember what PD model we were on.
I’m 58 kgs. All rides with Yumi in December:
3 hours @ 161w, 2.77 w/kg
2.5 hours @ 160w, 2.75 w/kg
2 hours @ 156w, 2.68 w/kg
3 hours @ 164w, 2.82 w/kg
4 hours @ 150w, 2.58 w/kg
2 hours @ 154w, 2.65 w/kg
However, I assume we’re smart enough to disregard anecdotal evidence and look at hard data.
Let me state again. Your pace on the flat at 3 w/kg is equal to Yumi’s 2.7 w/kg, all else being equal.
Luck makes Zwiftinsider article on the steady state w/kg isn’t loading right now.
Your 3 w/kg is equal to Yumi’s 2.6 w/kg at equal height. Add in the height penalty and the bot is at 2.7 when you’re at 3.
I assume we are all smart enough to ignore someone’s personal data if it dismisses other data. Also smart enough to understand that if real world experiences don’t align with the “research” there is something wrong with the conclusion.
I don’t waste time with condescending and dismissive posters using internal validation to dismiss the experiences of others (I’m not the only one).
Enjoy your day, we are done here.
Sarah, my intention was not to be condescending or dismissive. I apologize if you felt offended.
That’s a good question. What do you think? Should we brake riders when you are doing 0w (and most likely super tucking) and overtaking other riders near the front
or because you are super tucking is a bit bizarre to auto brake?
Sack off supertucking for anyone unless you have 0 draft, and include autobraking (churn on descents is a big problem).
Don’t engage supertuck unless rider has had 0 draft for at least 2 seconds.
1 Like
This is a common occurrence with Robo Pacers they surge at random times on flat sections which has never been addressed for whatever reason.
1 Like
I think we should see how things go with the new pack dynamics before we start tweaking the downhill speeds. I’d like to see how the downhill speeds are affected with the global PD4 dynamics first, it may be that we don’t need to address the descending once PD4 is working well.
Both you and Sarah have made some excellent points that I think contribute well to the conversation. I’ve been enjoying what you both have brought forward for discussion. All of which I think has helped us all in our understanding of what’s going on or at least helped determine which questions need to be asked.
1 Like
In that particular race the 2nd place rider was already on his 3rd ride of the day (at 10:45am!) and l guess might have been more interested in racking up distance for the Rapha 500 challenge than producing a sprint finish in an insignificant race. But in general terms, young children can be impressively quick.
I would rather it be some modifier to drag savings but ultimately the effect is to reduce churn, right? I assume it won’t be pack or collision detection. Triggering the slowdown based on sudden reduction of draft benefit instead of reduction of power output is the way to look I think. I also think if you/we can crack the churn issue in a 0w descending group that the solution will be applicable to everything trying to be accomplished with no more than minor tweaks.
I was trying my best ha ha! I was beaten fair and square!
1 Like
Any way you look at it, it was an impressive performance. Though I frequently see references that raw power is pretty much what matters on flat courses, and w/kg (relative effort as term has also been used) isn’t as important. I’m not really seeing it in this example.
Interesting idea. Would give the light riders who can blast a climb an actual advantage instead of guaranteed drop on the descent. Just have to figure out how to apply it to a big group as the people on front won’t have draft.
Those people on the front can still aerotuck. Don’t mind that.
This is already a feature request BTW. I put it in separately because better to focus on the churn in this thread:
I think that alone would reduce descending churn. Front row tucks, everyone behind gets draft benefit but no tuck and would be a lot more stable.
1 Like