Zumo XT - Software Update ??

[Peobody]

Express and 7 items updated 29 October - this done first.
The complete system reset would have been 29th October - I would have done this just after the update - habitual.

OK. That rules out the 7 updates being needed because of the reset.

[jfheath]

The reset wouldn't affect the updates anyway. But I take your point.

[Peobody]

Hmmm... I thought when I did a reset on mine it immediately wanted to update. Must be a different device I am thinking about.

Wait a minute, this would have been when I downgraded the firmware. It wasn't a reset but the installation of old firmware that resulted in the XT wanting to update, and that update would have been the firmware. Sorry!

[BashStreetKid]

The spikes I've seen are always next to a point with missing data. Here's a typical one at more reasonable speed:


I'm pretty sure I did not accelerate from 31 to 56mph and then come to a complete stop to spin 76º degrees and back before accelerating to 30 mph in one second and a foot of distance. My memory is slipping, but it is not that bad (yet).

Just noticed this thread and comments.
What I think is happening here is quite possibly related to the “smoothing” algorithm.
I did quite a bit of work on it with other navigational and GPS tracking software, some fifteen years or so ago.
Unfortunately, I can’t remember much but this:
https://en.wikipedia.org/wiki/Dilution_ ... avigation)
might give some idea?
There was a much better wiki explanation available (which I cannot now find) but might have been removed/deleted.

[FrankB]

Just happened to have a look at some old tracklogs created by my Zumo 220. They had similar spikes! The 220 never had strange routing behaviour. (As far as I remember)
What i'm trying to say: The spikes can be a symptom, but unlikely the cause of weird routing.

[jfheath]

Entirely agree @frankb. It'll be interesting - out of my discussions with the support team, 3 things have emerged. The broken track log , the routing back to an XT-added via point and the track log spikes.

At present they are focusing on the problem of my broken track log and so far they have been unable to reproduce it. So they have asked for my unit to be returned so that they can find out what is going on. This was after I had pinned down the circumstances when it happens and then I checked back through all of my past track logs. It seems that it started sometime after my original XT died and was replaced under warranty.

My 3rd (brand new) unit arrived yesterday and is currently charging. I am duty bound to perform the same tests as before and report back. Meanwhile they will test my 2nd unit so that they can see it happening and investigate why. They want to know if it is a one-off hardware fault or something that could happen on anyone's.

Once they have established that the engineer wants to look at the circumstances that caused the broken track log to return. Ie The repeated U-turns when deviating from a route that the Garmin has recalculated.

The technical support person seems impressed with the quality of my testing and seems keen to get to the bottom of this.

Fingers crossed.

[Stu]

Once they have established that the engineer wants to look at the circumstances that caused the broken track log to return. Ie The repeated U-turns when deviating from a route that the Garmin has recalculated.

Is that the issue in where you deviate from a planned route and it just keeps on trying to take you back no matter how many times you ignore the directions?

I had an issue in Wales where I missed the turn (On purpose) and just carried on knowing full well I could re join the route further up

It kept on trying its hardest to take me back at every opportunity and I had to be right on top of the planned route before it decided to re join

[jfheath]

Is that the issue in where you deviate from a planned route and it just keeps on trying to take you back no matter how many times you ignore the directions?

I had an issue in Wales where I missed the turn (On purpose) and just carried on knowing full well I could re join the route further up

It kept on trying its hardest to take me back at every opportunity and I had to be right on top of the planned route before it decided to re join

Yes. That's the issue. I reported it and described it ages ago, and submitted evidence and descriptions. It was acknowledged and sent to the team to investigate further. Nothing since then. Half way through this process, my XT died and wouldn't restart, so it was replaced under warranty.

Then I then discovered that every time it got the 'go back whence you deviated' scenario, the track log ended, a short section was missed and a new one started. Repeatedly.

It would happily direct me to the route when it was about 2-3 miles ahead, but before that it still wanted me to turn and go back. I reported this and this is what we (the tech support expert and I are working on - and she expressed an interest in the u-turn issue. So once we have identified the broken track issue, she wants to do some more with the repeated U turn to the point of deviation. Which is great.

I discovered more info about this (which I need to confirm, but which @lkraus has also observed. It seems that this happens :

* with planned routes with route points;
* If something has caused the route to be recalculated;
* And you deviate from the recalculated route.

When that happens, a new Via point is added to the route at the point of deviation. It doesn't show on the map. It doesn't show in the trip list, but if you select 'Skip' or 'Edit Route', this unknown point is shown as the next destination. Note 'destination' (via point) rather than 'shaping point'.

As I say, I have seen the u-turn behaviour a lot of times, and the additional via point a few times, but I have only spotted both at the same time just once - but I haven't been looking. But now I've seen it, it sort of explains previous observations. So I need to verify that. If it is that, I suspect that I know what is happening, but it all has to be checked out.

But my next test is to see if my brand new XT will create the broken track log in the identical circumstances to my returned unit. Meanwhile, they will be testing my returned unit to see if they can get that one to produce a broken track log.