Zumo User Forums

I'm starting a new thread for an old topic in order to try to focus on the information that we have gleaned so far.

I came across this weird routing behaviour way back in January, and I raised the issue with Tech Support and exchanged a few emails with Tiphaine to provide extra details. It's to do with the issue that sometimes arises when deviating from the plotted route - the Zumo sometimes calculates a new route towards the next route point, but sometimes it is determined to navigate you back to the point where you deviated from the route.

My original description of the problem is described here - but I will provide a brief summary below.

The problem:


The left hand picture shows the route that The XT want to take me - from Ribblehead to Settle - Via Ingleton. B6255 and A65.
The red route shows the direction that I intend to ride. So I deviate just after Ribblehead - and turn south - the B6479.

The right hand picture shows what the XT is trying to do - the bike and the green flag are approaching settle (heading south). It is insiting on taking me back to Ribblehead, turn left and then along the A65. It has been doing this, telling me to U-Turn ever since I turned south at Ribblehead.

The only route point of concern is a Via Point to the south of Settle. There are no other route points.

On their help pages here, Garmin say :

If you are driving with an active route (you have entered a destination and touched Go!) and decide to take a shortcut, the device will recognize the new path and recalculate the route using that change. It may try to take you back on the original path at first but typically will adjust to your new route as you progress.

But sometimes this does not to appear to be happening. Instead it initially calculates a route to get you back to where you first deviated. And it seems to do it - not by remembering that original point, but by marking each point where it tells you to go back and navigating back to that.

Like laying a trail of breadcrumbs to find your way back out of a Maze. Hence the title of this thread.

I have no wish to repeat the dicussions that have already taken place. I'm just setting the scene. The issue is - When does this behaviour show itself? When does it not happen ?

To test this it needs a layout with two possible routes - preferably open roads with possibilty of getting from one to the other. The satnav will prefer to take one road - seeing that as the faster option. The test will ignore the road that the satnav has plotted and take the other. No route points plotted between where the two roads separate and where they rejoin - bit some tests will have the option of adding route points (via or shaping) either before or after the test section.

Using just the XT

1. Use XT to select destination. Say Go ! Deviate from the route 22-10-22 XT behaves 'properly'. When deviating it sometimes expects me to go back, but as I continue it soon calculates a route using the road ahead. This is the typical behaviour on 590 routes. I've tested this a few times on different routes with the same result.
2. Use XT to select destination. Say Go !. Immediately add another point before the roads separate. Say Go ! Add it as Next Stop. Make sure you can pass through it. Then deviate from the plotted route.
3. Use XT to select destination. Say Go !. Immediately add another point after the roads separate. Say Go ! Add it as Next Stop. Then deviate from the plotted route.
4. As above but with shaping points.
5. Create a few Favourites / Stored locations by using the map. Place them before and after the test roads separate and rejoin. Then use Trip Planner to build a test route from the Favourites (they will be places as Vias), load it in, run it and deviate from the plotted route in the test section.
6. As above, but skip one of the points before the test section

[Edit]
I've removed the later suggestions for tests. I performed some tests but then things started to change and I am not certain why. At present my XT is behaving as I would expect and like my 590 still behaves. The details of these tests and the results are posted in later posts.
I also have a case open with Garmin tech support awaiting the results of some suggestions that they made.
[/Edit]

