NOTE: I have cut (and edited) these two posts from a parallel thread, in the hope that people will find the topic more easily.
Richard
It's to do with the weird routing behaviour that happens with the XT under certain cirumstances.
It often manifests itself as repeatedly asking you to turn back - seemingly to a point where you left the magenta line. It also results in the active track log being fragemented into very short sections.
Because of the the U turn demands, I coined the term RUT - as in 'being stuck in a rut', and 'Repeated U Turn' behaviour.
As my tests continued I was able to pin down the nature of the behaviour and found out exactly when it occured, and crucially observed that it only happened with routes transferred to the XT from outside. It didn't happen to routes that had been created on the Zumo screen.
1. To make it happen you you have to be navigating a route that the XT has recalculated. This could be at the start, by choosing closest entry point, by skipping a route point. Once recalculated, any future deviation is likely to result in the XT trying to send you back the way that you came. What it is actually trying to do is to get you to go to the closest point of its route - which is often the bit of the route that it has just laid behind you !
If you turn off permission to perform U turns and the roads are such that it cannot find a different way to turn you back, then it can be seen that it is not trying to take you back to the point of deviation, but it is heading for the closest point on its original route. With no opportunity to head you back for about 5 miles, if it spots the original route 4 miles ahead, it will head for that. This behaviour can also be seen if you deviate from a track that has been converted into a Trip.
The best examples of this happening are when the XT calculates a route that uses faster roads, and (say) takes two sides of a rectangle to get you to the next route point. You deviate by taking the diagonal / direct route that is both shorter and faster. With a route like this that has been planned on the XT screen, the route will immediately recalculate to take the road that you are taking - because it is actually faster. It would be a mistake to think that just because the XT asks you to turn back, you have triggered the RUT behaviour. Unless you check it out, it might actually be faster to turn back.
None of this has anything to do with Via Points, Shaping Points or whether any of these were first created as waypoints. Closest Entry point does not aim for a route point in the route. It finds the point on the route that is closest to the XT's current position. Navigating a track that has been converted to a Trip - when you deviate it finds a new way to get to the closest point of the original magenta line. The XT has the ability to aim for the closest section of a magenta line. And this is what it is doing when this RUT behaviour begins. The point is that it shouldn't. It should calculate a new route to take you to the next route point in its list - which is what it does when the route ahs been created in the Trip Planner app on the XT. But when the route has been imported, and when it has recalculated mid-route, any future deviation seems to make it behave differently - as if it was using the wrong algorithm to perform the calculation.
The observation I made early on that it didn't seem to happen with routes created in the XT turned out to be key to the solution - but I had to prove it by being able to make it happen whenever I wanted and it not being some random event - like chosing a different route due to historic traffic data that is still stored in the maps, and which can affect routing on certain days and at certain times (as used by the 590). Once I was able to make it happen, prove that it was aiming not for the point of deviation, but for the point where it last asked me to turn back, I was able to say categorically that if the route recalculates, then at some future point in the route you deviate significantly so that it has to turn you back initially - then RUT behaviour will happen - but only if the route was not created on the Zumo itself. If it was, it will never happen.
With that information a member spotted that routes were divided into Imported and Saved when displayed on the XT screen, FrankB (who had been following my tests and commentary, and had performed a number of his own) went searching through files in the System folder and found flags in some Trip files that were labelled 'mImported'. So more tests. By changing the value of that flag using a Hex Editor we were able to prove that imported routes that had previously got stuck in a rut, now worked correctly on the same test routes. Other people have been able to back up these results. FrankB then developed a program to make the editing of that data easier to handle.
All of this information has been passed on to Garmin. Tech Support have passed it onto the team in the USA and we are waiting some action.
I don't know whether it would help or hinder progress if other people reported the fault. But please, if you do, make sure that you are talking about the same thing !!
Richard
It's to do with the weird routing behaviour that happens with the XT under certain cirumstances.
It often manifests itself as repeatedly asking you to turn back - seemingly to a point where you left the magenta line. It also results in the active track log being fragemented into very short sections.
Because of the the U turn demands, I coined the term RUT - as in 'being stuck in a rut', and 'Repeated U Turn' behaviour.
As my tests continued I was able to pin down the nature of the behaviour and found out exactly when it occured, and crucially observed that it only happened with routes transferred to the XT from outside. It didn't happen to routes that had been created on the Zumo screen.
1. To make it happen you you have to be navigating a route that the XT has recalculated. This could be at the start, by choosing closest entry point, by skipping a route point. Once recalculated, any future deviation is likely to result in the XT trying to send you back the way that you came. What it is actually trying to do is to get you to go to the closest point of its route - which is often the bit of the route that it has just laid behind you !
If you turn off permission to perform U turns and the roads are such that it cannot find a different way to turn you back, then it can be seen that it is not trying to take you back to the point of deviation, but it is heading for the closest point on its original route. With no opportunity to head you back for about 5 miles, if it spots the original route 4 miles ahead, it will head for that. This behaviour can also be seen if you deviate from a track that has been converted into a Trip.
The best examples of this happening are when the XT calculates a route that uses faster roads, and (say) takes two sides of a rectangle to get you to the next route point. You deviate by taking the diagonal / direct route that is both shorter and faster. With a route like this that has been planned on the XT screen, the route will immediately recalculate to take the road that you are taking - because it is actually faster. It would be a mistake to think that just because the XT asks you to turn back, you have triggered the RUT behaviour. Unless you check it out, it might actually be faster to turn back.
None of this has anything to do with Via Points, Shaping Points or whether any of these were first created as waypoints. Closest Entry point does not aim for a route point in the route. It finds the point on the route that is closest to the XT's current position. Navigating a track that has been converted to a Trip - when you deviate it finds a new way to get to the closest point of the original magenta line. The XT has the ability to aim for the closest section of a magenta line. And this is what it is doing when this RUT behaviour begins. The point is that it shouldn't. It should calculate a new route to take you to the next route point in its list - which is what it does when the route ahs been created in the Trip Planner app on the XT. But when the route has been imported, and when it has recalculated mid-route, any future deviation seems to make it behave differently - as if it was using the wrong algorithm to perform the calculation.
The observation I made early on that it didn't seem to happen with routes created in the XT turned out to be key to the solution - but I had to prove it by being able to make it happen whenever I wanted and it not being some random event - like chosing a different route due to historic traffic data that is still stored in the maps, and which can affect routing on certain days and at certain times (as used by the 590). Once I was able to make it happen, prove that it was aiming not for the point of deviation, but for the point where it last asked me to turn back, I was able to say categorically that if the route recalculates, then at some future point in the route you deviate significantly so that it has to turn you back initially - then RUT behaviour will happen - but only if the route was not created on the Zumo itself. If it was, it will never happen.
With that information a member spotted that routes were divided into Imported and Saved when displayed on the XT screen, FrankB (who had been following my tests and commentary, and had performed a number of his own) went searching through files in the System folder and found flags in some Trip files that were labelled 'mImported'. So more tests. By changing the value of that flag using a Hex Editor we were able to prove that imported routes that had previously got stuck in a rut, now worked correctly on the same test routes. Other people have been able to back up these results. FrankB then developed a program to make the editing of that data easier to handle.
All of this information has been passed on to Garmin. Tech Support have passed it onto the team in the USA and we are waiting some action.
I don't know whether it would help or hinder progress if other people reported the fault. But please, if you do, make sure that you are talking about the same thing !!
Last edited by a moderator:
