Jump to content

Equipment Advice


NetraLee
Followers 3

Recommended Posts

Truly enjoy geocaching - but after discovering my perfectly-functioning Garmin is no longer able to connect/download (too old????)

 

I' m looking for a handheld that is easier to see, easier to input.

As I get older, it's more challenge to see the screen and use the unit when it's cold outside!

 

Any advice would be appreciated. 

Thanks!

NetraLee

Link to comment
1 hour ago, NetraLee said:

Truly enjoy geocaching - but after discovering my perfectly-functioning Garmin is no longer able to connect/download (too old????)

I' m looking for a handheld that is easier to see, easier to input.

As I get older, it's more challenge to see the screen and use the unit when it's cold outside!

Any advice would be appreciated. 

 

Curious ...If viewing the screen in cold weather is a challenge, wouldn't any gizmo have to be viewed in the same, cold weather ?  Thanks.

You don't say what you're using, but if you're still going to do only a couple caches a year, why not just load them manually ?    :)

I've done that since starting, also on a long-discontinued model (60cxs), and simply bring a pocket notepad for notes n stuff.

 

Like RuideAlmeida, if you already have a sorta-smartphone, and going after a couple caches a year, I'd use that.

 - Realize though that as a basic member, the caches you can view on the website above D2/T2 aren't available on the app. 

You'd have to load them manually into the app too.  ;)

Link to comment

Besides "the app" which is somewhat beginner-focused, there are other quality caching apps for both Android and iOS.

 

And the better apps do allow you to magnify things for old eyes, so you don't need to keep pulling out the reading glasses.  :)  With the bigger screen of a phone, even in magnified mode you still have a usable display.

  • Upvote 1
Link to comment

I'm actually quite torn. I used to cache with a 60csx. Loved that thing to death. Literally.

 

I had a bit of a lull in geocaching from 2015-2020. I still did it casually. Mostly with an iPhone. Currently have an iPhone XR, and I've found hundreds of caches with it. It's great for casual caching - you've always got it with you, the data plan lets you pop open a map and see what's around, you can log and post photos from it, etc etc. Phones are great for casual geocaching.

 

However, if you plan to do more than a few, you'll kill the battery pretty quick. The reception and accuracy isn't quite as good as a real handheld GPSr. The "compass" is laughably bad. If you lose cell reception in the woods, suddenly you feel very nervous. And in the bitter winter cold, all of that is exacerbated. Touch screens are not great with gloves on. And better make sure you don't ever drop it, or you're totally out of luck.

 

I've started to pick up the hobby again and starting to do more substantial hikes into the woods instead of just park and grabs and short walks. I learned the hard way last week that when you're bushwhacked into the woods a few hundred meters from the trail, relying on the phone to get you back out was iffy.

 

So I bought a GPSMAP 66s. And, well, I kinda hate it. Compared to my previous experience with my 60csx and spoiled by the responsiveness and giant screen of the iPhone. I find the geocaching function on the 66s to be slow and clunky. Takes forever to download a pocket query. Something as simple as the "Found" button on the compass view of my 60csx, is not available on the 66. If I want to mark that I've found the cache, I have to push something like 6 buttons (menu - arrow down to Log Attempt - Found). And the map view with a dashboard is really small.

 

I see that the 64 and 65 do have the Found button on the compass. I'd almost switch just for that. But then I give up the nicer screen of the 66, and other nice features. I'm really torn about whether to just keep the 66 and learn to live with its quirks, "downgrade" to a 64 or 65, or just return it and go back to just my phone (and carry a large power bank in my backpack).

 

Edited by GreyingJay
  • Love 1
Link to comment
7 hours ago, GreyingJay said:

However, if you plan to do more than a few, you'll kill the battery pretty quick.

 

Some of your complaints will be lessened if you save your desired caches (or a PQ, or a List) for offline use, by instance.

Edited by RuideAlmeida
  • Upvote 1
Link to comment

I am sorry to read that GreyingJay doesn’t rate the 66s.

I have had mine for two years having gone thru the 60,62,64 versions

 I would not go back

Ok the FOUND Key has gone but if you set the Compass screen to have the geocaching dashboard then from an active cache. - Hitting Menu>  Geocache> enter takes me to the log screen. The 66 will generally remember your last page to page sequences

