RUT on XT2: Intended behavior? Low Priority? Garmin wants to hear from you.

[smfollen]

Yes RUT still occurs on the XT2, although there may be some improvement.

I believe that RUT had been reported to Garmin a couple years ago by JFHeath, and perhaps others. I first reported “zumo XT - Strange & Inconsistent Off-Route Behavior” (known on this forum as “RUT”, or “Weird routing behaviour”) to Garmin Product Support back in April of this year. A summary of the dialog that followed is below.

Garmin Support said: “I want to address your question surrounding whether or not this is intended or a bug. This is not intended. [emphasis added] However, we can not say that this is unexpected. The basecamp program was discontinued and no longer receives updates.”

Garmin Support requested “some pictures/videos showing the problem so we can get a better example of what is going on.”
I clamped an action camera to my handlebar, facing the zumo, and captured both the reasonable “saved route” behavior and the strange “imported route” behavior.

Garmin Support requested additional information, which I provided.

Garmin Support said “…due to basecamp being outside of software maintenance/and our lack of support for third party routing programs, we have ultimately concluded with closing the ticket. We can/will track other customers reporting similar experiences [empahsis added], but cannot promise any changes moving forward, and suggest to use the route planner on the device for the best experience as it is unlikely we will modify current products for use with 3rd party software.”
and
“It is more likely for changes like these to be made/considered with future releases, which can be expressed via our ideas submission page. Our engineering team reviews submissions on said page, for considerations when developing new products.”

I pointed out limitations of route planning on the small screen of the device. More importantly, I demonstrated the strange and inconsistent behavior without using Basecamp or any 3rd party app. I did so by creating a simple 2 point route on the XT, and later on the XT2 (see further below), saving it to the sd card, re-importing it and demonstrating the behavior difference between the two.

Garmin Support said “Since there wont be any changes to Basecamp or the zumo XT I am happy to offer you a one time complementary upgrade to the XT2.”

I accepted and, after upgrade, I re-tested and documented that the behavior still occurs on the XT2.

Garmin Support said” Thanks for the pictures and brief explanation, I have attached this information towards your case … Please give us some time to look into this again.”

After almost 3 weeks without word, and after doing some further testing, I provided this chart and footnote to Garmin support:

Comparison Chart.jpg (81.07 KiB) Viewed 235 times

Garmin Support said: I can totally understand how it can be frustrating for the way the unit is wanting to loop back to the entry point. I have heard back from the engineers of the unit and that is by design [emphasis added]. They would love to hear feedback at Garmin.com/ideas . We will continue to track any future reports from other customers besides yourself and will pass your feedback onto our engineers. [emphasis added]

I pushed back, telling support that I had been told by them that it was not intended behavior and that I couldn’t imagine such strange and inconsistent behavior was intended. I asked them to explain why they would intend behavior to be different for saved and imported routes.
I also provided a link to this forum, pointing out that I am not the only one frustrated by this zumo behavior.

Garmin Support said: “I am happy to try and reproduce the issue you're having when sharing a route via SD Card. This will help us determine if there is anything that can be changed to work better for your usage needs. In order for me to attempt to reproduce this please submit the route gpx file.”

I again clarified that the issue is related to any imported route, not limited to the sd card. I provided the requested gpx file.

Garmin Support said: “These devices are designed with the assumption the user is following the guidance given and not deviating. In those cases where I ignore the guidance and deviate from my original route, I end the current route and restart it for the optimal guidance. Would you kindly test this and let me know you experience?”

I pointed out that this could not possibly be true since automatic recalculation when going off-route was a specific feature of the zumo.

Garmin Suuport said: “Thank you for your reply. I have fully documented your report and will share with the team here.”
and
“Unfortunately, it doesnt sound like our devices are working for your needs. For this I apologize and I'm happy to offer you a refund of the original zumo XT you purchased so that you may find a better solution.”

I declined the refund, told them that the zumo was a very useful product overall and that I was only trying to make it a better product, for both myself and others.

Garmin Support said: “We are always looking for ways to improve our products and appreciate your feedback. These reports are triaged and reviewed in order of overall impact on our customer base. [emphasis added]”
and
“Feel free to submit any ideas you have that can or will improve the user experience via our website here, garmin.com/ideas. I also highly encourage sharing this link within the community should they also wish to share their ideas for improvements. [emphasis added]”

It would appear that the “Strange & Inconsistent Off-Route Behavior” (a.k.a “RUT”, a.k.a “Weird routing behaviour”) on the zumo XT and XT2 is not being fixed because it does not have enough “overall impact on [their] customer base”. In other words, perhaps, they have not heard from enough customers about the issue? (That may be true for other issues as well?)

Should you wish to help Garmin Support “track other customers reporting similar experiences”, their email address is: Product.Support@garmin.com

Should you wish to “share [your] ideas for improvements”, as Garmin requests, you can do so at: garmin.com/ideas


For those wondering how I've demonstrated the issue on the XT and XT2, I'll explain one of my two test routes. My test routes are the result of my own experience and testing as well as the insights provided on this forum by JFHeath and others.

