Article Zumo 590 & 595 Trip Planner & Basecamp - What Goes Wrong and Why

Great info! I am sharing with my local riding group, as many of them end up with via points being visable.
I do all my trip planning in Google Maps, which directly exports into Basecamp now for final review before uploading.
So much easier than designing a route from scratch in the garmin software.
Do others do this? Could write up a short process that would be a sort of prologue to this manual.

CYYJ said:

Apropos of Garmin's Basecamp application, I have learned (the hard way) that routes created using Basecamp will not display or function correctly if they are uploaded from Basecamp to the Garmin 660 series navigator. The 660 series can only (successfully) import routes from the Mapsource application (the older, now deprecated Garmin map management application).

There is, however, a work-around for this problem, if users prefer to create routes in Basecamp rather than Mapsource: Create the route in Basecamp, then, open MapSource, and copy the route you have created in Basecamp into Mapsource, using standard Windows copy/paste commands. Save the newly-created Mapsource file, then upload the route from Mapsource to your 660 series.

The ability to do this is important for me, because I have two ST motorcycles: an older one with a Zumo 660, and a newer one with a Zumo 590. I prefer to keep all my work (routes, waypoints, track logs, etc.) in the Basecamp application because it has greater capability than the Mapsource application.

Michael

Click to expand...

Ok I am so glad I stumbled upon this thread.
In May 2018 I purchased a cream puff 2014 Yamaha FJR1300.
The Bike came with a Garmin 660.
Getting acquainted with the 660 I stumbled upon Base Camp.
My buddy and I are planning a 2 week trip to North Carolina in October.
He has a Garmin 590.
I have the 660.
I had mapped out routes for about 10 days riding all the Big Name Roads in the Smokies.

The Map being utilized in both Base Camp is City Navigator North America NT 2019.1

Am I correct in your statement that the GPX Exchange Files GPX eXechange Format (*.gpx ) need to be ran through Mapsource.

And in doing so what format does the Routes need to be saved as and Exported to the Garmin 660.

As standard Base Camp saves them as GPX Exchange Files. GPX eXechange Format (*.gpx)

Map Source gives the options saving as several different versions:
Garmin GPS Database Version 3 (*. gbd)
Garmin GPS Database Version 2 (*. gbd)
MPS Files (*.mps)
Text (Tab delimited) (*.txt)
DFX (*.dfx)
GPX eXechange Format (*.gpx)

Blue-N-Bethany said:

Ok I am so glad I stumbled upon this thread.

Click to expand...

Hello Blue:

You are taking - or perhaps attempting to take - a somewhat more complicated approach than I do to transferring routes and waypoints created in Basecamp over to Mapsource so that this data can then be uploaded to the Zumo 660 using Mapsource.

I do all my work in Basecamp (route planning, route creation, storage of waypoints, etc.). Then, when I have finished my work and want to transfer the routes and/or waypoints over to Mapsource, I simply select the route and/or waypoints from the left-hand side list in Basecamp and then "copy" them (using the standard Windows copy command, typically Control + C), and then I past them into a new, empty Mapsource document.

I then upload the routes and waypoints from MapSource to the Zumo 660, and then discard the MapSource file.

I hope this provides sufficient explanation.

I don't try to save the Basecamp file and then open it with Mapsource, although I have in the past imported very old (like, from 2001, 2002) Mapsource files into Basecamp - that works just fine.

Michael

jfheath said:

Use Mapsource or Basecamp to transfer the routes to the Zumos **. Don't put files into the folders in the way that you are describing - you will lose important information.

Click to expand...

How or why????

I do however use the Back Up feature in Base Camp also.

Again what format is the 660 using?
Garmin GPS Database Version 3 (*. gbd)
Garmin GPS Database Version 2 (*. gbd)
MPS Files (*.mps)
Text (Tab delimited) (*.txt)
DFX (*.dfx)
GPX eXechange Format (*.gpx)

Blue-N-Bethany said:

How or why????

Click to expand...

Good question. A very detailed explanation is in the pdf availabl as described in Post #1 of this thread.

But a simple explanation - when you create a route in Mapsource or Basecamp, Garmin's software ensures that the identical route is transferred to the Zumo (550, 590, 660).

If you send a GPX file, often this just contains the start, finish, Via and Shaping points. So the SatNav may calculate a different route between these points.

If your Zumo never seems to get the same route that you had in Mapsource or Basecamp, then something is wrong with your settings, or you have a different version of the map in your Zumo from the one in your Basecamp / Mapping software. (Again this is explained in the pdf).

has any of you guy tried to import routes using the Bluetooth option, from zumo to zumo. I've tried it a couple of time with a buddy and no luck.
Lyle

ROAD TRIP!!!!!!!

@jfheath

Thanks for the detailed explanations.

Looks like I need to add a lot of shaping points in between the vias. Only way to be sure that it will follow my planned route and get me back on my route soonest if I should wander off or get detoured.

The Select Next Destination is the goofiest (and most confusing) feature of the newer Zumos with Trip Planner. I noticed that prices for used Zumo 660s is still pretty strong and I suspect it is because of the Trip Planner app.

