SnoWake

I have also experienced this: Both the bold text 'gumming things up', as well as certain formatting / text that cause the Colorado to lock up 100% of the time when viewing the description - e.g. the following cache: http://www.geocaching.com/seek/cache_detai...8a-f21640c45230 I've no idea how much of the XHTML, CSS, etc actually make it all the way into the GPX file (haven't done the research) - but I know there's a series of caches from this hider, all with the same look and feel - and they all hang the Colorado, consistently. All the more reason to find them, and have them 'off my list'. ;-)

Just a quick confirmation: As suspected by all, GPX files containing caches (either PQs, or generated by GPSBabel, GSAK, etc) must be placed in: [sD Drive Letter]:\Garmin\GPX I tried placing a GPX file in the root folder of the SD card - no dice. Of course - I had to go GET my SD card, for this experiment. With the copious amounts of memory on the 400t, I haven't needed it for anything yet. Now, if we could get some "eXplorist-like" functionality, but with datasets of 2000 caches - and have 2GB worth on the SD card, and just toggle between data sets... that would be pretty slick.

Greetings, Othum- Can you look at the geocache_visits.txt file with an editor? Are there "Found It" records inside - specifically, ones that are not later trumped by a "Didn't Find It" record? Another relevant point: Are you checking, or clearing, the box on the upload page which asks if it should "ignore caches older than <date>" If you've got entries in the 'log' file, and aren't ignoring them at upload time - I'm not sure WHY they wouldn't show. Are you uploading a 'vanilla' file, as generated directly by the Colorado - or are you manually or programmatically generating one, and trying to put Log Data in that final field? My limited experimentation with the latter has shown that I was able to cause the import to fail based on the volume and specific content of my log text. Not sure what problems you're having or the problems you're experiencing. Let us know...

I guess it shouldn't be surprising, that I've have this very same discussion with my fiance. I'm definitely a "north up" guy, and having the map "pan" around me is totally disorienting, and doing the 'correction' to determine a mental 'track up' image (e.g. is that a left or right turn, coming up?) is second nature. Conversely, Daphne absolutely prefers "track up", which seems absolutely intuitive, and 'correct' (it is, after all, exactly aligned with how you're "seeing the world"). I have to concede to that perspective, but have struggled dealing with the rotating map, or, for example, seeing the SF Bay Area "upside down", with the pacific ocean on the right side of the map. I'm using "Automotive mode" to ease into track up - at least that unique perspective lends itself to that orientation.

I totally understand this, from a conceptual perspective: save the timestamp in an unambiguous format which does not allow for variation in interpretation: Zulu time is Zulu time, and then, you can always convert it after the fact... Provided, you know the time zone offset - at THAT point-in-time / location. So, when I was caching in Florida a couple of weeks ago - these same timestamps represent a different 'corrected' time given the -5:00 offset, as opposed to my default -8:00. While we can always calculate it after the fact - it requires that we track another data element, per record (e.g. TZ Offset) - OR, get really fancy, and calculate it, based on location, date, etc. So, I totally agree with you - timestamps really SHOULD always recorded in 'absolute' time (syslog in GMT, etc) - but, for such a mobile activity as caching, with the possibility of time zone offset changing from find to find (or at least, outing to outing) - I would like to store the corrected time zone (and corrected date, when the time math pushes it into a different day). Again - to each is own. It totally depends on where and how you want to process, and consume, the data. I'm digging converting the zulu time to a "local" date/time, and inserting it into the notes field in GSAK to serve as fodder for my log. Feeling pretty good about the functionality with the import macro - I'm starting to think about what Alan has described, in using geocache_visits.txt, and the online interface which consumes it, as a way to further automate and idiot-proof my current logging processes. Has anyone determined a maximum length for this field in "geocache_visits.txt"? One would like to assume it would match the maximum length of a log submitted via the standard online logging form, but I haven't even begun testing that. Also, I've been working hard to keep my head in the sand about the UTF8 / UTF16 issues around this file, and what needs to be uploaded to geocaching.com. Ignorant of the issue or not - it's time to start learning.

