SnoWake

Echoing sentiments above... I'm not making any excuses, or rationalizations, or dismissing that there are, in fact, some issues with the Colorado. As recounted in another post, my early 60CS, AND 60CSx, both had a variety of flaws - some, perhaps, more significant than any we've seen in the Colorado: Anyone remember the lockup when switching between follow road and off-road navigation? 100% reproducible, and I still remember the manual work-around I had to follow to keep from hitting that nasty bug. Regardless - I was happy to have the new features and functionality the unit provided. And this is now how I feel about the Colorado: Not having to carry my Palm to have all the cache data at my fingertips? A huge benefit, in my book. So - I'm a satisfied customer - and, if I had it to do all over, I'd buy the Colorado again. In the first week I had the unit, the first firmware upgrade was released - and I'm confident that Garmin will continue to chip away at the list. Just through these forums and the support of fellow cachers, I've been able to learn (and share) enough about the Colorado to make it a useful, and viable geocaching and navigational tool. I look forward to the ongoing refinement and feature introductions, and to providing my feedback to Garmin to help influence the prioritization of of the fixes/enhancements. Alright then -- let me have it!

I realize now that my previous issues had already been mentioned (or at least, were already on GO$Rs list). I've tried searching the forums, and haven't seen discussion of the following point. While this may be expected behavior, it's definitely a change from how previous units behaved, and I can't find any rhyme or reason to it. Simply stated: The specific geocaches (when uploaded to the unit as waypoints) which are displayed on the map at any given zoom level may change. Meaning: If I start in zoomed all the way in on my house, and then zoom out until I can see the nearest caches - well, I see the NEAREST caches. I can zoom out a few more clicks, and still see the nearest ones, as well as the ones exposed by the now larger zoom level. All makes sense... Then, I get to a certain zoom level - and the 'nearby' caches seem to disappear. It's not JUST the nearest ones - but rather, just 'random' (?) caches around the map - it's just most obvious with the nearest ones, given the nature of 'zooming out'. This may not make much sense - so I'll demonstrate. Note the zoom level - these 4 screen shots should be read left to right, top to bottom (1.2m, 2m, 3m, 5m scales). You'll see in the first three zoom levels, there are caches to the NW (RyansHope and its neighbors). You continue to see these caches as I zoom out -- until I get to the 5m scale. Suddenly - those (and several other caches that were visible on the previous zoom level) have disappeared. Its as if - perhaps there's some limit on the MAX number of waypoints it can/will display on the map at any given time - so, as more and more become visible, some have to disappear? I've seen this behavior in Google Earth (the KML geocache viewer) before - but I've never seen it exhibited on a GPSr. Usually, the screen just gets more and more cluttered as you zoom out, until it just looks like one solid mass of caches. I haven't tested the same issue when caches are loaded as POIs rather than Waypoints. I'll test that next... Anyone else experiencing, or have an explanation for, this behavior?

Here's a couple more for the running list - seem to still exist after the 2.3 firmware upgrade: - Wherigo cart "crash" - this has happened to me twice, playing the tutorial, 'play anywhere' cartridge. - particular geocaches cause the unit to lock up when selecting "View Description". My current theory (not yet tested) is that caches with special characters (e.g. "&") in the name. Thanks to all for all the testing, documentation, and feedback. I'm off to check out GO$Rs FAQ and Issues/feature list.

Ditto: I'll be there, too - with 400t in hand, and a laundry-list of issues. Looking forward to what kind of responses we here, now that the unit is "out in the wild". I wonder if the Wherigo cart I've downloaded in the South Bay is at/near the event?

