Transportation mode, how is it set?

[Wapping]

and I would point out you too were unable to explain how

I didn't have my Nav V in front of me.... Better not to guess, sometimes.

I still think it is trying to do something in 'Motorbike' mode that is exhausting its memory or calculation capability. What that something is, is apparently not map related as (unlike my experience on the M20) yours occurred in OSM and in Garmin's generic maps. Nor is it present in your 'Car' mode. Put simply, your device was unable to complete the task of recalculating a route in one of two different Transport modes.

Question: Does it persist in doing this? Or was it just a one-off? What happens if you ask the device to create another route in both 'Car' and Motorbike' modes? Does it freeze up again?

The spike (for want of a better word) out to Leicester is an oddity. I have seen something similar but only once or maybe twice before when another route on a Garmin device seemed to 'leak across', getting mixed in with the route I was running. This created a very long route, too. The only way to fix it was to stop running the corrupted route and restart. I can't now remember what circumstances prompted the 'leaking across' nor indeed if I ever found the cause. They are not perfect machines. For example, you might sometimes see a dead straight line between two points on the same route as the 'true' wiggly line - following the actual road - between the same two points. In short, the device is capable of displaying the route accurately on the screen and incapable of doing so, simultaneously. I wonder if your device, just for a moment, just got very confused for some reason?

I've never been a big fan of recalculation of routes I have created myself carried out by the device, hence I leave auto-recalculate turned off or set to prompted. You use your devices differently, drifting / driving off the route (which is fine) then relying on the device to bring you back to the next waypoint / shaping point or end destination automatically. That something happened at the moment of recalculation is near enough plain to understand but quite what is was is difficult / impossible to establish without you riding / driving the route again. It may just be a simple - but inexplicable - gremlin in the system that has now hopped off to trouble some bod heading off down goat tracks. Whether this is directly linked to the device's struggles to complete the calculation of a route beyond 80% in one mode but not another is maybe not a definite.

Irrespective of a device's capabilities, I turn off all the bells and whistles that I can find. By and large I limit myself to just Garmin's generic maps, though I do sometimes have OSM maptiles as a back-up. Similarly, I go to great lengths to have any Transportation modes identical to each other, not differentiating between 'Car' (leave in motorways) or 'Motorbike' (leave out motorways). I also do just the same with BaseCamp on my Mac. In short, I make it all as basic as possible. I also get rid of voice instructions and don't bother with music, phone calls or any of the windy (now hilly, too) routing malarkey. Why? Because I want to reduce as far as is possible any variations that might want creep in and / or to reduce the chances of the lump of plastic and electrical widgets getting so busy on some other task that it forgets to show me where I asked it to take me.

 

[The Grey One]

I didn't have my Nav V in front of me.... Better not to guess how, sometimes.

Excuse accepted!

 

[Blackal]

I don't think it is. The Nav IV and its 660 sister could do it of course, through their 'More map' or 'More data' choices. The Nav V does not have this feature. All it offers is alternative dashboard views, which live horizontally along the bottom edge of the screen by default.

PS It's miles off topic, but hey-ho.

It wasn't miles off until I tried the route...........

Al

 

[The Grey One]

The spike (for want of a better word) out to Leicester is an oddity. I have seen something similar but only once or maybe twice before when another route on a Garmin device seemed to 'leak across', getting mixed in with the route I was running. This created a very long route, too. The only way to fix it was to stop running the corrupted route and restart. I can't now remember what circumstances prompted the 'leaking across' nor indeed if I ever found the cause. They are not perfect machines. For example you might sometimes see a dead straight line between two points on the same route as the 'true' wiggly line - following the actual road - between the same two points. In short, the device was capable of rendering the route accurately on the screen and incapable, simultaneously. I wonder if your device, just for a moment, just got very confused for some reason?

.

On that point I had deleted all routes on the device before loading the ones that caused problems. The "Leicester diversion" was the most marked but the day before it had done some rather strange routing whereby it wanted me to avoid the A46 Evesham bypass by taking a farm track towards the town centre, riding through the town centre and then come back onto the bypass. This as I said before was in the wrong direction for my journey home. This was a 25 mile route made by pressing the "home" icon, this one did calculate!

John

 

[Wapping]

John,

Can you email me the routes, please in a .gpx format.

The only way I can think of possibly looking at your problem(s) is to try replicating them or at least see if another device can load the route without it freezing at 80% and / or offer up a sensible routing alternative.