I have never gotten the hang of Basecamp - I wonder if I can bring gpx file that I prepared in Furkot into Basecamp and have it create the ghost points?

Thanks again all.

So I sold my Nav V and bought a Nav VI - mainly for the better screen. Only had it for a couple of short rides so far and I have found the screen to be brilliant in all light conditions.

I noticed that the Nav VI has a new feature called "Automatically skip waypoints" that you can check in the settings. Based on what I read about this new feature, it only works for waypoints that are missed that are fairly close to the route - a waypoint that was placed in the northbound lane and you are in the southbound lane for example. It may not work for an errant waypoint that was placed 1 mile up a side road or if you had to detour 5 miles around construction and wind up some miles farther on your route. In those cases, it would probably still try to route you back to the missed waypoint just like the Nav V. Not sure what the algorithm is for distance but I assume it is less than 1/4 mile or something in that range or maybe even 100s of yards.

Note that this is not to be confused with the manual SKIP WAYPOINT override button which still works just like before on the Nav V - you press this and you lose your planned route until you hit the next waypoint where it then picks up your planned route again. The auto skip feature simply ignores those nuisance waypoints that were not placed exactly on the road and it will still preserve your planned route.

What I am wondering is if this new skip waypoint feature works on the "start" point too. In other words, we may no longer have to create a start point that is just along the beginning of the route instead of where we actually start from. I am referring to the SELECT NEXT DESTINATION screen when you begin a new route. For example, if the GPX route has "Joe's Bar-B-Q" as the start point the Nav VI still asks you if Joe's is your next destination but I am wondering if this may not be so rigid now with the auto skip waypoint feature selected. With my Nav V I was changing this to a point down the road to make sure that I "hit" that point because sometimes when I checked the SELECT NEXT DESTINATION as the start (Joe's for example) and I was sitting in (Joe's) parking lot it sometimes got confused as soon as I started my ride and it would tell me to u-turn back to Joe's which was a major PITA. If this new feature works the way I think, I may be able to SELECT NEXT DESTINATION as the true start location ("Joe's) and not have to create a new waypoint that is just down the road...............This will save me some time with GPX routes that I use that were created by others who have the start points already set. And also I can plan routes that are easier to share with others who have older Zumos. The logical start point is where you start from and not some point along the route. If Garmin fixed this with the auto skip waypoint feature then the only other thing that we have to be careful about is when we go off route and for those instances I now keep my NAV's auto recalculation set to PROMPT so that I can be sure the magenta line remains intact and I can navigate back to it and then pickup again............Learned my lesson on that.

EDIT: Sorry to taint this forum with BMW equipment but the BMW Navs are basically the same as the current Zumos which have the Trip Planner feature so the function should be the same.

Wow John - this is really great work on your part.

Many thanks indeed!

Pete

Agreed John. I have never seen a built-in GPS unit in ANY car brand that is as good as my $130 CDN Garmin stick-on-the-window model.

The one feature that they all lack IMO is a vector on the screen that continuously points at your destination. If I had that,I could go exploring backroads much more effectively because I’d always have an idea of my desired overall direction.

Pete

CYYJ said:

Apropos of Garmin's Basecamp application, I have learned (the hard way) that routes created using Basecamp will not display or function correctly if they are uploaded from Basecamp to the Garmin 660 series navigator. The 660 series can only (successfully) import routes from the Mapsource application (the older, now deprecated Garmin map management application).
Michael

Click to expand...

I've been using a Zumo 660 and 665 for years and have never experienced this problem. I quit using Mapsource as soon as the Mac version of Basecamp was released. I'm wondering if routes transferred to your 660 only work if coming from Mapsource is a PC limitation? Just curious.

BTW, thanks John for a great body of work. Very informative and much appreciated.

Also, anyone having a problem with their GPS, I'll echo SteveST1300's recommendation for the Palm Dr. I sent in a 665 that was having some glitches and it came back promptly, files updated, memory cleaned up and works faster and better than when new.

Shuey

MaxPete said:

.......... The one feature that they all lack IMO is a vector on the screen that continuously points at your destination. If I had that,I could go exploring backroads much more effectively because I’d always have an idea of my desired overalll direction.

Pete

Click to expand...

If your GPS has Off Road as an option to select on the navigation settings page you will have something similar to the below. You won't have the road map to follow but on deserted trails and forest roads or out of town where you have a limited number of roads to choose from you don't need them any way as you only have one road to follow. The direction arrow will always point in the general direction that you need to go and since there is limited road choices you simply follow the road that you are on until you come to another road that the arrow is pointing down.

I have followed regular out-of-town routes using this mode. I put a way-point very close (no more than a couple of hundred feet) on to the next road I want to follow just after where I need to turn. Because the way-point is so close to the turn the direction arrow will always point in the general direction that you need to follow along your current road until you get very close to the turn. When the arrow suddenly points to the left or right you know that you need to turn left or right on to the upcoming road. It makes for a much less cluttered screen and is easier to follow with this big arrow but would require to many way-points to make it work where there is a high number of roads near to each other.

jfheath said:

So with the start point - yes, you can skip the start point, but it will take you to the next available point on your route using its own routing software - not your planned route. I now always put my start point away from where I actually intend to start. I always use BaseCamp or Enter the points using the satnav itself.

Click to expand...

Yes, this is what I have been doing with the Nav V (equiv of the ZUMO 590) and it works great. I just had to change every GPX file that I received from others by moving the START point.

With the new Nav VI and the new auto skip waypoint feature I will experiment on my next trip and see how it works. If I am right, I won't have to move the Start point on every GPX file that I download.

Shuey said:

I've been using a Zumo 660 and 665 for years and have never experienced this problem. (The problem referred to is not being able to successfully import routes created in BaseCamp into a Zumo 660 or 665 - see post #18)

Click to expand...

You can import simple routes (origin - destination, or origin - destination with only a small number of intermediate points) from BaseCamp into a 660 or 665. But, if you create a complex route in Basecamp - meaning, a route with many intermediate waypoints or considerable 'shaping' of the route to cause the route to follow roads you have selected, rather than roads that the autorouting logic selects - the route will fail to operate correctly if you transfer it to the 660 or 665 using the BaseCamp application.

The workaround, described in my post #18, is to have both applications (MapSource & BaseCamp) running on your PC, do all the route creation and manipulation in BaseCamp (if you so desire), then just copy and paste - using the Windows copy and past commands - the route from BaseCamp to MapSource, then send the route to the device from MapSource.

Michael

CYYJ and jfheath, I really appreciate the feedback and will continue looking at routing results with a critical eye based on your information.

However, I'm running Basecamp on a Macintosh then transferring routes, waypoints, etc. to both my Garmins (660 and 665) and haven't experienced the problems/limitations described. I also make sure that map versions match all around. There are occasionally some differences in point-to-point routes generated on the fly while riding between the two, but nothing major.

When the Macintosh version of Basecamp was first released it was fraught with problems and was being updated and improved almost daily, then weekly, then monthly, and now, for quite some time its been stable with no new updates (and I guess there won't be any more). They've worked well for me during many multi-day rallies to include two IBRs. Hopefully the route planning gods will continue to smile favorably on my equipment.

Shuey

I was very involved with Garmin's development of GPS navigators for motorcycles from 2002 to 2008 (see attached story from Garmin's internal newsletter), but have not been active with Garmin since 2008. I do recall that each time I received a new pre-production device to test (these included the 25xx, 26xx, 27xx series, the 396 ad 496, and the very first Zumo) there would always be small issues between the new device and MapSource that had to be worked out and would result in a MapSource update before the product was released.

Back in the day, those of us who used GPS on motorcycles were very much the "early adopters" and we would create our routes on a computer and then download them to the device. Today, I think that a much smaller percentage of users create routes on a computer (ST riders being, perhaps, the exception), and as a result, Garmin does not get as much feedback from the field about little issues like this.

I agree with John Heath - the cause of the intermittent glitch when transferring routes from BaseCamp to a 660 or 665 is probably a result of Basecamp recognizing, working with, and downloading 'road attributes' in the cartography that did not exist when the 660 and 665 were released and/or the 66x series software was last updated. For example, today, most tunnels have a (invisible to the user) road attribute that tells the GPSR that the section of road is a tunnel, and to not expect satellite reception while in the tunnel. This is why today, with current hardware (e.g. a 590) you usually won't get a "Lost Satellite Reception" message in a tunnel as long as you are moving at a speed close to the posted limit for the tunnel. Instead, the device will show you continuing to progress through the tunnel, even though it obviously has no satellite reception. It is probable that older devices such as the 66x don't support similar recently-introduced road attributes, and when one gets used to create a route in BaseCamp and then that route is downloaded to the 66x, that's when the route fails to load on the GPSR.

Michael

I remember testing one model - I think it was a 2650, but I can't recall, it was a long time ago - that had an internal accelerometer in it (a MEMS sensor) to sense yaw (turning) and also had a hookup to an outside signal to provide wheel speed to the unit. The idea was that when satellite reception was not possible, the unit would still display accurate speed and heading data to the rider.

I hooked the speed-sensor input line up to the front wheel ABS Hall sensor on my ST1100 - that wiring harness is still on my ST 1100. The device self-calibrated (easy enough for it to do when it had a valid satellite fix), and speed measurement worked perfectly in tunnels and urban canyons. Distance travelled could then be derived from speed.

All hell broke loose when the unit tried to sense heading changes, though. When installed in a car, which is not subject to leaning in turns (unless it is on a NASCAR racetrack), the single accelerometer detected heading change quite well. But, on a motorcycle that leans going into and coming out of turns, it didn't work very well. We concluded that it would require 2 accelerometers to measure yaw & roll for the device to work reliably on a motorcycle, and the idea got scrapped. Now, 10 years later, the road attributes in the cartography tell the unit when it is in a tunnel, and the newer devices just do a bit of predictive math to display estimated speed and position.

Michael