robertlipe

Yes. See e.g. https://www.spirent.com/Blogs/Positioning/2018/January/GPS-Rollover-Week for an accessible discussion. It's quite possible that you won't notice a difference looking at your receivers. It's more likely that the NMEA data or the track times during and after that time will act funny, so unless your event is prepared to gather tracks during a walk at that tie and capture and analyzer captured traces, you may never notice.

The answers by HHL and Mineral2 seem complete and helpful. Thanx, guys. Be careful to not fall into a trap sometimes unwillingly set by experienced overachievers. Switzerland is a lovely place to cache. (Look for my name in logbooks in Zurich and Basel. :-) ) Carrying around ALL of the caches in Switzerland is really not very practical. You've found 46 caches, so don't frustrate yourself with the limits of a "mere" 10,000 a day in pocket queries. You're probably not going to be doing terrain 5 puzzle caches in St. Gallen and Lausanne on the same day. Be realistic in what you're going to look for (find the difficulty/terrain/cache type) and the areas you're going to hunt in and focus on carrying a fresh set of caches that you may actually look for between times you'll be near a computer instead of fretting about carrying ALL the caches and potentially having stale data and finding yourself spending hours looking for a cache that's been removed, for example. The tricks above are valid for helping you get all the caches, but you'll find you probably don't NEED all the caches as a practical matter. My advice for a new hunter is to focus on "enough to have fun in between the times I'm near a computer" instead of "all" and you may find a happier place with more time hunting caches and less time messing with computers and searching for removed caches because you have stale data. Oh, you sort of asked, but it's widely considered a bit goofy that you have to calculate the date in American Pacific time and schedule it to run instead of there being a "do it now because why else would I be here" button. It seems a bit silly but the experience folks that have seen that screen for 15 years are largely blind to it. Good luck and happy hunting.

I really don't think the GPS-using public of that era understands the engineering chops that went into that stuff. My day job at that time was developing the USB stack for a large operating system, so I happened to have the USB protocol relatively committed to memory at the time as well as access to the specs and protocol analyzers and such. I helped Apple identify a bug in the Garmins that crashed the Mac OS USB stack just because the Garmins were built to do what the Windows USB stack did (always respond with 10 bytes or something) instead of doing what the spec said (read the two bytes containing the size and then maybe read bytes) in the early days. The early USB Garmins were such a total mess. I don't miss those days at all. It is a bit cathartic when your day job has all the individuality sucked out of it and you have thousands of people protecting developers from end users - and vice versa - to have a constant little "behind the scenes" show. :-) Don't worry. In the time it took you down to download and install the service pack, your machine was already 0wned. :-) But it's actually somewhat of an interesting comparison. Think about how many more GPSes are in use right now than there were in 1999 when the last rollover happened. There's a whole lot of equipment that's never battle-tested this case on anything but simulation and unit-test. There's a tech bulletin from ublox (more popular in embedded cases more than the kind of GPS we deal with in geocaching) describing how they handle the gps week rollover and at a blush it seems reasonable. But, just like that Windows XP system that's controlling the MRI in your doctor's office that you pray is never connected to the internet at large and never sees a firmware update for better or worse, how many cases are there marine or aviation panel mounts that go 20 years without a firmware update? Are there units on the neck of an elephant (fun fact: one of those elephants is named for my boss for his outreach work with them...) or measuring glacier movement or other cases beyond finding pizza with your cell phone that'll never see any firmware update? Certainly. Bugs in some of those will happen and bugs that happen once every twenty years aren't exactly likely to show up in casual testing. I *think* most of the bugs will be somewhat quickly self-correcting and will show as glitches like tracks ending before they started and not total navigation failure where we have emergency vehicle dispatch paralyzed and planes flying into Null Island. Recall that GPS has uses beyond navigation; it's a key part of global time synchronization. A world-wide database where time runs backwards for some connected nodes - and not others - even for a short time is likely to expose all kinds of entertainment. It'll be an interesting industry spectacle to watch...for the, like, five of us that watch such things. We probably won't get Dick Clark counting down a dropping Space Vehicle dropping to zero for this. Maybe we should start a petition...

