Mac/Windows Software

Basecamp Windows BaseCamp flagging intersections on Zumo 66X

BaseCamp flagging intersections on Zumo 66X

MXCHNEY over 12 years ago

People riding MC like routes on twisty roads but don't like the Zumo display being cluttered with flags and the headset announcing route points not needed. We used to be able to prepare routes in MapSource with viapoints on intersections. That would prevent flags and announcements for the Zumo 66X and Zumo 550. With BaseCamp that does not seem to be possible anymore. We had a discussion on that on the Zumo Forum from where I quote:

quote ..

I noted the suggestion by Dave that it could be a problem with BaseCamp. I normally make and modify my routes in MapSource (taking advantage of snap-on to intersections) and then copy/paste the route to a list in the BaseCamp database from where I download whatever routes I want to the Zumo.

I made a test by downloading the route to the Zumo directly from MapSource bypassing BaseCamp entirely. Guess what - no flags except my one intentional waypoint.

It does appear that BaseCamp does some strange things to route points, both via and shaping, that cause flags to appear on routes in some random fashion on the Zumo 66X. I really like the folder/list structure of BaseCamp and would hate not being able to use it.

I plan on raising this concern also on the Garmin BaseCamp Forum.

.. unquote

I attach two screendumps, one with the route downloaded from BaseCamp, the other from MapSource. BaseCamp is V 4.1.2.

Please make BaseCamp consistently honor the intersection facility for non-announcements when downloading routes to the Zumo 66X/550. If BaseCamp would also allow the snap-on facility then I could drop MapSource entirely.

0 Former Member over 12 years ago

I would like to put my voice for this proposal as well. On previous incarnations of BaseCamp, the shaping points would sometimes be without flags, and on others it would be shown. It is rather disturbing to have "You are approaching waypoint, you are at waypoint .. " in your ears. It is rather irritating, and totally unnecessary.

Can you please either persuade the 660 team to update the Navigator IV / 660 to handle BaseCamp correctly or correct BaseCamp (or even both!)

Thanks very much

0 Former Member over 12 years ago

We'll try to find some time to look into this.

0 C14_Rider over 12 years ago

We'll try to find some time to look into this.