In my opinion, definitely "ready". Done? Absolutely note. But as Marky already pointed out, each of the MAJOR shortcomings were addressed - and the new "FieldNotes" logging on the unit, and the associated interface on geocaching.com - I'm REALLY excited. For now, I'll still need my Palm to record TB/Coin/Sig Item #s, and any brief notes. However, the 'logfile' generated on the Colorado already has an 'empty field', so I'm sure that capability will be coming soon (though no matter HOW you slice it, data entry on the Colorado is ALWAYS going to suck when compared to same on a Tungsten C, or other 'full keyboard' device). Here's an idea: How about a wireless keyboard that utilizes the ANT protocol on the same wireless interface used by the heart rate and cadence sensors?? Back on topic: The unit was barely usable w/ the 2.3 firmware (LOTS of workarounds required) - but 2.4 introduced "consumer-grade" (as opposed to early adopted grade ;-) functionality. Still various issues, to be sure - but my 60csx hasn't made it out of the pack for a week or so. With the Colorado, you can carry 2000 caches, with complete description, logs, hints, etc - and then mark them as found (or DNF, or Needs Maintenance) in the field - even if it's raining, like it has been here in the SF Bay Area this weekend. I was always protective of my Palm in weather - but you expect a GPSr to be able to survive a little rain. Come home, plug the GPSr in, and upload your finds - that's all pretty convenient, and with fewer complexities/moving parts that using a Palm, CacheMate, Hotsync, and a potentially long list of other tools. I'm looking forward to continued refinement, feature additions (that Issues List is LONG - while the heavy hitters are mostly cleared (at least, from my perspective) - there are still some basic items that need to be addressed, before we get to the feature/enhancement requests, that will likely emerge over a fairly long lifecycle. Here's hoping for several quick successive updates though - chipping away at the list as they resolve them.

Hi Allen- I think that would be a feature request for geocaching.com. Of course, as noted, it's not as simple as taking the date from the geocache_visits.txt file - since this is based on Zulu time, and hence, may not even be the correct date, much less, time. Which gets back to a Garmin feature request: Since the GPSr most certainly knows the CORRECTED time/date (given the current time zone offset) - why not use THIS value for logging in the geocache_visits.txt file, since it's almost certainly 'more relevant' to the action (finding a cache). Not to get 'off topic', but in the interim, I'm dealing with both these issues via GSAK and macros. Working on making it a bit more 'configurable', so you can stuff the date/timestamp, and any 'notes' (once we can capture them in the Colorado, in the field) into various User Notes / Logs fields, for subsequent logging at geocaching.com (though NOT by using the FieldNotes interface - but the traditional logging pages). Ahh - I think the lightbulb just went on with regard to the question you asked, about GENERATING a geocache_visits.txt file, over in the GSAK forums.

I push a single, consolidated GPX file containing just under 2K caches, from GSAK. I include child waypoints in the export, which pushes the total 'objects' pushed to around 2100. The 1990 geocaches appear, as expected, under the geocaching lists, while all the child waypoints, correctly (IMHO) wind up as waypoints. All of the above - the different cache types, as well as parking coords, trailheads, etc - are all assigned the appropriate icon when displayed on the map. However, when I load that same GPX file, or a direct PQ file from geocaching.com, directly into MapSource - both the geocaches and child waypoints still load, although now all caches are assigned the closed treasure chest, while child waypoints are either the parking icon, or just a square waypoint marker. Loading the main, and they -wpts.gpx files from a PQ yielded the same effect. No Trip and Waypoint Manager for me - in fact, about the only thing I've used MapSource for over the past couple of years is uploading Maps to the various units. With regard to item 3 - it's been an interesting transition. Initially, the dramatic changes in UI, coupled with some key missing features, had me reaching for the 60CSx from time to time. Now that I'm comfortable with switching profiles, and the basic operation of the unit - I'm digging it.

FWIW, and at the risk of getting flamed for cross-forum pollination: Working with the great community of folks over on the GSAK forums, we have assembled a GSAK macro which does precisely that. Virtually all the heavy lifting (especially the SQL code, which I barely understand - but basically, all of it) was provided by lignumaqua - and the current product, while perhaps not 'finished' - is a sight to behold. It's basic functionality (which replaces what I have historically done through a combination of Hotsync, CM2GPX, and the CacheMate import routines in GSAK): Provides a form for user to select timezone offset, and geocache_visits.txt location (sticky) Creates a SQL file of all entries in FieldNotes "Rationalizes" list according to predetermined logic (e.g. found, followed by DNF = DNF) Matches each cache, and flags (Found, DNF) and respective dates Populates the User Notes section of the Notes field with Time/Date stamp Populates Log Section of Notes field with "Needs Maintenance" text if marked Parses still-unused final text field, and populates Log Section with this text (once we can enter stuff there - tested via mockup) Outputs a summary of records and actions Anyway - I realize there's an entire forum, and specific thread dedicated to the topic. But, since it was particularly relevant to this thread - I thought I'd share. How long time we get the firmware that allows us to enter text into that final field? At that point, once I can enter basic notes (TB/coin #s, brief notes)... then, I truly am finished with CacheMate and the Palm. Then it's on to Marky's wishlist above of being able to 'pre-load' TBs/Coins/Sig Items, and just 'select' them along with the field log - not unlike what we do today when logging on geocaching.com. Add a little wireless capability to the GPSr, and... you've got yourself a SOLUTION! Peace, Billy

