robertlipe

The best way is with a premium membership. That way you get the description, hint, cache type, container size, logs, etc. The non-premium .loc files contain only a tiny fraction of the data. You can convert .loc to .gpx via GPSBabel, but there is no alchemy; it can't produce the data I listed earlier because it's just plain not there in .loc files. The $30USD/year to use your $300 GPS to its fullest is worth it. Mac and 60cx worked lovely for over 10 years via GPSBabel.

Done. https://github.com/gpsbabel/gpsbabel/commit/27d5db7ec80aa7603632a3151d8736d4728a5e92 (Yes, it's silly that code appears in multiple places...)

Enjoy. It should remember that your settings so you have even fewer clicks next time. Drag and drop of GPX files should work once again now. (That were broken on certain OS/X versions until a few months ago.) Bonus tip: If you want to hunt with real cache names instead of GC54321, go "Advanced Options" and select "Synthesize short names". It will make the best human-readable name (with an English slant) that fits on your device, but is still unique. I see the gauche colored icons are in the buttons for advanced settings. I'll make those Windows-only tonight...

Using GSAK, a Windows program, on a Mac isn't trivial. If you've not already navigated the waters of Bootcamp or virtualization like Parallels or VMWare and purchased a Windows license, preferring a native MacOS solution is wise.

GPSBabel knows about that GPS and it knows about geocaching pocket queries, so it'll get it done. It'll take a drag and drop of an unzipped PQ as input, but you'll still need to select "garmin" and "usb" as an output. I won't pretend it's the easiest possible solution for that specific case. That's the price of flexibility. As pedantry, in the computer business, "MAC" is the Media Access Controller, a low level in the ISO protocol stack while a "Mac" is a computer built by Apple. As disclosure, I'm the GPSBabel creator and a geocacher.

"Gulf of Guinea", also known as Null Island, is special in electronic cartography as it's coordinates "0, 0" The intersection of the equator and the prime meridian is where you describe. I'm doubtful that toggling GLONASS was actually involved. More likely, the passing of time while the unit was recovering from an internal crash or inconsistency was the "fix". It probably had a very confused idea of your location (corrupt time or saved location) and you had to wait for a cold start for "first fix". If it happens again, I'd consider the unit slightly defective.

You're wasting effort with a 500GB card when the largest map you can use on this device is 2GB and there's not really a way to switch on the device, IIRC See the pinned faq at the top of this group for discussions on why even 8GB cards are overkill. http://www.gpsfaqs.org/faqs/garmin/xseries/g60cx/accessories.html#memory