Regarding the Route from Hawes to the A65 south of Settle as shown in the maps above (and post#1) Hawes isn't shown on the map - it is about 8 miles NE along the road that disappears off the top centre of the displayed map.
.
The calculated route takes the B6255 SW to Ingleton before turning SE on the A65.
I choose to turn left at Ribblehead and take the B6479 SSE to joint the A65 South of Settle.
Both routes pass throught the same route points and there are no other route points involved.

When I deviate from the plotted route by turning left at Ribblehead, the XT repeatedly demands that I turn back to the junction and follow the plotted route, forvever - until I have got to within 2-3 miles of where the two routes meet again.

The same thing happens if I place a shaping point just after the start, and just before the end.
The same thing happens no matter which software I use to create the route.
It happens whether the XT has calculated the route or whether it has initially been calculated by Basecamp.

But today, I simply selected my home from the 'Where To ?' menu when I was at the original start point in Hawes. It calculated the same route as before - going straight on at Ribblehead, and heading towards Ingleton. I turned left at Ribblehead as before. There was no complaint. No demand for me to turn back. It was wet - there was traffic. I negotiated the cattle grid at right angles, and looked down at the XT screen. It had silently recalculated the route, taking the road ahead of me towards Settle along the B6479. No fuss, no U-turns, no problems. It did what I expected it should do, and what the 590 would have done. It just recalculated a new route in the direction that I had decided to ride.
It's actually better than I would have expected. This doesn't become a faster route until I am about half a minute along the road, but it must have done it immediately that I turned left. I didn't see it - I had to lift the bike out of the bend so that I was upright to cross a slippery cattle grid.

So why doesn't it do this when there is a route loaded ? (that's a rhetorical question - but I think I will follow up a previous post to Garmin asking a question about algorithms. What can they tell me that would help me to predict the behaviour).

I had noticed a number of times that whenever I get into this cycle of repeatedly asking me to perform a U turn, the tracklog is broken.

Here is an example taken from our recent tour of Scotland. We were heading to Skye from the south. The planned route was to take the A87 from Invergarry - it is a much more interesting route, but we needed fuel, so instead I went to Fort Augustus filled up and then continued NE to the A887 and joined the original route ta BunLoyne. From Fort Augustus, the distance to Bun Loyne is 20 miles if I go back to Invergarry and take the original route along the A87. It is 21 miles if I head NE and take the A887 from Invermoriston. SO initially, the satnav is correct in routing me back to Invergarry - but it should adjust as I head towards Invergarry. It doesn't give up demanding a U turn until 4.5 miles from BunLoyn junction.

Click the image to zoom in to see the red broken track log superimposed on this OS OpenData 1:250,000 map

1:250,000 Open Data Ordnance Survey Maps are free to use in this way providing the following acknowledgement is given:
Contains OS data © Crown copyright 2020


I have observed this a number of times, but I sent a couple of examples to Tech support, and described the circumstances.

I have to say that once a ticket number has been allocated and the task of investigation has started, the folk at tech support are very thorough. Their job seems to be to understand the problem and reproduce it. Sometimes they can, sometimes they can't. If they can, the detailed information and their observations are passed on to another team who's job is to decide what they can do about it.

In this case, they have not been able to reproduce the broken track problem, but since I can reproduce it at will, they want to check that it isn't caused by something else. But curiously, they latch onto my comment about the repeated U turns - which I made passing reference to becasue I have already lodged that fault, and that ticket is still open. Since the two are related (in my view), maybe this will lead somewhere now.

Garmin Tech Support in an email to jfheath wrote:
The issue we are looking into at the moment is regarding the Zumo XT's broken track logs. We have yet to replicate this on our end despite vigorous testing so we wanted to check:
• Can you replicate this without any SD cards inserted to the device?
• Do you have any 3rd party mapping or routes installed on your device? If so, can you try removing these and check whether the issue continues then?

What I will say is that if the issue is not reproducible without any SD cards and/or 3rd party mapping/routes on your device we suspect that it'll be down to those that the issue is happening and is unfortunately not something we would at that point be able to investigate further.

Can you tell me a bit more about the situation where your XT is repeatedly demanding a U-turn?

So I need to get out and see if it still does it without my OSM maps (even though they are iticked in myMaps), and without an SD card installed.
I'll probably reset the XT to avoid any other complications. Also, it occured to me just now that while my two examples of repeated U turns were taking place, that I was also collecting evidence of behaviour, so I took a lot of screen shots. There is a possibility that the screen shots were causing the issues with the broken track.

But they have expressed an interest in the repeated U turns, so I will reply to that as well.

As far as I know, all of the track logs are saved to internal memory. Actually, I can't think of anything that is written to the SD card by the XT.

