Navigating track compass points back to prior point already navigated passed

I have seen this behaviour.

Add a track to the device. Find, select the track, view map, then "Go".
Compass page needle is correct... as each point is navigated to it seemlessly changes bearing to indicate direction to the next point on the track.
Then at some random point it gets confused, and despite your current position being on the track it now points back to some prior point on the track.

In an experiment over 5km I did to investigate this, I passed within 5m of a corner it was navigating to, but approximately 2km later, the compass was indicating I should be travelling in the opposite direction to the correct direction of travel, apparently BACK to the random point it missed. And at that 2km point I was still on the track. i.e. It seemed to have missed updating the bearing when I passed within 5m of the corner it was previously navigating to.

This appears to self correct if you stop navigation and repeat the steps at the start of the track. (Find, select, view map and Go)

Have I missed a setting somewhere?

Is this normal?

Anyone else seen this behaviour?

- Carl.

0 KiwiGPS over 3 years ago

Sorry this is no direct help but I saw the exact same thing when working in BaseCamp 4 years ago on a route converted (using BaseCamp) from a track that had been first made in Google Earth and sent to me. The only way to find the turn backs to previously traveled parts of the road was to review the route and carefully watch the direction of travel arrow for the 180 degree changes in direction. I did not try the finished, edited route in the zumo GPS but just sent it to the customer however did not hear of any issues.

0 twolpert over 3 years ago

I have never seen this behavior when I could not explain it based on the topology of the route. This is not to say that there is not a bug. Just that I have not seen it personally.

What iR units attempt to do is to point you to the NEAREST point on the route which is "ahead" of where the device thinks you are. The problem arises with "nearest". Depending on the topology of the route and your location, it may be that the nearest point on the track (the only one that the device believes to be "in range") is actually a location which you have previously passed. If you actually navigate to that point, the device SHOULD pick up the route from there in the correct direction. If it does not, then there really is a problem.

If you can duplicate the behavior, open a support ticket. Support will want the .gpx file, and (at least) the coordinates where you were when you were directed "backwards", and the point towards which you were told to navigate.

Note well: The so-called TracBack function does not behave this way. When you engage TracBack, you MUST navigate the entire reverse route from end to beginning. If you engage the function somewhere in the middle of the route, you will be directed back to the end, then over the route to the beginning. Yes, it's stupid. No, nobody knows why this works differently. But it does (or it did, the last time I tested it).

0 SleeplessAtKnight over 3 years ago in reply to twolpert

Yes. I've seen that behaviour using TracBack too. The failure does not always reproduce on a track... I'll see what I can produce by way of a gpx when it occurs - save the activity at the point where the navigation goes wrong perhaps?