Is your script shared in a place where we can see, download, and use it? "Totally unusable if you're not me" means it's not really something I'm interested in publishing and supporting. I put a version of it here in 2009. I've updated it a little bit here and there to special case GPSes like the Magellans or a geocache-unaware Nuvi, but it's still about the same. I have a version somewhere that prompts if you want to eject the drive and does the umount / diskutil eject for the right volumes, but it's not on this computer. There's no real magic here, but given the difficulty in this audience of describing copying files with drag and drop, I expect this to not go over real well. There's a whole bunch of hardcoded stuff here like fire-hydrants for the StreetPilot 2720 (the last great dashtop Garmin made, IMO) that aren't exactly obvious - it's not because geocaches have anything to do with fires; it's because it's the highest contrast icon on that model that provides caps so you can see clusters from a distance. The default.wpt stuff is a file of points I always want on the device, like "Home" and family members I may be visiting. [ -d /Volumes/MAGELLAN/Geocaches ] && { GEODIR=/Volumes/MAGELLAN/Geocaches WPTDIR=/Volumes/MAGELLAN/Waypoints } [ -d /Volumes/Garmin/Garmin ] && { GEODIR=/Volumes/Garmin/Garmin/GPX WPTDIR=/Volumes/Garmin/Garmin/GPX # Nuvi 1350LMT. [ ! -d $GEODIR ] && { GEODIR=/Volumes/Garmin/GPX WPTDIR=/Volumes/Garmin/GPX SMART=" -s " } } #for OUTDIR in $OUTDIRS #do # [ ! -d $OUTDIR ] && continue for i in "$@" do case $i in *-wpts.gpx) DEST="$WPTDIR/$i" ;; *.gpx) DEST="$GEODIR/$i" ;; *.zip) echo "Skipping zip file $i" DEST=/tmp/ ;; *) DEST="$GEODIR/${i}.gpx" ;; esac echo Copying $i to $DEST if [ -z "$SMART" ]; then cp "$i" "$DEST" else gpsbabel -i gpx -f "$i" $SMART -o gpx -F "$DEST" fi #done gpsbabel -i gpsutil -f ~/default.wpt -o gpx -F $OUTDIR/default.gpx done sync The similar script I use for my StreetPilot and older Garmins is: $ cat ~/bin/gspup : # Strain of gpsup for uploading to Garmin USB. #GB=~/src/gpsbabel.sp/gpsbabel #[ -x ~/src/gpsbabel.sp/linux/gpsbabel ] && GB=~/src/gpsbabel.sp/linux/gpsbabel GB=~/src/gpsbabel/gpsbabel if [ `basename $0` = "gspup" ]; then TTY=usb: else TTY=/dev/ttyS0 fi for i in $@ do CMD="$CMD -i gpx -f \"$i\"" done CMD="$CMD -i gpsutil -f $HOME/extra.wpt" ${GB} -i garmin -f usb:-1 | while read unit junk junk model do THIS_TTY=usb:$unit echo Sending to $model case "$model" in StreetPilot*) ICON=",deficon=Water\ Hydrant" SMART=-Sn ;; *60C*) ICON=,deficon=geocache SMART=-Sn ;; esac ${GB} -i gpsutil -f ~/default.wpt -vS -o garmin -F ${THIS_TTY} eval ${GB} -w -r $CMD ${SMART} -x duplicate,shortname -vS -s -o garmin${ICON} -F usb:$unit # eval done

A number of posters in this thread would be better served asking questions in the website group at http://forums.Groundspeak.com/GC/index.php?showforum=139 I really don't think that anyone responsible for the site reads this group. FWIW, I've loaded probably hundreds of thousands of caches at this point via scripts that unpack the PQ, use GPSBabel to suppress duplicates, and do some special case things for the Magellans vs. the Garmins and the GPX devices vs. the Garmin protocol devices (I still keep a 12 y/o StreetPilot on my dash) and such. It's totally unusable if you're not me, but a little bit of scripting can automate this and let you not be reliant on plugin and site features that you don't control. As perspective, my script is named "toco" because this version was named when I needed to ship geocaches TO my Garmin COlorado...the first Garmin to actually understand geocaching.

It seems highly unlikely that anybody that knows this number can talk about it, but the tech group is certainly not the right place. Moving.

