"on course" constant alerts

following

In my opinion small discrepancies between the course and the actual GPS positions should not make it go off course in the first place. Often when I get an off course warning I am standing right on the right trail and the map shows me on top of the course too. Then a few seconds later the watch tells me I am back on course.

So the root problem is that the tolerance for going off course is very low to start with. By the way, this issue existed in Fenix 6 too. If you search Fenix 6 forum you'll find a number of similar posts. Also I strongly suspect that this issue has the same underlying root cause as forums.garmin.com/.../fenix-6-7-bug-nearly-100-failure-rate-when-tracking-longer-strava-live-segments-on-mountainous-terrain.

I created a post awhile back about this very issue and it's still frustrating.  As mentioned, the tolerance just isn't set high enough.  Saying that, it shouldn't matter what the tolerance is set at if you have course notifications set to OFF.  What's the purpose of having those settings if they don't work.  When I'm on course running a 100-250 mile race and I know I'm on course I don't need my watch chiming "off course / on course" all the time. It's wearing down the battery and I know I'm on course.  It's especially bothersome when on switchbacks having it go off constantly.  

I have no idea why this has yet to be addressed.  It's ridiculous.

They need to give us an adjustable sensitivity setting. Sometimes you want to be informed immediately if you go even a little off-course, and sometimes you don't want to be warned at all unless you're very, very far off course. Or somewhere in between.

Garmin's off-course sensitivity threshold is a mystery, and it can't be changed.

Worthwhile sending this in as an idea on their official idea submission page, seeing as they usually don't monitor all the threads here:

https://www.garmin.com/en-US/forms/ideas/

C.sco said:

Garmin's off-course sensitivity threshold is a mystery, and it can't be changed.

Based on my observations it isn't a simple threshold. Sometimes I am pretty far off course but that doesn't trigger an alert. And sometimes it triggers when I am less than 10 feet (3 meters) off course. I think there is some sort of complicated algorithm that takes the direction and possibly speed into account. That's why it often triggers at sharp 180 degree turns. Also sometimes it triggers when I stop to adjust laces. But it is less likely to trigger when I am running fast. Perhaps it triggers based on time (number of seconds) off course rather than a particular distance. That's why sudden changes in speed may incorrectly trigger it. 

And I agree that there are two different issues on top of each other:

1) Navigation goes off course way too eagerly in some situations. It goes off course only to go back on course a few seconds later. The same applies to live segments tracking, but in the case of segment tracking it can't recover and go back on segment. 

2) The alert setting is ignored. 

silentvoyager said:

It goes off course only to go back on course a few seconds later.

I've observed that many times as well.

I think it would be helpful if the on-course and off-course thresholds were different from each other. For example, an off-course alert is triggered when 50m off-course, and an on-course alert is triggered when you're back to within 20m of the course. I think that would reduce the annoying "on course, off course, on course, off course, on course, off course" cycles that we all sometimes experience.

If you look at the thread about the live segments that I linked above, I documented it going off segment while I am no further than a few meters from the segment track. I have measured that on Caltopo. My examples show my track vs. the exported segment track. I think tracking courses is exactly the same. So if there is a threshold it must be very small. But in other cases it is perfectly fine with me running on another side of a street at least 15 meters away from course. I suspect as long as you run parallel to the course it would not trigger off course alert. 

I need to do some further experiments to understand this algorithm better but it must be something more complicated than a simple threshold.

That's probably true.

I should add that going off course isn't just a temporary inconvenience. I does messes up things. I messes up Pace Pro which gets reset every time when a watch goes off course. I may also mess up course elevation profile and tracking of elevation gain.

For example this this example from my yesterday's trail run:

What happened here is that the watch went off course (incorrectly) in a beginning of a long mountainous training run, a large part of it was on an out-and-back trail. What happened next is that when it went back on course it did somehow latch to the return part of course. After that for the remainder of the run the elevation profile was ruined. It got stuck at that point on the return path and it didn't track the remaining planned elevation gain, which was kind of a big deal during that run. You can see that it is showing 160 feet remaining climbing. That is a big lie because at the point when that happened we still had about 5000 ft of climbing ahead of us.