tombarrington wrote: ↑Fri Aug 11, 2023 4:26 pm I know there are a number of threads on the RUT topic. Is there a sense of how this method fixes the problem? I've taken to being answering no to the recalculation prompt but it would be nice to go back to trusting that recalculation.
The designation of the route as either 'saved' or 'imported' seems to be the single thing that causes the Zumo to behave differently in its routing. The mImport byte in the .trip file seems to change the designation.
RUT was an acronym I came up with for Repeated U Turns, but it was more related to the fact that the XT seemed to be in a neverendung loop of insisting that you rejoin the original route. Stuck in a rut, so to speak.
It's a poor phrase because people have latched onto it and blame their own errors on the RUT behaviour. Eg setting off without visiting the start point will always demand repeated u turns. That is not RUT behaviour. That is user error.
If you deviate from the route, then you can expect the XT to want to turn you round, because that is the quickest way to get you to your next route point. Only when you have reached the point where the way ahead is faster than turning back, can you start to believe you are in a RUT loop. Fortunately, there are other symptoms that always occurs in the RUT scenario, which doesn't occur with normal recalculation of the route.
For all of my tests, I started out with a clean XT. This is because the XT builds up a profile of your favourite roads and riding speeds, and uses those when it calculates the route. That can affect the results. So I always reset my XT for each test and I never noticed that there were two categories of routes - saved and imported. Mine always showed up as 'imported'.
So someone spotted that and @FrankB had found the mImport flag in the trip file.
So two questions remained
Did changing the mImport flag make the route appear in the 'saved' list. Yes it did.
So did the 'fixed' route - ie imported, but with its flag changed - did that then behave like a route created on the XT.
I was probably in a unique position to be able to confirm this having tried, tested and documented many different tests, and observed and recorded all of the symptoms of a route that displayed RUT behaviour.
And the answer is - yes it does fix it. It makes the route behave exactly like the route created on the XT. Where previously the XT would recalc the route back, it immediately calculated the way ahead when I went off route. And I checked all of the other tell tale signs for RUT behaviour as well. None of the other symptoms were present.
So the same behaviour has been checked on my other test routes with the same result. Of course I get u turn requests, but they are valid. It is trying to find the faster route, but the requests are not relentless, and well before the tipping point - the point where the XT itself will calculate the route I am taking, rather than the opposite direction - the XT starts to calculate ahead - seemingly placing importance on my direction of travel, rather than just my position. More importantly, the other key symptoms of RUT behaviour were not present.
So how does it fix the problem ?
The problem only exists in imported routes. It seems that for imported routes that when it has to recalculate, a different process may be employed. To me it appears to be similar to that used for when a track-trip is being navigated - with no shaping and via points in the track trip ( a trip created from a track) the xt heads for the closest entry point of the route. This appears to be what RUT behaviour is doing - the closest point nearly always being behind you.
Changing the route to be a saved one seems to be all that is necessary to change the behaviour of how the route is recalculated.
All supposition and theory, but I do have the evidence on which these suppositions are based.
As far as I am concerned, the fix works completely. I have been checking out the on screen resaving if the transferred route, and this too has worked every time.
