Spinning green circle on Garmin

[+hzoi]

Posted earlier in "how do I" but dropping anew here by recommendation.

 

I have been experiencing the spinning circle of doom on my Garmin Montana more often as of late -- cache description and/or hint and/or logs just won't load. But it's not for every cache. For example, the other day I was unable to see the descriptions for this cache but was able to see this one just fine.

 

I have been loading caches using GSAK and the GarminExport macro, but I've also experienced this in the past using the regular Send Waypoints function in GSAK.

 

I have just under 1200 geocaches loaded in my GPSr at present.

[+Viajero Perdido]

Hmm. Looking at the cache in the first link, I see it's a bog-standard simple write-up with absolutely nothing more than a few sentences of plain text. No fancy HTML at all.

 

That would've been my first thought: crazy HTML. But nope.

[+Red90]

I would delete all GPX on the device and reboot. If you are on a MAC, empty the trash. Reload and try again. If that does not fix the problem then repeat with a master reset.

[+hzoi]

Deleting the GPX files seems to have fixed it, for now. Curious how this was caused, as I was under the impression that my old GPX file of caches was deleted just prior to new files loading to the device.

 

Perhaps from now on I'll delete the old caches.gpx file regardless to avoid this.

[+GeoTrekker26]

I've noticed times when my eTrex 20 did not handle duplicate (new vs old) caches as I expected. If you want to be sure the GPS is clean, you need to do a reboot after deleting the old file before you add the new file. This will insure both the GPX file and the internal database index are purged.

[robertlipe]

[ 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.

[+hzoi]

I've noticed times when my eTrex 20 did not handle duplicate (new vs old) caches as I expected. If you want to be sure the GPS is clean, you need to do a reboot after deleting the old file before you add the new file. This will insure both the GPX file and the internal database index are purged.

 

Thanks. Will keep this in mind. Been using paperless GPSr's almost from the get go, amazing that I have taken this long to figure this out have this spelled out.

 

[ Warning excessive nerdiness follows. ]

 

Many thanks for taking time to explain this. Certainly makes sense.

[+Mineral2]

At one point I had two rather large GGZ files on my Oregon 600, and the files did overlap a bit - one was for my local area, the other for a road trip we were planning to take. I noticed my Oregon was very sluggish and couldn't figure out why. I first thought that I had just loaded too many geocaches (~24,000), but ruled this out since the stock file Garmin provides contains 250,000. Also, the GPS was working smoothly prior with the larger road trip file. I figured that it might be that I have two GGZ files with overlapping caches. So I removed the GGZ files and loaded a single GGZ file and it seems to be working better now. I haven't yet tried multiple GGZ files with no overlap, though I'll probably do that soon since I'm traveling for Thanksgiving this year.

But at the moment, the working hypothesis is that overlapping GGZ files don't play nice the way overlapping GPX files do.