Another fairly major point: So, I picked up a 2GB SD card yesterday - figuring, there was no point in needing 4GB (at least, currently) based on the following reasoning: -2GB SD cards are CHEAP - got mine for $15 @ Fry's, and I'm sure they can be had for even less. - With the ~3GB of topo maps already loaded - I could City Navigator2008 data for the entire continental US - plus tidal data/marine services, National Park 24K topos, and even SnowRanger ski resort maps - all in less than 2GB (still leaving plenty of internal memory available, as well - say, I wanted to load up some Blue Chart maps, etc.). Or - so the theory went. Until I tried it... I assembled all the maps into a 1980MB dataset in MapSource, and sent it to the external SD card. It crunched (somewhere on the order of 5 hours) building the mapset and index files, then pushing the data... but in the end, it appeared to be successful. Until I tried to use the unit. So far, I've been unable to get it to complete a Power On cycle - just gets to the "Loading Maps" stage, and hangs. I know, it took a LONG time here already - but now, I'm talking about waiting 20-30 minutes... and nothing. Have to take the batteries out to resume. But wait - it gets worse (?): The device also will not complete going into Mass Storage mode when connected to the computer. Gets as far as the: "Saving all waypoints, routes, and triplog information in GPX format: 1% complete" and just hangs. Again - battery removal required to reset the unit. So, I removed the SD card, and tried again. WHEW! The device was 'back to normal'. No idea if it was a matter of the shear volume of maps/data, or some particular mapset, or combination - or even the fact that they were written to the SD card. Warrants further investigation - but for now, I think the best approach is to load JUST the data I anticipate needing (it's not like I take unexpected trips to North Dakota, for example) - all of which easily fits within the ~1GB of available internal memory. So - who needs an SD card (at least, until the unit can cope with that volume of data)? More to follow...

I'm still not QUITE sure I exactly follow - but, if I'm understanding you, I think the answer is "yes": The 400t will have the entire US topo maps, pre-loaded. So - if you added your City Select maps into the unit, as well - you would have both available to you, and be able to switch between them, depending on your purposes. To your second question: I definitely use the City Navigator maps most often, but it's not at all unusual for me to toggle over to look at to Topo map if I'm out on a hike, and terrain may be relevant. This was even with the old Topo maps, prior to the DEM shading - which, as I've noted elsewhere, I think makes a HUGE difference on the usability / information conveyed by the map. So - you might still use your City Select maps for most of your caching - but (at least with a 400t), you'll always have those topo maps available. This may be a pro, or a con, depending on your perspective and use cases. Well, I am convinced, at this point, that Garmin will release multiple firmware updates in the not-distant future - just based on past experience. However - if you're in no hurry to get a new unit, you can certainly just "wait and see" what happens. I was perfectly content with my 60CSx - but couldn't WAIT to get my hands on this new unit, and put it through its paces. One final point: There IS a workaround that allows geocaches to be seen on the map - at least when they're sent as waypoints. No need to do the POI thing - though I've definitely been experimenting with every possible way to send data to the unit. That is - until I encounter somebody else holding one, and finally try the "wireless transfer" bit. I'm learning more by the minute.

Interesting - and I've had similar experiences. Here's one aspect I find odd - even AFTER I realized the backlight settings weren't "sticky": It seems that somehow, backlight brightness is not only controlled by the setting - but also, by battery voltage (to a more significant degree than I've noticed in past units). What I mean to say is: With fresh batteries, the unit was useable with the backlight only at 50%. However, as the batteries waned (both with Alkaline and NiMH), the backlight seems to dim (at the same setting) - until I had it cranked up to 100%, which eventually was too dim to read. I guess that's when you know you need to slap in a freshly-charged set... ;-)

I've noticed a couple of new (greater) Bay Area cartridges appear, already. I'm off to play a couple, and am already baking ideas for ones in my area. Time to dive into the builder - and the forums/threads dedicated to THAT discussion. For starters, I'm looking at reviving an old 'take a tour' multi-cache I had in a nearby local park with many diverse attractions - and involving interactions with / details from the real world in order to determine the next location. Hope to get a better idea of what's possible, and how things work in the development environment, here in the coming weeks.