So why are they interested in the presence of a SD card?

lkraus wrote: ↑Sat Oct 29, 2022 4:38 am As far as I know, all of the track logs are saved to internal memory. Actually, I can't think of anything that is written to the SD card by the XT.

So why are they interested in the presence of a SD card?

You are correct, and that was my reaction at first, But they get a lot of requests for help from people who are fumbling around and don't know much about the devices. I guess that very much like a computer, if it has a device, it needs to be able to talk to it, and if all is not well it may take up a lot if resources attempting to communicate. I spent a long time once trying to work out why my comouter was going so slow. I suspected a virus. It turned out to be an old and dying disk drive - one that I rarely accessed, but which seemed to be demanding attention. As soon as I unplugged it, all was well again. I don't know if the same is possible with SD cards, but its a reasonable request to remove any external factors.


I have removed the SD card and the maps, and just connected the XT to the PC using the USB cable. It is MUCH faster making the connection without the SD card in place.

The OSM maps can cause problems if they are ticked as well as the Garmin maps which cover the same area. Ive had no problem if they are left unticked. But its a suspicion worth removing.

The symptoms would not lead me to believe that either of these are the cause. Particularly since I can use the manual recording facilty for tracks at the same time, and these tracks are not broken. But I am happy to jump through the hoops.

I have a couple of other suspicions which I will investigate and report back to them. I may have a hardware fault which would be a nuisance as the guarantee has expired. This is a replacement unit- my original failed, and it looks as though the refurbished replacement may have come with this fault, from trawling through all of my track logs since April 2020 (i keep them all).

I'll be watching to see your results after your hoop jumping, but I think Garmin really doesn't have an answer and is putting off your question rather than investigating the problem. I really don't see what the map has to do with it either. A track recording should only involve data generated from the GPS signal, regardless of whether any map is in use at all.

I can imagine how taking a screenshot could interrupt a track log, since they are both writing to internal memory, but that would be a fixable bug.

Well that was a surprise.

I realised that in order to test whether or not the track log is broken by issuing U turn commands (or by recalculating), I didn't need to re-run my original test route. All I needed to do was to plot a route and then after passing the start point, head off in the other direction. It will keep giving me U turns.

I cleared everything off the XT including my OSM maps and removed the SD card. Then performed a reset.

So I prepared a route starting a mile away and heading somewhere to the east. I didn't care where - I was going right round the roundabout and head straight back home. I pressed screenshot a few times while I was heading for the start of the route, and screenshot a few times after joining the route. Then left it alone as it tried to get me to perform U turns repeatedly to head east.

Oh - I started the manual recorder on the track page just after heading back towards home.

There was one oddity. Just before I reached the start point, the magenta line I was on did not quite meet up with the magenta line of the route. I drove through it. It then asked me if I wanted to 'Skip ?' I've not seen that message for a long time. I thought it had been abandoned.

The result. Perfect. No broken tracks anywhere. Not in Internal Storage/GPX/CurrentTrackLog.gpx; not in .System/GPX Drive Logs; not in the manually recorded track.

Os now I don't know what happened.
Has it something to do with the Skip ?
Is it the removal of the SD card or the OSM Map.
Was it the complete system reset - were the track log files corrupt or something like that.
Was it the fact that over the last couple of weeks I have had Explore set up. I know it used to have some odd effects, which stopped when I disabled it so I stopped using it except to answer questions.
Was it becasue I had only a start and an end point with no intermediate points.

I think I need to do this again, and may have to go back to my test route - but its a three hour ride including the stop at the cheese factory cafe which oddly enough coincides with when my backside is starting to feel numb.

What is not in doubt is that something stopped it from going wrong which was there before.

This could be tedious.

Please keep chiming in Larry if you wish. I'm going to repeat the above, see if I can eliminate that odd behaviour at the start, add a couple of shaping point to pass through near the beginning and near the end, and deviate from the route after that. See what happens then. I'll miss out the screen shots. That definitely is not the cause.

