2 observations with fixed routes.

[FrankB]

1. You can share trips between Zumo XT's via Bluetooth. Me and my son use that method now that he currently has no laptop with Basecamp on it.
So on my Xt I have a trip that has been fixed with the tool, and it's listed under 'Saved'. I share the trip to my son's XT via Bluetooth. The trip arrives OK, but it is listed under 'Imported'! We did not actually drive the trips to see if there's a difference, but I would bet a case of beer that they behave differently.

2. Today I tested a 'trip from a track', with recalculation set to auto. It's not something I do normally, but the question was raised, and I did not have the answer.
In short: It makes no difference if the trip was fixed yes or no. The trips behaves the same. Asking for U-Turns, a ghost via point was added and broken tracklogs. The good news is that it's not recalculating straight to the end point when you deviate.

For all people fond of 'hex editing': A trip from a track has the flag 'mPreserveTrackToRoute' set to '01'

[Peobody]

You can share trips between Zumo XT's via Bluetooth.

This has been a frustrating process for me. The first time I did it, a buddy and I were out for a ride on route he had created and emailed to me. It crossed paths with a route I had on my XT. When we stopped for lunch, I suggested my route home. We both knew that our satnavs had bluetooth sharing capability but had never used it. It was surprisingly easy. A couple of months later we attempted to do it again but my XT would not connect to his NAV. He could connect and share to my XT though. We have not tried it since.

The good news is that it's not recalculating straight to the end point when you deviate.

What does it do instead, recalc only to next route point then continue with the preplanned route?
If so, how were you able to determine this?

For all people fond of 'hex editing': A trip from a track has the flag 'mPreserveTrackToRoute' set to '01'

Is it your thinking that editing this byte will prevent the 'recalc to then end of the route' annoyance for routes not created from a track?

[FrankB]

What does it do instead, recalc only to next route point then continue with the preplanned route?
If so, how were you able to determine this?