Here's a basic functionality question I've yet been able to uncover: Does the Colorado store daily tracklogs, in GPX format, somewhere (uniquely) accesible? Clearly, they're in there, somewhere... but, not like on the 60CSx, where, in USB mass storage mode, there was just a directory full of: <datestamp>.GPX files, one for each day I had the unit turned on. VERY convenient for use in geotagging digital photos - or even just for fun, to look at a day's travels on Google Earth, etc. Based on other hints (e.g., the message displayed when attaching the USB cable) - I would guess tracklogs are somewhere inside the file: <device>:\Garmin\GPX\Current\Current.GPX But if that's the case - what a pain! Of course, that feature wasn't immediately available when the 60CSx shipped - so this is the kind of item I can hope to be fixed in subsequent firmware releases. Time to go add it to the list in that thread... Or: Am I just missing something obvious, and it's right there in front of my face? I've checked the setup: Shortcuts-> Setup -> Tracks Configured as follows: Track Log: On Record Method: Auto Interval: Normal Show on Map: On I did see, from this page, under the Options menu: Archive Current Track Which allows me to select start/end points of the current track, and save it as a file (filename defaults to the current date). This resulted in the tracklog GPX file being written to: <device>:\Garmin\GPX\2008-01-20 79468.gpx Not sure what the additional 5-digit number represents - but at least this is a workable, MANUAL solution. But - that means I have to proactively remember to perform this task, when I might want to use the tracklog - as opposed to just going to the folder and picking out the file (date) I'm interested in.

Anders- Thanks for the info. Firmare 2.16, huh?? Where do we get a copy? Obviously, we just need to stay tuned to Garmin's site, and presumably - with any luck, WebUpdater will learn how to deal with the unit. Anders- Are you using Web Updater, or a more 'direct' approach to installing new firmware? As of this morning - I ran Web Updater, which FIRST checks for updates to itself - and reports, none found. Then - selecting the device [in my case - "Garmin (F:\)"] and selecting Next, reports: "No updates were found for your Garmin device. There may be additional updates, such as voice [?] updates." Clicking Next, this is where I see the error: "There was a problem communicating with the Garmin website. Please try again later. If you continue to experience the problem, contact Garmin technical support". Not sure if this second check is the GPS (receiver) software - which, as I understand it, is new (switching away from the SiRF receiver of the 60CSx) - and so, perhaps, not 'coded for' in the backend of Web Updater, yet? Waiting for 2.2 with baited breath...

Marky- I haven't tried the Mac OSX plugin yet: Did you install it in Safari, Firefox, or both? I installed the plugin under Firefox on Windoze, and just pushed a waypoint directly from a cache page, using the "Send to GPS" button. Looking forward - what a TIME saver this will be, when going after new caches! Rather than pulling the GPX file into GSAK, pushing a new CacheMate database (and having to wait through the long hotsync) and a new set of waypoints to the GPSr (selecting the closest 1000) - it can be one-step, and GO!! I'll fire up the Powerbook and give it a go - but for reference, when performed on Windoze: The resulting file is: <Colorado drive>:\Garmin\GPX\<GCID>.GPX For example, I see the one I just pushed at: F:\Garmin\GPX\GC18MAX.GPX And the geocache appears, alongside all the other caches, by distance/name, in the "Shortcuts-> Geocaches" list. I'll let you know what I find when I get around to trying it on the Mac.

Yes, the Colorado has this feature, as well - though, it seems to behave a bit differently? As you mentioned - in the 60-series, there was a 'hierarchy' of maps, and if you had multiple layers turned on (most notably, Topo and then, say, City Navigator) - you would waste a tremendous amount of time as the unit would draw the topo screen - and then simply "overwrite" it with the CN map. Well, on the Colorado, I can turn map sets on/off still - but, they seem to sort of be 'concurrent' - for example, if I have both CN2008 and the built-in topo maps turned on - I still see the DEM-shaded topo map detail - and yet, the unit can perform turn-by-turn auto-routing. Haven't quite figured it out yet, though... Similarly, I'm not sure I fully comprehend the changes around the different Guidance Method and Off Road Transition settings - even after reading the manual, and some brief experimentation. I've got enough questions/observations about that, it's probably worthy of a post of its own.

INTeresting! There's a little detail I never realized - and suddenly, my eXplorist envy over that feature is somehow diminished. As to finding the multi with nothing but information on a single unit: NICE! Now that's what I'm talking about...

