This discussion has been locked.

You can no longer post new replies to this discussion. If you have a question you can start a new discussion

Edge 1000 "time to next" is completely wrong

"Time to next" is consistently wrong by a huge margin. "Distance to next" is correct, so I have no idea how Garmin could be getting this so wrong. It seems to be calculated as if I'm going 80 to 100 mph. I assure you I have never biked that fast. This has been true for as many revisions of the firmware as I can recall. This is simple math: "time to next" = "distance to next" / speed. Since "distance to next" is reasonable, it's the speed that must be totally off. An instantaneous speed, my average speed over the whole ride, or even a random number generator would work better than whatever Garmin is doing now.

0 dpawlyk over 3 years ago

I believe the units use the time and distance in the file for that. That is, it worked like the virtual partner.

Some course creators don't add useful time data (what they use as speed is unexpected). (Originally, the files used for navigation were your records rides, which means that it used your speed on the ride).

Where are you getting the course from?

0 bertrem over 3 years ago in reply to dpawlyk

Thanks for the reply.

I typically get courses as FIT files downloaded from RideWithGPS (or pushed over directly from RideWithGPS via their IQ app).

I can't comprehend the rationale for using speed from a file. Whether historical or predicted, why would that ever be better than my actual real speed on that particular ride on that particular day? That may well be what Garmin is doing, but if so, it certainly doesn't make me think it's any less stupid on their part.

0 dpawlyk over 3 years ago in reply to bertrem

So, let's say you are riding at 15 mph and what's ahead of you is a steep hill.

It doesn't make much sense to use your current speed in that case.

The historical speed accounts for the terrain. The historical speed can also be useful for training.

RWGPS uses something like 10 mph (I believe) to add the time stamps (so the 100 mph thing is still odd).

0 bertrem over 3 years ago in reply to dpawlyk

I don't want to totally go down a rathole, but I think I'd actually prefer "time to next if you hold your current speed" over "time to next based on what you did two years ago". Either the next waypoint is close, in which case the terrain isn't likely to change a whole lot, or it's far in which case it may change, but it will likely change a bunch, and may well average out to something like your speed with a decaying average applied over the last quarter mile or so. I'm certainly aware that this is untrue if the slope is getting monotonically steeper, but at least as you get closer to the waypoint, the estimate will converge to the right answer, which is a heck of a lot better than what I'm getting now.

Moreover... in practice, I never really use routes with historical performance data, so I'm left at best with "time to next" based on whatever guess RWGPS made about how fast I may or may not ride. I'd most definitely take a locally average speed over that.

At the very least, I think that if the file is missing data or has bad data, the computer should at least fall back to a locally average speed.

0 bertrem over 3 years ago in reply to dpawlyk

and I should add... thanks in any case for the explanation. I'm pretty sure you're right about the root cause, as there are a number of other bits of evidence to suggest that the times embedded in the RWGPS files are completely detached from reality. At least now I know what's going on, which gives me a chance to fix it, even if I don't think I should be having to fix it in the first place.