Falagar, I must offer a gentle reminder that the lack of, and value of, the snap-to function in BC has been discussed extensively on this forum, as recently as one month ago, when you agreed you would try to bump up the priority of getting it added to BC. (See https://forums.garmin.com/showthread.php?37494-quot-Snap-to-quot-Status) The comments above reinforce once again the need for this by the Zumo community. I urge you to consider this as a serious bug rather than a feature add, since it is a significant take-away for those of us who use or used MapSource and shaped routes frequently using intersections to avoid announcements.
　
I believe there are two matters that need addressing to make BC work like MS did, one is the visual snap-to itself, and the other is to program BC to allow intersections that are used multiple times, and may therefore have the numeric suffix added to the point description in some of the cases, still sent to the device as a standard intersection so the firmware in the device can interpret the point as a valid non-announced intersection.
　
I hope you can offer us some encouragement that this will be addressed sooner rather than later. Honestly, I am not trying to whine. I am a BC-only user now, despite the challenge of getting intersections selected properly. But I think you have a chance here to make a lot of customers happy.

0 Former Member over 12 years ago

Use Route Properties to change Via Points into shaping points - will Zumo honor them?

In BC, when I double click to open a route (Properties, Route Directions, Route Options, ... etc) I see a list of the Via Points and their symbols in the Properties tab. Some of them are 'light gray' with "(won't alert)" after the via point name. I can right-click on any intermediate via point in the route (not the first or last) and I'll see one of these options: "Alert on Arrival" or "Don't Alert on Arrival (shaping point)". You can toggle a point between these two options. I believe I did some tests once to see what the Zumo did with such a route, but (sigh) I do not remember the outcome. I'll try to do it again. But if the Zumo announces on a point that says "Don't Alert", then that is a bug in either the route code generated by BC or the Zumo when interpreting it.

Now, ....
It seems to me that what is desired is a way in BC to add points to a route in a manner that automatically makes them via points with the "Don't Alert on Arrival" characteristic.

Does that sum it up correctly?
-cj

0 Former Member over 12 years ago

The problem with the "won't alert" setting is that the older Zumo models do not support it (it only works for some, I believe intersections and address points). I am under the impression that the newer Zumo models (the 350) should support it fully. Can someone confirm this? BaseCamp writes a shaping point extension and only the 350 can read it. We do some special massaging to support the older models as well as possible.

We'll look into the issues mentioned in this thread for one of the next feature releases. Unfortunately I cannot make any promises when exactly this will happen, sorry. But I'll try my best to push it up the priority list.

0 Former Member over 12 years ago

Falagar,
I do not have the zum350 but what I read in the Dutch fora is that the Zumo 350 fully supports the won't alert feature. Support for the Zumo 660 would be very very nice.

Kiind regards

0 Former Member over 12 years ago

Falagar,
I do not have the zum350 but what I read in the Dutch fora is that the Zumo 350 fully supports the won't alert feature. Support for the Zumo 660 would be very very nice.

Kiind regards

I add my voice to this. It gets really annoying to constantly hear waypoints that are merely routing points. It also makes it hard to understand what the route really is when going through an intersection more than once with overlapping waypoints (the Zumo 660 will warn that I'm approaching a waypoint but won't tell me the actual directions through this intersection).

0 MXCHNEY over 12 years ago

Falagar,
I do not have the zum350 but what I read in the Dutch fora is that the Zumo 350 fully supports the won't alert feature. Support for the Zumo 660 would be very very nice.

Kiind regards

The 350 has a different microcode from the 660. Interpretation of routing files is device specific and Basecamp can't make up for that. What Basecamp could and should do however, is to generate a similar routing file that MapSource does when transferring a route with viapoints on intersections to the 660. MapSource transfers a route with no flags and and no announcements on intersections that are viapoints.

0 JaVaWa over 12 years ago

The problem with the "won't alert" setting is that the older Zumo models do not support it (it only works for some, I believe intersections and address points).

No, it works a bit differently.
On de zumo 550/660 via points won't be announced when they are put on a intersection, or on a road section without an address. The distinction lies hidden in the subclass code of the via point. This doesn't work anymore when you move the via point; it gets a generic subclass code (000000000000FFFFFFFFFFFFFFFFFFFFFFFF), apparently caused by the lack of "snap to road", and will always be announced.

Now, I observed the following phenomenon: When you put a via point on an address point and set it to "won't alert" the zumo 550/660 doesn't announce it! This is not caused by the shaping point extension (the zumo 550/660 does not understand that), but because the subclass code gets changed too. Unset "won't alert" doesn't revert the change in the subclass, so the effect is permanent (until you move the via point).

A lot of users have used "unflag" programs (that haver their drawbacks) to get rid of the annoying announcements, but actually all it needs is a change of the subclass; something that should (and could) have been possible with MapSource a long time ago...

0 MXCHNEY over 12 years ago

Thanks for your insight and observations, Javawa. I'm trying to understand the implications of your statements. I think we agree that a route created in MapSource and transferred from MapSource don't get announcements on the Zumo 550/660 if via points are on intersections or on road sections with no address. It is my observation that this always works for MapSource.

BaseCamp is a different story. My experience has been that it is somewhat random whether such via points get announced. You are saying that moving such via points will cause announcement. During route creation I often move via points to shape the route. This could be the explanation for the seemingly random behaviour. The random announcement problem exists also if a route is created in MapSource and then copied to BaseCamp for transfer to the 550/660.

So what is your advice for route creation in BaseCamp for Zumo 550/660? Put via points on intersections or roads with no address and then never move them? Your other suggestion to put via points on addresses and select "don't alert" would work on Zumo 350 but are you really certain about the 550/660?

What should the BaseCamp team do to help users of Zumo 550/660? Implement snap-on as for MapSource and review the subclass codes generated by BaseCamp?