I couldn't agree with you more - but I'll add the following observations/perspectives. Not to defend the current behavior, but its likely a by-product of when, given the current architecture, the maps NEED to load (at startup time). Your point and suggestions are well-founded, and we've wrestled with the same problems at work, sometimes: Can't we display the basic portal application to our customers, once they've logged in - while we're off fetching their specific usage and payment information? Why make them wait - while displaying "Accessing your personal information - please standby". If designed correctly (assuming user experience is your top priority - which, clearly, in not always the case) - You would provide the basic user interface, and continue loading maps/waypoints/etc in the background - only causing the user to wait if they tried to immediately go to one of those functions/displays. Problem is - things are often built for optimal machine efficiency: E.G. "Well, of course they have to wait - because we need to initialize all the maps BEFORE we start acquiring satellites, all before the user can actually navigate somewhere". So - we provide our feedback to Garmin, and let them know what is important to us. With regards to the L-O-N-G overall startup time, it's already been said by others, but... I'm willing to live with this, and consider other fixes a priority. The good news is - you only suffer this penalty occasionally - perhaps as infrequently as only once, at the beginning of a caching session or navigation to a location. I, too, want a shorter startup time - but, IMHO, this is less critical on a device like a GPSr (perhaps just need to establish a routine where I turn on the GPSr, THEN fasten my seat belt, start the car, and... by the time I'm at the end of the street, I should be good to go). Conversely, on devices like a digital camera, where timing can be critical - I consider this a purchase-influencing factor. It sure would be nice if, for example, you have a BUNCH of maps loaded (because you CAN) - but the unit would only 'index' / load (whatever is causing the time penalty at startup) the map sets that you have selected as active. I've already confirmed (by deselecting all maps) that this is NOT currently the case.

I haven't really seen this detail discussed, amidst all the swirl around the new Colorado. Those who just got their hands on the units (and the few that have had them for a bit longer) have discussed all the limitations / shortcomings (as well as the new features) - and many (myself included) assume that much will be resolved in what will no doubt by numerous firmware updates in the coming weeks/months. I'd guess even MORE than we saw with the 60-series, as it's an even more dramatic shift in the User Interface. SO: The purpose of this thread is to note, and discuss, "current" versions of the firmware: What works, what doesn't, and any workarounds, if available. If the moderators feel this just belongs under one of the existing Colorado threads, I'm happy to see it move to an appropriate home. SHIPPING VERSIONS (at least, this is what was loaded on my unit, purchased from REI in Berkeley, CA) Software Verion: 2.10 GPS Software Version: 2.50 For starters - is this what others have, as well? This information is accessed via: Shortcuts-> Setup -> System -> Options -> Software Version I tried using Web Updater - it first reported I was running the current version (perhaps software version?), and then, threw an error and died (perhaps when it came to checking the GPS software version?). Going to Garmin's support / download site - they don't even LIST the Colorado line yet: http://www.garmin.com/support/blosp.jsp So, for the current version - what are the major gripes / shortcomings? In my mind, there are two categories: Obviously missing, core functionality that needs to be provided, and Nice-to-have or expected features in a next-gen unit So, in the Obviously missing category: Ability to show geocaches (loaded via GPX file) on map Ability to control (turn off) digital compass Ability to mark a cache as found I'm sure there are more - so let's hear them! In the 'expected' list - there are many items, JUST to get this unit to a point where it's providing the base functionality users had in previous models (e.g. 60-series) - not to mention the expectations one might have of a "next-gen" unit: Basic 'geocaching' mode functions: Find nearest/next, select by symbol/type, etc A 'calendar' (60-series) or journal of found caches - IDEALLY in chronological order Quick toggle between 'follow road' and 'off road' routing Like I said, THIS list will be long - I just seeded it with a few obvious examples. Finally, the "workarounds" section: Everyone expressed frustration with the lack of visibility of geocaches (whether loaded as waypoints or POIs) on the map. It seems the "Auto" setting for user waypoints is not functioning properly - the workaround, documented in this thread and others, is to just manually set the zoom level for user waypoints. This seems to effect the visibility of both caches pushed as waypoints (e.g. via MapSource), as well as custom POIs. Others? For starters, does everyone (except perhaps some early testers) have the same version of firmware on their units?

Interesting: I registered, using that number, without incident. Well -- or so I thought! I just logged into "MyGarmin" - and while the new Colorado is shown on the right under "Registered Products" - suddenly, all of my previous units are gone. Hmmm... ?

On a similar, related note: The biggest limitation I encountered, map-wise, on the 60CSx was not that of storage SIZE - but rather, number of map files. I don't remember the exact limitation off the top of my head - but with and earlier version of City Navigator (not NT) and the old Garmin Topo maps - I ran into the FILE limitation (I believe it was a little over 2000 - but not a nice, round 2048?) before I hit the space constraints of my microSD card. I don't know how many specific files comprise the built-in Topo2008 maps - but between that, and the big chunk of CN2008 that I've got loaded - I'm guessing they've worked around that. Being an old-school UNIX guy, when I experienced the first limit, I couldn't help but think: They need to up the file descriptors (fdlimit) :-) Another tangent: Has anyone noticed, or NOT noticed - any direct correlation to the amount of data loaded (e.g. City Navigator) and the response time of related functions (e.g. "Find -> Food and Drink" or "Address search", etc)? I seemed to experience this problem in the 60CSx when having a HUGE dataset loaded - which led me to the practice (as described by someone in another thread) of "just loading my home turf" by default ('home turf' being defined as CA, NV, OR, WA - both CN2008 and Topo) - and then loading specific mapsets when I travel out of state/country.

