Weird Routing Behaviour - Major Success.

[danham]

6. Change the entry at "mImported" from a 01 to a 00 and export the file back to your Mac desktop.

A screenshot showing which byte to change.
hexedit.jpg

I found this and the previous screenshot a little hard to follow -- likely my fault for being a babe in the woods when it comes to thinking in hex.

Here is the exact spot where I successfully changed the trip file using the online hex editor:

Screenshot 2023-05-22 at 11.49.57 AM.png (296.14 KiB) Viewed 5181 times

-dan

[jfheath]

How to I access the location for the trip files in the Zumo XT ? I cant see the folder, even viewing hidden files on the PC ?

You need to make the .System folder visible to the PC on Internal Storage. You do that on the XT.

See this link - app.php/ZXT-P84

[Oop North John]

Great work by everyone, has anyone thought to see what happens if you have a saved route on the XT, change it from say "faster" to "shortest", then back again to fastest to see if it changes the attributes that makes the XT navigate sensibly?

Or do you have to do the above shuffle, and then save it in the XT?

And, if you add an extra way / via point to a route in the XT, and then save it in the XT, then it's ok?

TVMIA

[Stu]

Great work by everyone, has anyone thought to see what happens if you have a saved route on the XT, change it from say "faster" to "shortest", then back again to fastest to see if it changes the attributes that makes the XT navigate sensibly?

Tried that and it was still a no go

[jfheath]

Great work by everyone, has anyone thought to see what happens if you have a saved route on the XT, change it from say "faster" to "shortest", then back again to fastest to see if it changes the attributes that makes the XT navigate sensibly?

Not to see if it changed these particular attributes no. But I switched from Faster to Shorter and back and all sorts of other tricks to try to get the XT to think the route had been created in the XT. That was because I suspected that the issue was with Basecamp routes early on. And I thought that if I did that, and the XT recalculated it, then it would be an XT route. In fact it promoted the RUT behaviour - because until a route recalculates, the XT will keep the Basecamp route intact. Recalculating subsitutes a new route.

By inference, it it was still displaying RUT behaviour then this flag cannot have been set. But that is a logic that isn't necessarily correct. It an XT after all.

Or do you have to do the above shuffle, and then save it in the XT?

I tried all sorts at the basecamp end, including sending the XT direct routes, sending with default subclass information, stripping out the subclass info completely. Using only Via Points, using only shaping points, using only waypoint via points, using only waypoint shaping points.

After 2 years of trying everything I could think of it boiled down to the fact that routes from outside the XT were being treated as different from routes created within the XT. I could have assumed that a lot earlier - but I needed the evidence for tech support.

And, if you add an extra way / via point to a route in the XT, and then save it in the XT, then it's ok?

If it was created within the XT - Yes . If it was a BC route with modified byte after import - then probably. I havent tried that since Frank's 'modified byte' discovery. (That sounds like he's been to the dentist) But I expect that it would work - given what I observed yesterday on routes that I have ridden and tested in all sorts of scenarios.

But that isn't proof. You can try it though. Modify the byte and see if another via or removed via demotes it to the list of imported routes.

[Rofor]

@danham

Here is the exact spot where I successfully changed the trip file using the online hex editor:

Isn't that the wrong position?
You have marked the position after the '09' - @FrankB said, it is the value between '07' and '09' which must be changed?

[FrankB]

@danham

Here is the exact spot where I successfully changed the trip file using the online hex editor:

Isn't that the wrong position?
You have marked the position after the '09' - @FrankB said, it is the value between '07' and '09' which must be changed?

It's indeed the wrong position. It should be between the 07 and the 09 bytes.

For your info. We're working on posting a small Java program that will handle updating the file

[danham]

@danham

Here is the exact spot where I successfully changed the trip file using the online hex editor:

Isn't that the wrong position?
You have marked the position after the '09' - @FrankB said, it is the value between '07' and '09' which must be changed?

Yes it is -- apologies, I was juggling too many things at once. Now fixed.

-dan

[pcdabbler]

Im really grateful to the efforts of eveyone on here to solve this issue, especially the dogged determination of jfheath for taking this on and not letting go,and the efforts of frankB for identifying the byte to flag imported or not to the Zumo in the trip file. I've a 3000 mile trip coming up in the next four weeks through to Eastern Europe, and now feel fairly confident that I'll I'll be following the route I intended. Last year I went off piste twice and around in circles because of temporary road closures. No fun when the weather had just turned in the foothills of the Alps and it was raining/Snowing. On one occasion I just switched the Zumo XT off and rode for tewnty or thirty kilometres, then put it back on with a direct to destination. At least we now have a workaround. Thanks again.
Alan.

[jfheath]

Isn't that the wrong position?
You have marked the position after the '09' - @FrankB said, it is the value between '07' and '09' which must be changed?

Good catch @Rofor .

It is really very important to edit the 'correct' byte. Assuming that this is correct data to alter.

This isn't a text file that is being edited, it is a data file, and those numbers all have a specific purpose.



I know that you know this but I want to emphasis the possible significance of getting this wrong - and perhaps the reason why @FrankB is concerned about giving out instructions for using a Hex Editor

The data to alter is for the information that is outlined in green - the data that relates to 'mImported'.
The 00 to the right of the 09 (in red) is for the data that relates to the next item - 'mRoutePreference'.

In 4 bytes after the 09 represent one numeric value consiting of 4 bytes: 00 00 00 01. (A byte is represented by two hexadecimal digits)

You read it like you would read a decimal number eg 1234 as one thousand, two hundred and thirty four. ie 1x10x10x10 + 2x10x10 +3x10 + 4

Except these numbers are 8 bit binary numbers, each represented by two characters
So 01 02 03 04 would mean 1 x 256x256x256 + 2x256x256 + 3x256 + 4. So that is 16,909,060

So put if you make that alteration to the '00' that is after the 9, you would make the value relating to mRoutePreference be 01 00 00 10
which is 16,777,232. And that figure represents the length of the name of the data !

Goodness know what would happen if the XT ended up trying to manipulate a name that was 16.7 million characters long.