My zumo is configured with automatic off-route recalculation, u-turns allowed and faster routes preferred. I start my routes using Closest Entry Point.

I'm using Basecamp here to illustrate, but an identical route was created on both the XT and XT2, then written to the sd card and imported, so that I had identical saved and imported routes on the device without using Basecamp or anything else.

The planned short and simple two point route:

TestRt2Orig.png (514.76 KiB) Viewed 235 times

The route just after selecting Closest Entry Point:

TestRt2CEPstart.png (498.91 KiB) Viewed 235 times

but I fail to make the left turn, instead continuing straight ahead. The zumo tells me to turn around, which initially is logical.

After missing the left turn at point D, I eventually turn left at point E and begin a long loop back toward the original endpoint. Note that until I reach point F, the faster route to the endpoint is to turn around. For both the imported and saved versions of the route, the zumo correctly tell me to do so.

After passing the "Tipping Point" at F, is where the variation comes into play.

Imported Route:
Both the zumo XT and XT2 continue to tell me to turn around until after point G, which is well past the point where it makes more sense to continue ahead:

TestRt2TurnAround.png (490.32 KiB) Viewed 235 times

Identical Saved Route:
The routing behavior logically changes at point F. Prior to F, I am told to turn around to follow the faster green route back, but after F I am directed ahead to follow the faster the blue route:

TestRt2RouteCalc.png (463.29 KiB) Viewed 235 times

You may notice the extension of the imported route at Point E that does not occur for the saved route. Prior to turning left at E, the zumo has extended the route past that point as it directs me to turn around. For an imported route, it seems to continuously extend the route. For a saved route, it seems to recalculated the route as noted in the table above.

[FrankB]

Very good and informative post. Thanks.

I do have a question. When you mention a 'Saved route' you mean a route (trip) created on the device. Did you ever modify an 'imported' route to a 'saved' using any of the methods described here: viewtopic.php?t=2301 and test that?
We (@jfheath and I) already established that the software still works on .trip 's created on the XT2, it would be nice if someone could verify that the routing fix also works.
If that method, that was created with the XT in mind, would still work for the XT2, it would be worthwhile changing the topic.

[jfheath]

@smfollen Thanks for this post - I skimmed it first thing this morning. I'll spend some more time gleaning through it and come back to you. You may or may not know that I was in conversation with technical support for about 3 years regarding the routing of the XT. They told me that they were working on the issues and it will take some time. I note that they now say that there will not be any changes to the XT.

Interesting that they want ideas from others - they have this in abundance from the evidence with the XT, and in spite of leading me up the garden path for three years, they have done nothing to address it.

I wonder if you would be prepared to share the name of the support people that you have been talking with ? Do it by PM. I'll share too.


Casual Observations on XT2

1. The indications are that the XT2 uses a better routing algorithm. Faster roads (which often resulted in a more prolonged route) do not seem to be selected in preference to a faster route.
2. Where a U turn is a legitimate request to make, there seems to be a limit on how many it requests it will make. After 2 or 3 it has then resorted to looping back using side roads (as if U turns were disallowed). It makes me wonder if me coining the term Stuck in a RUT, has had an impact here, making it less easy to recognise. If that is what they have done, they have missed the point. The RUT scenario is much easier to recognise of UT turns are disabled - becasue all of the 'Turn Back Loops' which are how the Zumo gets you to go back without performing a U turn, can be seen in the plotted route back.
3. Resaved routes coming back from Scotland on Wednesday worked very well. No issues at all in spite of taking an alternative route. But that is just an observation. It needs to be proved, and for that usual behaviour needs to be established.

I'll scrutinise your post later and post comments.

[smfollen]

@FrankB

I do have a question. When you mention a 'Saved route' you mean a route (trip) created on the device. Did you ever modify an 'imported' route

Yes the Saved route was created on the device. The imported route was that same route "shared" to the "memory" card and reimported.
I have not yet tried to filp the mimported bit, but I will and report back.

[smfollen]

@FrankB

OK. I tested it today. Yes, flipping the mImport bit does work for the XT2. With the bit cleared on an imported route, the off-route behavior becomes that of a saved route.

[FrankB]

With the bit cleared on an imported route, the off-route behavior becomes that of a saved route.

Very good news. Thanks for testing.

Will update the docs accordingly.

[jfheath]

@smfollen - Just cleared my desk, head and other tasks to do (including on here) to go back and read your post.

That is comprehensive enough !

I have a link somewhere on a Garmin help page, which says something to the effect that initially, you can expect the Zumo to want to turn you back - beut eventually it will calculate another way to reach the next route point. I know that I quoted it in an email to support, I alos think that I posted it on here. Now - how to find it ...... ?

Garmin give me the impression that they are not so keen to acknowledge that a fault exists, or putting effort into fixing it when they have so many other' customers who are not making complaints. Closing the ticket; Giving money back; ignoring emails - all seem to be standard behaviour from what I have experienced. But the tech support people are very pleasant about it. There must be a company policy that dictates what they can and cannot do.

