sammydee
-
Posts
134 -
Joined
-
Last visited
Posts posted by sammydee
-
-
Seriously what do we do - return the units to the store we bought them while there is still time to do so or have faith in Garmin to recall the units / quickly fix these seemingly major hardware flaws?
I am torn, because other that this confirmed serious altimeter issue and hit and miss squeaky case issue (geeze, do i need more "other thans"?), I like my new 62ST.
Everyone has the same tough choice to make. The safe thing to do, of course, is to return your unit and buy another later if/when a fix comes out. Assuming you can get a full refund, of course. But that's not a very satisfying thing to do, since the 62st is so cool in most ways - but with one major flaw.
If your retailer won't give a refund - like mine - then it's more complicated. But I expect Garmin to do the right thing, so it'll all work out. !?
-
The pn-40 ALWAYs shows 2ft or less when at the marked point and will hold that reading (2ft or less) for the hour or so that I leave it there. The 62s will do the same thing but and show about 3-4 ft standing on the spot and if you walk around with it trying to zero it out it can have you walking around anywhere from about 10 ft from the spot or less. If you let is set on the spot it will drift up to 12ft or so but normally less. The pn-40 takes you to the spot and sticks. I have tried the 62 both flat and vertical.
My bet is the PN-40 is simply using its built-in accelerometer and notices that the unit isn't moving based on that ... and due to that it's ignoring the GPS entirely. If you tilted or otherwise jostled the PN-40 I'll bet it would take a new GPS reading, which would be off by some feet from the previous one.
I don't believe the 62st has one, so it's displaying GPS coords all the time.
I'm not sure how relevant this test case is to any real world scenario. I'm not likely to really sit, unmoving, at GZ for an hour.
...Sam
-
I called Garmin Support for an update.
They did their own in-house testing in Support and verified that, sure enough, pressing the buttons on the 62st causes disruption to the altitude data that the GPS records.
They passed the information on to Engineering, and have not yet heard back.
Support noted that the 62st has the barometer in a different internal location than the 60csx, which they think is part of the reason for the poorer behavior of the 62st vs. the 60csx.
Reasonably enough, they could not commit today to whether there would be a fix or not, nor to when we might expect a reply from Engineering.
I made it clear that the acceptable outcomes to me are either a software fix, a hardware fix, or a complete refund on the unit. The support engineer understood, but reasonably enough could not commit to anything today.
The support engineer agreed to contact me when he hears from Engineering. If I haven't heard from him in 7 days I will contact him again, and will let you know what I find out.
...Sam
-
I did another head-to-head test on my commute today...the PN-40 with the barometer vs. the 62st in "Fixed" mode (allegedly disabling the barometer and reporting GPS elevation).
The GPX results are indeed much smoother, and don't show any sign of spiking when buttons are pressed. (I didn't look at the 62st's on-device altitude track, so I don't know if it made a difference there or not. I would hope so.)
HOWEVER the results vary dramatically from the other runs. In other runs comparing the 60csx, PN-40 and 62st the 3 GPSes altitude solutions would typically match to within a couple of meters (once the units all finished calibrating, which could take a while). However, comparing the PN-40 barometer track and the 62st non-barometer track the altitude solutions were often off by 10 meters or more.
So while turning off the barometer makes the button interference problem "go away" in the GPX track, naturally taking out the barometer subjects the user to the whims of GPS altitude calculations, which are known to be dodgy ... and are the reason why folks put barometers in GPSes in the first place.
Garmin either needs to fix the mechanicals of the 62s[t] so pushing the buttons doesn't impact the altimeter (as they had successfully done in the "gold standard" 60csx), or at minimum filter the results in software. The GPS knows when the buttons are pressed, after all, and could easily throw away the altitude readings for several hundred milliseconds before and a second or two after any button press. That would probably hide most of the problem, though a true fix would involve fixing the mechanical separation between the barometer and the buttons. As was done successfully in the 60csx and PN-40.
Note that on the PN-40 and the "gold standard" 60csx not only is the case quite rigid, but the buttons only travel a very short distance when pressed. On the 62st the button travel is dramatically greater, thus increasing the amount of air being pushed around.
Still waiting for comment from Garmin Support. They didn't give me a case number, just asked me to email data to someone.
...Sam
-
See my comments on the 62st's barometer in the main 62 thread. Comparing the PN-40 and the 62st, the 62st is severely flawed with respect to the altimeter. Still waiting for feedback from Garmin Support.
...Sam
-
Regarding the elevation spikes when pressing buttons issue.
I'm no math genius but wouldn't it be easy enough to smooth the data from the barometer? Couldn't you write an algorithym that would smooth all unreasonable jumps in elevation? I'm probably not going to jump 80ft in less than a fraction of a second. Simple firmware fix could solve the issue.
Agreed. Not sure if 'solve' is the right word ... 'hide' seems better. But yes, such a firmware filter would be better than recalling the units in the field ... and far better than ignoring the problem. I would be happy to help test such a fix.
-
Regarding the elevation spikes when pressing buttons issue.
I'm no math genius but wouldn't it be easy enough to smooth the data from the barometer? Couldn't you write an algorithym that would smooth all unreasonable jumps in elevation? I'm probably not going to jump 80ft in less than a fraction of a second. Simple firmware fix could solve the issue.
Agreed. Not sure if 'solve' is the right word ... 'hide' seems better. But yes, such a firmware filter would be better than recalling the units in the field ... and far better than ignoring the problem. I would be happy to help test such a fix.
-
I did another comparison on the way home tonight. Same as before ... ran all 3 GPSes on the passenger seat while I drove home. This time I left them mostly alone; three times on the trip I pressed the keys on each unit (15 times each).
Here are the results.
All three units seem to use different algorithms to calibrate their barometers. It takes them a while to do so, but once they do the curves all look very similar ... except for the three quite obvious spots where I touched the 62st and it went crazy. I don't see any similar artifacts on the 60csx or the PN-40.
I think that positively demonstrates that:
1. The glitches are due to pressing keys on the 62st.
2. This is NOT normal behavior for other GPSes with barometric altimeters. It's a bug in the 62st that needs to be fixed ASAP.
Again, spreadsheet and GPX files are available upon request.
I will post this to gba.net, geocaching.com and will send it to Garmin Support.
...Sam
-
I've asked Garmin about this but the response was that all units with waterproof altimeters do this (to some extent). Seems much worse on the 62s to me.
I should note that in my test all three GPSes have barometric altimeters, and only the 62st demonstrates the problem. So I believe their claim is fairly simple to disprove.
I emailed the raw data and spreadsheet to Garmin Support as they requested this afternoon, but haven't heard anything back. I will update here when they report back.
...Sam
-
I've asked Garmin about this but the response was that all units with waterproof altimeters do this (to some extent). Seems much worse on the 62s to me.
I should note that in my test all three GPSes have barometric altimeters, and only the 62st demonstrates the problem. So I believe their claim is fairly simple to disprove.
I emailed the raw data and spreadsheet to Garmin Support as they requested this afternoon, but haven't heard anything back. I will update here when they report back.
...Sam
-
The raw data is available here:
http://spreadsheets.google.com/ccc?key=0As...uthkey=CJGmvZIJ
A higher resolution version of the chart is here:
-
Sadly, I can now confirm 100% that this is due to gripping the unit and pressing the buttons.
During my drive to work this morning I ran my 60csx, PN-40 and 62st. All were started at the same time, turned off at the same time, and sat in the passenger seat of the car in the same way. Periodically during the commute I reached over to each GPS in turn and pressed the "Page" button precisely five times. I always did the 60csx first, the PN-40 second and the 62st last. During one part of the trip I refrained from touching the units at all, to act as a control. And at one point in the trip I pressed the Page button five times, AND held the unit in my hands, squeezing the unit firmly repeatedly as one might do while holding it in regular use.
When I got to work, I used GPSBabel to export the tracks from each unit. I then used Perl and Excel and plotted the altitude data. The X axis is TIME; the Y axis is altitude.
You can clearly see the spikes from the 62st when the buttons were pushed. You can also clearly see the much longer period of instability when the unit was simply being gripped, no buttons pressed.
None of the other units show ANY sign of similar failure.
I will contact Garmin Support and send them this. Sadly I consider the unit badly flawed at this point. If anyone wants the raw GPX files and/or the Excel spreadsheet let me know.
...Sam
-
Deleted duplicate post.
-
Deleted duplicate post.
-
I experienced the spikes this weekend and figured out what causes them. As you walk and log your track things are smooth but as soon as you start pressing buttons, say to the trip computer or map page, you get spikes. Try walking down the street as you watch your elevation plot.
Came here to post basically the same thing.
Oh, jeepers. I think I know what it correlates to.
When the unit is in my hand.
I added the geocaches onto the Google Earth map. Sure enough, there are spikes in altitude around caches where I would have been playing with the GPS, and often for some time after the cache - when I would still have been playing. But during periods of heavy slogging down the trail - no caches, no reason for me to have the unit in my hand - the altitude track is nice and smooth.
When the GPS wasn't in my hand, it was hanging from my belt on the carabiner.
I bet the squeak-flexing-plastic is driving the barometer crazy.
I'm calling Garmin Support tomorrow. Wow, this is really bad news. A GPS you can't hold in your hand is of no value whatsoever.
...Sam
-
The GPS did a good job tracking my location, but the vertical profile shows bursts where the GPS couldn't keep track of the elevation.
The black line shows the profile per Delorme Topo 8's built-in topo data. The green line shows the profile from the Garmin 62st. Note how the Garmin usually did well, but when it lost elevation "lock" it really went crazy.
To get a better idea of when the 62st had trouble with altitude, I imported the track into Google Earth. BUT I un-checked the box telling GE to change the track so it was at ground level. This lets the track bounce up and down in the air, showing where the Garmin went a little crazy.
It pretty clearly shows that the incidents of altitude-loopiness do not match up with tree cover or anything else I can determine.
Curious.
-
Do you know if those sections lined up with areas of particularly bad tree cover, or some conditions that could interfere with the ability to see the satellite? Does this happen all the time, or was this unique to this trail?
The bursts of poor vertical resolution do not match up to tree cover, and I cannot correlate them with anything obvious. I'd like to see similar data from others.
-
(Edited the "bottom line")
Took the 62st on its first hike / caching adventure today. In general it worked well, but there is one odd thing.
The custom maps I made with Google Earth, putting an image of the park trail map into the GPS, worked out very well. They displayed fine, and were very easy to use. In fact I disabled the built-in topo maps, since the topo lines in the park map were easy to read.
The GPS did a good job tracking my location, but the vertical profile shows bursts where the GPS couldn't keep track of the elevation.
The black line shows the profile per Delorme Topo 8's built-in topo data. The green line shows the profile from the Garmin 62st. Note how the Garmin usually did well, but when it lost elevation "lock" it really went crazy.
I post-processed the track through Fizzymagic's AnalyzeTrack program, and it claimed that I hiked over 8000 vertical feet ... when Everytrail and Topo 8 said I did under 2000. I guess Fizzy's program isn't handling the odd burstiness of the Garmin's elevation data very well.
Battery life was super, compared with the PN-40.
Oh, finding caches. The 62st did very well. The "workflow" of finding caches and logging them is quite a bit different on the 62st than on the PN-40 that I'm used to, so it took some getting used to ... but everything worked out just fine. I think I need to play with the order of pages a little, as I find I'm spending a lot of time scrolling from Compass ---> Geocaches and back. But once that's done I think I will be very happy with the 62st.
Bottom line: the altitude thing is quite disturbing. This thing goes back unless there's a fix. Calling Garmin tomorrow.
...Sam
-
I hated the electronic compass in my 60csx. I almost returned the unit untIl someone told me how to disable it.
The one in my PN-40 is better. I never calibrate it, and never trust that the arrow means anything when I am standing still, but at least it never gets in the way.
-
I agree, around water the aerial imagery is very useful. Knowing which side of the water the cache is on is pretty important ... you don't want to wind up 30 feet from the cache, on the wrong side of the water.
But I have to say ... I use the aerial imagery on my PN-40 a LOT less than I thought I would. It's cool to have, but I use it every few months, not every few days.
...Sam
-
We also liked the PDF print with the ability to also print 0. 5, or 10 logs. Please put it back
Yes, please!
-
We've been working with Santa Clara County Parks in California (San Jose and vicinity) for a couple of years. They just got the first official Geocaching Policy from a major land manager in this area. It's pretty friendly. Here's a link to the policy.
-
I'd honestly vote 'no'. I think this sort of advocacy is best done locally. I don't think a County Parks department is going to be interested if an 'international advocacy group' walks in and tries to tell them what to do. But if a bunch of locals show up, they'll be more interested.
I do think that strong organization is essential on a local level. We've had a very good group working together here, and have just got the first official geocaching policy from a major land manager in our area. FYI the policy is here.
-
FYI you might show them some examples of what other Counties have done. We just got this enacted in Santa Clara County California, as an example.
Lots of folks worked a long time to get this accomplished. Personally, I started lobbying for this with the County almost 2 years ago. I started showing up at community group meetings explaining caching, then started going to Park Commission meetings to meet everyone, then started volunteering at trail maintenance events, then helped run one as a CITO event and got 20+ cachers to come. And lot and lots of other folks have been making contacts, giving presentations, building trust, etc. It took a long time, but working together we got the job done. I'm sure you can too.
...Sam
New Garmin 62st
in GPS technology and devices
Posted · Edited by sammydee
Sure, that's to be expected. At this point just one support engineer has seen my data, has shown it to one help desk person, who has forwarded it to one engineer - who hasn't yet looked at it. Nobody else knows even this much is going on. Patience is a virtue at this point. Let's give them a few days to digest the situation and decide what to do next.
Of course, the clock is ticking and lots of folks are watching. A point I made to them firmly, by pointing out that i'm posting the info here and elsewhere. If I don't hear positive feedback in 7 - now 6 - days, we should go postal on them. But for now let's let them investigate and ponder for a few days.
If you want to call or email to let them know you are concerned about the issue that's super, but I wouldn't be surprised if the low level rep you talk to doesn't know anything about the issue yet.