Hi all,
David will be along in a moment to provide additional details, but I’ve just put 3 races together on Friday which will use the latest incarnation of PD4.
All found here: The at Home Cycling & Running Virtual Training App
Hi all,
David will be along in a moment to provide additional details, but I’ve just put 3 races together on Friday which will use the latest incarnation of PD4.
All found here: The at Home Cycling & Running Virtual Training App
Ok, so to kick off another round of PDv4 test events I would like to give a more detailed description of how the system works in order to avoid more guessing and speculation that leads to false information being spread.
For the ones that are not familiar with PDv4, essentially the goal is to improve on the current pack dynamics system to try and fix a long existing issue which is the “automatic” relay of riders at the front of a pack, even without actively putting effort to pull the group, which leads to excessive pack speeds.
How the system works?
The core change behind PDv4 is the application of auto-braking when travelling inside a group in order to reduce automatic forward movement. If for some this sounds strange, the idea is to mimic what also happens inside IRL pelotons where if you are inside a group a lot of times you have to tap the brakes so you don’t crash into the rider(s) in front of you.
Rules for the auto-braking
Auto-braking will be applied if:
So to put it in simple terms, if the system detects you are “relaxing” your power but your speed is above the rider in front in HIGH draft situations, it slows you down.
Other situations:
Double Draft
The previous system contained double-draft active by default. This time we decided to turn it off by default in order to have the option to turn it on or off. However, for the first few test events we will be setting double draft ON.
Visual Feedback
One natural complaint from previous tests is the lack of visual feedback. To improve on that we included a visual queue every time auto-braking is being applied when you are inside a pack.
The power number of the top left corner of the HUD will turn red whenever braking is being applied. That way you can decide your actions based on that:
This visual feedback can also be easily turned on/off, so if we find that it’s more harmful than good we can easily turn it off.
Other concerns
Is the auto-braking some sort of draft lock?
It’s not. After the last round of events, and from the feedback seen here in the forums there was some concern around this system, like if the auto-braking was some sort of “tight lock”. It’s not, and you will see that with the visual feedback of the red power numbers.
Besides, the previous version contained a bug that made the system much slower to respond causing a bad experience in a lot of situations. Hopefully that will be sorted now.
I’m doing an all out sprint to the finish, maybe I get braked?
If you are in a position where you have mostly a clear road or riders not in a tight group formation, that is almost impossible. Unless you are boxed in a tight group the amount of draft savings won’t be enough to trigger it.
Current limitations
Currently the downhill experience might not yet be the best in terms of the speed reduction we are looking for. We need to test and adjust accordingly based on feedback.
Or, maybe I could be wrong and it’s already good enough
Good info. It will be much easier to discuss when both sides know more about how it is implemented. Less guessing. I’m looking forward to more tests
The 38% percentage threshold you are referring to - is that the same number (Draft) we can see in Sauce4Zwift?
Good question about the draft percentage because I think in a sprint finish situation, all of these criteria could be met. High speed, therefore high draft (according to Sauce), while having a higher speed than the bike in front of you, and decreasing power because you launched your sprint too hard and are fading slightly. Sort of seems like a recipe for getting auto-braked based on the described criteria.
That said, @DavidP I thoroughly appreciate the full description of how it works and look forward to testing it!
The 38% percentage threshold you are referring to - is that the same number (Draft) we can see in Sauce4Zwift?
No, that’s not the one. I believe Sauce shows a measure of total draft. But surely they are correlated, just not the same number.
@DavidP, thanks for all the work you and your team have been putting in to improve the user experience, as well as being so responsive to feedback. I’m really looking forward to Friday’s test.
Quick question about the power dropping below the last 10s average. Is that a percentage below, or is it absolute? Just wondering because of sprints. The benefit, it seems, will be to stifle the riders who love to do the “pulse and glide” BS.
It’s a configurable percentage below. Currently it’s set at 1%.
How do you handle situations while trying to grab back onto a blob as they stretch out? This was a huge problem in the first round of testing. Below are the criteria and my comments - The scenario is you are going all in to catch a pack that is 6-10-15m ahead and crumbling. So in the scenario where I am trying to grab a pack that is slipping away I was hitting the full scenario of auto-braking and just getting ripped out the back. You could visually see my speed drop while I was out of the saddle at 500+ watts. I think there needs to be some threshold of power to overcome the autobrake in this scenario.
EDIT _ This autobrake could also happen in a long sprint. If you sprint > 10 seconds and fade power then it assumes you are relaxing and will brake you if you are catching the wheel in front of you.
There is a fundamental difference now:
AND your speeds exceeds the speed of the bike in front of you
This part was not working well before, causing a lot of weird behaviours. That effect you reported shouldn’t be the happening this time, and if it is, we need to go back to the drawing board.
My draft is higher because I’m still in the group of riders stringing out the back.
Besides, when you are in single file, it’s difficult to reach the necessary draft thresholds. You need to be in a more tight group.
Thanks for the additional feedback. Hopefully the tweaks help this scenario.
as you know the website events interface is garbage… what route is this on?
I see it is one lap, 25 miles… picture looks like Neokyo?
Thanks!
Makuri 40
wouldn’t it be great if you didn’t need to look at a 3rd party website to find that crucial information
Wonder if anyone has mentioned this before
smashfest out the gate then to hold the main group uphill for the first few k
Oh good, it’s not just me, I was wondering where the route info was from that link - spent about 5 mins looking for it before giving up - Makuri 40 is a great route, some good opportunity for me to get dropped multiple times Will see if I can make the 11am PST version of the ride.
Glad to see more test events on the calendar!
Very excited to see how this UX element works, I can see this making racing much more engaging actually, and help people trust the draft a bit more, and make more explicit decisions when to move up the pack - will be fun to try it out. Not sure if you’ll eventually run into accessibility issues from folks who have certain color blindness - you might need to bold the numbers when they go red (or have the numbers go into a different font -italics- or something etc…) before it goes fully live if that does turn out to be a problem, but either way it seems like a good thing to try out.
For the colorblind, instead of the red numbers there could be an auditory cue…like Matthew McConaughey saying “alright alright alright” or something equally non-intrusive.
Thanks for the very helpful post and the addition of the visual cue.
One question I have; in the previous iteration I believe there was a rule that autobraking would never be applied on an incline above 1-2%. Is that rule still present, or is the draft% tied to gradient?