Jump to content
Sign in to follow this  
Followers 2
flowerskunk

Geocaches not showing up on my Garmin eTrex Touch 35

Recommended Posts

I just purchased a Garmin eTrex Touch 35. Yesterday I followed the instructions on Garmin's website for deleting the preloaded geocaches, and now my Garmin just loads for hours without turning on. Last night I put the GGZ files back onto the device, and it will turn on when connected to external power, but it wasn't showing any of the geocaches I had downloaded (GPX files). I've used BaseCamp, and it says they're there, but they don't show up on my device. I tried deleting the GGZ files again, and now in addition to my new GPX files not existing, none of the preloaded geocaches can load--even though they show up on the list--because their data has technically been deleted. I just want to be able to use my GPS for what I bought it for. Is that really so much to ask?

 

Anybody run into this or a similar problem before and know what I can do to fix it?

Share this post


Link to post

Sounds like you are making a huge mess out of it.

 

Removing/deleting the preload.ggz file is the correct way to remove preloaded geocaches, but the next boot sequence can take a very long time for the device to rebuild the internal database.

 

Do this:

1. Remove all geocache GPX and GGZ files from the internal memory.

2. Delete the SQL folder.

3. Reboot the GPSr and allow it time to do whatever it wants to do, however long it takes to boot completely.

4. Turn GPSr off.

5. Power GPSr on again, this boot sequence should only take a few seconds.

6. Download the desired geocache GPX files to the Garmin/GPX directory on the GPSr or microSD card.

7. Reboot and WAIT..... wait..... wait until it has finished rebuilding the internal database.

8. The more caches you load in step 6, the longer step 7 will require.

9. Your geocaches should now be visible on the device.

10. Remember to apply the 'Show All' filter and clear any other filters set.

11. Make sure you have the Map Zoom Level for Geocaches set to a high value so they will show up on the map page.

12. Remember, only geocaches within ~100 miles of the GPSr current location will show up in the Geocache List.

 

More eTrex Touch info here.

 

 

Edited by Atlas Cached

Share this post


Link to post

This always bugged me. Since GGZ files contain their own index, shouldn't adding/removing them speed up the boot process compared to removing/adding GPX files with the same number of caches? Then again, 250,000 data points is a lot to deal with.

Deleting the SQL folder *should* make it boot faster because the device is rebuilding the database from scratch, and without that GGZ file in there to read, there will be significantly fewer items to index.

Share this post


Link to post

Reading XML isn't particularly fast and making it into data structures that can be rendered onto a map with reasonable draw time takes more than just a linear scan of lat/lons and stuffing them into a Sqlite3 database - and probably a different still structure in memory - takes a while. A quarter million points just plain takes a bit. Taking several minutes really makes me suspect they're doing something silly, though.

I just checked GPSBabel reading a .loc file (approximately as complicated as the index part of ggz) and it takes almost a second to read 26,000 caches. I get that's more horsepower than you have in a handheld Garmin, but the point is that reading large-ish XML isn't instant.

The SQL tables are accessible via computer now? Is this something in the newer models or in the newer firmware builds? I've been out of the geocaching biz for a while. I'd almost bet that a real computer could read those ggz files and cram them into a sqlite3 file to be copied over faster.

They probably have to do a full rebuild of the databases when they see changes in the .ggz filestore. A geocache could be present in multiple files. If it's archived in B and active in A and you remove either one, you probably want the handset to reflect the remaining data. It's certainly less opportunity for bugs if you rescan them all at boot and skip the re-read ONLY if the full set is unchanged. (You could also do that while the device is running to be less annoying.)

I do agree with your final sentence. If you delete the SQL AND the source, it should be fast...

Edited by robertlipe
Clarification

Share this post


Link to post

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
Sign in to follow this  
Followers 2

×
×
  • Create New...