You may not want to start with Earth or Maps as there may be licensing issues. (As a practical matter, nobody's going to notice you screenshotting your favorite park. Build a tile scraper and sell the imagery from a state and you're going to capture attention you probably don't want.) Going straight to government sites can usually get you license-unrestricted aerial and satellite data. Maps and Earth two use different projections which is unlikely to matter for small areas like individual parks. Rich did a good tutorial when this was announced. http://gpstracklog.c...er-imagery.html and http://gpstracklog.c...maps-day-2.html - it's in multiple pages. Garmin forums are pretty dead these days, but there's https://forums.garmi...min-Custom-Maps There are probably newer articles and tools, but that'll get you started.

Closing because it's not geocaching and overlapts another active thread. TL;DR: Don't.

Garmin has made many hundreds if not thousands of devices. Some of them have mini-USB sockets. Some of those devices came with cables. There are many hundreds, if not thousands, of tablets running a variety of operating systems. Those operating systems and their associated hardware as well as the vagaries of things like USB On The Go and the presence or absence of any needed software to do what you're actually seeking makes this a bit of a riddle. Can you please try to focus your question down a little? What Garmin are you trying to connect to what Tablet and what are you trying to do? It'll really help you get better answers.

There's mixed quality advice above. If you're making legal decisions, such as giving directions to a timber harvester, the advice to not save a few hundred bucks on a surveyor seems sound. Sounds WAY easier than defending against property damage and "theft" when a timber harvester drifts too close to the edge. But I'll leave legal to legal experts and focus on the technical. Consumer grade GPS is still rated 3 meters in fantasy conditions. Newer GPSes make that fantasy more likely, but you're still at about ten feet - and in the woods, on a hill, surrounded by cliff walls isn't it. Your 76CSx, used properly, will be about on par with what you can buy today. But you're going to have to work for it. Hint: the single least expensive upgrade you can make. You want approximately this, but double check that connector type. As for the accuracy while walking a line, observe that specific model, I actually wrote up a (nearly forgotten) article on that very device over ten years ago at http://www.mtgc.org/robertlipe/showdown/ The SirfStar III chips in those had three modes, IIRC. "Track Smoothing" which would compute your moving velocity over time and figure you were probably continuing in about that direction at about that speed (your hike wasn't going to become a jet in two seconds). This had an effect very much like the famed Magellan "overshoot" from the early 2000's. "Static Navigation" where the math would assume you weren't moving 1m this way, .7m that way, .4m that way, etc. in adjacent seconds: you were probably stopped at a stop sign or resting on a bike. There was also the "raw" mode where every little jitter was reported. When you weren't using waypiont averaging (which we assumed was done by software off the Sirf/MediaTek cores) we deduced this generation of devices was using the latter. So if you really wanted good position from these, be prepared to use waypoint averaging over time. But you really should temper your expectations reasonably. If you're expecting to walk 1.3 miles in the woods over terrain following an arrow with a spray can and tell your loggers that anything on that side of the line is fair game, well, that's just not reasonable. I have over a hundred GPSes (yeah, really) and there have been times I've taken a dozen or so of the 'best' for a joyride. Even at auto speeds (my car moves further in a second than you do on foot in the woods, so that 3m matters less) there's some pretty crazy jitter. There are good reasons the GPSes on each end of the blade of the dozers sloping that curve in the road are getting additional help from pro grade gear. As for being "not strictly geocaching related", while I happen to be one of the moderators, I also allow some leeway based on community feedback. This post flushed out many experts that have been here a long time that were willing to help. If your account was created to ask "how I hack the gps to track my cheating spouse's cell like Will Smith does in the movies" or "who knoz the best fleet tracking device?" when you have no finds or hides, but your signature and profile says "contact me fo rthe best fleet tracking gps device", I'm going to have a good day making you have a bad day. :-) We do have some reasonable percentage of the world's (mostly non-professional. mostly.) experts on this tech represented here...and they're pretty consistently telling you to seek professional help (some are even offering it) for more than rough sketches. But as a moderator, I'm going to do my best to strike a balance of 'interesting' and spam-free.

To save you from some perhaps unkind replies, can you please confirm whether it worked _before_ you replaced the batteries? The way it's written, it looks like you've just replaced/installed dead batteries. Whose "help desk" did you contact and what suggestions did you try? When asking for help, asking good questions is a big part of the result.

They've existed for over 15 years. Closing.

Closing in favor of other pandering thread at http://forums.Groundspeak.com/GC/index.php?showtopic=343178

You are, indeed, correct. It was a Mini B and not a Micro B. (My day job was USB for many years, so that's just embarrassing.) Unique shortname collisions are something I solved in the Meridian Plat era in GPSBabel. Not losing 'This is my supercool caching series #43" was an early 2000's project for me. (I can point you to the code that tries to retain the last numeric digits in favor of just making one up to keep it unique within device restrictions if you're into that kind of thing...) That code WAY predates the Delorme units, Delorme giving up on their troubled protocol and presenting USB mass storage and parsing GPX was much welcomed - much like the purchasers of what was left of their business did years before.

I'll defer to the others that actually geocache with these on the exact version numbers, but you really really want to upgrade the firmware to the version where it shows up on your computer like a mass storage device and you just copy pocket queries to it. Delorme's communication protocol was, uuuh, sub-awesome. I actually removed it from the last couple versions of GPSBabel with nobody noticing. (I think I was about the only one to ever support delbin....) If you use your fone for picking hotels and places to eat and your PN-40 for actual hunting in the woods, you should be fine. Mountains change less than hotels. The use of a proprietary cable was unwise when they did it. They're unlikely plentiful these days. It's worth a mention that their cables were well known to be sub-awesome. Three new cables from a box would often fail in different ways. There was a "slug" that plugged into the back that came out into a Micro-B that was WAY more reliable. The kindest thing I can say for the PN-40 was that it was less terrible than the PN-20. I would not go to great lengths to recover an investment in that device, though. A contemporary $200 eTrex can save you from lots of rounts of Delorme Trivial Pursuit if you're in a position to spend money over time.

Hey, Balloo&bd. I know you've been at this for a while and I'm not trying to be mean or start a fight, but I'd advise you to look at a different class of products. Not to be disparaging, but this is a dead market for a good reason. Laptops are terrible to navigate by. I've tried it with every product above and even my own product (which I'm not recommending because it's terrible for this...) It's my personal experience that even the worst Nuvi you can buy today is a better auto nav system than any combination of S&T, Mapsource, Mapsend, Street Atlas, etc. It's not a coincidence that all those programs have stopped focusing on this market. I have over a 120 GPSes and there's still a StreetPilot 2720 on my dash, so I can speak for nostalgia. Any Nuvi (with "LM" or, better yet, "LMT" in its name to add "T"raffic to "Lifetime Maps") for $100 is going to be much less aggravating than keeping a laptop running. An old cell fone running Google Maps with offline maps cached (has to be refreshed every 30 days) or a data-only SIM is going to give you the streets that you won't get on a Mapsend CD (for the cost of the Nuvi...) for years. If you're doing things like multi-point routing (I do) you may need to move from the bottom of the product line, but the overall experience is just better. The price of licensing the map data from Navteq/TeleAtlas is crushing in low volumes. I used to love S&T - it was my favorite mapping app for years. There are features in GPSBabel that exist for me power-caching with S&T...in 2003. https://www.gpsbabel.org/formats/s_and_t/Importing_into_Microsoft_Streets_and_Trips_2003.html I traveled thousands of miles with a laptop operated by a co-pilot, shouting out turn-by-turns and reading geocache descriptions, but I just can't imagine doing it these days. Sorry if that sounds like tough love, but it kind of goes hand in hand with my previous post on serial port GPS...

GPSBabel still supports the serial Garmins. It's easy to imagine a the day I remove it. Honestly, the USB protocol devices might go at the same time as the two are deeply entwined and the last time we saw a NEW Garmin Protocol device (not a paint job or a receiver chip swap) is about fourteen years ago. Honestly, if you tried it and it didn't work, it's not like I'd spend two hours tracking down one of the devices and the cables and adapters and replicating your OS environment unless it were a contract effort. (Maybe you're a park with 400 of them and it's worth you writing me a check...) I'd probably spend the 30 minutes removing it totally. You probably don't ever want to be the first person using some exact combination of USB/serial adapter, driver, OS, device firmware, and host software unless you're prepared to debug it. You're outside herd immunity with serial devices at this point. I can't really say I miss the days of week-long conversations like this: https://sourceforge.net/p/gpsbabel/mailman/message/4907336/ GPSBabel should even read your old EasyGPS files. https://www.gpsbabel.org/htmldoc-development/fmt_easygps.html is another thing that I doubt anyone has actually used in ten years, but it's at least low-maintenance cost for me.

Here's another thread where I have the awkward position of being both a mod and a 15+ year contributor. As a mod, I'll remind you to be respectful of each other. There's a lot of unnecessary roughness above. As a "mere" poster, I happened to be involved in the creation of GPX, the creator of the first multi-platform GPX reader/writer, the creator of GPSBabel, and that guy that wrote War And Peace in "spinning green circle". I have some 15M-ish GPSBabel users and bought an Oregon 600 to riff on implementing .ggz support. First, the community requests/support simply wasn't there. A HUGE percentage of Clyde/GSAK's market needed/wanted it and I helped him/them through some early teething pains, but I think the number of requests I've seen for it in GPSBabelsville probably fit on a single hand. I actually implemented and checked in partial support for it in GPSBabel 1.5.3 which, for totally stupid reasons that were my fault, broke our GPX writer for files > 5MB. Only this holiday weekend did I get a 1.5.4 (mostly) out to correct this, though the source revert has been available for a while. I did the original implementation back in '15 http://forums.Ground...dpost&p=5519295 and spent months calling out for help, test feedback, etc. to be met with silence. My initial implementation worked OK for US english, but went up in flames if anyone did any multi-byte logs, cache names, or descriptions. The device would render trash or crash. This is the dirty little secret of software. Things happen because someone wants them badly enough to make them happen. You put in in a few hours testing and describing a request, your cache-mate puts in a few hours translating to Elbonian, someone donates a GPS, someone pays an intern or student worker to implement and upstream something. If you can't point at the sugar daddy, it's probably you. GGZ in GPSBabel has no sugar daddy. I totally pulled it out of the 1.5.4 release, but if you're interested in working on it (I know where the skeletons are...) I'd welcome a champion to land them. A few hundred users writing tip notes on the backs of tens gets attention. I won't say that I've hit every branch on the way down, but I'm pleased that I identified enough while on a plane to GeoWoodstock to have not published a mostly working writer. I'm more happy to have (officially) not released a ggz writer than release one that breaks if someone uses an umlaut or accent grave. For nerds willing to talk bits and bytes, our (GPSBabel's) remaining deal-breaker was when we moved to QXMLStreamWriter for output. StreamWriter is super awesome and it treats characters as characters, regardless if they're Windows Bloaty Bytes or sane UTF-8 encoded data, as in GPX itself. The way to write .ggz is to call the gpx writer and split the output, but then run a reader over the output (sound slow? Probably. But it's still faster than the battery powered device in your pocket.) to compute those indices (valet parking thingies) that I described before. The "problem" is that that ggz file wants a byte oriented (utf-8) index instead of a sane character count that's awesomely abstracted away from us. So we probably have to write the files to disk, read them back into memory, and then call C era strfoo instead of QStringfoo on them. Probably. At this point, it's about two years in my rear view memory, but I could absolutely coach someone that cared on the issues involved. GGZ absolutely makes [ stuff ] the problem of the writer to save the reader, which is a reasonable tradeoff of processor power in modern times. If you're interested in working on ggz (doc, testing, implementation, funding, coding, whatever) please contact the gpsbabel mailing lists. It's quite dead right now. RJL