Routing you away from a perfectly good ring road, down a goat track and through a town looks - on the face of it at least - as if the device is defaulting either to the windy roads (it can read roundabouts as bends, apparently) or possibly 'most direct' route.

 

[The Grey One]

John,

Can you email me the routes, please in a .gpx format.

The only way I can think of possibly looking at your problem(s) is to try replicating them or at least see if another device can load the route without it freezing at 80% and / or offer up a sensible routing alternative.

Routing you away from a perfectly good ring road, down a goat track and through a town looks - on the face of it at least - as if the device is defaulting either to the windy roads (it can read roundabouts as bends, apparently) or possibly 'most direct' route.

I can't send the route that calculated wrongly as I deleted the bloody thing after it did the same crazy thing at least 3 times! I don't think the replacement route which worked will be of any use either. Because it worked.

As for the diverting off the ring road, it was something like onto a parallel track,then left on a farm track, somehow ending up in Evesham town centre so neither a "windy" route or anything like direct. Obviously I didn't follow it so I can't be exact.

I will try again next time I go somewhere I will try the "motorcycle" mode again and if it plays up again I will save the route for you.

John

 

[Wapping]

OK, let's do that.... If it goes wrong again.

 

[Wapping]

Well, that's interesting... Or not.

I am on my iPad so I asked Google maps to route me from a little north of Evesham on the B4088 (Norton Grange restaurant) due south to Evesham football club, to the south of Evesham itself.

Using 'car mode' Google routes me around Evesham on the A46 Evesham ring road. 5.3 miles in distance

If I ask Google to give me the identical same journey by foot or by bicycle, then it routes me straight through Evesham, the most direct route between the two points, in 4.2 miles. Call that a mile less and of course avoiding dicing with death on the dual carriageway.

Now let's suppose just for the sake of hypothesis, that your device somehow read the most direct route (straight through Evesham) as being more efficient than going around the ring road. It's a mile shorter, for starters in my example but that does not take into account the likely 30 mph speed limit through the town versus whatever speed limit applies on the ring road. Garmin devices sometimes lose their data as to a road's speed limit, so the software cannot make one of its calculations. If that happened, then indeed it would be logical to assume that it would default to the next best definite option, that 4.2 is 'better' than 5.3 miles *.

I am now dreaming up other possibilities. Does your device have the traffic feature that (might????) trigger an automatic route recalculation? Was the ring road possibly congested, making through Evesham a better option? I only suggest this as a car device routed us away from the A3 and then through through Guildford, when it picked up some traffic data on slow moving traffic on the main road. I am clutching at straws here!



* One last one.... If you were using OSM, do they have the road's speed limit data included within them? If they don't, then indeed the shorter (direct) distance would be the way that your Garmin device would be forced to cough up the (likely) fastest time between two points. Again, just a guess.

 

[The Grey One]

Well, that's interesting... Or not.

I am on my iPad so I asked Google maps to route me from a little north of Evesham on the B4088 (Norton Grange restaurant) due south to Evesham football club, to the south of Evesham itself.

Using 'car mode' Google routes me around Evesham on the A46 Evesham ring road. 5.3 miles in distance

If I ask Google to give me the identical same journey by foot or by bicycle, then it routes me straight through Evesham, the most direct route between the two points, in 4.2 miles. Call that a mile less and of course avoiding dicing with death on the dual carriageway.

Now let's suppose just for the sake of hypothesis, that your device somehow read the most direct route (straight through Evesham) as being more efficient than going around the ring road. It's a mile shorter, for starters in my example but that does not take into account the likely 30 mph speed limit through the town versus whatever speed limit applies on the ring road. Garmin devices sometimes lose their data as to a road's speed limit, so the software cannot make one of its calculations. If that happened, then indeed it would be logical to assume that it would default to the next best definite option, that 4.2 is 'better' than 5.3 miles *.

I am now dreaming up other possibilities. Does your device have the traffic feature that (might????) trigger an automatic route recalculation? Was the ring road possibly congested, making through Evesham a better option? I only suggest this as a car device routed us away from the A3 and then through through Guildford, when it picked up some traffic data on slow moving traffic on the main road. I am clutching at straws here!