Those guys running a 32-bit OS in 2038 will have way bigger problems on their hands than trying to find a USB 6 adapter for their Musk 28x NIDP for their Garmin. :-) But as a fun task, I did check. All the serial Garmins and some of the older USB ones are going to have problems with waypoint times (little used) and track times in the year 2038. I looked in the GPSBabel source, and all the time handling in Garmin protocol looks approximately like this. In layman terms, they read 4 bytes (that's the GetUint and +=4 stuff) and then shove it by a constant to adjust from GPS Time (1980) to time_t time (1-1-1970) - that's the GPS_Math_Gtime_To_Utime() stuff. There are many types of Garmin serial packets, but that's in the code for D110's which is the newest of the lot. You can find similar code in the D30[123] path for tracks - it's all still 32 bits for time. So, yes, the serial Garmins will, at best, start reporting times of 1970 starting in the year 2038. This would also include the ones that smuggled Garmin serial protocol over USB which would include the 60 and 76 series, StreetPilot, i3, Rino, Quest, Legend HC, Legend Cx, and so on. If your Garmin doesn't show up as a USB disk drive with GPX files for waypoints when you plug it in, it's affected. "New" units, like Nuvi, Oregon, Colorado, and such that use GPX throughout wouldn't be affected by this - they may very well have their own issues, but they won't have the issue where it's impossible to represent the current time in the protocol on the wire. So all the devices (and probably more) that aren't footnote 2 at https://www.gpsbabel.org/htmldoc-development/fmt_garmin.html will likely start returning tracks in 1970, for example. To be clear, this is a 2038 problem and not a 2019 GPS almanac wrap issue. But you guys are largely right. The inertia of the the installed base can be surprising. Somewhere there'll be a classroom with textbooks in Nheengatu that'll include screenshots of this exact model of device and that has a hundred of them, so someone will need it to work and the cost of replacing them with something "better" will be ridiculously high. A large portion of the consulting industry in tech is dedicated to "solving" (or passive-aggressively making...) problems like this. If you find my writing in code entertaining, ecanderson, see some of my Garmin USB grief. :-)

Be careful mixing device generations. Garmin has two completely different lines called "eTrex" for example. Any serial device doesn't really support GPX files in the sense that a geocacher thinks about it with the eTrex 10, 20, 30 family. GPSBabel still supports those serial Garmins, even as crazy as they make me. That means that GSAK and anything else using GPSBabel for comms should still work with them. Garmin had two generations of serial cables: the round 4-pin and the one with sliding blades on the edge. Serial eTrex had the latter, but the GPS 12, V, and others used the older one that OP is describing. The cables and USB adapters can probably be found in the junk drawers of locals as easily as they can be found on eBay. There were zillions of those devices sold around the turn of the century. Be prepared to find generic/unlabeled USB devices finicky on modern operating systems. Remember that the old serial devices are "Garmin Protocol" while the newer ones are "USB Mass Storage". Also think hard about your time/grief investment: don't spend $20 on a USB adapter and $20 on a cable and then 17 hours of head-banging to make them work if you think you'd be happier with the $100 newer models that will Just Work with geocaching and provide a much more pleasant experience on the trail. Again, hand-me-downs from locals will get you far. A ten year old Oregon 300 is a MUCH better geocaching device than an original yellow serial eTrex, even though that was the "bread & butter" device of geocaching for a LONG time.

I'd be surprised if any Oregon-class device totally "broke". There might be some interesting things in the industry going on in the moment that it wraps, like programmers forgetting to mask on a carry or subtracting time without expecting it to go "backward". I'd expect at least a few drones or robots to jitter, a few tracks to have weird things, some systems need reboots, etc. I doubt that any modern device will be bricked or even need a firmware update. Probably. If they're fixed by a reboot, they can wait another 19 years. :-) I did muddy the conversation somewhat by mixing what presents itself in GPSBabel as a Y2038 problem when the reality is the Garmin just presents a whacked out time. See https://sourceforge.net/p/gpsbabel/mailman/gpsbabel-misc/thread/20180715114005.6aac7ca4%40raspberrypi/#msg36368348 (Libusb and Pi turn out to be red herrings. Packet analysis begins at the message with GPS_COMMAND_GET_TIME - In the next message he says "The Garmin is indeed showing the wrong date: today it is 1-MAR-2038". We didn't really tie it to the 2019 issue being discussed, but we did notice it's "about 19.7 years" off, which is about the period for that problem, too. Numerology? Maybe. You can tell from the tea leaf reading that I'm kind of used to that. We've seen it on original Vista https://sourceforge.net/p/gpsbabel/mailman/message/10805638/ and Forerunner 201: https://sourceforge.net/p/gpsbabel/mailman/message/21304913/ and I know we've seen it in others. As for boneheaded designers, we've seen them hardcode things like the WAAS SV's in the firmware instead of using the ones in the almanac (remember patching the hex files and reprogramming Meridians?) we've seen devices report GPS time instead of UTC even though the offset between them is broadcast in the almanac and not made visible to the host. (This is why there's some stupid data logger where we have to patch GPSBabel every time there's a leap second introduced...yeah, we should fetch it from a network server somewhere.) We've seen devices that have access to some of the most magnificent time keeping devices we've ever built display human-readable time very, very wrong (see Map330, Meridian, aforementioned time-traveling Garmins). So, yeah, there'll be *someone* in the GPS biz that gets this wrong.

Moderator Note Subject changed to make it sound less like an announcement. Alpin3peaks, please be mindful when choosing subject lines. Those few short words are the way to attract relevant experience to your post while not distracting others scanning the forum for tips. Thank you in advance.

On the GPSBabel list a week or two ago, we had someone with an older model Garmin seeing a failure that realized he was N weeks before the rollover and his unit was reporting that it was N weeks after the rollover, but resulting in it being 19.7 years off. This meant his unit was reporting a time that was after the "4.2 billion microseconds since 1/1/1970" epoch rollover time in 2038 so he was getting on overflow when he ran a 32-bit OS, but a different (still wrong) behavior on a 64-bit build of the same OS. He was able to find a very similar failure on a Legend (an even older serial model) that had a similar weird stuck time, but it was stuck at the first rollover in '99. We weren't able to help him. Even after a factory reset, it remained stuck a few decades in the future. Somehow he connected the amount it was wrong to the 10-bit week overflow next year but it's entirely possible that it's numerology and his GPS is just slightly broken. We've definitely seen GPSes handling things like this badly in the past and I'm sure we'll see devices failing in some way this time, too. Time wraparounds and overflow and underflow are things that programmers just tend to handle poorly because they're hard.

If you copy the gpx file to the GPX directory (Maybe it's Garmin/GPX or Garmin/Garmin/GPX) that's on the device, it'll read the contents of that directory on boot. Unlike some of the older devices, it's not like there's a menu on the device to "load" from SD card; it just reads it once on boot. You'll know it's in the right place when the unit takes frustratingly long to boot the first time. That's when it's reading the card...

As a developer of GPX and GPX apps that are geocaching-aware, that GPX file is just weird. It's using the GPX 1.1 <extensions> format, but Groundspeak PQs are GPX 1.0. Because they changed the case name of the tags, I think GPSBabel (and thus Google Earth) will let the <cache> extensions be handled by our "I don't know what this is, but I'll try to preserve it" code paths and not our "I know what a pocket query looks like and can actually read the logs and render them specially" path. I would not be at all surprised if other readers of Pocket Queries get similarly befuddled by that file format. I wonder if this is some residue from their failed Opencaching effort. I'd second the advice to just avoid PQ's written by BaseCamp if that's what it does to them. Just copy the PQs over to the device with script/batch file or drag and drop from the file manager or whatever. Having seen 0,0 done badly billions (no exaggeration) of times, I'm now of the opinion that no software should ever do anything for coordinates on Null Island. I actually experimented with making GPSBabel drop them on write, but someone fussed that they depended on it.

I agree with that assessment, Atlas Cached. There is no doubt they're an old school hardware company; once Model+1 is announced (it doesn't have to even ship...) Model gets ignored. There are bugs and usability issues that have been with us so long they're approaching voting age and they're just not getting fixed. It's evident in their software, too, where Mapsource, Basecamp, and a few others have come and gone, often with poor compatibility even across versions of an app, let alone app renames, leaving folks like GPSBabel (that's me for our new readers here...) to fill in the gaps of people trying to get their own collections of data across programs. I've thought for so long that what they needed was some competition and I hoped that the Mitac iteration of Magellan would be it, but every attempt in the market has never gotten even a fraction of any market share before they (have to?) give up. Compared to the PND market, the outdoor - and geocaching specifically - markets are small so it's unfortunate that one maker so completely dominates this space. In ten years, we've seen what economy of scale and modernization have done for mobile phones but we've seen only minor changes in the hardware in this market. It's like they're so insistent upon repackaging the free government-collected Topo data into $89 map updates they they keep building $600 handhelds just to sell those updates. Twenty years ago, 30 GB of data for maps was a lot and now it's just not. They've gone from building their own receiver circuits to buying commodity stuff. (Adafruit, Sparkfun, Mouser, etc. sell pretty much the "hard" part of GPS receivers these days...for tens of dollars.) There's just a pressure each year to change the model number slightly so you have something new for the trade show market circuit that the "old" units get left in the dust, never minding that a five or even ten year old handheld at this point really isn't *that* different in capability at the software level. This industry really has lost its way.

