Time behind/ahead formula and math

The Archives Archived: Zwift Feedback
1

It seems to me that your time behind/ahead math doesn’t use the logically correct approach. Based on my observations, I believe when it is showing that I’m, for example, 45s behind someone, this is saying that I’ll get to where he is in 45s if I maintain my current speed. It’s pretty easy to see that this is the way the formula is implemented, because the time-behind yo-yos considerably as I (and the guy I’m chasing) change speeds (primarily due to changing gradients). While this seems OK, it is entirely counter-intuitive to anyone that that has asked this question on a ride: “how far behind Joe Blow am I?”. In reality, when we get that feedback from our stationary fans and support, they tell us how long ago Joe Blow passed this point in space. It may sound like it’s splitting hairs, but it really isn’t. Let’s assume Joe Blow is 45s ahead of me, and we’re going at exactly the same speed at any give point on the course (i.e. assume constant power/constant wind/no draft) - then the time-behind will always report 45s, which is true. If, on the other hand, my current speed is used to calculate time behind, then even though we are going exactly the same speed at any give point on the course, the time-behind will yo-yo, making it seem like I’m sometimes catching, and sometimes losing, ground. Honestly, to me, the approach of (time_behind = distance_behind / current_speed) is almost useless. What I would expect to see is that, given equal input powers, distance_between is constantly varying based on gradient, but time_behind is constant.

TLDR: Please don’t use speed to calculate time_behind or time_ahead! If you just use time, it will provide a much more stable metric, and a much much more useful feedback.

I can see that this will screw up the calculation for guys that are not moving; in theory, they haven’t yet passed any given point in space, so time_behind or time_ahead can’t be calculated. For truly stationary points of reference, it makes sense to use speed to predict when I’ll reach those fixed points in space. However once they are moving (and thus leaving breadcrumbs of what time they passed a certain point), then it should not use my speed to report time_behind.

Thanks,
Richard.

2

Totally agree, however running a realtime simulation of a rider w/X power over a stretch of terrain constantly for every rider in the list isn’t optimal or trivial, so it’s due to lack of time & priority vs other features right now.

Eventually it will work exactly as you describe.

3

Hi Jon,
Thanks for the reply. Actually, I wasn’t meaning to suggest to use a constant power method to determine time_behind, I only used that to illustrate my point. Instead (in one solution), you’d need to store time/location data for at least one lap for each user, and use that to make a time delta table for all the users. This universal table would then be adjusted to each user’s point of reference, to get absolute deltas to/from each other user.
Having said that, I do believe this also isn’t trivial. I’m glad to hear it is in the works; it will be hugely beneficial to have a rabbit to chase, where a reduction in time_behind actually means I’m catching, instead of meaning I’m probably on a descent and the rabbit is probably on a climb…
BTW, the Edge 500 uses the same formula (of distance / current speed) to calculate time_behind in course mode.