I don't have anything to contribute but I sure am watching with bated breath.

Results of Testing.

Rather than adding the results one post at a time, I'll keep adding stuff to this post so that all of the results are together. I'll 'bump' the post so that it gets put up the new posts lists when I add the result of a new test.

Clean system - simple tests changing one thing at a time. Start Point located up the road. End point 10-20 miles away. Follow route to start, follow route for a short while then turn off in the opposite direction.

01 November 2022 wrote:Route Created on XT. No OSM Map. No SD Card.
Lots of U-Turn requests. Track Log continuous. Skip ? displayed on passing start point.

01 November 2022 wrote:Route Created on XT. No OSM Map. SD Card in place.
Lots of U turn requests. Track Log Continuous ie No broken track. Skip ? displayed on passing start point. Route recalculated to use a back road to get to end point. Did not route me to point of deviation once this road presented itself.

02 November 2022 Outbound wrote:Route Created on XT. OSM Maps re-installed, but not selected. No SD card
Route behaved perfectly. Deviation from the plotted route made withing the first 5 miles, after the start point. Recalculation was immediate and produced the route that I was intending to follow - even though the XT had plotted the original route. The Active Log was perfect and unbroken. Exactly as I would have hoped. But previously, every time I have made that deviation at the same place, I have had repeated U-turn requests. Something has changed.

02 November 2022 Homebound wrote:Route Created on XT. OSM Maps re-installed, not selected. SD card replaced in Zumo.
Route behaved perfectly. Deviation didn't take place until about 7 miles from home when the deviation from the planned route was massive. (I had set my destination to be along the obvious main road well away from home). I turned off, the satnav recalculated a route in the direction I was heading. It made two attempts at the two round abouts ahead to get me to go back - which is reasonable - and then gave up.
The routing is perfect and unexpected.

I had two breaks in the track log on the way home. They were about 2 miles apart and both were when waiting at road junctions. But earlier on, we had stopped a couple of times to look at things in villages, and these interruptions didn't break the logged track. WHatever, the breaks weren't associated with any weird routing behaviour or demand for U turns.

Two More tests. This time the first of series of 4. A short, 3 point route: Start -> MidPoint -> End
Between A and C there is a shorter, faster By-Pass of a small village. The Midpoint is plotted in the small village, but when travellng, I take the By-Pass to see what happens.


This is the wrong image. I deleted the original by mistake when editing this post. This shows a similar test ont he same road A would be off the picture on the left. The coffee stop would be the mid point. C would be a point a couple of miles off to the right.
I'll replace it witht he correct one when I get the chance.

03 November 2022 By Pass Via Point wrote:Route Created on Basecamp. OSM Maps installed, not selected. SD card in XT.
The mid point of the route was a Via Point. The route recalculated immediately on deviation from the route to take the bypass, finding the alternative turnoff at the other end of the bypass. This was also ignored. Surprisingly - the route the satnav then continued aheadand the Via Point was removed from the Skip list - just as if I had visited it.
The trip log showed a break at each point when the XT needed to recalculate the route. ie at the two deviations at each end of the by-pass.

03 November 2022 By Pass Via Point wrote:Route Created on Basecamp. OSM Maps installed, not selected. SD card in XT.

The same route was used in reverse using the same route points. This time the mid point at Addingham was a shaping point.

The route wanted to take me straight from where I was parked to the west (left), but I was facing the other way. There were a couple of ignored instructions as I found the best way to get back to the main road. Both of these resulted in the track being broken.
Once the route had started, the first break was where I refused the trun off at the east end of the bypass.
Very surprising was the next section. I expected the satnav to take me to the end of the by pass and ask me to turn right at the roundabout to get me to visit the shaping point. It didn't. From a mile back I could see that the plotted route was going to miss out the shaping point altogether - before I had rejoined the route. It seemed that it had plotted the route tot he roundabout, realised that this was now on the route and ignored the shaping point altogtether. The shaping point was no longer in the list to Skip.