> Garmin's BaseCamp does not know anything on Garmin's own GGZ file format. Bwaaahahaha. It's not easy being me. :-) It's a bit funny that for over 15 years, I (via GPSBabel) have supported more combinations of their file formats, hardware, and operating systems than they have. Thanx for the good help on4bam.

Also, this works only on the Black (PN-60), Orange (PN-40 with firmware version 2.something) and never on the yellow (PN-20). Since you didn't say what GPS you have (Delorme was a company, not a GPS model) it's really tough to advise much. Delorme (the company) has neglected these units for many years and after they were bought by Garmin, updates got really hard to find from them. Hopefully Mineral2's answer is enough to get you going without needing to dive into GPS Trivial Pursuit where we ask "what GPS" and actual details for "not working" .

There have been various forms of corruption of popularity at different times. GPSBabel used to fix some. GSAK used to fix some. Groundspeak slowly added fixes on their side to make flagrantly broken GPX more rare. The one thing that's seemingly remained constant since the Garmin Colorado 400 about 10 years ago is that Garmins simply crash on some geocache files instead of displaying a parse error, reporting it upstream to the user, or whatever. Maybe there are some statistics that they crash less, but I still see posts like this often enough to be pretty sure this is not a solved problem for Garmin. They just reset and it's positively maddening. The onset of GGZ theoretically makes it more rare to happen as the device doesn't have to even parse the full GPX of a geocache until that geocache is selected from the menu, but even then, they still crash more than a device should in modern times. Red90, if you want to play historical trivial pursuit with common forms of GPX/PQ breakage, some that come to mind include: Garmin's own software used to write GPX with encoding of ISO 8859-1. GPX requires it be UTF-8. Oregon 400 or 450 or so used to crash on Garmin's own files. Various software (including my own) do weird things when mixing GPX 1.0 and GPX 1.1 and that can cause some software to not read them. A software upgrade at Groundspeak caused all PQs to start with a Byte Order Mark, which was prohibited by GPX. Starting 2012-02-14 and for a couple of weeks/months, any software reader that strictly followed the spec requirement of UTF-8 or looked at the first few bytes and flipped out when they saw a BOM were doomed. Many programs responsive to the geocaching community quickly developed workarounds. See or so. Back in 2003, there was a bug that lived for several years that allowed hex encodings of ASCII control characters that were forbidden in GPX. Encoding a backspace as &#x09; didn't make it less illegal. That used to crash some programs, but I think it was before GPSes read GPX. GPSBabel had code specifically to deal with it and I was so annoyed by it that I included code to get people to letterbomb Groundspeak to fix it. :-) See https://github.com/gpsbabel/gpsbabel/blob/e7adcb0f395a0aae6ea288feaf2c721ff8266173/gpsbabel/gpx.c#L787 and the line at 833. That code's been gone for a long time and nobody's complained. This was one of many "fixes" where using GPSBabel to convert GPX to GPX resulted in better GPX. (Yes, this "fix" inside GPSBabel is horrifying in itself and we don't have code nearly that fragile now.) Early Garmins used to crash on embedded Javascript in the HTML instead of ignoring it. Through time various forms of 'bad' HTML markup have crashed the units. Over time, Groundspeak has cranked down the amount of "creative" CSS/HTML allowed (I'm guessing via something like htmltidy...) that's resulted in less weird stuff making it to the receivers. For a long time, older caches that were last created or last edited before the tighter restrictions were in place and would more likely crash the devices. Now the cache editors tend to "undamage" a lot of things like bad quoting or made-up HTML by Front Page or whatever. We just don't see things like foo='bar" (note the mismatched quote characters) making it into PQs much these days. It's also frustrating because different models of Garmins have overlapping bugs: we'll identify a specific cache that crashes the Oregon 450. The next month, they'll ship the 600s that still have the crash. It'll get fixed in the 450, but has to be independently identified and fixed in the 600. It really seems that not only are they not sharing code, the responsible teams aren't even talking to each other. Because the Garmins parse the GPX from PQs on boot and they have poor handling of poor input (crashing instead of ignoring or error messaging or saving crash reports to be delivered back to the mother ship) that results in them booting, they often enter "boot loops" where a bad entry in a PQ will crash the device while booting, which makes it reboot and then crash when it tries to boot the next time and ... I think later Garmins have gotten somewhat better at this, but this is the root of the wisdom of putting new pocket queries on your SD card so you can remove it and at least use the GPS to get you back out of the woods. Why are GGZ files less fragile? They're potentially huge so they should be more fragile and not less, right? No. The GGZ files are a zip of several files. There's a little file that's super fast and easy to parse and then there are little GPX files that contain the PQs as always. The little files contain lat, lon, cache type, and container size - just enough to splash stuff on a screen. This file is read on boot. Inside this file is also an index offset to the individual geocache in the big file. The (potentially large and, uuuuh, creative) entries that contain the HTML thus don't have to be opened and parsed until you actually choose that entry from the screen and try to display it. It's possible that it'll crash then - my Oregon 600 does this pretty regularly - but since it doesn't have to read the big file every time on boot, it's less likely to enter a boot loop. It's also possible/hopeful that it'd be a better user experience if they can associate "my Oregon crashes when I try to open GCwhatever" as a shorter action/response loop than it crashing when booting. I think if we were making GPX (and pocket queries and GPS receivers) today, we'd have done something like mail and include both rich HTML (for something like an Android or iOS that has the RAM and software chops to pull it off) and a markdown-based text format because that can be formatted so easily and even if you do nothing, it looks pretty good. It's closer to the bbcode which, oddly, leaks into the logs sometimes. There's been a lot of user frustration because the problems above come and go over time. A PQ today may or may not work next week. In today's world of auto-updating everything, it's hard to know what changed, but the GPX specification includes tips on automatically validating the XML (validating HTML is a problem addressed by groups many, many times our size) so that we can easily identify if we have a "bad" file being generated or it's the fault of the reader. The PQ generator hasn't always followed industry best practices. While I know my meds make me rambly at night, this has been a huge pet peeve of mine for many years. So while I've barely been caching in recent years - certainly not since my recent round of spinal surgeries - it's something I've thought about for a long time. To the OP's question, I think the prescriptions written by our regulars are spot on: either you have corruption somewhere - a bad PQ itself or junk written into flash during an abrupt power - and a full reset will cure it or, less likely, you have slightly broken hardware. Good luck.