I can't help but think, just a LITTLE, of the occasional "email storms" that are created at work, when messages are sent to large lists where the recipients may not realize they're on it. This thread is a bit like the: "Please remove me from the list" - done as a REPLY TO ALL - thus adding to the churn, and further responses. A very strange phenomenon, I've always thought. My apologies for my contributions to "all the Colorado threads" - but I've tried to search for another, appropriate thread - focusing primarily on the firmware thread, for version-specific info, the issues/bugs thread, for general observations, and the performance test thread for topics specific to that. However - at this point - you're going to see my activity dropping off a bit, because - this unit really IS all that. I was fired up about the 60-series - I remember the excitement, and how 'revolutionary' auto-routing felt. The Colorado, with it's data-carrying, and now field logging, capabilities - is on the very verge of making my Palm and CacheMate obsolete. I'm FIRED up about it. So sue me. But see - now I'M perpetuating they 'myriads of Colorado threads' problem! DOH!

Hi John- That's very interesting: That's not how my unit behaves, at all. What I find really strange is that in my experience (which, granted, has been almost exclusively with the internal memory on my 400t - with still over 800MB free, I haven't even needed to install the 2GB SD card yet), the GPX file you export to the Colorado is only parsed once (unless it changes) - and loaded into the "Current.GPX" file on the internal memory (e.g. F:\garmin\GPX\Current\Current.GPX. I just tried this, as an experiment: Pushed a GPX file to the units internal memory: F:\garmin\GPX\caches.GPX Rebooted the unit - confirmed that the < 2000 caches loaded as anticipated. Reconnected via USB, and removed the caches.GPX file. Rebooted again: Caches are... gone. So, apparently, removal of the 'source' GPX file, even if it's not being parsed on each startup - is enough to trigger the removal of the caches from Current.GPX. I assume something similar is happening when you remove the SD card containing your caches. But - what process are you attempting, that results in a GPX file pushed to the Internal memory, but no caches showing up? I'm sure we can resolve that problem.

Yes. I'm seeing the same behavior. I'd noticed similar results in 2.3, but there was a LOT of screwy stuff going on with routing, and I didn't pay these 'occasional glitches' much mind. Now that things are settling down, and starting to work more as expected /desired - these smaller issues are able to rise up from the noise floor. I've had to go re-select the cache I was navigating to, and "Go To" again, the restore the auto-routing.

Agreed - I'm seeing the same behavior. Auto Zoom seems to work correctly on the 'geocaching' page (combo cache summary, bearing pointer, and map). It's only if you select a "Go To Location", which puts you in a fixed-zoom, full-screen map that it doesn't seem to work.

On the geocaching screen, this worked fine for me in 2.3. I haven't tried with 2.4 yet. --Marky Now that I'm on the right page, and know what we're talking about... it doesn't appear to function as it does on a 60CSx - e.g., no "Auto Zoom". I selected a cache a good distance away, along the route I've got loaded for tomorrow's 'commute' - and when I select "Go To Location" - there's no "Auto Zoom" (ironically, there IS auto zoom on the first page that comes up - the combined summary, compass pointer and map page. But after selecting Go To Location, and the switch to a full-screen map - the zoom simply reverts to whatever zoom level the map was last at. It's good that it works on the first page - since, like others, I'm finding this to be a very useful page - but it would be nice if the auto zoom feature worked when in full-screen map mode.

DOH! You're absolutely right. I read your other thread, and realized immediately that I'd had it all wrong. Sorry 'bout that. I know exactly what you're talking about - though I can neither confirm nor deny the behavior of my unit at this time. I'll do some testing during the drive up to Tahoe tomorrow, and see how it behaves.

If I recall correctly, the hints selection was always there in 2.3, but it said something like 'no hints' when you clicked it. Precisely why I got excited about the feature in 2.4. Keep in mind I dumped the .gpx files I had loaded with 2.3 and downloaded one large .gpx file from a pocket query and copied to the unit manually after the 2.4 upgrade. I can't confirm it with a screen shot or anything, since upgrading to 2.4 - but I am 100% confident that in 2.3, if a cache did not have a hint - the left softkey wouldn't even have the "Option" label, and there was no "Show Hint" - just a "Done" on the right softkey. Seems like it's still working that way now, right? Only, slightly re-arranged, now that logs are a separate selection... e.g. from Show Description, now there's Show Logs - and, if applicable - show hint. Right? At least, that's what I'm seeing on a collection of caches with and without hints.

When you say "not working", what behavior are you observing? While I would like to see there be a unique "zoom level" setting for caches (as opposed to all "User Waypoints") - but, when set to Auto - it seems that it is working in some 'automatic' fashion (e.g., I think caches are visible at below 3 miles zoom?) What would be ideal behavior for you - and what are you experiencing?

Hmmm - duplicate post. How do I delete this second one? I'm sure it's here SOMEwhere...

Will you do the math, within your script, to correct the zulu timestamp to 'local' time? I've already considered the same thing - but my coding skills suck.

Hey... yeah! What gives? I've yet to get the new firmware 'out in the wild' and actually do some caching - and I'd failed to realize that even though I'd deleted the geocache_visits.txt file from the Colorado - that it is still retaining those caches as 'found' (and, hence - [/b]not displaying them in the 'notfound' list of caches. This is rather annoying, since through my experimentation, I've marked several of the caches closest to home as 'found' - and now, can't get them back. I'm sure one or both of these processes will resolve it - but, this doesn't seem like it should be required: 1) Select each 'found' cache, one at a time. Then: Option->Log Attempt->Unattempted 2) Delete \garmin\GPX\Current\Current.gpx Since it's not tracking this information in the actual text file - it's got to be in here, right? Option 1, in addition to restoring the caches to 'notfound' status, creates a new geocache_visits.txt file with all the 'unattempted' entries. So, yet another file to delete. Option 2 is more destructive than should be necessary. This was a good observation, Warriorrider.

Oh Yeah!! When we get to this point... stick a fork in my, I'm DONE! While we're at it - I ought to be able to load the numbering sequence of whatever sig items I'm carrying (I guess that would fall under your 'swag list') - so that I could just chose the item from a drop down. Adding the timestamp to the log would be nice - but since I do my logging by way of GSAK macro, I reckon I have all the information at my disposal (If I can figure out how to parse the geocache_visits.txt file) to automagically insert it in the Log section of the Notes field (whereas today, CacheMate populates the timestamp into the User Notes section of Notes). Very, VERY cool!! Dare to dream...

It seems that most of my initial issues (especially the major ones) have been resolved in the latest firmware. What are the rest of you percieving as the largest outstanding issues? I would consider bugs/failures to be higher priority that 'feature requests' - but then, I guess it depends on the feature. The top of my list, right now, is the ability to enter some text into the 'log' when marking a cache as found. Clearly, Garmin has set a field aside for this (as suggested by the empty quotes at the end of each line) - but has left us (thus far) without the ability to populate it. After that, I would like to see unique zoom level settings for geocaches - so that I could control precisely when they are displayed, as opposed to other waypoints / POIs. I would like backlight settings to be sticky. A quick way to toggle on/off the electronic compass, toggle between north up/track up, or change from "follow road" to "off road" (although changing profiles is pretty quick, especially if you put the 'change profile' into Shortcuts). I suppose, holding more caches might be nice - but 2000 is enough to cover most any 'routine' scenario, even here in the cache dense SF bay area. However, all of these are 'nice to have' enhancements - but, with the exception of log text, none of them really impair my ability to use the unit as desired. How's it working out for everyone else?

DOH! Aww, shucks: I got all excited there for a minute, thinking someone had figured out something that I just hadn't stumbled upon, yet. Well, the fact that this field simply exists is proof enough that Garmin has plans for it (or, so I would infer). Now, we just give them a chance to add the input dialog. My suggestion would be another option, from: Geocaches-> <select> -> Options -> Log Attempt -> Found From here, go to a text entry page (I'm hoping eventually they'll arrive at something a little more friendly that the current interface for adding text - e.g. naming a waypoint, etc... but that would suite me just fine for now!). THEN proceed on to the "Find Next Closest" or "Done" page. C'mon, Garmin! You can DO it!!

I would be satisfied if Garmin would just 'do the math' for us, and include the corrected, LOCAL timestamp, rather than a zulu one. I mean - we can work around that, programmatically, with a GSAK macro or something, but... Isn't a timestamp of when you found something best represented by the local time - even if it IS 'arbitrary', but time zone? Since they never (?) need to be correlated, across timezones - I personally would prefer to see this adjusted value (e.g. GMT - 8:00 for me here in PST). Since the unit is constantly calculating/displaying local time - it doesn't seem like there would be much overhead in recording this value, instead of zulu time. Just a thought / feature request. Adding it to my list...

Greetings, Red90- This function is working for me, but I do have one question: How did you populate the text field at the end of the entry - e.g.: "An easy find today ... 1" ??? If I could figure out how to accomplish even the most rudimentary data entry in the Colorado (just enough for TB/coin numbers, or terse notes on hide/condition/etc) - I really WOULD be able to retire my Palm/CacheMate. For now - while this is so close to being exactly what I need -- I'm still lugging the palm (even if I don't take it out of the pack very often), so that I can log those 'field notes' (not to be confused with my actual online log, which I write offline in GSAK and then post via logging macro). Perhaps this text is being added by geocaching.com when you write your log using this page: http://www.geocaching.com/my/fieldnotes.aspx but I can't even find a way to add it, here. Any insight is much appreciated! Billy