robertlipe

Since those last digits are way beyond the actual precision of consumer grade GPS, Garmin is basically telling you that you're wasting your time. If I've counted my digits right, you're looking at .11 meter accuracy when civilian GPS is good to 3-4 meters in fantasy conditions. You can dream about 4 inch precision from a Nuvi, but it's not reality. The description at http://gis.stackexchange.com/questions/8650/measuring-accuracy-of-latitude-and-longitude is a good guideline. The follow-up comments are worth reading, too. More than five decimal places is pretty much noise for geocaching.

Since I've participated in this thread as a non-mod, my moderator involvement is awkward. However, as this thread has veered further away from actual GPS tech topics, past Geocaching topics, and is bordering on personal attacks, I'm going to post one reminder to keep this conversation on topic for "GPS and Tech" before I close it for being off topic. Instead of issuing personal love letters in the form of warnings, I'll ask everyone involved to brush up on forum rules of civility, staying on topic, etc.

Since this is in the tech forum, your question is clearly about the tech side and the musings about the moldy boxes was meant for some other group. I actually consider it a GOOD thing that this group is so quiet. I used to dread the day after Christmas when this group was flooded with questions from people about their new GPS, each struggling with a missing cable or some crotchety USB/Serial adapter, or unable to find decent software. The available tools are so much better (and, perhaps, local support groups are better) that we're just not seeing that. Our local group used to teach a class each Jan to help those new to the game work through all these issues and we've just not had to do that for years. I won't say that we never have original questions even in this group, but so much has been written and is easily findable via search that we're just not having to repeat the same conversations every few days. The tools are absolutely more accessible to newcomers now than they were at the beginning of the century. I have kind of the same thing going on with GPSBabel (where geocaching is only one of many verticals served); in 2002 people were trying things that couldn't be done or hadn't been done before. These days, most of the verticals are feature complete with wide device and format coverage and just about anything someone wants to do can be found via online help (which has evolved from 15 years of answering questions not well described before) or a Google search. I've seen a downturn in traffic in just about ALL of the various product forums I participate in.

I've only spent 10 years working on Earth and 15 on GPSBabel, so maybe I'm confused. I pulled the the gtrnctr_power.gpx file from the reference/track directory of GPSBabel (which is probably 6 years old at this point; it came from Training Center from a cyclist not too far from Google HQ) into production Earth 7.1.7.2602, but it matches my mental model of the geography (and thus, crank cadence and heart rate) in that area. It's using the Garmin GPX Extensions v3 and TrackPointExtensions v1 - as I said, it reads "some encodings" and not just any ole set of angle brackets. HR and Cadence are displayed. I don't know what "EGPS" is. If you have a file you'd like placed under the microscope, please PM me. I shall cast my scepter of judgement upon it. It's certainly a goal of mine (and thus, GPSBabel and Google Earth) to read data from a Montana 650 and display it in a useful format.

Google Earth, courtesy GPSBabel, will read some encodings of Heart Rate, Crank Cadence, Power, Temperature, and other things that can be correlated with location. Right click, terrain profile,and you're there. Screen grabs are possible, though I'll admit that hardcopy isn't exactly a key goal in presenting such dynamic data. I kind of happen to be responsible somewhat for both, so perhaps I should feel bad for the plug, but they're both free, so dock my moderator wages if they miss expectations. But everyone in this conversation so far knows those connections...