It writes its own native format and uses GPSBabel to make the KML that it injects into Earth, IIRC. THat's ultimately basically how Earth reads GPX, Mapsource, Mapsend, NMEA, log, and most other consumer-oriented formats, too; it calls GPSBabel to convert to KML. That trick in Earth of dragging an unzipped PQ into Earth and having it render maps with tabbed interfaces with geocache details? That's GPSBabel doing that work.

I asked for an authoritative URL and you provided on that's peripherally related. You keep making up a connection where there is none. You've been told this by both the Google employee that helped Garmin develop this feature and independently. Maps and Earth are indeed related, but they're two different products. The word Earth does not appear on the page you cite and doesn't even offer the APIs being discussed. The only price change I can find for existing product is mobile StreetView and certainly the Desktop app is not using that. Google's "greed" is still providing unlimited mobile and embedded maps and for the new products, wanting to recover some costs from the new features (of programs not being discussed here) for collection, development and serving images of the whole planet collected from satellites, planes, and cars. I get wanting everything to be free - it'd be awesome if my local Wal Mart offered that - but let's not confuse "won't give everything away for free forever" with "greed". Basecamp's use of Earth wasn't anything magic IIRC - it just wrote its gdb or gpx file (or whatever it uses this week) and handed that to Earth (perhaps via Earth's copy of GPSBabel). You should be able to dot he same thing with a drag and drop onto our icon or screen or maybe a file->import. We probably broke it last year when we internally changed the name of the app from Google Earth Free to Google Earth Pro and thus, on Windows, changing the registry key name. Bummer that key had to change, but not difficult to recover. Did Garmin remove the feature rather than changing the name? Dunno. Disclosure: I've been OOO on medical leave for several months. Maybe there's more to it than the public info, but I don't see any greed in action. Garmin just removed a feature that's easy enough to emulate in other ways.

