Jump to content


+Premium Members
  • Posts

  • Joined

  • Last visited

Everything posted by ecanderson

  1. That assumes that the claimed "precision" is even there. I don't really care how precise you make the display - a 4th digit isn't even cute, much less useful at this time. It reminds me of folks who publish puzzle caches that resolve to dd.dddddd. The 64 isn't going to get anyone closer to a cache for having 4 digits of precision. I do not understand the claim that "None of those models were precise enough to support the fourth digit like your new 64 is!" The 64 has no better repeatability to a 4th digit (precision) than others I've seen in the field. Not sure why Atlas doesn't understand that repeatability is precision. He's usually the first to get the terms right. As long as I can hit the target in a small group, even if way off to the side, that's repeatability. It likely also means I have a sight adjustment problem or a bad habit, but that's for another day...
  2. I'm aware of that. Again, we've been down this road before. If results aren't repeatable to the 4th digit, doesn't much matter to the person using the device to locate something whether it's 3 or 4, does it?
  3. When the technology allows for repeatability down to less than 1 foot square for consumer units, get back to me on that. Haven't we been down this road before?
  4. No doubt edited after the fact. Do these show the Wheelchair attribute? I ask, because once set up as 1.0T + wheelchair, you cannot switch off or use the 'negated' wheelchair attribute.
  5. I swear I recall back in the early days when 1.0T meant flat, level ground - end of discussion. If one could reasonably expect to reach a cache from a wheelchair, one was expected to use the wheelchair attribute to flag the accessibility of the cache.
  6. Although not mentioned in the 66's manual, it appears from the 'help' section on Garmin's support pages that this process is still performed using the old POILoader program. Looks as though this is still done using *.gpi files, which may be built from *.csv and *.gpx files by POILoader. Can anyone confirm?
  7. It used to be a relative piece of cake to upload custom POI to a Garmin automotive device of fairly recent generation. Drop a file into the right folder, and bingo. (The older units were a bit more work, but workable). Is it still easy to do this on the most recent generation of their automotive units (DriveSmart)? Do they still support *.gpi and *.gpx format? As I read the current manual, it bothers me that it appears that the only interface for POI is via FourSquare. Tell me I'm wrong, please!
  8. Well said. My original point exactly. Over the last 12 months, it's become difficult to know what logs to trust without first checking find numbers. That's certainly no guarantee of an accurate result, but I'm having to discount many logs by those with smaller counts this year. Rather than trusting DNF and found logs as one might expect to do, am having to spend extra time checking up on my own caches, not all of which are easy to access. Found logs when they're actually MIA doesn't help me or other finders, and may delay my action to correct things.
  9. They're logging both types. Logging the unfindable ones are the bigger issue since that's prone to throwing off finders, and also the none too swift gc.com algorithm that alerts reviewers to potential problem caches. If all their logs get deleted, perhaps they'll get tired of the armchair game?
  10. Read that thread and noted the "20" issue might be the root cause, but I'm seeing counts all over the map for these sorts of things. One finder with 61, another stuck somewhere around 10. So not sure if the "20" is playing into it here or not, but doesn't seem to be. Those who do achieve 20 don't seem to be hiding anything. More like kids playing with phone apps. And as I say, they never have validated email accounts, which is something else that has been beaten to death, but that I find a big problem with the gc.com approach, especially with the advent of the app.
  11. As I say, I don't really care so much if people are claiming bogus finds on caches that aren't issues ... there will always be armchair loggers out there ... it's the finds on problem caches that are the larger issue. The bogus finds will also throw off the algorithm that flags the local admins that there may be a problem with a cache. When you say "Definitely a thing this summer", I assume you're saying that you've been seeing this in your area as well?
  12. Is it just in our area, or are the rest of you also seeing an extraordinary number of bogus finds from 'cachers' with low (< 100 finds) counts this summer. It's as though people are downloading the app and just logging things. Some of these logs are on caches that aren't even there, some 'finds' occur after a long string of DNFs by experienced cachers, and none include any log signatures. Online logs are of the 3 letter "lol" sort, a short string of meaningless characters, or something equally unhelpful. None reply to queries about their finds at the message center. If you're not paying special attention to the counts of these 'finders', it's easy to be led into thinking a cache with a string of DNFs and a few recent 'finds' might be worth looking for after all. Hate to get into 'cache police' mode, but all of these finds on caches that aren't there to be found is getting pretty annoying. I really don't care if they claim ones that ARE there to be found but that they never visited. Time to start going back to the old practice of comparing online logs to those in the cache, I guess. I'm going to start doing it, and it would be good if my fellow COs would consider doing this, too. The process isn't very hard since once you see that the first half dozen you check have no signatures, or they've been logging caches that are disabled and truly MIA, you just delete all of the logs for your caches by those folks to clear things out.
  13. To the latter -- Evidently! As to the former... The receiver takes the satellite signals and calculates its distance from each satellite by computing the difference between the time the signal was sent from GPS satellite and the time the GPS receiver received the signal, using time data previously obtained from one of the satellites (as you say) and backing out the 'time of flight'. Keeping accurate on-unit time derived from a satellite and the process of time differential calculation can induce errors in the result. I haven't found that consumer devices include electronics with tolerances tight enough to produce sub-0.001 fixes ... yet. Have played around a bit with selective use of the various constellations and the results have been interesting. Not seeing a great deal of variation in results.
  14. First, it wouldn't matter if Galileo could generate timing signals capable of producing a good fix to 1cm on the ground. If the differential internal timing circuitry of the GPSr can't resolve a fix to better than 0.001 minutes, it really doesn't matter. Moreover, the timing signals of the birds aren't the only factor in obtaining a better fix on the ground. Even should a satellite own a timing signal good enough that the geometry could mathematically provide resolution to 1cm AGL, a MEO at 20,000+km up wouldn't actually produce a 1cm fix. That's why ground based references are always used to get a better idea of location when a tighter fix is needed. I'm not confusing precision and accuracy. In fact, that's the whole point of the exercise. Unless the direction and amplitude of the offset caused by a lack of accuracy in a high precision device is repeatable, the additional precision isn't of any value. In short, if the 4th digit after the decimal on a Garmin consumer device doesn't provide useful information, and I'm arguing that the device itself doesn't allow for this, then there's no point in displaying it, leading the owner to believe there's a level of accuracy involved that simply doesn't exist.
  15. Excuse? The THIRD digit in a dd mm.mmm format defines a space (at my latitude) of about 6 feet x 8 feet. Are you claiming that the 64 is capable of an accurate fix of 0.6 feet by 0.8 feet??? If not, what is the point of displaying a 4th digit?
  16. I consistently find that compass accuracy and calibration are VERY dependent upon battery voltage. Calibrate on a pair of 'hot' cells and wait until the voltage drops a bit, and the calibration is off. Calibrate on a half used pair of cells, charge them up, and the calibration is off. Was true for my 450, and is true for my 600. It appears to me that the 3-axis chip output is sensitive to input voltage differences, and that Garmin isn't using a constant voltage reference to power the chip in their devices. Have never been able to get anyone at Garmin to discuss it.
  17. Other than the bugs in the 'au courant' version, I would have other reasons for preferring the old version as well. Every time a feature is taken away or made less convenient, I find another reason to use GSAK rather than whatever this web interface to gc.com is offering me. I find myself using the web site very rarely now. Aside: Is there ANY chance of having the GC code displayed along with the cache name on the Daffy Drafts page (the new one)? Some prefer to work to GC codes rather than cache names. Seems a pretty small ask.
  18. My current favorite for USA use is http://www.gmaptool.eu/pl/content/usa-osm-topo-routable for their OSM topo routable maps.
  19. Had an unusual situation pop up, and needed to add 7 new maps to my Oregon 700. None of them are particularly large. Got them at BBBike. After downloading all 7 of the *.img files, I placed them on the uSD card of the 700 in the Garmin folder (after first providing unique filenames, of course), Of the 7, only 3 of the new maps appeared. Understanding that the 700 would ignore any maps with duplicate Map IDs, I wondered if perhaps BBBike had assigned duplicate Map IDs to some of the maps. I went in and manually renumbered all 7 (from 4000 to 4006) with GMapTool. Still, only the same 3 of the 7 appeared in the list of available maps on the 700. Wondering if there was some bug/restriction on where they were placed on the 700, I moved the whole shootin' match over to the 700's own Garmin folder. No change whatsoever. What could be causing this? Never had issues like this on my 450.
  20. Really? All 4 of them? Just curious. How did you plan to get there? East Coast Rotator? You won't be flying United Polaris class on Patriot Express, that's for sure. Have some equipment there for which I am responsible. REALLY don't look forward to that trip. https://www.af.mil/About-Us/Fact-Sheets/Display/Article/104594/ground-based-electro-optical-deep-space-surveillance/
  21. https://www.amazon.com/s?k=game+camera&ref=nb_sb_noss_2
  22. Hadn't visited the site in a long while. On a recent attempt, I noted "Sorry, due to server problems only country maps are currently available. You may need to refresh the browser cache first (CTRL-F5)." Does anyone know how long this has been going on, and any ideas on when the problem might be resolved. I was looking for a very small couple of map tiles in different locations, and can't handle several entire countries.
  23. Announcement is hardly 'recent', and support still continues thanks to a great group of GSAK volunteers. Clyde is definitely still alive and kicking and is said to be enjoying his retirement, but is in regular contact with the crew supporting his baby.
  24. FWIW: I always select No Logs, which may produce the same better result as your selection of some limited number of logs, and never have the GC code clipped. Could be why I've never seen this problem, and like you, I do still print a LOT of cache pages.
  25. Maps not working again for me today. Small map within a cache page shows nothing but a partial map (half the 'tiles' missing) if produces anything at all. Choosing "View Larger Map" doesn't produce anything.
  • Create New...