Jump to content

Oregon 6xx Owners, A Question or Two


Recommended Posts

Toying with upgrading my OR 450 to an OR 600. A question or two:

 

  1. The OR 450 after firmware v5.5 connects tracks across different days, does the OR 600 do this also?
  2. Battery life better, worse or the same?
  3. How does one switch from portrait to landscape, as simple as rotate?
  4. Anyone using it with Tempe?
  5. Would you "upgrade" again?
  6. Recommended screen protector?
  7. Anything you really like/dislike about the 600 vs the 450?
  8. Wait for next generation, seems due?

 

FWIW: My 450 has been stone reliable since I bought it and is to this day. Now a battered old friend, like me.

 

Thanks

Link to comment

1. Yes, unless you set it to archive daily.

2. It's about the same

3. Rotation baby. You can also lock it to landscape or portrait.

4. I'm not, but I've considered getting a Tempe.

5. Absolutely.

6. Just go to Amazon and search for Oregon 600 screen protector. The screen is fairly scratch resistant and the screen protectors do scratch and scuff pretty easily, but after scratching up my 450's screen, I decided I wasn't taking any chances. You can always replace the screen protector.

7. Hands down the most useful feature is the custom button. That, coupled with the ability to pause/start track recording sealed the deal. The screen is brighter and easier to read, even when the backlight is turned off. But don't get rid of your 450 either. The 600 doesn't have a Wherigo player.