Google Earth for consumers has been and is likely to remain free. Do you have an authoritative source that says otherwise? Source: 11 year software engineer working on Earth...

"can also now" == about 2006-7. I can't remember if it was in Earth 3, but it was in Earth 4.0. Earth's been able to read GPX for a long time. It was around 4.2 or 4.3 when I added geocaching-specific voodoo to it that lets it read a PQ specifically. You can drag and drop a (n unzipped) pocket query into Earth's 3D view and (though it asks you a kind of distracting dialogue) it'll render Geocache icons, cache container and size, with balloon content optimized for cachers like logs and links to other maps. It may be a bit dusty since I barely cache these days for health issues. Those same health issues are why I don't know the details of the precise Earth that's in play. As for the Earth naming thrash, once Google Earth Pro became free back in 2015-01, the need to keep the consumer "Free" Earth dropped. The one that was kept had the feature set of Pro, but the outer shell was still the free version. There were reasons related to auto-updates that required the weird naming. Garmin rather uniquely reached into Earth's innards to run the copy of GPSBabel that was there to use its KML writer, so they're coupled unfortunately tightly. When things got renamed, Garmin's tools broke and that was a bummer.

GSAK doesn't have any magic spell here. It's "just" writing a GPX file to the device, pretty much like a drag and drop from file explorer or any other copy operation. OK, *technically*, GSAK might pick up the straws from a GPX file and arrange them into slightly different bales. But any case where that actually matters is probably hitting a defect somewhere - and I'm carefully NOT saying there are no defects. If you can copy a GPX file to a USB thumb drive or other removable storage, I'd expect a similar copy to work to Explorist. But if that copy doesn't work from the draggy droppy file browser, I wouldn't expect it to work from GSAK because at some level, that's basically what it does for these devices: copying a GPX file to an external drive. Yeah, it might know to unzip it and it might know the right directory in that drive to place the GPX, but the resulting bag of bytes on the device is *probably* the same. But this IS a three year old post with a bunch of unrelated topics dumped into one, so expounding on any of them here may not be productive. Perhaps best for anyone still having problems to look at the volumes already written and perhaps post a clean help request with enough details that other users of that same combination can help.