Once you have done the sequence a few times......It takes me 1-2 seconds

 

 The other thing I have done is to remove many of the screens on the opening ribbon 

I just have 4 .  Map (1st opening screen) , Compass with GC dashboard, Geocaching and Trip Computer. ( I have 10 fields set up)

 With this set up I can page quickly in a loop to anything I need for GCing very quickly , literally in seconds

 

I generally find it quicker to load PQ via a Pc. None of the other  devices using “over the Air “downloads are very quick ( I have an Oregon 750 and that is the same)

  • Upvote 1
Link to comment

I went out again this morning to further shakedown my 66s experience. I think it is growing on me, though I still don't like the multitude of button presses to note a cache as found. I will look into your suggestions, mikeD. Maybe with some unit customizations I will learn to love it. I know on the forum I see many people who say they love the 66s over the 60/62/64. Maybe a future software update will bring back my beloved "found" button :D

 

I am still experiencing issues with live syncing of pocket queries and lists (it is SLOWWW!! and I must have aborted the process mid-transfer because some of the trads I hoped to find today weren't on the unit -- yikes!) so I agree I think I'll just load PQ's from my PC like I used to do.

 

Edit 1:

mikeD - I just tried your suggestion to put the GC dashboard on the compass page. Doesn't that mean you end up with two compass dials on the same page?

 

Edit 2:

I just set up my main menu ribbon to be simpler, like mikeD suggested, and turned the scroll animation/preview off. I like this better already.

 

Edited by GreyingJay
Link to comment

I suspect this is the journey I will be taking too...

 

Anyway, I hope my feedback is of help to @NetraLee. The 66s is a good unit with a bigger and more hi-res screen than the other GPSMAP series. Same screen and interface as the Oregon 7x0 series. You just have to decide if you prefer a touchscreen or clicky buttons. Each have their pros and cons.

Edited by GreyingJay
Link to comment
4 hours ago, GreyingJay said:

I am still experiencing issues with live syncing of pocket queries and lists (it is SLOWWW!! and I must have aborted the process mid-transfer because some of the trads I hoped to find today weren't on the unit -- yikes!) so I agree I think I'll just load PQ's from my PC like I used to do.

 

It is not extremely fast, for sure - but you can check your PQ/List downloads on the device to be sure the SYNC is complete before you disconnect the GPSr from the internet connection (Bluetooth or Wi-Fi).

 

If your PQ's or Lists have hundreds or even thousands of geocaches loaded, may I ask how many of those you are certain to hunt for and find on any given day?

 

I find it much easier to use the GCLive feature to simply download local geocaches on the fly, when and where I need them, instead of using a lot of valuable time contantly downloading and refreshing large PQ's and Lists.

 

You may find some helpful information about your Garmin GPSr here.

Link to comment
1 hour ago, Atlas Cached said:

 

It is not extremely fast, for sure - but you can check your PQ/List downloads on the device to be sure the SYNC is complete before you disconnect the GPSr from the internet connection (Bluetooth or Wi-Fi).

 

If your PQ's or Lists have hundreds or even thousands of geocaches loaded, may I ask how many of those you are certain to hunt for and find on any given day?

 

I find it much easier to use the GCLive feature to simply download local geocaches on the fly, when and where I need them, instead of using a lot of valuable time contantly downloading and refreshing large PQ's and Lists.

 

You may find some helpful information about your Garmin GPSr here.

 

I've found the GPSrChive website to be most helpful. I assume you run it? Thank you for putting together such a great resource.

 

As for PQ's, you're right, perhaps I need to rethink how I do things. My PQ's date back quite a few years and include searches for things like "1000 traditional/multi/virtual caches near me". The thinking dates back to pre-iPhone days. The idea was that I never knew when or where I might desire to cache, so I'd keep as many as possible loaded up (1000 was the limit of the 60csx) "just in case" and refresh every week or so to keep it up to date. Now that data is so ubiquitous (and now that I can do live searches from the unit itself) this approach probably makes a lot less sense.

 

I do have a bookmark of "solved puzzles - go get 'em!" that currently consists of about 230 caches with corrected coordinates. (Including a set of 150 geo-art caches that were put together for Canada's 150th birthday in 2017) I'm obviously not going to go get them all in one day, but up until now there had been no reason to keep the list small. I hope to connect the 66s to WiFi and sync the list live - and just keep it synced as the bookmark list evolves as I remove the ones I've found and add new ones I'd solved. However, it appears that when I try to sync, it takes the GPS quite a few minutes to do its thing. Maybe I just need to go find those 150 caches - then my bookmark will be a lot smaller and more realistic to keep synced going forward.

 

Edited by GreyingJay
Link to comment

 

“Edit 1:

mikeD - I just tried your suggestion to put the GC dashboard on the compass page. Doesn't that mean you end up with two compass dials on the same page?”

 

 Yes it does but it speeds up  access to the GC info. Btw I change my compass pointer ( menu>Heading set up>Small) to the. Thin pointer-  It makes for a better page view IMHO

  • Upvote 1
Link to comment

Thanks to you all.

 

I do not have nor do I wish to have a smartphone. Preference is to work with the library.  And the cold weather makes it uncomfortable to use the keys. That is workable, if the unit is simpler and requires fewer entries to get going. 

 

The larger screen is for boomer eyes. Not much else to say.

 

How does downloading so many pqs work?  I've had some loaded (years ago), sought them days/weeks later, only to find they were gone or others could not locate.  Again, I prefer to maintain my anonymity and privacy with electronics. 

 

Again, thank you all - I will check into the 66.

 

NetraLee

Link to comment
On 1/9/2021 at 9:18 PM, GreyingJay said:

If I want to mark that I've found the cache, I have to push something like 6 buttons (menu - arrow down to Log Attempt - Found). 

 

Just wanted to comment on this - if you go Menu -> Up arrow once you are on Log Attempt.  Saves a few clicks.

 

But I agree with you about losing the Found button.

  • Upvote 1
Link to comment
On 1/19/2021 at 8:08 PM, NetraLee said:

How does downloading so many pqs work?  I've had some loaded (years ago), sought them days/weeks later, only to find they were gone or others could not locate.  Again, I prefer to maintain my anonymity and privacy with electronics. 

 

With the 66 (and most modern Garmin GPS units, from what I can tell) you just set up all the Pocket Queries you want, and download them to your computer as ZIP files. You then plug in the GPS to your PC via the USB cable and it mounts like an external disk. You then unzip all of the pocket query files and copy them to the GPS.

 

(There are other ways to do it - including connecting the 66 to your home WiFi and having it download the files directly from Geocaching.com servers - but this method is slow and clunky, and I think I'll stick to copying the files)

 

As you surmised, downloading the PQ's to your GPS only capture the state of the caches as of the date you ran the query. Over time caches disappear, other caches are added. Best bet is to re-run the queries periodically (every week?) and just copy the GPX files to your GPS again, overwriting the previous ones.

 

At least with modern units you can download as many as you want onto the GPS. My 60csx had a hard limit of 1000 so I was constantly wiping it and replacing the waypoints stored on it.

Link to comment
7 hours ago, GreyingJay said:

At least with modern units you can download as many as you want onto the GPS. My 60csx had a hard limit of 1000 so I was constantly wiping it and replacing the waypoints stored on it.

Do you load this many PQs? On my 66st, when I get to about 30 PQs or so, everything starts to slow down. When I get to 50, it's almost unusable, so I have to clear it out and start over.

Link to comment
19 hours ago, dprovan said:

Do you load this many PQs? On my 66st, when I get to about 30 PQs or so, everything starts to slow down. When I get to 50, it's almost unusable, so I have to clear it out and start over.

Do you load all those PQs directly? I've put well over 50,000 geocaches on my older Oregon 600 via GPX and it only really chugs during that initial boot where the unit is reading the GPX files and indexing the geocaches to the database.

That said, I didn't load 30 pocket queries directly, but rather installed a single GPX file with 70,000 + cache listings from iCaching. You could do the same by keeping a database in GSAK if you are a windows user. Or you could install all those caches via a single GGZ file which does seem to work faster since the file contains its own database index within it.

Link to comment
15 hours ago, Mineral2 said:

Do you load all those PQs directly? I've put well over 50,000 geocaches on my older Oregon 600 via GPX and it only really chugs during that initial boot where the unit is reading the GPX files and indexing the geocaches to the database.

Yes, I load that many PQs. It does chug during start up, but the real problem is that everything else gets slow. Most of it I could live with, maybe not even notice, but even map drawing slows down to the point I find it unbearable.

 

15 hours ago, Mineral2 said:

That said, I didn't load 30 pocket queries directly, but rather installed a single GPX file with 70,000 + cache listings from iCaching. You could do the same by keeping a database in GSAK if you are a windows user. Or you could install all those caches via a single GGZ file which does seem to work faster since the file contains its own database index within it.

Wow, that's really interesting input. I was assuming the problem was just raw cache numbers, but from your input, it sounds like something broken about the handling of PQs. I wonder what. The one thing I can think of is that my PQs tend to overlap, so maybe it's a problem with the fact that, in my unit, any given cache might come from 2 or 3 different PQs.

Link to comment
17 minutes ago, dprovan said:

The one thing I can think of is that my PQs tend to overlap, so maybe it's a problem with the fact that, in my unit, any given cache might come from 2 or 3 different PQs.

 

Bingo!

 

Doing this creates a lot of extra work for the GPSr, as it has to decide which copy of each duplicate the device will use, and which will be ignored, especially since not all PQ's (or GPX or GGZ) files are updated at the same time, which can lead to multiple copies of the same geocache, each with different data! I do not know exactly how this is decided.

 

 

Edited by Atlas Cached
Link to comment
12 hours ago, Atlas Cached said:

 

Bingo!

 

Doing this creates a lot of extra work for the GPSr, as it has to decide which copy of each duplicate the device will use, and which will be ignored, especially since not all PQ's (or GPX or GGZ) files are updated at the same time, which can lead to multiple copies of the same geocache, each with different data! I do not know exactly how this is decided.

 

 

Too bad the software doesn't make those decisions once when it loads the PQs instead of continuously during operation.

 

Did I miss the documentation of this limitation?

 

Now I know why no one else sees the problem with PQs expiring I keep having: everyone's managing their cache databases externally and continually downloading everything as a single file.

Link to comment

I'm not entirely sure why these devices behave the way they do. Back when I loaded PQ files directly, I didn't have much of a problem, but I also only loaded 10 PQs at a time. I was always under the impression that the devices handled overlap only during the indexing at startup. After that, a cache was in the database only once, and I think it simply takes the first index and discards all future listings with the same GC code. But maybe it doesn't do that? Maybe it's pruning the listings in real time as they show up for search or on the map? If so, that seems like a real computational inefficiency on the part of Garmin.

Link to comment

Nobody knows 'exactly' how Garmin GPSr function under the hood except Garmin software engineers, and even then.....

 

But, anyone can open a GGZ to see that it is just reformatted GPX that includes a TOC with basic elements required to display each individual geocache on the map or in the list, but when you want to open or view a geocache from the map or list, the device actually uses the GGZ index to find the detailed information for the requested geocache somewhere else in the same GGZ file.

 

Used to be that the Garmin devices were not as sensitive as they needed to be in determining if any GGZ files were updated or changed at each power on event, resulting in crashes when they tried to access specific information that had been moved slightly within the same file. But they seem to handle this much better now.

 

So, try to image the GPSr is reading each and every unique geocache from each unique GPX and GGZ file on the device, one at a time, to create an internal master index. Each time, the data read must be compared to the data that already exists in the master index to determine if the data is older, newer, or the same.

 

Total available RAM is not unlimited, so where one entry ends, the next starts. This information is saved as part of the indexing process.

 

Now, two or three GPX or GGZ files later, the device finds another copy of a geocache that was already indexed during the same power on event, and must now 'choose' which will actually be used (likely the more recent version, but I do not know for certain). Now, the old entry from the master index must be removed, and a new entry inserted, but likely the new entry will not fit into the space left behind by the removed entry, so now the entire master index is either 'fragmented' or rebuilt again to maximize memory usage efficiency.

 

Imagine doing this for tens of thousands of geocaches, in multiple files, many of which likely contain duplicate entries, some of which will not agree with each other as they may be from different dates.

 

Then repeat again for any geocaches loaded to the device via GCLive, which are not in any GPX or GGZ files.

 

And even when this entire process is complete, the device now has to go back through the entire master index and find any entries that exist there but were no longer found in any of the existing GPX and GGZ files on the device. These are 'deleted' or 'removed' geocaches, and they must now be removed from the master index, which must then again be rebuilt if it is not to be left fragmented, which I suspect it is not, else they would eventually have a very ugly and very fragmented master index to deal with. And since there are no 'defragment memory' options in the user interface (other than a master reset), I find it more likely the index is rebuilt in real time to prevent fragmentation.

 

All of this is performed by a CPU that is powered by a pair of 'AA' batteries while expected to provide 16 hours of runtime per charge.

Link to comment
25 minutes ago, Atlas Cached said:

Nobody knows 'exactly' how Garmin GPSr function under the hood except Garmin software engineers, and even then.....

 

But, anyone can open a GGZ to see that it is just reformatted GPX that includes a TOC with basic elements required to display each individual geocache on the map or in the list, but when you want to open or view a geocache from the map or list, the device actually uses the GGZ index to find the detailed information for the requested geocache somewhere else in the same GGZ file.

 

Used to be that the Garmin devices were not as sensitive as they needed to be in determining if any GGZ files were updated or changed at each power on event, resulting in crashes when they tried to access specific information that had been moved slightly within the same file. But they seem to handle this much better now.

 

So, try to image the GPSr is reading each and every unique geocache from each unique GPX and GGZ file on the device, one at a time, to create an internal master index. Each time, the data read must be compared to the data that already exists in the master index to determine if the data is older, newer, or the same.

 

Total available RAM is not unlimited, so where one entry ends, the next starts. This information is saved as part of the indexing process.

 

Now, two or three GPX or GGZ files later, the device finds another copy of a geocache that was already indexed during the same power on event, and must now 'choose' which will actually be used (likely the more recent version, but I do not know for certain). Now, the old entry from the master index must be removed, and a new entry inserted, but likely the new entry will not fit into the space left behind by the removed entry, so now the entire master index is either 'fragmented' or rebuilt again to maximize memory usage efficiency.

 

Imagine doing this for tens of thousands of geocaches, in multiple files, many of which likely contain duplicate entries, some of which will not agree with each other as they may be from different dates.

 

Then repeat again for any geocaches loaded to the device via GCLive, which are not in any GPX or GGZ files.

 

And even when this entire process is complete, the device now has to go back through the entire master index and find any entries that exist there but were no longer found in any of the existing GPX and GGZ files on the device. These are 'deleted' or 'removed' geocaches, and they must now be removed from the master index, which must then again be rebuilt if it is not to be left fragmented, which I suspect it is not, else they would eventually have a very ugly and very fragmented master index to deal with. And since there are no 'defragment memory' options in the user interface (other than a master reset), I find it more likely the index is rebuilt in real time to prevent fragmentation.

 

All of this is performed by a CPU that is powered by a pair of 'AA' batteries while expected to provide 16 hours of runtime per charge.

And that they can do that at all is rather amazing - I got my Computer degree in '74 (when 32K was a nice machine) so seeing the changes and improvements is quite something.

Link to comment
31 minutes ago, The Jester said:

And that they can do that at all is rather amazing - I got my Computer degree in '74 (when 32K was a nice machine) so seeing the changes and improvements is quite something.

 

32k was a very nice machine back then!

 

I remember writing programs for machines with 8k and 16k ram. Had to be very purposeful and efficient with every line of code.

 

Good times.

Link to comment

Indeed.  Back in '67, the IBM 1130 I was using had only 16K of foreground memory and 16K of background memory.

Then again, that's back when a FORTRAN compiler could run in 4K.   APL was a total kick.  Here's a "Pick 6" (from 40) lottery number generator:

x[x6?40]

If you didn't know the language well, it was just Hieroglyphs.

Link to comment
On 1/26/2021 at 10:31 AM, The Jester said:

And that they can do that at all is rather amazing - I got my Computer degree in '74 (when 32K was a nice machine) so seeing the changes and improvements is quite something.

Unfortunately, what's happened is that the very careful focus on efficiency that you learned in '74 is not understood by modern programmers because it isn't an issue on the laptops they learned to program with. That ends up being a problem even on laptops, but when you take the same kind of laptop approaches and put them on a teeny, tiny -- comparatively -- handheld GPSr, things start to take a long time when, if you'd programmed them knowing what you learned in '74, they'd be quicker.

 

I can't specifically say anything about any of my GPSrs' implementations, but they tend to be so slow that I'm inclined to believe that someone like you that actually understands the tradeoffs of various sorting algorithms could do way better than someone calling the generic sort function from whatever their utility library is.

Link to comment
12 hours ago, ecanderson said:

x[x6?40]

If you didn't know the language well, it was just Hieroglyphs.

 

I still have some ForTran books around here somewhere...

 

 

7 hours ago, dprovan said:

Unfortunately, what's happened is that the very careful focus on efficiency that you learned in '74 is not understood by modern programmers

 

The other thing that happened is the internet.

 

Back in the day, there were no bug fixes via a nearly instant internet downloadable patch... No, back then they had to test the code over and over and make it right the first time. Releasing a product that didn't work or crashed all the time almost guaranteed the failure of the brand.

 

In todays world, memory is inexpensive and plentiful while bug fixes can be applied anywhere in the world with an internet connection, so why care?

Link to comment
3 hours ago, Atlas Cached said:

No, back then they had to test the code over and over and make it right the first time.

 

Like Garmin still needs to do.  Operating system + application together in a single download, what could go wrong?  (I assume it's still that way with current models.)  I always crossed fingers and clenched cheeks when installing an upgrade, because the risk of bricking was small but definitely not zero.  Every upgrade had to be evaluated on risk vs reward.  (Sorta like vax's today, heh.)

 

I'm willing to bet (with no way to prove) that the Garmin slowness mentioned upthread is due to a bad pessimal algorithm, not a lack of processor speed, and that the use of some profiling software & skill at Garmin HQ could make a world of difference.  (I've done profiling & speed optimization; it's challenging but gratifying work.)

Link to comment
On 1/27/2021 at 6:04 AM, Atlas Cached said:

 

32k was a very nice machine back then!

 

I remember writing programs for machines with 8k and 16k ram. Had to be very purposeful and efficient with every line of code.

 

Good times.

You reminded my of my first computer. An Atari 400 that I had upgraded from 8k to 16k! What a wonderful machine.

Link to comment
1 hour ago, colleda said:

My son  had a 520ST and a Jaguar. We still have them.

My first computer was a Kaypro 4 with 64K of memory (so 'roomy' after working with the college's 32K).  I still have it, plus it's 'big' brother a Kaypro 10 with a 10meg hard drive.

  • Love 1
Link to comment

I've posted before how I'm reasonably sure the Garmins handle reading those files ... at least based on how I would build it based on my experience building similar systems. I'd bet strongly there's a SQL3-lite database (or something close to it) that gets (at least partially) clobbered on boot and then populated by GGZ and GPXs on boot.  GGZ's contain a crc (the spec had ambiguity on how exactly it was calculated but as long as the same software cmoputed it the same way, it washed) so you could know to shoot down entries that had been seen in that GGZ from the last boot that now had potentially different contents The ordering that was in the Garmin spec I last saw was "undefined" and it's probably in the order they're last seen in the file walk and even within the same file. Last one in wins. Outside the files, the order is _probably_ the order they appear inside the FAT directory table, which is so hard to predict that you could never describe it or predict it so I'd also call it "undefined".  I doubt it's doing any scanning at runtime, which is why boot on these things is so painful - pay for that file I/O and XML parsing up front and not on a map draw or a user touch event.

So I think I agree with Minera'ls understanding (educated guess - same as mine) except I'd make the "last" instead of "first" be the authoritative copy that's kept in the master DB and that's dragged into the more efficient (likely a quadtree) structure so you can map them without killing that ARM core.


Oddly enough, one of my hobby projects right now is programming an OS on a computer ... with 32K of RAM. I'm porting the OS that would have been about what was in use in the mid 70's. I knew the guy at IBM that managed the team that did the Fortran compiler for the 1130 - because I've programmed those, too. I think it was used on either 1800, too, but I never used one of those.

Oh, and get off my lawn. :-)
 

  • Funny 2
Link to comment

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...
Followers 3
×
×
  • Create New...