8. It's a great unit and I can't imagine that the next generation will have a significant advantage over this one (much in the way that the 450 wasn't a huge upgrade from the 400). Go for it, especially if you can find it on sale.

Link to comment

No one has mentioned the freezing issue. Reading the Amazon reviews, as late as May 2016 there was a review mentioning freezing. The need to remove the batteries for minutes/hours to restore. What exactly freezes? How would the freeze affect my track recording?

 

Yesterday I visited GPSCity OR600 $250, today $340. Was I hallucinating?

 

Thanks all for the replies.

Link to comment

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.

Link to comment

I can usually count on having to pull the batteries at least once a day when geocaching for long periods of time with the Oregon 600 (I'm using firmware version 4.80).

It usually happens when trying to view a cache description, but I've also had it happen reading logs, and one time while trying to log a find.

 

I also had to pull the batteries with the GPSMAP 62s I had before I bought the Oregon 600, so it's not limited to the Oregon 6x0 series.

 

My guess, and it's just that, is that when Garmin did a firmware update in January 2015 (across numerous handheld models) to fix track related issues, they introduced a new glitch into all of the related firmware releases.

Link to comment

No one has mentioned the freezing issue. Reading the Amazon reviews, as late as May 2016 there was a review mentioning freezing. The need to remove the batteries for minutes/hours to restore. What exactly freezes? How would the freeze affect my track recording?

 

Yesterday I visited GPSCity OR600 $250, today $340. Was I hallucinating?

 

Thanks all for the replies.

 

It happens. It's been happening less often for me since I first bought the device. Inconvenience? yes. Deal breaker? no.

Link to comment

It's been months since I had a problem with my Oregon600. I'm still not on the latest firmware as the last few versions didn't fix anything that needs fixing.

When I first had it I had it lock up and no matter what I did I couldn't restart. After a few times of battery changing and connecting to my tablet it worked again. I guess that was FW 2.60 or 2.80 I'm now using 4.40.

Link to comment

I upgraded from a 450 to a 600, and honestly I wouldn't have done it had I known how the 600 worked.

 

I've only occasionally had my 600 freeze, and now that I think about it, it's been a while since it has. However, if I'm out finding lots of caches in a day, often at some point I'll lose the ability to view the description, logs, and hint. That is, if I'm navigating to a cache, go to the "Geocaching" app, and tap one of these items, I get a circular loading icon and nothing ever shows up. If I select the cache on the map and tap the name, I can still view the description and logs that way, so at least I have a partial workaround. After this starts happening, it will continue to happen for any other cache until I reload the caches from my computer (restarting doesn't help). I suspect something is corrupting part of the internal database where the caches are stored.

 

I've also been extremely disappointed with the accuracy and responsiveness of the GPS location, which is unfortunate since that's the core function of the device. I've found that the position seems to lag behind, so I often walk right past GZ and have to backtrack as much as 30+ metres. Switching between the 450 and 600, the difference is like night and day. The 450 updates to your current position instantly, whereas the 600 will almost always be delayed. On a few occasions, the position has been offset as much as 50+ metres for up to an hour, with a reboot not helping. The track logs from those occasions show the correct shape of the route, but the entire thing is offset. It's so bad that for my OpenStreetMap mapping, where I need things to be as accurate as possible, I've completely abandoned the 600 and only use the 450 now. However, I still use the 600 for caching, because the better screen, customizable buttons, and faster touch response marginally outweigh the decreased positional performance.

Link to comment

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.

Link to comment

The crashes are due to the html interpreter not dealing well with certain code. Whether or not you see it happening is very dependant on what caches are on the device and whether or not they have that sort of code. I never see problems if I use GSAK to form the GPX file. It was years ago that this was looked at and they figured out what code caused lock ups and this is stripped before the send. I don't have a 600, but this held true for every other unit I've used since the problem started. If you just drop a PQ onto any unit, you will get a lockup if you open the right cache.

Link to comment

I use the GSAK GarminExport macro to create the GPX/GGZ files, and get the occasional lockup/freeze.

 

I use that macro too (always have) and only use GGZ files. I can't remember the last tile my 600 crashed but it's months ago.

 

Is it repeatable with specific caches?

 

Probably but I guess it would take a lot of time to find out which one. I typically load a few 100 caches each time anyway so splitting a selection in order to see when the GPS will crash is not something I want to invest time in. FWIW, it may even be something in a log.

Link to comment

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.

Actually, one of the things I do like about the 6xx is that I've been able to reduce the number of taps while caching. I've set up a long-push on my user button to take me directly to "Log the cache". If I was doing a powertrail, I'd hold down the user button to log the current cache, hit "Found", hit "Find next closest", and repeat. This is much faster than it was on the 450. In a few weeks I'll be in an area where I'll be finding lots of geo-art finals in a powertrail-like fashion, so I'll be able to exercise this capability thoroughly.

 

FWIW, the inaccessible description, logs, and hints I've experienced are after loading caches through GSAK. I had originally been loading through the "Send to GPS" menu into GPX files, but recently changed over to the GarminExport macro in GGZ files. I saw the same problem in both scenarios. The next time I see it happen, I'll do some testing afterwards to see if it's repeatable on the same cache(s) and look for any odd HTML or other code.

Link to comment

If you can repeat the lockups on the same cache pages, then I would suggest posting that up on the GSAK forums. If it is code related, it can probably be addressed much like the ones that were found years ago. Knowing specific cache pages that cause the problem should allow the problematic code to be found.

Link to comment

If you can repeat the lockups on the same cache pages, then I would suggest posting that up on the GSAK forums. If it is code related, it can probably be addressed much like the ones that were found years ago. Knowing specific cache pages that cause the problem should allow the problematic code to be found.

In the future I'll make note of which ones appear to cause the issue and test them again afterwards to see if it's consistent on the two units we have, as well as the 650 my buddy has.

Link to comment
The crashes are due to the html interpreter not dealing well with certain code. Whether or not you see it happening is very dependant on what caches are on the device and whether or not they have that sort of code. I never see problems if I use GSAK to form the GPX file. It was years ago that this was looked at and they figured out what code caused lock ups and this is stripped before the send. I don't have a 600, but this held true for every other unit I've used since the problem started. If you just drop a PQ onto any unit, you will get a lockup if you open the right cache.

Good info, Thank you!

Link to comment

I've had the same experiences with the 600 as the A-Team. Crashes and walk-backs. The crashes I could put up with but frequently having to walk back to the cache to find my caching buddies already found it was too much. The 600 currently resides in a drawer and I'm much much happier with the 64s that I purchased. I'm keeping the 600 in the hope that they do a firmware update that fixes the darn thing, but my hope for that is fading as time goes by.

Link to comment

I'm glad it's not just me with issues.

 

I have a 64s and an Oregon 600. Both have problems and ideally I'd like a fusion of the two!

 

Yes the 64s suffers less from lagging but I found that because it was all button pressing it took forever to find info, enter new coords etc by which time my buddies were half way across the next field.

 

The 600 otoh lags like crazy at times (although I'm getting better at slowing down when it says 20m to next destination) and was a nightmare before I changed the default screen sensitivity, found the lock datascreen button and created profiles (who thought it was bright idea to have a reset defaults button on the map page menu? Like I'm going to reset the machine to its default state when half way round a day out. This should be buried deep in the setup menu.) But I like the fact I can customise it and ditch all the junk stuff I don't want or need.

 

Both units lock occasionally and both suffer from the dreaded press enter Next Stage and the machine turns off instead. Oh and don't even get me started about the day I turned up 50 miles from home and the 600 only had a handful of the loaded caches showing despite the file being intact and full when I checked it at home later.

Link to comment
I upgraded from a 450 to a 600, and honestly I wouldn't have done it had I known how the 600 worked.

 

I've also been extremely disappointed with the accuracy and responsiveness of the GPS location, which is unfortunate since that's the core function of the device. I've found that the position seems to lag behind, so I often walk right past GZ and have to backtrack as much as 30+ metres. Switching between the 450 and 600, the difference is like night and day. The 450 updates to your current position instantly, whereas the 600 will almost always be delayed. On a few occasions, the position has been offset as much as 50+ metres for up to an hour, with a reboot not helping. The track logs from those occasions show the correct shape of the route, but the entire thing is offset. It's so bad that for my OpenStreetMap mapping, where I need things to be as accurate as possible, I've completely abandoned the 600 and only use the 450 now. However, I still use the 600 for caching, because the better screen, customizable buttons, and faster touch response marginally outweigh the decreased positional performance.

Most helpful reply! You mention that which I care most about . . . tracks.

 

Thanks

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