Jump to content


+Premium Members
  • Posts

  • Joined

  • Last visited

Everything posted by ecanderson

  1. I've tested my Summit using the techniques described by other members here. Indeed, if I power it up cold, zero contrast. If I immediately power down and up again, the contrast returns. I'm not leaving the unit on long enough to warm up anything. Sounds identical to everyone's Vista problems. Thanks to those of you who recommended this, as until Garmin sees fit to pass along the fix to those of us with eTrex HC units other than the Vista, there's at least a workaround until the weather warms up! I'm fortunate in that I don't depend upon the Summit for vehicle navigation in cold temperatures. I have a TomTom 720 that I much prefer for that purpose. I picked up the Summit because TomTom doesn't directly support software that is convenient for geocaching, and the 3rd party developers for these units were locked out of any but road-snapped data in the recent NavCore7 software release (!?!). No API this time. The TT units sometimes have their own problems, but fortunately, none of them has afflicted my unit, and I haven't seen any bugs yet. Again, thanks to those who persist with Garmin on this issue. I'll call tech support again tomorrow and reiterate my position that the Summit units share this problem with the Vistas, and will update them with my "power down / power up" experience as well. Gimme that 2.60 code!
  2. The real reason for bogus logs is not numbers by themselves. It's what the numbers buy the person doing the fake logging. One would have thought that to be obvious. As noted in a prior post, at least the fish stories would likely be a good deal more entertaining than watching a counter increment. A good liar would have to entertain us, at a minimum. Meanwhile, the integrity of the logs would be improved, thus improving the situation for the rest of us. Seems like a fine idea all the way 'round. There's a logical jump there somewhere that I'm at a loss to follow. It seems that it's the "purists" who are most up in arms about all of this. As "purists", they shouldn't have as much emotional investment in the numbers game to begin with, right? One wonders. Again, the leap of logic escapes me. The justification for the simplification of what has become in some cases an excessively competitive game (that, so far as I can tell, wasn't meant to be competitive in the first place) in order to improve the quality of play... That's a far cry from suggesting that bogus logs are tolerable. Bogus logs aren't tolerable for the reasons I've already outlined. I've probably been around this online business far longer then 99% of the folks here. During the years of 300 baud (acoustic) dialup, it fell upon me to make and enforce some rules for a network that predates public use of "the internet". After listening to all of the kvetching by members and users over the course of several months, it became possible to distill what needed to be said into 4 simple rules: 1) You don't screw with someone else's equipment (e.g., mailbombs, hacking, etc.) 2) You don't impersonate other members 3) You don't do things that cost another member unnecessary time or expense 4) You don't use the medium for any purpose deemed illegal under local laws Beyond that, it was "get a thicker skin and get over it". Period. (something a few here could learn) Sadly, bogus online log entries violate #3. For that reason, and that reason alone, I object to them. Were it not for that, I wouldn't even have an interest in participating in this thread.
  3. About says all there needs to be said, if you ask me... You'd think some of these folks were competing to be first to get their orienteering merit badge. Actually, that'd be a more worthy venture (batteries not included). It seems obvious to me that if anyone is concerned about "the numbers game" ruining their caching experience, that its only because they are paying attention to "the numbers game". Ignore it and it goes away like magic. Unfortunately, it can't be ignored, because the "numbers game" is what is driving the sort of bad logs under discussion. There are real downsides to bogus finds -- the online logs don't necessarily tell an accurate story of the current cache site situation. That can be a real bother both for the rest of us and the cache owner. If it weren't for that one result, many of us would be able to ignore it entirely. All of us -- cachers and cache owners alike -- depend upon the logs being as accurate as possible within the realm of human error. It's foundational to the process. Do away with the public display of totals, and you will also do away with most of the bogus log problems to which this entire thread is directed. All the "invention" of a find serves is to boost someone's numbers, unless they just want to screw with people by inconveniencing them. If you want to make these problems go away, recommend to the site owner that the design not display total counts. The resulting clean-up of attitudes would likely do a world of good here anyway.
  4. About says all there needs to be said, if you ask me... You'd think some of these folks were competing to be first to get their orienteering merit badge. Actually, that'd be a more worthy venture (batteries not included).
  5. Called tech support on my new Summit HC today. Tech initially denied knowing that there was any such problem with the Vista HCx. I suggested he determine the purpose of release 2.60 and get back to me. About 5 minutes later, he seems to acknowledge that the Vista HCx has this issue, but then says that they'd not heard this about the Summit. Given that the display technology and firmware are the same, I guess I found this -- well -- less than I would have expected by way of a response. He said he'd pass the Summit news along to his supervisor. Wonder if we'll ever see 2.60 for the Summit ... assuming it works for the Vista.
  6. Just received an eTrex Summit directly from Garmin, and it exhibits precisely this behavior. FWIW, I am using fresh Duracell alkalines. This problem (for me) only occurs in cold weather -- somewhere in the 32F and slightly below range sets it off. It seems to occur only during power on in cold weather. I am certain that this unit has issues with cold weather as if I stick it in my pocket for a few minutes to warm it up, it recovers. I'm reasonably certain I'm not turning it off before sticking it in my pocket -- I just continue to walk toward the last (almost) visible compass reading while it warms.
  7. Just picked up a new Summit HC, and I am having the same problems. Took it out over the weekend in about 25F weather, and there was almost no screen contrast at all. Had a buddy with an older Cx unit with me, and he was having no problems at all. Whatever they're saying, it's definitely a temperature issue. I can put it in my pocket for a minute or two to warm it up (no power switching) and it seems to recover. Might need to talk to Garmin about this one, too.
  8. Why do the "honest folks" need public totals, either? Perhaps a far more relevant discussion would be one that focused on whether or not we could find a way to just live without public totals. I get the sense that this hobby/sport has gone a bit astray of its original intent. Not that Jeremy's baby must avoid morphing into something new to avoid some sort of collapse of the universe, but he may not be especially impressed with its adolescent years. From what I know of him and the history of geocaching, he must be a bit bummed over some of the turns it has taken. [EDIT] In fact... removing the public totals might do a great deal for the integrity of geocache logging, making all of these several pages of arguments moot, and improving the situation for cache owners and cachers alike through more accurate record keeping -- and the whole tenor of these forums in general might improve. The only downside would be a loss of revenue to geocaching.com -- very difficult to quantify that in advance -- since those whose primary focus has really been on the numbers all along (not that they'd admit to it) would find something else to occupy their time. Public display of counts and human nature are, in conjunction, what drive 99% of the problem you're all obsessing over. From a purely practical perspective, I can assure you that the latter certainly isn't going to change. That does leave the former as an option, and perhaps one that is overdue? Frankly, I'd much rather give credit to someone who does a truly amazing job of designing a cache or is willing to go to some real extremes to snag one. Yes, there would undoubtedly be some fish stories about those events, too, but they'd be a WHOLE lot more entertaining than watching a counter increment, which is about exciting as watching paint dry. I'd much rather hear about the guy who wound up overboard bringing in the marlin (and perhaps even succeeded!) than I would about the guy who caught more bass than anyone else, doing it like he was counting the dents he'd pounded out of a car. As a measure of success, the current system really lacks imagination, and I guess I'm surprised that our "founder" allows this to continue, and that so many people here are happy to let it stand.
  9. More to the point -- if the numbers weren't visible to the public, there wouldn't be nearly so much incentive to fake a log in the first place. I'm beginning to form a strong opinion on this count business, now that I see what it is causing.
  10. Another strong argument for scrapping public view of total counts from the geocaching.com site. While I'm a relative newbie at this, I can tell you that whoever designed the geocaching.com web pages with total finds made public was clearly more interested in the number of views/impressions (a marketing term) than the end result of publishing those counts. Whether that's a necessary evil to support the site can only be answered by an understanding of the site owner's business plan. At the margin, you can bet that there are enough who would spend less time here without the bragging rights that it brings, and would reduce overall revenues from Shopzilla et al.
  11. You are pretty much using the same example as Ecanderson did. Much like his example, I wouldn't have logged the creek cache as a find. Not at all the same. Mine was a matter of near certain exposure of a cache to muggles due to cache location. If I'd been out there by myself, I'd have taken the personal risk of the climb (and did, the next day -- but private moments during "open" hours here are very nearly impossible to find -- it is both the entrance to and 'crossroads' within a very popular spot). I guess I object as a matter of principle to really PUBLIC locations that require gymnastics that are far too obvious. Then again, if an owner doesn't mind having their cache muggled all the time... Perhaps that's the right answer. The cacher should make a "best effort", but if someone places a cache in such an untenable spot, they take their chances.
  12. A conundrum: Of interest -- I was very nearly tempted to do exactly the same thing yesterday. I was able to see a cache that simply could NOT be accessed without drawing HUGE amounts of attention. The cache was in a public park area that maintains dawn to dusk hours, so it wasn't like I could come sneaking back in the dead of night to tend to the log. Actual access to this cache for log signing purposes would have required climbing up on a bit of public signage/kiosk at the entrance to the park where many people were passing by and moving in and out of the park. The cache was 8+ feet off the ground. As I get started in actually placing caches, I think I might be a bit more circumspect about location. Anyway, due to coordinates and a bit of focused looking, the thing WAS there to be found, just not touched. Got a brain fart this morning, and realized that if I were to drop by on a cold, cloudy day half an hour before the Super Bowl started, there might be less people about. A person shouldn't have to find one of perhaps 5 half-hour slots in a year to visit a cache without making its presence obvious. Did manage to get the thing signed without being observed. Having actually seen the thing, would I have been doing geocaching a favor by grabbing it during any of the other 360 days a year (and most of the hours within the other 5) when it would have been pretty obvious and might well have been muggled, or would this pastime have been better served by just logging the thing as found -- since it really was found?
  13. I don't know if you play golf, but the description of the web site from the previous poster isn't really all that different from how it's actually done. After playing a round of golf, if the player intends to play with competitive golf with a "real" handicap (not purely recreational golf), the results of the game are entered on the course computer by the player at the end of the round. It is by that system that a player's handicap is computed for competitive purposes. The resulting scores and handicap then available for verification. It's not enough to enter a competition and say "I shoot a 22 handicap". This system is the way we know you're not really an 8 handicapper and trying to sandbag us! For those who prefer their geocaching as a competitive sport, the same honor system applies to both logging caches and posting your round at the end of a golf game. The difference it that the pros rarely get away with anything (too many fans, officials and cameras) ... not even Vijay (1985 Asian Tour). Much of what many geocachers do is done in as much stealth as conditions permit. I could care less whether someone posts a bogus golf score or does a bogus online log of a cache. When caught, it certainly provides information about a person's character, but unless there's money on the line that has been taken out of someone else's pocket (e.g., professional golf), nuts to 'em.
  14. A coordinate error can be either + or - and will create a error in either one direction or the other of a specific distance. The idea of considering distance as +/- in reference to a coordinate system doesn't seem all that peculiar since there is a datum in mind to which the motion is associated (moving north in the northern hemisphere being plus, and moving south in the northern hemisphere being a minus). That a coordinate error is being described as a "possible actual distance from target center" error makes perfect sense to me -- it has more meaning than specifying the error in 0.001 minute increments, especially as many people don't really know what that represents in terms of distance. If your latitudinal error is, for example, +/- 0.002 minutes, that'd give about a +/- 12 foot error radius from center along the N/S axis, and if the longitudinal error is also +/- 0.002 minutes, that'd give about a +/- 9 foot error radius from center (up where I live) along the E/W axis.
  15. Long as you don't slow down the pace of play, and you replace your dadgum divots (gotta figure a baseball bat is going to require some extended turf repair), you'll be fun to watch! I have enough trouble with a 2 iron.
  16. Could be I'm just lucky. Could be I'm just too new to this at a couple of weeks to give a rip -- I don't have the time to even consider playing "catch up" to those with thousands of logs under their belts. I'm logging the finds and signing the logs. As long as those placing caches use decent coordinates and tend to them, and those who are looking for them are having fun finding them, it's enough already. Only the things that detract from one of those two activities really matters to me. People making false claims of finds doesn't impact either one. I try not to even look at the online log entries until I've already returned from the hunt. As they say, "spoilers" can occur. OTOH: If a bogus online entry causes a cache owner unnecessary grief -- and I can see how that could happen, that's not good. Apart from that ... some people taking the numbers game all too seriously.
  17. An update on TT units, NavCore7, and geocaching... I've been communicating with the author of OffRoad Navigator, and it seems that there won't be any 3rd party applications that are really good for geocaching UNLESS/UNTIL TomTom goes open kimono and finally releases an API/SDK to the developers for NavCore7. There are TWO places on your TT that you can get GPS coordinate data. The first is when you press in the lower right corner on the "bars". That takes you to a screen where you can see your unit's firmware version number and some coordinate data in little, tiny print. THAT data is snap to road! If you're near any kind of paved surface that is known to the TT maps, you'll have a bugger of a time getting the coordinates perpendicular to the road to update properly. Unfortunately, it is THAT data that is provided through the old API/SDK to developers (harumph). HOWEVER, if you press on the right side again, you'll get to the page that shows the satellites in their orbital positions, and yet a different set of coordinate data. THAT data is "unsnapped" and pretty raw, and can put you right on top of a cache site. I'm betting that it's beginner's luck, but I'm 5 for 5 on finds that were within 4 feet of the specified coordinates.
  18. I'm starting to wonder whether I've just developed an incredible case of beginner's luck here. I picked up a TT720 for road navigation at Christmas, and after hanging around a geocacher on a regular basis, figured it would be fun to try this unit in that application. It's a SiRF III chipset, and that's all I know about its abilities on the front end. It provides either snapped-to-road coordinate data (not good for geocaching) or, if you go to the right screen, the raw GPS information in your choice of formats -- I use the dd mm.mmm for this purpose since it seems to be the geocaching-preferred notation. It's the screen that shows the satellite orbit positions and individual signal strengths. Granted, I've done a whopping total of 5 caches, and all have been in good weather conditions with clear air above. I know that helps, but ... After allowing the numbers to settle for about 15 seconds, the 720 has put me within no more than 4 feet of the actual location of the hides in each of the 5 cases. That would seem to indicate that not just my unit, but those of the people placing the caches as well, have some serious accuracy going for them. AFAIK, the TT720 doesn't even incorporate WAAS. So should I thank my lucky stars, or has the technology with the advent of the SiRF III really gotten this good?
  19. I picked up a 720, which came with NavCore 7, as did the 1, 3rd edition as I understand it. Consequently, it would seem we have a lot in common at the moment, especially as I don't have a copy of the NavCore6 software to work with. We have the same core system with the same 3rd party options for our units. The 720 was initially a bust for earlier versions of OffRoad Navigator as the screen was pretty well buggered. After the author issued OffRoad Navigator 1.7B, it became usable. Data entry is still a problem, though, so instead of trying to enter a latitude/longitude set in the ORN display, it's FAR easier to set up your destination either using the TT's "itinerary" (load it as a "File" from the ORN main window) or using the TT's "favorite" method (again, load it as a "Favorite" from the ORN main window). Here's the link to the software itself: http://www.webazar.org/tomtom/offroad.php?lang=en With that in mind, I've taken out the 720 and tried a bit of caching, and can advise as follows: You really DO need to make a couple of adjustments to the ORN configuration for caching. Here is my configuration file, including the "tweak" that cleans up the screen a bit for NavCore7. It also accomplishes two other important things... a) it reduces the "at target" distance to 1 meter, and it uses "real" coordinate results, NOT the "snap to road" type results. Without both of those changes, you're toast if trying to use one of these units as a caching device. These are the contents of my config.txt file for ORN, found in the "offroad" folder once you have the software loaded. The "targetdistance 1" sets the 'proximity detector' to 1 meter instead of 100. The "snapping no" avoids on-road snapping by the TT software. Those were changed. Also be aware of the "processperiod 500" which updates every 500 milliseconds (1/2 sec) and the "coordinates degminute" which puts you into degrees and decimal minutes, useful for avoiding conversions when caching. A quick edit of this file with notepad or wordpad can be a lot easier than dealing with the config screen in ORN, but that screen is actually functional on NavCore7 now. [Other parameters] language english.lng units english colorscheme night targetdistance 1 gmtoffset -7 geoidfix no 48 coordinates degminute snapping no mapfile [Manual parameters] processperiod 500 [Colors parameters] topforegroundcolors 0,0,0 255,255,255 204,204,204 bottomforegroundcolors 255,255,255 255,255,255 204,204,204 topbackgroundcolors 255,255,255 0,0,0 bottombackgroundcolors 0,0,128 0,0,128 linescolors 204,204,204 204,204,204 labelcolors 255,0,0 255,255,0 daybackground nightbackground screenadaptation rider2 [End] Once I had ORN tweaked per above for caching, I took the 720 out for a couple of test drives. I have a couple of observations about using the TT in this mode. These observations are made in otherwise "clear sky" conditions. First, I've had instances where the TT itself was balky about updating coordinate position. At first I thought perhaps it was the ORN software, but in going directly to the TT's own direct display of satellite signal and immediate coordinate values, I found it was the TT that was sometimes balky about updating, primarily about the latitude figure. Even with "snap" off, it seemed that the TT would sometimes not trust the data, and give me a bit of a hard time in this regard. It seemed that motion at 2mph or more would often get it off the dime and the display would start to update. ORN can only work with what the TT is providing to it. Second, I've come to learn that even the SIRF3 chipset can be fooled pretty seriously by reflections. In attempt to check out a benchmark near a bridge, we were confounded by the ORN software telling us we were 6 yards from the target, and suddenly having the unit blow us to 38 yards distance within the space of a foot or two. The reflections from the bridge were driving the TT unit nuts. I would imagine that this isn't all that uncommon for other units, but as a newbie in this business, it's a bit disconcerting. Apart from those two caveats, the 720 with NavCore7 and the 1.7B ORN software is certainly adequate for most caching purposes. The lack of a true electronic compass seems to be a real shortcoming, though. I am thinking seriously about soon adding a purpose built unit to my stable just for caching. As this is clearly a TT thread, I won't post my suggestion now, but in practice, it would seem that a unit that includes that feature certainly would have an advantage.
  • Create New...