And, to answer an earlier-posed question: No, de-selecting mapsets (e.g. CN2008, and/or the built-in Topo2008) does not seem to have an (at least, significant) effect on startup time. Now, not HAVING them there... that would probably reduce the startup time. ;-) Seems it crunches them, at startup, whether enabled, or not...

Not that I've been able to discover. But, at least sending via MapSource, there's an option - just a loss of granularity on the custom icons. At least caches look like treasure chests, parking and trailhead symbols are appropriate, etc. It's a START...

Here's the event page: http://www.geocaching.com/seek/cache_detai...5a-714434d40cff That's about all the detail that's available, that I know of.

The issues were with the odometer not reading at slow speeds. I think the current firmware on the HCX still won't read below 1.1mph. This normally isn't a big deal but if you are using detailed topos then you could be climbing steep mountains and going very slow. There also seems to be an issue with max speed being glitchy. Some people have done hikes where their max speed was reported as high a 90mph. So maybe you can check this stuff out. It's very possible that the Colorado could be using a newer version of the chip that addresses all of those issues. I was thinking that is was a hardware issue all along. Interesting - I'll definitely keep an eye on this, as these are stats/values I often pay attention to. I had noticed, out caching with a Magellan user, that our units (Garmin 60CSx / Magellan Explorist 600) consistently read significantly different odometer / trip meter readings, both when hiking on foot, as well as a day in and out of the car. Of course, minor differences would be expected - but these were often signficant, to the difference of more > 10%. Since I'll be carrying the 400t alongside a 60CSx for awhile, I can do some side-by-side comparisons of track logs and trip computer calculations - thus comparing both the hardware and algorithms/logging in both units.

The Waypoints do display on the map. It is a "bug", see the instructions below to adjust the display settings....as given in another thread. Thanks - I remember seeing this while reading the forums, BEFORE I got my unit yesterday - but had forgotten about it in all the excitement. Interestingly, I HAD played with that setting, but guess I never cranked it out far enough, but... It seems to have turned on MORE than just the "User Waypoints". Oops - wait: the problem is that I'd cranked the "Detail" setting up from Normal, to Most, in an attempt to see POIs. I've set it back to Normal, and now - it's what I (we?) want: Caches shown on the map - in my case, both the POI ones w/ custom icons, as well as the closest 1000 waypoints, send via MapSource, with the treasure chest icon. They show different information when "moused over" or clicked on, with waypoints showing more/better formatted information than the POIs. The ideal functionality (IMHO) would be linking from the custom icon on the map, directly to the "geocaching data" (e.g. entire description, logs, diff/terr, hint, etc) - with an easy way to get back (there doesn't seem to be the notion of a "quit" (/escape/back/triangle) button, as there have been on all previous units? Except when one of the softkeys changes to "done" - but that's a little different, I think. ANYway... thanks for the reminder! The device just became INFINITELY more useful!!

