Jump to content

ecanderson

+Premium Members
  • Posts

    5623
  • Joined

  • Last visited

Posts posted by ecanderson

  1. 35 minutes ago, barefootjeff said:

     

    Precision without corresponding accuracy is just meaningless digits.

    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...

     

     

    • Helpful 1
  2. 20 hours ago, barefootjeff said:

     

    It being a rainy day, a little playing with Search has yielded some surprising results:

    • There are 997 terrain 1.0 caches with the Significant hike attribute
    • There are 136 terrain 1.0 caches with the Tree climbing required attribute
    • There are 65 terrain 1.0 caches with the Climbing gear required attribute
    • There are 61 terrain 1.0 caches with the Difficult climb attribute

    These aren't all old caches either, a lot have been published in the last five years. It really makes you wonder...

    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.

     

  3. 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.

    • Surprised 1
  4. 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?

     

  5. 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!

     

  6. On 8/24/2022 at 10:36 AM, thebruce0 said:

    If the game were just stats, then people's bogus logging behaviour would have zero consequence to others. But log history is public and can cause people to take real world action or not - and these days that action can be super expensive. SO, accurate logging history, as much as it can be, is paramount to a happy community and successful hobby on the large scale.

    Apply that thought however, just felt the need to re-emphasize the importance of accuracy of a cache's log history.

    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.

     

     

    • Upvote 1
    • Helpful 1
  7. On 8/19/2022 at 9:27 AM, ChriBli said:

    If the problem is that people are armchair-logging caches that are missing (and I agree that is a problem, even though this is rather easy to spot when it's a low-count basic member logging with "lol"), then I don't see how your suggestion would help. For there to be a logstrip to compare to the online logs the cache can not be missing.

    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?

    • Upvote 1
  8. 4 hours ago, Isonzo Karst said:

     

    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.

     

  9. 2 hours ago, Isonzo Karst said:

    @ecanderson I see you have 7 caches that will show in the free app for basic members (ie, Trads at D/T 2 or less, Events, and GeoTours)  If it gets too bad, you can PMO them for a while. 

     

    Definitely a thing this summer.

    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?

    • Upvote 1
  10. 21 minutes ago, Atlas Cached said:

     

    I was always under the impression these devices reserved the timing signal from on of the in-view satellites for this very purpose. They don't need an atomic clock in the GPSr when they can just borrow it from one of the satellites overhead! 

     

     

     

    Apparently, Garmin Software and Hardware Engineers disagree with you!

    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.

     

     

    • Helpful 1
  11. 24 minutes ago, Atlas Cached said:

     

    This has been hashed out here and in other forums more times than I care to count.

     

    There are links in this same thread with the information you seek.

     

    Galileo is substantially more precise than GPS, and Garmin GPSr that use Galileo satellites are capable of calculating a position using the dd mm.mmmm format.

     

    Also, please do not confuse Precision with Accuracy.

     

     

    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.

     

    • Helpful 1
  12. On 5/12/2022 at 6:20 PM, Atlas Cached said:

    None of those models were precise enough to support the fourth digit like your new 64 is!

    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?

     

     

    • Helpful 1
  13. On 4/8/2022 at 9:25 AM, luvvinbird said:

    Compass calibration has always been the one setting, bar none, that I dread performing on all of the Garmin receivers I own. Some go well, some don't.

    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.

     

  14. 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.

     

    • Upvote 2
    • Helpful 2
  15. 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.

     

  16. On 6/4/2021 at 9:18 AM, hzoi said:

    I was just talking about Diego Garcia at work this morning. I'd love to visit there and snag some caches.

    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/

     

     

  17. 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.

  18. On 4/1/2021 at 9:01 AM, sloth96 said:

    With the recent announcement from Clyde on GSAK, it seems appropriate to remind folks of geoget. 
    The integration of translation services into web browsers has made documentation much easier to understand in different language. 

     

    So this is just bumping this up.  

     

    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.

  19. 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.

     

  20. 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.

     

    1409429839_NoMap.jpg.12c95bee406738676d224124fbd47514.jpg

     

    2047801611_NoMap2.thumb.jpg.25da38770be31ce8ae17ff9ebedf549d.jpg

     

×
×
  • Create New...