As a slight sidebar to Mineral2 so he can continue to provide awesome help to others, I'll share my recollection of that era in the hope that it helps anyone. 200x-era Garmin USB trivial pursuit can be a tricky category. In the 1990's, Garmin had a line of products with overlapping prices and features that were all serial ports. In 2004 They had the new 60 and 76 models (with and without Color and Sensors) that added a USB port. In that era, map transfer and track transfer were the only thing that *typically* took over a minute to transfer so that's all that went over the USB wire. After shipping for a few quarters they added the ability to read and write the SD cards as removable storage devices over the internal memoru, albeit at USB full speed and not high speed. That was the point where Garmin USB got viable for moving GPS points and racks because you could just copy files to them as you would a thumb drive. By 2004/5, devices on the market that were using the CSR owned SiRFStar receivers which performed their home brews in a matter of ways. In Jan of 2006, Garmin released the "X" variations of the 60c/76c. The SirfStar supplier was under constant attack for alleged patent violations and Garmin, as their biggest user, was hit hard by both supply and concern if the suit continued on, so they double-sourced and went to the very similar MediaTek products. Garmin didn't like the uncertainty, but muddled on with their two flagship handhelds. By spring of 2007, the -other- entries in the handheld line (eTrex, Summit, Legend, + Nuvi) were looking pretty ragged. Serial port adapters and proprietary cables were costing a substantial percentage of the product. The typical user no longer even knows what a serial port is, let alone how to make one. So they ran back over those 1900-era models and re-cut Vista HC Legend HC, Summit HC, and eTrex HC Oh, and Nuvi but it's the odd duck here so we'll ignore it. There "HC" models retain all kinds of bizarre 1990s tech (six character upper case only names? Ugh) with their namesake models; they "just" got the better Highsensitivity Chip and integrated USB. They kept the cases and holsters and bike mounts and everything as possible as they could. Code-wise, though, these models acted more like stripped down 60's than their namesakes. You really can imagine (OK, _I_ can...) the engineering decision that this was a copy/paste exercise to put the (potentially depopulated, underrated) hardware into as close to the same case as you get - close enough to hopefully not need a new mold but just a new die flash cut (think cookie cutter) as they cooled. It would have been a very reasonable task for a small team of interns to knock down during the summer: take the schematics, source code, getber files, FCC guidance, etc, and "just" swap radios and turn off some features from the 60 to make it fit into a smaller flash EEPROM. Don't try to make Legend try lower case letters - just swap the chip and do as little to the code as possible. There are a few other glitches in that time frame, but remembering that the 60C/76C were the first of the second gen platform (to me). They didn't look/act like anything before them in Garmin-land and almost everything after them looked the same. Nuvi and Colorado hatched others named like states where bigger numbers == more awesome within the line, but they're totally different on the wire and in UX that in my mind they're the third gen. (Fitness, aviation, marine, etc. could more planes to this diagram, but let's not.) So, back to the sentence " you have the last model of the old family) supports GPX files and mass storage mode. You can just download a Pocket Query and drop it into the device's onboard storage (or a microSD card expansion) and be done with it." that's not quite true. The Legend hcx, for example, was shipped after the 60Cx, but it acts more like the 60 and original Legend than it does a Nuvi 350, 500, or Oregon 300. which shipped AFTER the 60 with noticeable improvements, like a geocaching mode that was more awesome than animating an icon lid closing on the container. To make matters worse, the new Nuvis (err, "Drive" models) will still take your GPX files, but it doesn't mount on your computer like a file drive. You have to treat it like a 15 year old flash player or camera and transfer files to it via PTP or MTP. On the up side, your GPS won't go into charging mode and "dead" when you plug into charge and you don't have to reboot to get your points visible on a map. But you don't have those models, so let's not stay with MSTO itself being an outdated standard itself at this point in time. Garmin isn't alone in this line of confusing product lines. The Meridian was clearly SD card hooked to code dealing with serial ports. Explorist x00. The successor to it, Triton was something totally new (and disastrous). Seeing those tank, Magellan, under the new leadership of Mitac - rolled out a less hacky Explorist and goes back to the former name, but the numbers confuse people because an X10 is newer than an X00. A 310 has more in common with a 210 than a 300. The newest Explorists (and they're going on 10 y/o at this point) have more in common with the turn of the century Magellans than either of the entire product lines that should have replaced them.| NOW going back to the original question. The 60CSx was a lovely unit. Search and Rescue teams, in particular, love many traits about them and aren't switching. You have to remember it's a 2007 remake of a 2004 product. It's probable that most of the geocaches between 2006 and 2010-11. It's not like site changes for, say, Giga cache are likely to impact it much as it doesn't know about geocache types; there's only found and not found. The device should work. However, as you've found, some of the software infrastructure that will cut maps and deliver geocaches in a "dumbed down" way needed by those has suffered from dry-rot. You didn't say what OS you were on, but Windows users will need https://www8.garmin.com/support/download_details.jsp?id=1245 That driver doesn'say much about Windows 10. If you're on Linux or MacOS, GPSBabel *should* be able to talk straight to the unit, but you may be the only one that's tried it in 10 years. Buzz me if that's the case. Garmin did their users no favors by not upgrading their browser plugins to relevant browser security stands...

