Bug on climb pro

aweatherall said:

rider position freezing is due to the climb having to few track points.

Hi, I am not convinced anymore.

"having few track points", as we discussed extensively here, it's a matter of how much a track is linear or not. A straight track requires very few poins and it works ok. On this I see general agreement.

Then, the fact is not whether the tracks has many/few points per se, but how often the rider goes off track.

But this is something that can happen for many different causes. Riders can go off track because even if they do have a robust track file, they just want to make a shortcut; or to stop into a gas station; or, a very detailed gpx track can become obsolete because the streets changes, etc.

Since I don't many other users complaining on a failure like mine, I can only conclude that either my unit is faulty (I hope not), or a concatenation of unfurtunate events induced the malfunctioning. For example I may have asked a very complicated route to subsitute the older one, and this caused too much load on the cpu. Just an exampe, not meant to be an explanation.

Thanks. But just for completeness, do you own a 1030+? Because I see your answers on many different subtopics of different units...

The many tracks that many thousands of people use without issues (they work for both navigation and climbpro) have variable resolution.

That is, the tracks created using planning software normally have more points per distance in curvey places and fewer in straight sections.

The tracks don't literally need a point every 50 m to work properly. Aweathrall, given his level of expertise, must know that.

Yes you need fewer points on straight sections of road for navigation to work correctly.

The 50/60 meter distance was guidance that Garmin gave Strava/Komoot for their course integration to give better rendering of the elevation profile. As elevation is just plotted between the points you have you will end up with long sections joined by straight lines when there are few points.

The VP and ClimbPro positioning updates are driven by you passing through track points, similar to the way time ahead/behind on segments is computed.  If the points are a long way apart the updates are less frequent.

Useful info.

I realize that what works for navigation won't necessarily work for Climbpro or virtual partner.

But, if a file is not good enough for navigation, it isn't likely to be good enough for anything. That is, if a file doesn't have enough points for navigation, then it won't have enough for these other purposes. (But a file that has enough points for navigation might not have enough points for the other things to work well.)

The routes from RWGPS work fine with Climbpro. So, it would seem they are adding enough points (and not just the minimum needed for navigation). (I'd expect the courses from Garmin would work as well.) The planners might add more points than necessary for navigation to get virtual partner and climbpro to work reasonably.

Given that these files use variable resolution and they work fine for Climbpro, the resolution doesn't have to be "exactly every 50 m". The planners apparently add more points than necessary for navigation to get virtual partner and climbpro to work reasonably.

One of the benefits of Climbpro is seeing the changes in grade (which means having enough points). The route planners appear to add enough points.

Roberto Ena said:

For example I may have asked a very complicated route to subsitute the older one, and this caused too much load on the cpu. Just an exampe, not meant to be an explanation.

I think you're right. But all the problems you had on this tour are due to the lousy track. Every time you leave the track, the elevation graph and the climb pro graph freeze temporarily, because your position is no longer part of the track and therefore of the graph. After the track is found again, your position on the elevation graphs will be updated again. But after you were off course so often, the system probably gave up at some point and the climb pro graph has completely frozen.

For your next tour I would first check the GPX track in your program Adze,so that something like this doesn't happen again.

It appears Adze (https://getadze.com/) is a MacOS program.

An alternative for Windows and Linux (and MacOS) is:

https://www.gpxsee.org/

This is a file viewer (so, no editing).

Roberto uses Adze ( https://forums.garmin.com/sports-fitness/cycling/f/edge-1030-plus/263399/a-bug-following-gpx-track  ), so I suggested to check the next track with his program.

Makes sense.

Other people might be reading this and not be familiar with either of the programs.

First of all I would like to thank McInner1 and aweatherall for the support.

I realized I could look to the timing of the video to calculate exactly where the issue occurred.

This is the result.

"

"Video" is the location where the video was recorded, and the issue occurred.
BTW I was going south. Brown is the track I was following, magenta is my actual activity.

You see that the problem was that I was not following the track at all (so that having a brown track with different resolution would not have changed anything).

I don't know what the logic of the device was after I left "Scanno". I am almost certain that climb pro did give me few incremental steps from Scanno to the "video" location. But I won't put my hand in the fire.

Maybe it was relying only on the elevation? 

Maybe it recalculated the route?

If we assume that the display should increment only when you pass a point of the track, then I should not have received any update of the screen. I am more inclined to think that it was just relying on the elevation, because passing a point in a 2D space is a much more topologically complicated problem than passing a given elevation in one (vertical) dimension. So the first hypothesis fits better in my opinion but this is easy to test anyway on my next activity.

Now probably someone will think that this solves everything: I am not sure, because a de-tour is something very frequent for many riders, and it is possible that during a de-tour someone wants to change the final destination.
I don't think Garmin wants hit top device to freeze in any situation. Clearly, it does not happen so frequently, otherwise we should have many more complaining on this.

I think Garmin should look into it, but that's all I have.

PS: the "bug with gpx track thread" problem occurred somewhere else, not here.