Well, here's what motivated me. And, you have to keep in mind, that this is EARLY rev firmware. I don't know about you, but when I first received both my 60CS, and then 60CSx, each had unique (and some significant) problems around functionality, lockups, etc. So - based on my past experience with Garmin, my assumption is that much of this will be fixed in what are likely to be imminent (and probably frequent, for awhile - I remember an upgrade or two that actually made things worse ;-). SO - why would you consider one, for caching: Geocaching data. As a heavy CacheMate/Palm user, I (and many others) have already commented that the current 'geocaching' capabilities fall well short of the mark, without being able to mark caches found, time/datestamp for chronological logging, etc, etc. BUT: Having the cache data in hand (in a single, compact, WATERproof unit), rather than digging into my pack and pulling out the Palm - is a HUGE benefit. I know, our Magellan brothers have had this feature for years, but - it's new to Garmin. The 400t has 4GB of internal memory, as opposed to the 64MB or zero of the 60CS/CSx. Peel off the ~3GB used for the built-in Topo 2008 maps, and you've still got over 1GB of available INTERNAL memory - before you even add an SD card. It looks like I can load the ENTIRE (continental) United States (City Navigator 2008) on a 2GB card. From a practical perspective, while I'm still understanding the performance implications of having all this data loaded (think about it: Find -> Food -> Restaurants -> Find by Name would search/sort/list restaurants across the ENTIRE US??) - and deciding on the "right" amount to carry, for day to day use, and know that I'll push another mapset when I travel out of state, to Europe, or ... While the topo maps have the same 'resolution' (e.g. 100K) - the addition of the DEM (Digital Elevation Model) shading is HUGE. From my perspective, this shading, even with the less-granular elevation lines, provides a FAR enhanced perspective of the actual terrain (hills/valleys/etc) than even the more detailed (e.g. 24K National Park Topos) "flat" topographical maps. Then new interface, while it definitely needs some work, is pretty 'sexy'. It's the most significant UI change I've seen in my experience, dating all the way back to the mid-90s and the 48 - more dramatic than even the jumps from the GPS III to a Vista, or from the Vista to the 60CS. The "rock-n-roller" shines the MOST when it comes to zooming in/out on the map. It's also a directional joystick, and select button - combined with the two softkeys, I've been able to access all the same functions, with fewer 'controls'. As I mentioned, some features are a bit more 'obscured' in the new interface than I might prefer. THESE things can be updated with software. So - those are some of my observations, so far. But, to your point: As it exists today, I would be a 'frustrated' cacher with the unit, and intend to use it "side-by-side" with my 60CSx (AND CacheMate on the Palm), until these issues are resolved. I'm headed to Palm Harbor, FL next week to present at a conference - and will be dragging both units along. I actually believe that a single firmware upgrade could make a huge difference: Just being able to see caches on the map, and mark them as found (ideally with "find next" type capabilities in the 60CS/x series). Just one guy's observations/experiences...

DUH. I went back into Mapsource, and saw that is showed both the Garmin (internal memory - in my case, Drive F:\) as well as the SD card (Drive G:\). I just pushed another City Navigator 2008 mapset, this time to the SD card - and have no problem accessing it. Or... perhaps it's still just seeing the first set I pushed, which is on the internal memory. More testing required... I was assuming you had used an unlock coupon, or (as in my case), purchased an additional unlock code for your particular unit and mapset. As a side note: Startup time seems directly effected by the volume of maps loaded (as indicated by "Loading Maps" during startup). This shouldn't be surprising - but, it is FAR more obvious and extreme on the Colorado than, say, on the 60CS/CSx.

Quick update: YES, a quick change to the "Automotive" profile adds some additional items to the 'Shortcuts' menu, specifically: Active Route Route Planner Active Route shows the turn-by-turn directions, similar to what the 60CSx displayed. I couldn't find the ability to change between "leg distance" and total distance, nor does it seem to show remaining travel time nor ETA? That seems to be an oversight - though I'm hoping/assuming I could display those items as data fields on the map page? More things to try...