This is VERY different from the 590/595 behaviour it would not ignore this shaping point and would try to naviagte me back to it at the end of the bypass. Only by ignoring it and turning left would it realise that I had rejoined the magenta line and automatically skip the missed point.

I'm not sure that I like this behaviour. It means that if the road that I chose to ignore was blocked, it would not then take me to the shaping point. In effect it ignores it after missing the turning once. I need to repeat this test in a different location, to see what it does.

Some Serious Testing - using the same route which started this thread

This is the same route that I used when I started this thread. I've used this course a number of times because it demonstrates two issues very clearly. One is the repeatedly trying to get me to go back to the point at which I deviated from the XT's route. The other is the apparent connection between the broken track log and the places where the U turn / route recalculations occur.

Click the image to get a larger view.


The solid red line shows the route that I intend to take.
The Blue dashed line is the route that the XT calculates between Ribblehead and Cleatop - it goes Via Ingleton.
The Pink dotted line is the longer route from Hawes - which I use in test2 for testing the behaviour of Closest Entry Point
The green dotted route is the calculated route when I introduced Skipton as the End Point (test 4 and 5).

Ribblehead - the start - is marked with a green circle.
The bike will start about a mile to the east so that I pass through Ribblehead once I have started riding
The End Point for most of the testing is Cleatop - the red circle on the map.
Hawes is marked with a Yellow Circle - only relevant for Test 2.
The white circle shows where the Cleatop route point was moved when it was changed to a shaping point.


This test is not about faster routes. It is about the XTs ability to come up with a new route after I opt to travel along a different road.
I created exactly the same route from Hawes to Cleatop South of Settle as I have used in earlier tests, although I save time and petrol by starting not at Hawes, but about a mile East of Ribblehead.

The XT calculated the route exaclty as before - creating the route that is marked by the blue line on the map. According to the XT, this route is approximately 1 minute faster than my route. But which is faster is not the issue here.
I intended to turn left at the road junctio just after Ribblehead, and head south twowads Settle and Cleatop.

There were slight differences in the test each time on previous occasions. I am trying to to tease out what makes the routing go wrong.

I had already established that when sitting at Hawes, if I asked the XT to navigate me to Cleatop with no saved route - it would initially plot the same route, but would INSTANTLY recalculate if I turned left at the junction after Ribblehead instead of going straight on.

So tTest 0 was to establish if it would do the same if I set off from just before Ribblehead, rather than setting off at Hawes.

All of the routes were created on the XT using previously stored Favourites. The routes were recalculated before each test. U turns were allowed. No extra maps on the XT and the SD card was removed - except for test 5 when I put it back in.

04 November 2022 Broken Track Test 0 wrote:No Route - Where To - Cleatop

I did not prepare a route for this, I just asked the XT to navigate me from my current position East of Ribblehead to Cleatop. It wanted me to continue straight on at the junction. I turned left. It Instantly calculated a new route along the road that I wanted to take. There was no break in the track log. No U turn requests. This is how it should be.

04 November 2022 Broken Track Test 1 wrote:Route from Ribblehead to Cleatop

The Start Via Point was at Ribblehead. I was a mile to the East. The End was at Cleatop. No intermediate route points.
I set of, and passed throught he start point. The magenta line wanted to go straight ahead. I went left. The route recalculated instantly to follow the road that I was taking. No U turns requested.

04 November 2022 Broken Track Test 2 wrote:Route from Hawes to Cleatop - Closest Entry Point

I was conscious that my route was shorter than the original from Hawes. For this test I created a new route from Hawes to Cleatop. It passed through my current position and went ahead at the junction as before. I turned left as before.
This time, the route wanted me to turn back to the junction. I kept going for 3 miles and in that time it made 6 demands for me to U turn. I have seen this behaviour before, and was not going to ride any further. It was stuck in a loop trying to get me to go back to the last point that it asked me to do a U turn.

I stopped the route and checked which way the XT would take me to get to Cleatop from here. It chose the route that I was taking.
Inspection of the logs afterwards revealed that the track log was fragmented with a gap which corresponded to the places wher it has recalculated the route and asked me to perform a U turn. My heart sank. It was still doing it. Never mind, continue with the tests.