* One last one.... If you were using OSM, do they have the road's speed limit data included within them? If they don't, then indeed the shorter (direct) distance would be the way that your Garmin device would be forced to cough up the (likely) fastest time between two points. Again, just a guess.

I think a little more time reading and a little less on wild theories would save you a lot of effort

Have a look at a map Find Evesham, I was coming from Bretforton on the B4035 then right onto the A46 for a short stretch before turning off for Harvington on the B4088
The device instructed me to turn onto the A46 but then wanted me to somehow come off this road onto, I know not what, turn in the wrong direction towards the town centre and then come back on the A46 just before the roundabout there the A44 splits off. I've had a look there are no roads or even tracks shown on the map to explain this. THE DEVICE WAS NOT FOLLOWING SOME PREFERENCE SETTING OR INDEED ANY KNOW ROAD, IT FUCKED UP! is that clear enough

John

 

[Wapping]

I give up. I'm trying to help you but enough is enough.

Richard

 

[leedude03]

if the preferences are set exactly the same for each transportation mode and the routes still change from one mode to the other, i would hazzard a guess as this is due to the algorithm for each mode being different, the bike mode uses a different algorithm to the car mode, so no matter what your preferences are it will plot a different route, unless you force it by pre planning a route correctly.

 

[leedude03]

i would also add if you contacted garmin they could possibly confirm this or give you an explanation as to why .

 

[Wapping]

if the preferences are set exactly the same for each transportation mode and the routes still change from one mode to the other, i would hazzard a guess as this is due to the algorithm for each mode being different, the bike mode uses a different algorithm to the car mode, so no matter what your preferences are it will plot a different route, unless you force it by pre planning a route correctly.

I am with you on this theory. I tried to say as much in post #18 where routes between shaping points can change between 'car' and 'motorcycle' transportation modes, maybe due to some 'invisible' data that each holds within their individual strands of software.

I still have a feeling that there are two (or maybe more) problems that are maybe not directly linked but more perhaps coincidental. The routing problem may be quite separate to the 'The unit freezes at 80% in 'Motorbike' mode. Maybe the algorithm within the 'Car' mode cannot sometimes - for some reason or another - be converted by the device's limited memory space / computing power into a 'Motorbike' route and the device loses the will to live?

I think the jury is still out on whether the 'Motorbike' mode is truly useless, as there were so many other variables in the OP's experience with - and use of - the device around the time of the problems. Maybe it is just that, 'useless' for the OP whilst others find it God's gift to bikers? Who knows....??? Who cares???

 

[leedude03]

i did a fair bit of research last night into this modes and preference setting, and i could not find any concrete evidence to support my guess work about different algorithm's. I came to my conclusion because i could not see garmin putting two/three modes in the unit when one would do, unless of course they were indeed different. i have not got one of the new units to test my theory, but if you gave the unit a task from A to B over say a distance of 50 miles in bike mode with XYZ set as preferences and used exactly the same XYZ preferences in car mode using the same A to B points it should if my theory is correct send you on two differt routes going from and to the same points, if it does then i would say with a fair degree of certainty i am correct if not then all the above is just waffle and pointless.
But of course dont plot the route start and end point on a motorway with no junctions between them. and i would also add that this should be done with garmins bespoke map sets.

 

[The Grey One]

i would also add if you contacted garmin they could possibly confirm this or give you an explanation as to why .

I might just do that but I think I need to try it again and save the route created or maybe take a screenshot so that I have something for them to work on. Might be next week now as plans for the weekend preclude use of the bike.

John

 

[The Grey One]

if the preferences are set exactly the same for each transportation mode and the routes still change from one mode to the other, i would hazzard a guess as this is due to the algorithm for each mode being different, the bike mode uses a different algorithm to the car mode, so no matter what your preferences are it will plot a different route, unless you force it by pre planning a route correctly.

This is what I suspect. The problem seems to be my device for whatever reason does not plot "different" routes, I could cope with that and maybe even find it useful once I understood what it does. Instead my device in "motorcycle" mode has plotted one route involving a two hour detour in the wrong direction and another involving impossible instructions over roads that do not exist on either my Garmin or OSM maps.

John

 

[Wapping]

OK here goes...

1. A Navigator V, with the latest software update, up-to-date Garmin generic maps and OSM maptiles for Belgium and France. The settings for both Car and Motorcycle modes are identical, with Avoidances set to avoid U-turns and unpaved roads in both modes. Device contains a 16 GB SD card holding some existing routes and the OSM maps but nothing else. Device set to fastest time.

