Snap to route with loops of same route
Is this a known issue? Is there a better way of achieving what I’m trying?
Encountered this with two activities on different days. Running and walking on the same route linked below. I created a route that is a single loop around a city block.
When I repeat this route, it’s apparent that when the route “ends” track is no longer recorded until I’ve walked a fair bit away and them it connects the difference with a straight line. It doesn’t seem to be affected by whether or not I dismiss the route end notification. I’m use best GPS performance settings.
I was looking it up on the forums but only saw the attached thread on loops. Am I doing something wrong? The goal is to have a single looping route and then decide on the spot how many loops to complete instead of creating repeating loops on the route itself, as that thread suggests.
- I didn’t use snap to route on the first loop while running, so I had a complete track and then second complete track for the first snap-to-route run.
- every loop after that has a disconnect at the end point
- first loop on walking works just fine, subsequently disconnects.
- disconnect and reconnets are at same spots.
- I had slightly adjusted start/end of route hence slightly different disconnect locations between activities.
you can imagine it as a rail with start and end. the manual says that it follows the predefined route. so I understand that when the route ends it starts calculating the track by its own again or when you have a certain distance to the route it “breakes loose” from the route.
hence I think it is more or less by design and not an issue.
the question is, how would you let your watch know how many circles you would like to run around your block?
when snap to route was introduced, I thought it would be made for ultrarunners in order to reduce precision of the watch to save battery but have a precise track anyway. but in the manual it mentions the city.
not sure if it was planned to circle? but it would be worth to mention that in surveys
I believe that this is well-known and it was made like this by design…
I remember we were discussing this last year. https://forum.suunto.com/post/86839
I think that the current implementation makes sense - if I run a (one loop shaped) race in tricky environment (like cities where tall buildings make the GPS track noticeably worse), I don’t want any additional distance to be recorded at the end of my race when my GPS position might jump somewhere forward due to some signal reflection etc…
If I know that I will run several loops, I can always create a route containing all the loops. Or, at the end of the first loop, I can trigger snap to route navigation again from the navigation menu and it will track a new loop without breaking the “connection”…
when the route ends it starts calculating the track by its own again
I feel the issue is that apparently it just hard stops the track completely when the route ends. So it’s not that the track after the end of the route is not snapping to the route or is a messy track, bit it’s actually missing a chunk almost like the watch was paused. And it keeps missing the exact same chunk. I’m unaware what the logic in the firmware is but it seems to assume that when the route has ended I’m assumed to have stopped moving? So was curious if it was a fault of how I set things up.
You’re right about mentioning it in the survey, thanks!
@Umer-Javed When the route ends, track will stop until you move 100 m from that end… It is the very same logic as the original “snap to route” idea (track is snapped to route unless you move more than 100 m from it).
Snap to route is nicely explained in DC Rainmaker’s S9P review: https://www.dcrainmaker.com/2021/07/suunto-9-peak-gps-watch-in-depth-review.html both in text and (probably better) in the video…
@inkognito thanks for the replies.
Yes, Ray’s review of the S9P and snap-to-route (s2r) is a big reason why I finally decided to upgrade from my old A3P. That review placed the seed in my head and I finally pulled the trigger last month.
I’ll be sure to add this to the surveys. I imagine something along these lines is already in the works.
Definitely feels inefficient UX to expect users to manually create loops. Perhaps a better implementation is by having route types (out and back, vs closed loop, vs end to end, etc), to prevent the race distance issues. And s2r can adjust behavior based on route type. But again, I don’t know what’s happening behind the scenes.
Anyways, I trust there’ll be a solution in the future and will make note of this on surveys. Thanks for the information.