There are also discussions pinned at the top "What GPS Should I buy" that go into background of phone vs. "real" GPS and who works best with each. While you're there, be sure to read up on Pocket Queries, a subscription-driven way to get data from the site and into your devices.

Great post, noncentric. Thank you. Added to the pinned FAQs atop this group. Let's all please refer new posters there.

Also, if you're asking about the pointer that's normally under a finger that you're moving to a location, however, this time of yeark can factor in. On he newer capacitive displays, it won't register the presence of your ringer, leat gloves withthe rubber tips so there's a capacitive reatction.

While it's a bit fiddly, you can clean up some of those noisy tracks in GPSBabel. Garmin hides the DOP information that would almost certainly identify the nonsense points and let you toss them with the DOP filter ala https://www.gpsbabel.org/htmldoc-development/filter_discard.html Bad data points like the upper right corner of the first map by jimlarkey would almost certainly get cleaned by those. The distance option in the track filter https://www.gpsbabel.org/htmldoc-development/filter_track.html could be used to break the track in the post above this one into two distinct tracks. Choose a threshold so that the straight lines get busted into separate tracks. The simplify filter https://www.gpsbabel.org/htmldoc-development/filter_simplify.html can be used to reduce the sheer number of points in a track. Because it removes points that change the overall shape of the track the least (unfortunately, thus favoring that "zinger" in Soapstone; arrange to remove those first) it can be helpful to removing clutter at trail heads, resting points for cyclists/hikers/campers, stop signs and such. While a GUI with a "make this track less terrible" that can figure out what combination of the above - esp. in light of Garmins that insist on recording made up data and not telling you WHAT data is low quality - would be awesome (please send me the code for that if you implement it...) I'm aware of no such tool. If you have valuable tracks that are worth cleaning up and are prepared to spend some time fiddling with it, the raw tools are in GPSBabel.

Please don't open multiple duplicate threads in different categories with identical content. Closing this one in favor of