2. The device was set to GPS simulator to ON, as I am using it indoors.

3. A BMW garage (picked from BMW's database within the Nav V) in Belgium was selected as a start point, with another - again picked from the same database - 174 miles away in France, selected as an end point. No intermediate waypoints set, so it's a journey A to B.

4. I first selected the Motorbike mode, the Garmin maps and asked the device to create me a route between the two points. This it did very quickly.

5. Without stopping the route, I then switched the device to Car mode. The device very quickly recalculated the route and changed the screen's dashboard display. As far as I can see, route was identical in direction, roads taken and estimated time taken.

6. Without stopping the route, I switched back from Car mode to Motorbike mode. Again the device recalculated the route and changed the dashboard back to my preferred view in Motorcycle mode. The route's direction, roads to be taken and estimated time were identical.

7. Without stopping the route I then switched the maps from Garmin to OSM maps in Motorcycle mode. The device recalculated. It jumped straight to 79% completion, paused very very briefly and moved on to 80% completion. It then paused for about 15 seconds at 80% before jumping to completion. The direction, roads taken over the 174 miles were as far as I can see identical.

8. Without stopping the route I then switched into Car mode. The device recalculated. Again, it jumped straight to 79% completion, paused very very briefly and moved on to 80% completion. Agin it paused for about 15 seconds at 80% before jumping to completion. The direction, roads taken over the 174 miles were as far as I can see identical. Again the device changed the dashboard display and layout.

9. Without stopping the route and remaining in Car mode, I switched out of OSM maps into Garmin maps. The device recalculated again. Unlike the recalculation made in OSM maps, it was very fast with no protracted pause at 80%. The route displayed was identical, as far as I can see.

10. Without stopping the route, I switched out of Car mode into Motorcycle. Again, the device recalculated and changed the dashboard. Again the recalculation process was very fast, with no protracted pause at 80%. Again it was unaltered.

11. I then stopped the route and cleared it from the device.

12. I then left the device in Motorcycle mode, switched to OSM maps and asked the device to create me a route between the exact same two Belgian and French points, picked from the same BMW database from within the device; it was therefore completely consistent. Again the device paused at 80% but this time the pause was longer, say about 30 to 40 seconds. On completion, the route offered up was, as far as I can see identical to the route created in the examples above.

13. Staying in OSM, I switched to Car mode. Again there was a recalculation and again the dashboard display changed. Again there was the pause at 80% but completion was was within say 15 seconds.

14. Staying in Car mode, I switched out of OSM and into Garmin maps. The device recalculated very quickly and again offered up a route that was identical.

15. One last time, I switched form Car mode to Motorcycle mode. Again there was a recalculation. Again, the dashboard display changed. Again, the recalculation was very fast, with no pause at 80%. Again the route was identical.

Thoughts:

A. Switching between Transportstion modes forces a recalculation each time.

B. The changing of the dashboard each time suggests that there are other fine differences between the Car and Motorcycle mode that are invisible to the operator.

C. As I had set my preferred dashboard view in Motorcycle mode but had never set it in Car mode, it reverts to the base dashboard display when entering Car mode. This suggests to me that the device always goes looking for the preference settings when switching between Car and Motorcycling modes.

D. That there was always a pause in the recalculation at 80% when switching between maps (and a longer pause at when making a route calculation afresh in OSM maps) but no corresponding pause when switching into Garmin maps or when creating a routemin Garmin maps. This suggests to me a memory or device capability issue, peculiar to running non-Garmin maps.

E. These tests were all conducted indoors in GPS simulation mode, within the device itself. The device was not outside, so was not moving or physically running a route, nor nor was it locked to or searching for satellites. I can only assume that this places less demands on its memory and computing powers.

F. I saw the same - but much longer - protracted pause at 80% and ultimate failure when I calculated a route on the move between the M20 and Calais in OSM maps. There was no pause in the same moving calculation of an M20 to Calais route when using Garmin maps. The difference here was that the device was moving at about 80 mph and locked to satellites when doing so, which I assume places more demands on its capabilities.

G. I am all but sure that the pause / freezing at 80% (a figure that matches the OP's exactly) is memory / device ability related, maybe further exacerbated when the device is busy on other tasks, like running a route along with all that involves - updating arrival times, reducing the distance to destination, analysing and displaying current and average speeds - or maintaining its satellite links.

H. I am as near as dammit certain that the devices struggles (to some degree or another) when in OSM maps as opposed to its own Garmin generic maps. Precisely why I cannot tell from just looking at the device as I can only see the delay at 80% but not the cause. It is easy to assume that somewhere in the OSM maps there is 'something missing' that the device has to struggle to fill in, sometimes failing to complete the process.

I. As the entire experiment was conducted within the device itself, I had to rely on looking at the map to see if the routes, whilst always the same length and appearing to take the exact same roads, were identical. I would have to copy the same multiple routes across to my Mac and BaseCamp to see if there were any fine differences between them or if indeed any of the routes followed 'non-existent' roads. I am not about to do this. From as careful a look as I could make by using the device's screen view, they all appeared to be the same and to follow known roads on a map. There did not appear to be any bizarre routing errors, either.

J. The OP in his open and subsequent posts had other problems beyond his freeze at 80%, the most significant of these being the bizarre routes the device proffered up during forced recalculation or by going off-route. It is difficult / impossible to recreate these without riding the routes, preferably with the OP's and another device side by side. All I can say is that I have never (bar the one time when another route leaked across) seen the same thing.

However, I can all but recreate the 80% problem, or at least a significant pause, at will just by switching to OSM maps.

K. I am now convinced that switching between Car and Motorbike modes will always force a recalculation and the device to go looking at personal settings between the modes. I am similarly convinced that there are other fine diffences between the two modes that are invisible to the humble device owner.

Garmin will know for sure.

 

[leedude03]

A very good test Wapping i would have done it exactly the same had i one of these units to test, it does appear from your testing that there is no difference between the algorithm of bike mode and the algorithm of car mode (i guessed wrong with the evidence provided) i would now say that this difference is created in preference setting for each mode, for instance have bike mode to avoid tolls and car mode to not avoid tolls. Also somewhere along the way it changes the dashboard layout (no biggy there then) and it takes more time to calculate when using OSM maps compared to garmins own maps(this i would expect).
I would only add that the results may be different, and i do stress MAY BE if you were to actually run the routes and not use a simulation, i myself do not think the results would alter but you never know.

 

[The Grey One]

My original route to Bridgnorth was working as expected and showing a sensible arrival time. However after a brief diversion the re calculated route was nonsense, this would imply that any problems are not going to show up in simulation. Likewise the previous day's route which suddenly recalculated in a very strange way despite my being on the planned route at the time.

I almost never create a complex route on the device so my experience of this is limited to simply asking to go to a specific point. I guess the route calculation doing this might be slightly slower than with Garmin maps. I would not be surprised as there is far more detail on the OSM maps to process. For me a few seconds wait is more than repaid by the fact that the OSM maps are more accurate. I have used OSM maps in Austria and one two trips east from there. In 2014 we rode down the Adriatic coast as far as Montenegro coming back through Bosnia. Last summer we rode through Hungary to Romania and ended up on the Black Sea. Now, back in the UK I use the OSM map all the time. Almost everywhere I have been the OSM maps are both more detailed and, importantly, more accurate. It is only since trying this "motorcycle" mode that strange things have happened. I have never found that there was any delay in re calculating whilst on the move which to me is the critical one. I don't mind a few seconds wait before I set off but such a delay would be totally unacceptable out on the road.

I have never had he device freeze up like it did on this short route home from Bridgnorth. It simply stuck at 80% for 20 minutes as I rode along. When I tied switching to the Garmin maps it also stuck at 80% but I have to admit I only waited a couple of minutes before changing the mode back to "car". I put the maps back to OSM and it calculated as normal.

Hopefully can get out on the bike early next week and test it further. I will try to download the result and post it on here.

John

 

[Wapping]

I translate 'stuck at 80% for 20 minutes' as a freeze. A delay of 15 seconds or even 40 seconds I translate as a pause, albeit a protracted one compared with instantaneous.

As to the relative qualities of map detail between Garmin and OSM maps or indeed any other proprietary routable (or non-routable) mapping suitable for use in a Garmin GPS unit, that's a matter for another day and (hopefully) another thread. But, for what it's worth, you won't find the road up to my parents' house in Provence in OSM maps but you'll find it on Garmin's maps, in Google maps and (naturally enough) on sufficiently detailed paper maps from IGN and Michelin.