04 November 2022 Broken Track Test 3 wrote: Ribblehead to Cleatop Via Point to Skipton End

For this test I created a new end point at Skipton - 13 miles SE down the A65. Cleatop remained ont he route as a Via Point. This is because I have previously noticed that routes sometimes behave slightly differently if there is a mid-point as opposed to a start to finish route. I wanted to see what happened in this case.

So the route is now Ribblehead START - Cleatop VIA - Skipton END

After setting off and passing through the Ribblehead Start Point, I again ignored the plotted route and turned left taking the direct route to Settle and Cleatop. The XT recalculated the route immediately taking me in the direction that I was heading. The track log broke at this point.

04 November 2022 Broken Track Test 4 wrote:Ribblehead to Cleatop Shaping Point to Skipton End

This test is identical to Test 3 -except that I used the XT screen to change the Via Point at Cleatop to a Shaping Point. Now we know that this causes the point to be relocated slightly and for it to be renamed. But the effect of this was more significant than I expected.

The XT's route was the same as before - straight ahead to Ingleton, but I turned left at the junction after Ribblehead. This time the XT wanted me to perform a U turn, so I kept riding towards Settle. I got two more requests to U turn and go back and had given up hope when it decided to calculate a new route in the direction that I was going. So that was OK. But why the difference between the Via and Shaping Points.

Tre track log revealed a number of broken track segements, each break corresponding to the recalculation and demaned to perform a U-Turn.

04 November 2022 Broken Track Test 5 wrote:Repeat Test 4 with SD Card replaced

This test is identical to Test 4 - except thsi time I would be riding all the way back home. And before I set off, I turned off the XT and reinserted the SD Card. Technical Support had asked me to remove OSM maps and the SD card to see if that made a difference. So far not, but I would need to reinstall OSM maps and repeat these tests and get the same results before I could be certain.

So with SD Card in place, I set off and turned left again - and obtained exaclty the same results - a number fo U turn requests and then calculating ahead. This is what I would expect it to be. But it doesn't explain the difference between the Via Point and Shaping Point.

Again track log was broken in places which seemed to correspond with the recalculation of the route and the U turn command.

After Settle, I did not take the dotted green line route to Skipton. I detoured wildly first south then east on much nicer roads. These detours were also treated sensibly. There were noww side roads to get me back to the A65, which it wanted me to take. But as I progressed, this route became faster than any other offferings - and it continued to navigate ahead presumably using my current position and the next route point.

This is a mjor success, and the first time that this has happened along any of this route in 2 and a half years and 2 different XTs. Something has definitely changed, and it is definitely for the better.

The reason why the XT made 3 demands for me to U-turn before navigating me along my route ?

Cleatop had been deliberately chosen as a Via Point point because it was on the A65 AFTER a roundabout where my preferred route joined the XT's 'faster' route. In other words, both routes would pass through it.

When I changed it to a Shaping Point the XT moved it so that this was no longer the case. It was now 3 miles away from its original location and positioned on the A65 3 miles NW of its original location. I have shown it as a white circle on the map. On my route I would have to make a detour in order to get to it - so it took longer for the XT to believe that my route was faster.

NEVER use the XT to change a Via Point to a Shaping Point. It always seems to move the shaping point onto what the XT considers to be the faster route - forcing you away fromt he route that you had intended.

I know this is an oldish thread, but it has piqued my interest.

Although the thread refers to a routing issue, and possibly implicates breaks in the the track history - did it ever get resolved by Garmin?

I was reviewing some breaks in my track history over the past few days, and noticed whenever I used the screenshot camera, the track log stopped recording; this struck me as being odd. The thin blue line broke.
It’s a phenomena I also noticed on past 660 and NAV IV devices (although the latter came with far more bugs than it should have )

Just a bit curious, really.
I have an SD card installed (but with no data loaded to it) and am only using Garmin mapsets.