Time is certainly a factor. If you rip the cable out while data has been written, but the free list hasn't been updated, it's probably benign. If the free list has been updated, but the directory hasn't been updated, you've "just" lost free space on the volume. The next fsck or chkdsk or other "reconcile the books" utility can work that out. If all the writes have been retired, it's _probably_ fine; the forensic cases are down to the exact order. If the directory had to grow and you've updated the end pointer to a block but not written that block yet or the new block is going to be removed from the free list in the next opcode[1], Very Bad Things will happen. (This is also why SWEs have to think about things like the drive controller's firmware "helpfully" reordering your writes in the name of performance or wear leveling.) It's a battle of microseconds. red90's been lucky. I've been paid to design this kind of thing and hope is not a strategy. (Technically, I suppose it is but it's not one that pays well in the long term.) The Oregon's processor does not access the filesystem while the USB storage is being written by the host. This is why the device goes catatonic when you plug it into a computer. (Yes, I know about the serial PVT/NMEA modes.) Filesystems need ONE arbiter of communications with it; if you have two uncooperating devices (think about networked computers, only this is the ARM in your Garmin and your host) that can each read and write shared data structures at the same time, someone WILL corrupt the free list or the directory or whatever. This is why mass storage mode on phones and cameras is such a landmine - it's solved on those devices by using MTP or PTP so there's one arbiter talking to file store and a well defined communications protocol with the other devices that operate at the "here's a file" level instead of scribbling straight to sectors and blocks. It's like a tiny little Netware/NFS/Samba server in your pocket. See discussions like http://www.howtogeek...b-mass-storage/ if this kind of thing interests you. It covers the various solutions without getting too nerdy into why a shared FAT volume just doesn't work. Once the computer has declared it's done (or the cable has been ripped out) the Garmin will scan the GPX directories looking for changes. It's at that time that it updates the internal database. That's also why that first boot after you copy a load of GPX files to is is so slow - it's then that it's parsing the GPX, seeing if anything has changed, and updates the records in what is presumably a sqlite3-like substance. The 4x0's (indeed, all the earlier Garmins) were full speed devices, not high speed devices. This is why they're less agonizing to access and the windows of time are smaller. http://arstechnica.c...2003/10/2927-2/ Given how often a Garmin won't boot after you copy GPXes to it, the "unplug and drive 50 miles" strategy is worth a few extra minutes to do a safe eject AND verify that the stupid thing will boot and show the caches on the map before you leave your computer. It might still crash when you open specific caches or crash because it crashes - problems Garmin's not gotten under control since shipping the original Colorado - but it's worth it to me to prepare to hedge that bet. My script that unzips the GPXes and puts the -wpts and geocaches in the right place does a sync and asks me if I want to eject the volumes. (My devices have an SD card, so there are two; I use the SD card so if the device has an allergic reaction to the newly copied files, I can remove the card and not have to remember which corner of the screen is needed for a factory reset...while I'm standing in the woods.) We are (I am?) veering off charter for geoaching, but firmly into "and technology." Like eating food off the floor is USUALLY OK, sometimes it's not and there are concrete reasons why. It's not magic or luck. [1] Writing this stuff to work MOST of the time isn't terribly difficult. Writing stuff that's resilient in light of all the retries and reordering that can happen at levels below you while someone is ripping out cables or you've hit a bump and lost connection to the batteries -even momentarily- is Really Hard.

I used to build OSes in a former life. The USB stack was one of my projects. I can't get behind the advice above to just ignore it, but since I'm not a Windows guy, I also can't tell you how to get past it. I can only encourage you to dig deeper. In the beginning, disks were attached to computers and couldn't be powered off independently. So it was OK to have stuff in memory that was on the way to the disk to make it consistent. Think of it as an "IOU" to magnetic media. Magnets came and went and went. Hotplug came and stayed. OSes that were designed to hold things in RAM eventually learned to aggressively retire transactions to permanent storage when the busses were otherwise idle because people WANTED to rip the devices from their machines and got grumpy when you were deemed responsible for corrupting the data on that device. Around the turn of the century, OSes learned to treat removable media as "special", even at some performance cost. IMO, if you're getting that message from your OS in modern times, it's because your OS _knows_ there is data that the OS is holding that has not been retired to the device. It might not matter today and it might not matter tomorrow, but you're only going to get lucky so many times. I encourage you to find what's using that device and to tell it "hey, this device is going away, you need to settle your check with the cashier NOW." before you eject it or rip the cable out.

Moderator Note. The OP's question has been answered and he's acknowledged such. This conversation has turned into a fight for no good reason. As such, Im closing this topic and reminding/requesting that posters to be helpful, respectful, and generally useful in ongoing discourse.

I'm pretty much with JohnCNA, but 16GB cards are so small now that they're in the bargain bin. If you're in an area that's well served by OSM and/or you use your phone for answering "where shall we eat/stay" decisions, there's just little reason to pay for Garmin maps. Contribute back to OSM and share the benefits.

Moderator note: I fixed the subject to make it more likely to attract experts on that model. Including details like what country you're in will also increase the quality of the help you may receive.

Former OS engineer here. Media Transfer Protocol, an evolution of Picture Transfer Protocol which was popularized on cameras, grew legs for music and video players last decade, but can handle any type of file that it chooses to support. It is a protocol that exists as a layer between one or more apps talking to a storage device and the code managing the storage device. If you think of a file system as a wall on a shoestore of boxes, it's the difference between everyone adding and removing shoes themselves ("oh, I saw it was empty, so I went to put a shoebox there - hey, I did the same thing at the same time!" or multiple customers fighting over the same box because they both saw it at the same time) vs having one one shoe salesperson that's the only one that's allowed to touch the wall. "Sorry, that box was JUST removed" This allows the salesman to adjust inventory on the fly ("Hey, we need to order....") which you just can't do if all the customers are touching the shoeboxes directly. This is why cameras like to use MTP; by saying "Hey, I'm adding/removing a picture", it can generate or delete a thumbnail or add it to a gallery database. You don't have to do the "safe eject" thing because the salesman knows exactly which shoes aren't on the shelf when the store closes; it's possible to safely reverse any outstanding transactions on the filesystem. It is indeed safer; the shoe salesman don't hand you things that aren't for sale. Anyone that's attached a Mass Storage device and deleted system files will appreciate this. This also means that unless the OS adds another abstraction on top of this, apps (like GPSBabel and thus, GSAK) that are used to reading and writing files can't just read and write files; they have to implement MTP themselves or have the OS do it or farm it out to something like http://libmtp.sourceforge.net/ As for making the Garmin boot times faster, it's likely this wouldn't make the actual read of the GPX and updating internal databases faster as you still have to crack open the GPX, parse it, and stuff it into the database because the same Geocache can appear in multiple GPX files. (You also have to handle the case of deleting anything in the internal database that's not there any more.) Where it COULD make a difference is that you don't have to reboot as often. Since MTP allows both the computer and the device to access the device at the same time without destroying each other (this is why the modern devices all go catatonic when they're attached to a computer) you could copy a PQ to the device, see it appear on the map, confirm that it really is the right area you wish to hunt in or copy more to it without incurring the plug/unplug/boot cycle. I'd expect the individual parse times to be the same. If each GPX file held only one geocache the rules would be different, but that would be terrible in other ways. (Pictures are one per file, as are songs and videos.) Over time, as the royalties and patent landscape surrounding FAT32 and exFAT worsens (TomTom and Barnes and Noble were both hauled to court...) I expect a decrease in the number of portable devices to offer that as an option at all. The device can use whatever filesystem it wants to use internally and use MTP as a way to get files to and from most operating systems. Now that MTP is part of the USB standard and without licensing issues, it's the "obvious" way to do it. Hint: this is another reason why expandable card memory is disappearing from portables. Even the empty socket involves royalties if you expect those memory cards to work (viably) with Windows.

Thank you for posting the solution. That helps others that may have this in the future. This is another case where Garmin could make such a tiny change in the user interface and not befuddle their users. "4321 Points filtered out." would have told you that the devices knew they were there and that the reason you saw zero was because the filters were inhibiting them. You might not have any idea what a filter is or why you accidentallyt urned them on[1], but you'd have been in a MUCH better position to diagnose it and solve it. [1] The touch screen on my 600 makes it easy to change crazy settings accidentally. The touch lock to prevent this is really annoying.

The electronics and firmware of the 60Cx/60CSx/76Cx/76CSx are pretty much the same. There is a mass storage mode that was added late in the firmware life's cycle. If you have really old firmware, it won't show up in mass storage mode ever. Unlike a Nuvi, Oregon, Colorado, etc. the mass storage mode is definitely an afterthought; the unit doesn't automatically enumerate on the USB bus as a storage device, so it won't just automatically show up like a thumb drive. Mass storage mode is useful for transferring tracks (see http://www.gpsfaqs.org/faqs/garmin/xseries/g60csx/tracks.html#gpx) from the device, but it's a bit of an odd duck. You can transfer maps if you're a masochist; it's way faster to remove the card use a card reader/writer and eliminate that model's terrible USB speed. Waypoint transfer via mass storage mode was never a thing in that generation. A program that speaks Garmin protocol is necessary to transfer waypoints. (I happened to write one of the ones cited above...)

Having seen variations of this problem many hundreds of times across a variety of Garmins, I just wish they'd fix this UX. Super easy string change: Instead of "No points found" just replace the string with "No points found nearby". If you have to get a programmer involved: "No points found within" << kSearchDistanceMax << "meters". (Now you have to honor user setts on km vs. miles.) Confirm that you know points are there and you're just not showing them. "0 of 1234 points found nearby" Now you know the device has read the points so you know the device didn't lose them. Be prescriptive: "No nearby points found. Try searching by name or area." This tells the user why you've not shown results AND leads them to the water of how they may get results. They likely limit the search for POIs to keep performance up. If you search for "Starbucks", you don't want to see all eleventy billion results. There just aren't that many user waypoints that even if you got zero on the first one that you couldn't double the size of the bounding box and try again or remove the search bounding box and limit the results by quantity. It's a pretty silly limit. Garmin has messed this up on on a wide variety of devices for many years now and it'd be so easy to just eliminate this issue totally. I know that even a string change isn't free (translation, etc.) but in terms of engineering/user experience problems, this one just isn't hard.

Confirmed. Several of the answers above are incorrect. Vista HCx does not support a USB Mass Storage to transfer waypoints. You need a Linux application that speaks Garmin USB Protocol, and, as a bonus, knows about Geocaching and is able to provide custom icons so you device can distinguish Multis and Virts and such. Lucky for you, I wrote one of those about 15 years ago and have given away over 15 million copies.

I can't speak to the Montana line, but in other lines, that threshold is configurable. On one hand, "every cache in the state" is so messy it's not useful on a map, but if you're in one state four states away and just want to see if your PQ got loaded and don't need map fidelity, it can be handy. It's likely a performance/usability tradeoff. Displaying eleventy zillion points on a map is slow and blurs the basemap, but that's what you're likely to be doing when loading a PQ for a trip for a travel destination.

The way GGZ works is that there are two main types of file in the ggz (which is just a zip file): 1: a collection of small (I think the guideline is ~ 5MB) GPX files that are what you're used to seeing. 2: a very simple "sidecar" xml file that holds lat/lon, cache name, type, container, and a few other things including offsets into the above files and checksums to know when a geocache has changed. It's basically a .loc with info on how each cache is represented in one of the many gpx files that gety bundled. On boot, I'd unpack the GGZ. The contents of (2) have to be read into the database as they're used for search and map display. They need to be fast to access. When a cache is selected, I'd seek into the (compressed, IIRC) file and offset given by the data in (1) for that cache and from there I'd read the long and short cache description and the logs - none of which are available in overview or search screens and which needs to be seen only when you're actually looking at the specific cache. Geocaching.com limits the prose to something like 50K and the number of logs, but other tools can aggregate both beyond that. For this class of device, an on-demand decompress of 50K + the logs should be pretty fast. But since it only has to read and parse the contents on one <wpt> tag, the on-demand part should be fast-ish and it keeps the copy-and-paste Wikipedia entries out of the internal database and on your SD card. It's rather inefficient to create these as you basically have to write the (2)'s and then read them back to build the (1)'s because of the way multi-byte encodings are represented in some XML serializers, but it makes sense for your desktop machine to suffer so your battery-powered ARM doesn't. My mental model of the device's file handling model matches my observations of things like it being terribly slow to boot when it first sees a new .ggz (flurry of database activity, including the "archiving" of caches that used to be on the device and now aren't) and faster when it's not. I think that's also why the device is so crash happy; it's like it doesn't totally shoot down entries of removed caches or handle caches moving from file to file but keeping the same CRC, but that's just my speculation. It's my observation that it crashes a lot, but I don't have repro steps or I'd be on the phne with Garmin until they were tired of me. Not having to keep a copy of the relatively unbounded data in an internal database (cache type + container type + diff + terrain easily fit in two bytes, for example) and keeping that in "long term parking" is likely a key to keeping large data sets. Signed, Wrote most a GGZ writer for GPSBabel...

I share geodarts' skepticism. If the presence or absence of a (well-formed and correct) <bounds> tag results in lost data, that's a bug in the reader. It's far more likely that the act of editing the files removed characters you didn't see or forced a timestamp update that made the device re-read the file. But enough people are observing this that there's an issue somewhere. I wonder if people are being confused by the Garmin silliness of only showing points w/in a hundred miles by default - a UX problem they could fix by adding "some points are not shown because they're too far away" instead of silently truncating. Since this is an extremely common tag, there would be rioting in the streets if this poisoned Garmins. I'd want to put the files before and after into an XML validator before placing blame, but even things like Notepad removing Byte Order Marks or changing the encoding wouldn't match this failure mode. <bounds> is completely optional in GPX. It exists as an optimization for streaming readers. By having a tag at the top that says "you're about to get data that falls in the following rectangle", the software could center a map that contained that and let you watch the data as it's streamed in, for example. The example that geocachers might most relate to is pocket query preview. In preview, you get to stare at a little slice of Seattle that presumably contains Groundspeak HQ while your thousand points are being sent; then the camera is repositioned over the received data. If something like <bounds> was being used (it doesn't actually use GPX, IIRC, though it could...) your map could be centered and you could then see the points appear on the map to see the progressive disclosure as they load without the need of an indeterminate spinner. When I saw that one of the posters was in the UK, I suspected problems involving the Prime Meridian. Bounding Boxes that span hemisphere boundaries are hard and lots of software gets them wrong. When you have four close points on a sphere, there is some ambiguity whether you're describing one small slice of the planet or a big slice of the planet that excludes that slice and software that assumes that "east" is less than "west" can get fooled at the sign wraps at the meridian or antemeridian. I can imagine Basecamp caring about <bounds> for the reason I described above. But since the GPS is "just" reading them into a database, I can't imagine why it would care; it seems unllikely, for example, that they're allocating quadtree nodes at that point, for example. <bounds> could give you the hint that the contents are potentially far apart, but not nearly enough info to be used effectively. It seems unlikely that if a bounds tag were present and wrong that a reader would discard points outside that bounding box, though I suppose that would be legal. (It would slow the read and probably not really provide any benefit...) If I need credentials, I helped create GPX am the author of the first cross-platform app to read and write GPX, helped Groundspeak define the format of the original PQs, etc.

I deprecated the delbin protocol in GPSBabel. Delorme's showed no signs of life in years for the PN devices.. The protocol, doc, and implementation was always poor quality and since they added support for GPX years ago, there's no reason for it to linger on now that Garmin has bought their remains. Delbin in GPSBabel is out.

Moderator note: this is perilously close to advertising for a company selling a product that's not actually geocaching related. That runs afoul of a whole bunch of rules posted at the top of this group that you agreed to and that I'm too tired at this hour to quote but that you can probably guess. Please direct discussions that aren't related to geocaching to that company's sales force or forum or whatever so we can keep this group focused on geocaching tech. Thank you.

Magellan has made dozens of GPSes over the last 15+ years. The ones from 1999 have little in common with the ones from 2015. Please ask more precise questions. WHAT Magellan do you have, what software are you trying to use, and what failure do you observe? Please help the people to help you.

Reasonably so. Supercaps and Li-Ions are kinda sorta interchangeable for this use case. OP didn't say what they took out, they said what they put in. The ones I've taken apart have had Elna components there and that's supported by pages like http://www.gps-forum.ru/cgi-bin/forum/showpost.pl?Board=gpsgeneral&Number=70650&page=0&view=collapsed&mode=flat&sb=5 (russian, sorry) and Elna makes a ton of supercaps and very few batteries. At a casual glance, they look about the same. See http://www.digikey.com/product-detail/en/elna-america/DSK-3R3H204T614-H2L/604-1147-2-ND/2171198 (I could take the time to match voltage, internal resistance, capacitance, etc; I'm not - it's late and I'm just trying to make the point that they look about the same.) Garmin and Magellan learned a hard lesson in the early part of the century when their older units were hitting upward of 7 years and were dropping like flies: a 10 year old battery is almost guaranteed to be bad. Advances in storage and reduced power consumption for CMOS-style clocks had made it possible to store a large constellation if you had a clock that was even vaguely right and a supercap could hold power for months or more and USUALLY lasted way longer than a battery. This isn't to say that they didn't break, but the companies learned from their RMA and unhappy customer rates to find a design that didn't rely on batteries. So I'm not positive for every model out there, but I'm reasonably sure that by the early 2000's, internal batteries to hold the clock up were pretty rare in high-volume, mass market devices. If you remember the horror of the GPS 12 and III or Magellan 315 era units dropping like flies as they hit their tenth birthdays, you'll notice this isn't coming up many times a day for this generation of products. Reference: http://forums.gpsreview.net/discussion/5413/memory-battery-in-garmin-gps-iii or http://www.gpsnuts.com/mygps/gps/hardware%20reviews/magellan%20315/magellan_315_review.htm and many, many threads there that, if they'd followed the same curve given the increased popularity of those units, would be a total storm.

The "internal battery" that looks like a coin hasn't been a battery in Garmins for a Very Long Time. Let's please quit calling it that. (Units like Nuvi or Forerunner that actually power from internal rechargeable actually do have batteries, of course.) A supercap is different than a battery and is used "only" to power the internal clock to reduce time to first fix. It's very rare for those caps to go bad (unlike batteries which have a pretty predictable life cycle measured in years...) but very normal for them to lose their charge if the device is unpowered for a few months. They'll recharge after power is applied. See the thread at https://groups.yahoo.com/neo/groups/Garmin_GPSmap_76C/conversations/messages/9891 The 0.00 firmware thing was well known in units of that era and fixed by firmware and receiver code updates. Many models were affected. http://www.gpsfaqs.org/faqs/garmin/xseries/gvistahcx/Usage.html#no_sats - running the updater several times was the common solution. http://www.naviboard.de/vb/showthread.php?t=20983 https://forums.garmin.com/archive/index.php/t-35977.html If your USB port is slightly broken (another very common problem with models of that vintage) you're going to have a bad time. See if the solder joints have pulled loose and consider reflowing the joints.

A-Team, I've not observed that overshoot, but it comes on on that wikispaces group a lot. I definitely see the indeterminate spinner that never ends several times a day, too. We really need to take a Garmin engineer geocaching. Spend a full day USING the unit and see if that gets converted into action. Bonus points for taking them someplace like Route 66 or E.T. and making them count how many taps it takes to find caches at that speed (not like you exactly need a GPS for most of them, but...) and see if they'd fix the UI. Then again, if they had any competition left in the market, they'd be more motivated to fix some of these long-standing problems. Crashes and hangs have been common since they added geocaching mode in the Colorado. Pretty much every model since then has been plagued by them.

MtnHermit,It is mentioned, albeit indirectly. Observe the bleeding red at http://garminoregon6xx.wikispaces.com/Common+Issues. The reliability of the device is markedly worse than the 450 - and the 450 was pretty bad. I can count on having to pull batteries out several times a day during use. The unit either just totally freezes, becoming totally unresponsive to input, or the display fades to grey as the LCD loses rows and columns of charge in a kind of matrix-y looking way. My suspicion is that the first is a lockup and the second is a crash. To a software person, the distinction matters, but to a user the end result is the same: it quits working and requires a reboot. Obviously, anythng you were doing at the time (averaging coordinates, recording a track, entering a new description, etc.) is lost whether it's a freeze or a crash. It's really sad that the devices don't record data when they crash (think "panic dump" on UNIXy systems) to flash that upload back to home so they can find the root causes by digging for patterns. The speed bump and the capactivie screen are nice bumps to the 450, but the unit is overall pretty disappointing to me. The units are a couple of years old at this point and updates/fixes have all but stopped. Maybe that's not bad because if you look at http://garminoregon6xx.wikispaces.com/Firmware it's not like the upgrades were actually making them more reliable anyway. It's a product line that's pretty clearly in maintenance mode at this time and I'd expect them to hit closeout within a few quarters.