If I would have to describe it I would say: It is trying to get you back to the route as fast as possible. I hope the screenshots will make it clear. (Blue is the original track that the trip is based upon, Magenta is the active trip.
Note: A trip from a track has no route points, only a start and an end point.

Is it your thinking that editing this byte will prevent the 'recalc to then end of the route' annoyance for routes not created from a track?

No. Dont think it plays a role. Just something I noticed when viewing the trip file.

[Peobody]

D'oh! I forgot about the 'no route points'.

I will be giving some thought to the practicality of tracktrips for routes in which route points exist solely for navigational purposes.

[FrankB]

If you allow me to add my thoughts.

It works.
Especially if your sharing routes to other people, thave a combination of: different hardware, different maps, different preferences. Etc.etc.
Your route will look (almost always) the same on the other devices.

I stick to routes with via/shaping points hoping that in case of a (forced) deviation it will recalculate a good alternative. And we all know by now that that's not an easy task.
Trips from tracks offer no real advantage when it comes to that. Fixing the trip works better.

But I would like to hear your thoughts...

[Peobody]

It works.
Especially if your sharing routes to other people, thave a combination of: different hardware, different maps, different preferences. Etc.etc.
Your route will look (almost always) the same on the other devices.

This is definitely a benefit however, as you noted, having via points along the route that can serve as meet-up points during group rides is valuable. Of course the downsides of route calc differences are that riders can think the leader has gone wrong, or worse, follow their satnav and end up separated. Also, a triptrack does not provide navigation instructions right?

My initial thought about the value of a triptrack was for local, solo rides. A recalc that returns to the route would be easier than manually navigating back to the route, and better than allowing a recalc.

I'm handicapped by never having taken a triptrack ride. I really need to do that.

[FrankB]

Also, a triptrack does not provide navigation instructions right?

I'm handicapped by never having taken a triptrack ride. I really need to do that.

Oh yes, they do provide intructions.

You can test it at your desk with the simulator

[FrankB]

And to be clear what I mean with 'A trip from a track'
Open the track in the app tracks. Hit the wrench and then select 'convert to trip'. Next go to the Trip planner and start it from there. You will have instructions.

You can also select Go from the Track app, but then you will have no instructions. And that was not what I tested today.

[jfheath]

Just relaxing after a hot day riding, walking and not much else.

I thought I would chip in.

Interesting observation from Frank, that a nobbled route transferred to a new XT returns i satus to imported. I'm not taking that bet. I'd lose ! I'd quite happily bu you a beer though.

Before you experiment with a tracktrip, (a track converted to a trip), can I suggest that you first load a track and select Go! I bet most people have never tried this but it is a most relaxing method of navigating. It tells you where your track is eg '3 miles over there' - pointing to the closest point as the crow flies.

Once you have played with that, you get an idea of what a tracktrip is doing. It does exactly the same thing, except it calculates a new section of route and superglues it to the original tracktrip at that closest point. The two joined sections now become the new tracktrip.

If you deviate from a track trip in such a way that the closest point is behind you, you will notice something very familiar. A RUT.

I believed two years ago that the RUT behaviour was caused by something in Basecamp making the XT think that it was a different type of route, and the only reason I could come up with was the subclass info. Frank and I had both looked into this possibility, but I tested routes with no subclass, with default subclass, altered subclass and normal. The results were inconclusive. But I still believed that somehow tracktrips and RUT. behaviour were linked - that when a route is recalculated, somehow the programmer had referenced the wrong subroutine.

The fact that Garmin call these tracktrips 'Trips', when they also call the things from Basecamp containing a start, end and a few route points, 'Trips'. .... well that added weight to my suspicion.


So. I think that a tack trip has to be distinguished from a standard point to point route, in some way. There are actually three kinds of routes. Those created by the XT. Those created in Basecamp and transferred to trip planner. Those created as tracks, imported and converted to Triptracks by the XT.

There's a fourth. Those tracks and routes created in Explore and cinverted into something navigable by the XT. This is similar to the third.

Problem is that standard Basecamp routes have been classed as imported and not saved. So when these get recalculated the behave like the triptracks.

I found a very definitive tell tale sign that the navigation is displaying RUT behaviour. Turn off U turns. Deviate and let it calculate a way to take you back by using side roads, laybys, housing estates etc. After it has done a couple of these, stop at the side of the road and look at the route that it is trying to get you to follow. It will contain all of those housing estate / sideroad / layby 'turn round' sections. Why, if it is calculating a new route would it do that?

The answer is that it isn't calculating a new route, it is suprgluing a new section to get you back to the closest point of the original. And that is behind you. And that is exactly what happens when you deviate from a tracktrip. There had to be one key difference that distinguished an XT route from an imported route. So I set about proving that an already tested RUT route would not display RUT behaviour using identical saved Waypoints, If the route was built in the XT.

And that was why I was so excited about that single byte change. It seems to be the single thing that makes the XT behave as if it is a tracktrip, and behave as if it was created as a normal route in trip planner.

And that was exactly what we were looking for. @Frankb found it. I'd already done the testing of various routes so that I knew when it would RUT and when it wouldn't

The observation that routes were divided into 'Imported' and 'Saved' was a revelation to me. Because I had been resetting my XT for every test, I never had both types loaded at the same time, so I'd never noticed it.

Info on tracktrips is in this section. https://www.zumouserforums.co.uk/app.php/ZXT-P45

[Peobody]

I just did a simulation test using the track of a loop route around my neighborhood converted to a trip. The resulting magenta line showed the loop but the navigation took me backwards from Begin to End (there is about 1/4 mile between Begin and End, they don't overlap). I received voice navigation instructions so that is confirmed. There is no need to respond about the odd loop behavior. It appears that my XT has me located down the street from where I actually am so is just navigating me from there through Begin and then to End. I'll create a better test.

I was surprised to see the track trip as an 'Imported' trip instead of a 'Saved' trip in Trip Planner. It appears that the mImported byte is flowing through the track to the trip track. I wonder if this behavior is different if the track was created by the XT rather than by Basecamp.