There's one thing that I noticed about your route. Using Closest Entry Point. I tried this a coupe of times - but becasue I don't know exactly what it is doing and I need something that behaved the same way for any route - I adopted a route with a start point that I would definitley travel through and an additional route point that I could skip. The skipped route point was there simply to make the Zumo recalculate the imported route - my belief (still) is that the recalculation makes the route behave like a track that has been converted to a trip - so that it will:

• Go for the closest point back to the original route, rather than find a new way to the next route point.
• Ignore (ie delete) route points from the route if you miss a turn that is heading towards it.

I wanted something that always did the same thing - so that it could be reproduced easily.

The thing that spring to mind in your test is that you don't know where the selected closest entry point is located. That point could be treated as the start of the route, and if it is just after the left hand bend heading south, then by going straight on at the junction, you will have failed to go its selected start point !

That 'just after the junction' is a tendencey that I have seen on the XT - if you change a Via Point to a shaping point int he trip planner, it tends (ie often but not always) to place the shaping point onto the road that is the faster road between the route points on either side. And it places it just after the junction.

The 'always going back' to the point of deviation behaviour that we have seen with RUT is actually an incorrect statement that I made earlier on.
Indeed that is what it does if U tunrs are allowed. IN fact, it is finding the closest point of its new route, and if it has justa sked for a U turn, then the closest point is the section of route that it has just plotted heading back in the opposite direction.

If you turn off U turns - ie do not allow them - then it is forced to look further ahead to find a 'turn around loop' - eg by using side roads. On my favourite test route, there are very few of these opportunities, and at one point it had to look 7 miles ahead before it found a side road - and that side road led to the original faster route - so it headed for that.

But turning off U turns hides that something is going wrong. On one route I had missed a Via Point (In fact, I hadn't - I'd approached it from the other direction and it didn't recognise that I had passed straight through it) - it was trying to take me 15 miles to a turn round point and then 15 miles back. I have recorded this behaviour. I don't think I mentioned it on here, or to tech support. At the time, they were still trying to reproduce the fault using the XT simulator !!

The XT2 seems to limit the number of U turn requests that it makes before using loop back opportunities. I have yet to confirm it (I have seen it do this just twice). That may be Garmins response to people reporting the RUT behaviour, and someone, somehwere not quite grasping what it means.

[jfheath]

Found it.

The same information is provided in all on-line manulals for the Zumo 590, 595, XT and XT2.

https://support.garmin.com/en-GB/?faq=N ... tab=topics


Click the image - I haven't reduced its size. You may need to save it to be able to read the screen shot - but the link above shows the page that I captured. Unless they change it.

Expected XT2 behaviour.png (541.09 KiB) Viewed 99 times

It refers to an active route - and then says - if you have selected a destination and tapped Go !. I believe that method does exactly what it describes. But an active route could also be a stored route in trip planner - from a gpx file from elsewhere. So this doesn't actually clinch it, but its the best we have got on how it should behave.

Edited to add another screenshot

Screenshot 2024-06-27 193503.png (80 KiB) Viewed 54 times

[smfollen]

@jfheath Thanks for the support page link and the comments. As usual, you bring up good points. You inspired me to do a bit more testing.

I adopted a route with a start point that I would definitley travel through and an additional route point that I could skip. The skipped route point was there simply to make the Zumo recalculate the imported route - my belief (still) is that the recalculation ...

OK, so I approached my same two point imported test route by going straight up the road from before the start, selecting the start point rather than CEP.

TestRt2Map.png (550.96 KiB) Viewed 58 times

TestRt2List.png (93.19 KiB) Viewed 58 times

TestRt2Start.png (73.56 KiB) Viewed 58 times

It appears that when I selected the start point as next destination, it calculated a route from my location to the start point and merged the 2 routes, making the combined route the active route.

TestRt2StartMap.png (785.53 KiB) Viewed 58 times

After passing through the original planned route start point, I turned right to go off-route.

TestRt2RightTurn.png (828.01 KiB) Viewed 58 times

The same RUT behavior occurred.
Side Note: from the above screen shot, it appears that once I passed through the original planned start point, the XT2 dropped the merged part from the active route, keeping just the original planned route as active.

The thing that spring to mind in your test is that you don't know where the selected closest entry point is located. That point could be treated as the start of the route, and if it is just after the left hand bend heading south, then by going straight on at the junction, you will have failed to go its selected start point !

So going back to the CEP approach, just before selecting a "next destination", the route looks like this.

TestRt2MapBeforeCEP.png (496.49 KiB) Viewed 58 times

Just after selecting CEP, but before I began to move, the route becomes

TestRt2MapAfterCEP.png (577.83 KiB) Viewed 58 times

The XT2 appears to have selected the intersection ahead as the entry point to the original planned route, calculated a route from my current location to that point, merged the 2 routes together, and dropped the now irrelevant beginning part of the original planned route. The start point of the active route appears to be my current location. This route has only start and end via points (at least as it shows on the map). There are, of course several hidden or ghost points. I would expect one of those to be right at the intersection.
You may recall my theory of how CEP works here: viewtopic.php?p=20792#p20792

Hopefully some of this is helpful. Your testing efforts are more careful and more complete than mine. You provide results where I offer theories.

[Stu]

@jfheath I have edited your post to add a better screenshot