[ Warning excessive nerdiness follows. ] Since you're curious, Garmin's GGZ and observation of the units behaviour offers a pretty good hint on why this has been a problem with dozens of Garmin models. I've not reverse engineered them to confirm this and I could be wrong, but I have a bit of relevant engineering experience here. If you add a big GPX file and boot, you'll notice it takes a long time. Some combination of the XML parsing and putting into the unit's internal (probably sqlite3) database is slow. Really slow. Slow enough we want to avoid it when we can. We'll come back to this in a moment. There's a bounded amount of flash storage inside the device. Garmin never says what it is (the flash chips are probably the most readily identifiable to someone willing to void a warranty) but we can be pretty sure it's WAY smaller than a typical uSD card. This is why every unit has a max. There are also parts of that GPX file that they NEED to be fast (lat/lon, cache type, container side) that are pretty small and some parts that can be large (I think a cache description can be 50K on Groundspeak but not formally bounded by size and logs are technically unbounded by number, even though there's probably a limit on log length.) You don't NEED the cache description and logs until you're actually viewing the cache page. So based on that limited internal space, it's quite likely that the device stores that stuff it needs to be fast internally and puts indices/pointers (think post-it notes or lines) onto the SD card. (Think of it like the valet getting stuff from long-term parking.) So there's a line that says "For GC1234, the data is in MyTrip.gpx and the description starts at file offset 64,536 and ends and 65,431. So the internal stuff is fast and only when we're going to actually view the full stuff do we have to send the valet to get the slow/long information, but that's OK because the valet's little drawer of keys knows that parking ticket number GC1234, came from the garage MyTrip.gpx, and is in stall 765. Now let's come back to that slow boot thing. Doing that all the time on every boot is not very awesome. Garmin eventually noticed, "Oh, I've seen this GPX before, I can skip the read." It's actually little bit harder than that. You can't always skip it, the contents might have changed. So if the timestamp on MyTrip.gpx changed, we just have to nuke everything that came from MyTrip.gpx and read that. That's why you see the slow boot in this case. (This is also why the general "take two aspirin" advice of "remove everything, boot, put everything back, boot" is solid advice.) This kind of hints that the speed problem is in their XML reader; if the database write was the bottleneck, they're probably just always read them and do 'replace into' which wouldn't change the record if not changed. Now, what happens if you have multiple files with overlapping geocaches on the device? Let's say GC1234 was in MyTrip.gpx AND in Winter.gpx. Which one "wins"? What if the internal database and the card contents get out of sync? Maybe the device crashed or batteries ran out or some programmer missed a 'transaction begin' or such. Now, the parking voucher that says it's in stall 765 may get confused because stall 765 is in a file that's been removed or there's a totally different type of car there so the beginning and ending pointers now point to nonsense. What if the programmers didn't handle some error case, such as the start and end XML tags actually being start and end XML tags? What if I copied the original on a computer that has an accurate clock, and later that has a date in the past: the date didn't move forward - does it do a re-read or not? In any of these cases (and probably more than I'm not coming up with right now.) the device will PROBABLY do something bad. That might be showing nothing, showing jibberish, or crashing: I've seen all three. This would happen exactly when you go from an overview (picking an entry from the map) to the detailed page to get the relatively large stuff, such as to get the hint or description. That's the majority of the time mine will crash a few times a day when I'm power-caching. This is also why I keep my geocaches on the SD card - if the unit loses its mind and I have to do it in the field, I can take the card out, fast boot, put the card back in, slow boot, and probably be OK for the remainder of the day. You can see Garmin tried to address some of this in the GGZ format[1]. They split the fast data out into what's little more than a .loc file with the kind of pointers I've described. They also added a tag inside the file that contains the CRC of the related pieces so they can see if something has changed without needing to read it all. I created a GGZ writer for GPSBabel (that I rolled back because I broke GPX in the process and general lack of interest in GPSBabel community in GGZ) that bozoed the pointers that came in any caches logically after any multi-byte character. So my original test case of all US text worked great, but the moment I fed it even European caches, it pretty much fell flat on its face. The symptoms were exactly that: the overview worked, but the GPS crashed when you opened the caches AFTER those. There's a bit of poetry here that what I've described above is "caching". (Remember, that word means putting something away for future use: hikers may do it for food, military may do it with gear, computer nerds may do it for performance.) So that's probably called a "cache cache". There is an old comp sci adage that "There are only two hard things in Computer Science: cache invalidation and naming things" so that plays nicely into both. :-) In case I need disclosure, I have no inside knowledge on WHY these Garmins crash show much, but I have developed several similar systems and that would neatly explain the observed behaviour like crazy HTML no longer being the smoking gun that it was in the Colorado era as well as why remove/boot/add back is the "cure" and why it's hard to reproduce. I could be wrong. Oh, and as a minor aside to Red90: thank you for your ongoing service in this group, and I hate to be picky, but to computer people a Mac and a MAC are different things. The first is a computer-like substance built by a company in Cupertino. The second is an acronym for Media Access Control, one of the lower levels of the OSI stack as used by 802 (Wifi, Ethernet) and even cellular radios. So a Mac frequently has multiple MACs. [1] GGZ is pretty bulletproof within a single GGZ, but I'd bet that multiple caches coming and going between multiple GGZs could probably trigger similar naughtiness. You're just less likely to trigger this because "everything in one honking huge GGZ" is probably a more common model than multiple GPXes.

Moderator note Hi, and welcome. I've tweaked the subject of your post somewhat. I see it's your first time here, so here's a tip to asking questions online in general: the subject is the easiest way to attract the attention of qualified helpers on the question you're asking, Think of it like being in a room of car mechanics and shouting "my car makes a funny noise HALP" vs. "my '83 civic makes a noise when going up a hill around a left corner."

My plan has long been to have separate hardware for driving and hunting. The value of lifetime maps, a big screen, spoken turn-by-turns, and not having to fiddle with navigation modes when entering and leaving the car is worth it. The 60CSx is a nearly eleven year old device that was a respin of the 60CS that was two years before that. Tech products just don't get upgrades forever. I use the free OSM data in my handhelds because the features are good enough to get into and back out of hte woods. If Delorme had one viable product to make them worth buying, it was the Inreach line. Replacing Mapsource with SA's city and nav data would be hugely regressive. Street Atlas had been treading water for years. The PN-20/40/60 fizzled.