SnoWake

I try to keep my eye on the various threads that seem to discuss this topic, and always try to weigh in on new ones. Having just come back from an epic road trip up to Oregon, I was again faced with the task of "filling in the gaps" from incomplete PQs. Now, in theory, a simple "OR_found" query should have returned all the caches I found up there, and the latest run of my "CA_found" query should return my last 500 California finds, including all the ones from this recent trip. Sadly, this is not the case. I'm fully aware and don't except archived caches to show in these PQs, but for some reason I can't figure out (and have described several times in other threads) - some caches simply don't get returned from these queries. There's no rhyme or reason - it's not a matter of distance, cache type, or anything I can detect. To get a complete history, I have to identify the missing caches (roughly 15 from the 74-find road trip), and download individual GPX files. So, I'll continue to watch the threads, and throw in my vote (and pleading) for the "all caches found" query. I'd be satisfied with a query that accurately returned all currently active caches - but the option to return ALL finds, regardless of status, would be fantastic. Any update on the feasibility or status of such a feature? Thanks! Billy

ARGH! Anyone else install the new Beta 3.41 software? While some of the feature adds in the changelog look promising... I JUST discovered a problem. I don't know how many of you use the "calendar" feature - but I find that when I'm on a major caching spree, this handy feature helps me keep track of my "finds" (in case I forget to mark them in CacheMate). So, I'm trying to finish logging a recent outing to Modesto... and after an upgrade this morning to the new firmware, went to the calendar, and... It's all GONE! I thought for a moment: "Well, maybe the upgrade just wiped the record of found caches" - so I went through the exercise of "finding" another... and it doesn't show in the calendar. I'm preparing for an epic road trip up to Oregon, and will definitely miss this 'feature'. I'll drop Garmin a line about it, and hopefully they'll fix it in the release version. In the meantime - I may downgrade to the previous (3.40) version, as it was working fine for me. Just an FYI... Billy (aka SnoWake)

I'm not the least worried about sort order (GSAK does that, and A LOT more for me), and I "spin" cachemate AND HTML files for my Palm. However - I guess no one else is having the problem of caches MISSING from the query? Might be hard to detect when searching for caches you haven't found - but my "CA_found" query continues to fail to return the "full" (most recent 500) set of finds. I can find no logic (distance, cache type, status, etc) to explain this behavior. No one else is seeing this, huh? Guess it's just a personal problem... Have a great day! Billy (aka SnoWake)

I'm STILL having troubles with pocket queries, returning all the "matching" caches. Of most interest (and most easily verifiable) is my "CA_Found" PQ. This query is configured to return my 500 most recent finds in California. However, for some reason, every once in awhile certain finds fail to show up in this query. Once I figure out which ones aren't showing, I can go pull down GPX files of the individual cache, for import into GSAK. So, the current example: I hit up 6 caches on my way up to a camping trip at East Park Reservoir, all found on 6/5/04. Yet, a few of the finds don't appear in my "CA_found" PQ. I've double-checked the PQ criteria, AND the individual caches (make sure they're properly identified as "California" caches, etc) - I don't see any explanation for the missing finds. In the latest runs of my PQ dated today, 6/11, the following caches are missing: Maranatha on Allendale - GC4F09 (found 6/5) I-80 Gold Run WB - GC2197 (found 5/30) I've had multiple instances of this - but if I stay on it, I can usually catch the stragglers, and pull them down individually. Any ideas as to what might be going on? Thanks, Billy (aka SnoWake)

Long history of Garmin GPS products, going way back. Only discovered geocaching in recent times, during the "eTrex Vista" era. Very recently upgraded to a 60CS, and couldn't be happier - it has pretty significantly streamlined the geocaching experience! Far less pre-outing research/planning - just a matter of ensuring the data in my Palm is up to date, that I've downloaded any new waypoints... and off I go. Not having to worry about navigation in unfamiliar neighborhoods (or states!) is an amazing benefit.

I'm not having the "scrambled" problem (or maybe I am, and just don't notice, cuz I pass 'em all through GSAK first thing). I'll take a look at that and report back... In the meantime - I AM having a different problem with PQs, and didn't find another relevant thread, so figured I'd post here rather than starting a new one. I've got a PQ for (the last 500) caches found in CA. It's: "CA_found" : http://www.geocaching.com/pocket/gcquery.a...68-c59dede846d0 For some reason, I've noticed over the past some time (month or so?) that I haven't been catching all my finds in this query. Everyone once in awhile, one will slip through. After confirming that it IS properly classified as a CA cache, and that my "found" log is still present... I typically download a GPX file of the individual cache, and add it to my GSAK "found" database. I recently had another such example, so I thought I'd ask about it before simply resolving the problem. Back on 5/19, I found "June's Cache" (GC60E6) - and yet this find still doesn't appear in my PQ received today, more than 5 days later. I even went so far as to grep through the GPX file, just to make sure GSAK wasn't dropping it for some reason. Nope - it's not there. I didn't notice any such pattern with past ommissions - but perhaps the fact that there's a single-quote in the title? I know that can do some damage if not properly escaped (at least in my world ;-) - but I'm rather clueless as to why it's not working. Interesting: When I select "Preview" from the PQ page, and scroll to the right spot in the list - the cache is listed. However, I'm quite certain that it isn't present in the GPX file being delivered to me. Any thoughts / suggestions / similar experiences? Thanks much, Billy (aka SnoWake)

Quick Follow-up: The first of my Friday PQs have started to arrive - specifically, the new one I created today. It was run at 14:40 (PST) and was delivered at 17:48. That's actually not much of a delay - perhaps more than we're used to - but certainly acceptable (in my case). So, my comments shouldn't be considered a "complaint" of any sort - merely additional data points. Thanks again, Billy (aka SnoWake)

I received my notice of the new software, and applied it this morning. Have yet to "field test", but under "labratory environment", the upgrade looks GOOD. The two obvious things - the difficult-to-see contour lines on topo maps, and the bogus search in the "geocaches" list, both appear to be resolved. In response to what color the contour lines are - well, I think that depends on what color scheme you're in. During daylight hours, mine went from a hard to distinguish light-brown to a more visible gray, seemingly "thicker" (from 1px to 2px?) line. Just some initial thoughts - but so far, so good!

Ditto. I've had a couple of PQs run today, that have never arrived. Checked all my mail logs, spam filters, etc - I'm receiving OTHER gc.com emails - just not the output of PQs. I even created a couple fresh ones, scheduled for today - they ran almost immediately, as expected - but hours later, still no email. Sounds like one the machines could use a kick - as I doubt all our ISPs (or, in my case, my own mail server) are all bogging down and sitting on these "store and forward" messages. Too funny - I'm ALWAYS the one preaching to folks at work about SMTP and "store-and-foreward" - folks get way to used to sub-minute response time receiving an email from their kids in college across the country, that when queues back up and things take 10 minutes, they freak out. Well, I waited a few hours, and did all the research I could, before paying it much mind. Once I saw that others were experiencing troubles as well, I was at least relieved to see it wasn't just a "personal problem". Much thanks to the GC team for their tireless support of keeping these services up and running, under what must be darn near exponential growth. Here's wishing everyone a great weekend! Billy (aka SnoWake)

Final Word: My problems were resolved by Hemlock (thank you, THANK YOU!), as well as my specific question answered. For the record: The maximum distance a hider may relocate a cache without admin intervention is .1 mile (528 feet). End of story! Thanks to all...

These are both correct responses, and actually describe the process I've taken (working with an admin in the one case where it's required). I also considered the "simply delete the cache, and create a new one" in order to self-service this request. However, that (over the long haul) introduces OTHER problems - so I'm hoping that someone "in the know" still understands the value of sharing this information. In the case of the cache that has been found by muggles - I don't want to move it far, or significantly "change the hunt or experience" - just far enough so that it's not readily discovered from the previous location, but close enough that I can "do it myself" (e.g. change the coordinates on the cache page). There are no other caches in this particular park, and it's large enough that I could probably move it as much as .25 miles without significantly changing the "experience". Anyway - I understand some of my alternatives, and as I've mentioned, I AM working through them. I still think it's useful information for the community at large to be aware of. Thanks for the responses, and thanks in advance for an answer... Billy

Funny, I was just in the DC area for a 3-day conference and whirlwind caching tour. The 60CS, and auto-routing, were a MIRACLE. Got me from Dulles to the flood of virtuals in downtown DC and back to my hotel in Frederick, MD without ever cracking a (paper) map. I actually noticed this difference then: For starters, back east there seems to be fairly consistent "Exit numbers", and these were ALWAYS accurate (not surprising). Additionally, I don't think I saw a single instance of the road name on the GPSr not matching the exit sign - and yet I'm very familiar with that problem out here in CA (where, for some reason, we don't have exit numbers - an issue that perplexes my various guests from back east). I'm guessing it's more a "data quality" issue rather than a programming or functional issue within the GPSr - but who knows? On a different note - I wanted to share a little "tip", and associated annoyance, and ask if anyone had any thoughts? So, for this recent DC trip (where there were MILLIONS of virtuals), I wanted to visually differentiate between the different types of caches. Thanks to GSAK, this is quite simple: I just selected the various icons I wanted to use for traditional, multi, virtual, event, and locationless caches... and VOILA! Mission accomplished. Now as I'm driving down an unfamiliar highway, I can tell at a glance what type of caches are nearby (although I would like to petition gc.com to institute "Micro" as a discreet cache type, rather than just being a subset of traditional). So that's the "tip" - and I like it so far. The annoyance: As soon as you use an icon OTHER than "geocache" - the 60CS doesn't know how to deal with them (e.g. they're not considered in 'geocaching mode'). Now I've heard some say that this mode is a joke, and worthless - but I was using it a fair amount before I adopted this technique. If nothing else, when out on a big caching spree, being able to go back to the calendar and review all the caches you marked as "found" is valuable (I performed this function on my Palm - but the more I can consolidate down to a single device, the better). So, I guess my feature request to Garmin is to allow ANY waypoint type to be applicable to geocaching mode, be marked as "found", etc. I'm sure there are other implications to this I'm overlooking, but... hey, that's what clients/customers get to do! One possible alternative/work-around I've considered is going back to using only "geocache" as the icon for all cache types - and then utilize GSAK's variables to append/prepend a single letter indicating the cache type. Unfortunately, with pre-pending it would make alphabetic sorts less useful, and appending would just be harder to consistently detect and "translate". This solution also sacrifices the quick visual reference provided by using different icons for the various types. What is everyone elses' experience with this issue? Just some thoughts, Billy (aka SnoWake)

Gang: I recently discovered a programmed limit within the geocaching.com site which limits the maximum distance a cache may relocate (and still be self-serviced by the hider). I discovered this the hard way when posting a new cache, and selecting the wrong set of coordinates (from several potential waypoints I set in researching/selecting the hide). So I'm working with an admin to get that one corrected, but... I would like to know what that actual limit is - and here's why. I've got another cache that seems that have fallen prey to frequent visits from muggles - who draw crude, offensive things in the log, leave inappropriate items in the cache container, took the disposable camera, and perhaps have even made off with a TB or two. So, I'm planning on relocating the cache, but within the same park. If I knew, for example, that the maximum relocation allowed by the hider was .1 mile, I would focus my efforts on finding a new secure hiding spot within 500'. If, conversely, it's .25 miles - I have a much wider scope of potential hiding spots. About all I know is that the limit is somethig greater than a few feet (as I've made minor, .001 type changes to previous hides) but less that 1.3 miles (the HUGE distance between the incorrect coordinates I entered and the actual placement of my new cache). Knowing this threshold might prove valuable for a variety of reasons - so I'm just wondering if someone can clue me in? My apologies if this is already documented or discussed somewhere - but I looked over the hiding guidelines, the FAQ, and even did a handful of searches here in the forums, and couldn't come up with the specifics (or even a discussion of the issue). Thanks in advance for any insight or answers. Have a great evening! Billy (aka SnoWake)

DRATS! The 3.20 upgrade didn't actually FIX the "Find By Name" bug, as I initially expected. However, as noted in this thread (and re-affirmed by me this afternoon) -- this feature appears to work properly when finding waypoints - but is definitely still broken when inside the "geocache" list. That's too weird - I can't believe the two functions use different code/logic... but obviously they do! In response to the "How do I get waypoints into the 60CS" question - have a look at this thread: http://forums.Groundspeak.com/GC/index.php?showtopic=68518 Hope this helps! Billy (aka SnoWake)

Well, until Mapsource starts being able to open/import GPX/LOC files, or GSAK adds USB functionality - I think we're stuck with at least a two-step process. As it turns out - I've already got SEVERAL steps, involving all of the various software components, in order to create CacheMate and HTML indexes of caching data (paperless), visualize caches within M$ Streets and Trips and/or ExpertGPS, etc. I've actually revised my process outlined above (see - I told you it was a moving target!), based on how much I prefer the friendlier, more meaningful "smart" waypoint names generated by GSAK. So - from within GSAK (where I've pulled in all the desired GPX files), I simply export (all, or a filtered set) of the waypoints to a Mapsource (.MPS) file. Then open this file in mapsource, and push to the 60CS. Pretty simple two-step process, and no extra software to buy. Yes, this is simply a repeat ahisma's early reply to this thread - sometimes I'm just a little slow catching on. Hope this helps, Billy (aka SnoWake)

I just applied the 3.20 upgrade made available today. All evidence is that is seems to have fixed the "find by name" problem. Interesting - the changelog suggests: (snip) 2. Find by name searches now only return a list of items that begin with the input string. (/snip) Are the suggesting that it was actually working all along - it was just doing a RegEx (regular expression) against the waypoint name, and matching those characters anywhere in the name? Not sure I'm buying it, but... since it seems to be working as desired now, I'm happy... Also, regarding the compass calibration problem (I've experienced this as well): (snip) 13. Corrected problem with the Calibrate Compass option on the geocaching compass page. (/snip) So, glad to see the next release came out so quickly. Wonder if they introduced any new problems, in their haste to resolve some of the larger ones? Let's hope not... but so far, so good! Hey, one more annoyance, and looking for a tip: I'm not a big fan of the "new" power connector (same one used on my old GPS III and earlier models) - instead, I much prefer the data/power connector used on the eTrex series. Regardless, there it is again - this barrel connector complete with frail pins on the unit just begging to be bent. So, my annoying isn't the use of the connector: the problem is how difficult it is to unplug when the unit is attached to the additional bracket for connecting to a standard dash (or handlebar) mount. I really struggle, trying to "rock" the connector back and forth, since I can't get a lot of grip on it. The alternative is to remove the unit from the additional bracket, THEN remove the power connection - but based on how the cable routes over this bracket, that's not particularly convenient, either... Any thoughts/suggestions/experiences? I've got a few days in MD coming up next weekend, and really looking forward to doing some caching with the help of my 60CS, a rental car, and auto-routing....

I'm dealing with a case of P.O. right now - I think my third case in the past year since I started caching. Out here in CA, I see it as something of an "occupational hazard". I'm well stocked with Ivy Block (preventative) and Tecnu (post-exposure) - and in this last incident, I even knew when I was exposed (digging through a bush at night up in the east bay hills, only to discover as I was REPLACING the cache that the bush was interlaced with a ton of poison oak). I did the full Tecnu regimen, immediately washed all my clothes (wearing shorts and a short sleeve shirt), gave the dog a bath... but a couple days later, it started coming on. When I realized how extensive it was, I decided this time I was going to try the doctor (as my last batch was a long, itchy, sometimes painful month of recovery). First, in discussing the treatment I had been doing (the HOT shower method, plus Claritin, plus topical cortisone cream), he warned me strongly against this technique. I described the same logic I just read here - that it draws out the histamines from the skin (this has certainly worked for me in the past). He claimed that while this may provide temporary relief from the itching, it was a Bad Thing overall for the rash, causing it to "blossom". I'm not sure I experienced that - but I decided to take his word for it this time around and cut that out of my treatment routine. So, I asked for the full treatment - and got it! A big shot in the butt cheek, and then a 6-day "dosepak" of MethylPrednisolone tablets (tapered off dosing - 6 pills the first day, 5 the next, then 4, etc), and some Kenalog spray (Triamcinolone Acetonide in a spray). He suggested not only using the spray for relief from the itching during this outbreak - but to carry it in my field pack, and apply immediately when I suspect exposure. Well, I think I'll still Tecnu first (didn't have any mobile with me this time, and waited until I finished my caching outing and returned home to clean up) - but I'm definitely going to add this to my kit. Poison Oak definitely sucks - but being only three days into it, and already seeing signs of signficant improvement (when typically it's still coming on for about the first week and a half) - all I can say is: Better Living Through Chemistry! If I'm over this in a week (which it looks like I just might be...) I'm going to be SUCH a happy camper. Just my experience - TMMV, Billy (aka SnoWake)

Ah-HAH! I had configured for "prompted" mode - but hadn't made the leap to merely "recalculate" when I get to the trail head. That makes PERFECT sense, and resolves the issue of trying to get back to the previous route - since, in theory - I'll never have to leave that original navigation! Thanks for the tip! I think I'll go give it a try... Billy

Gang- I wasn't trying to re-invent the wheel, and I did actually search, read, (and in some cases, reply) on various threads about 60CS features, saw mentions of lockups, etc. My intention in starting a new thread was not to build a soap box to talk about those two issues - perhaps I should have refrained from including any examples in my original post. I was just looking to start a thread (which I hadn't seen one of) for "Annoyances, Tips and Tricks" on this neat new gadget some of us are enjoying. If you're suggesting that these forums aren't the appropriate place to discuss, I could always dedicate a thread to the topic over on gotwake.com - but who goes there? I thought that's what these forums were all about - exchange of information. Granted, this thread is only of interest to a very small subset of visitors - but then, I'm not forcing the Magellan (or Vista ;-) owners to read this thread - the title is intentionally fairly explanatory. To demonstrate my intention: I discovered that problem with the "find by name" feature - and at first, was rather disturbed (I thought the waypoints were actually MISSING, so I was investigating my export/upload process, etc). This was the "annoyance". Then I stumbled upon the fact that they were actually there, and just not being displayed properly. So, I found the "tip/trick" of just using the "page" button to quickly exit the keyboard mode, and then scroll (typically, but not always) up in the list to the desired waypoint. I've got some similar comments about switching between mapsets, and between navigation modes. For example, I establish a route from cache to cache, and auto-navigate using the "follow roads" feature - but then, once at the trailhead, have to jump into "Find-> Nearest", select the cache, and select "off road" - and frequently at this point I toggle between City Select and Topo maps. They annoyance is, once finding the cache, it will navigate you to the next nearest - but to return to your previously established route - you have to do just that (menu to that page, select the route, and activate it - and it has to do some calculation cuz now you're in the middle of it). The tip is: I used to toggle off individual maps (carryover from my Vista, and turning of particular MetroGuide maps to expose the topo maps). Well, I discovered in the 60CS, that from "Setup Map", on the map selection 'pane', hitting menu again provides a list of map sets, and allows a quicker, easier way to change ALL the maps from one to another, without having to scroll through the list and toggle individual maps. Now maybe that's just an RTFM thing, and everyone else already new that when they picked up their 60C - but when I fiigured it out, I was stoked -- so I thought I'd share. Have a great evening, Billy (aka SnoWake)

Well, at a minimum, we can point folks to existing threads on the topic: Loading Waypoints thread Unfortunately, because of the variety of software available, there's no clear "here's how you do it" option. I'd be happy to clean up the process I'm (currently) using to get data (maps and waypoints) into my 60CS, create a simple web page and post a link - but understand it's a moving target. The thread above has a couple of different options, depending on the software (and hardware) you have at your disposal. hth, B

Okay, I figured there weren't enough threads dedicated to the 60CS, and since I know how popular they are with the Magellan owners... here's another. I've had mine for about 5 days now, and been out on several outings, using it for both caching and just plain old navigation. I'm still learning my way around, and poring over the manual, but... just some initial observations, and wondering if others are experiencing the same problems, or know how to work around them. First and foremost: Lockups. It doesn't happen a lot - but it does happen - in my experience, exclusively while calculating auto-routing information. There seem to be certain scenarios where this is more likely to happen - but I'll try to capture some more data on this before proposing any theories. If you've got a "work-around" for this... talk to me! <snicker> I assume the only fix will come in the form of firmware upgrades - I had to apply one the day I received my unit, and I'm sure (based on my experience with the Vista) there will be many more to follow. Here's hoping they get that fixed, soon. Secondly, and MOST annoying: I'm having trouble with the "Find by Name" feature. I'm enjoying the more meaningful "smart" names as generated by GSAK (e.g. "SECURITYBY" instead of "GCFD9E"). However, when doing a 'Find by Name', I begin to spell the name of the cache - and suddenly, I'm way down in the list, beyond where the matching name is displayed. I have to exit the keyboard display - and then instead of being ON the matching record, which I should be - I have to scroll back up (to an entry not even shown on the page) to find the matching record. I just can't make ANY sense of it - and have already submitted a bug report to Garmin. Does anyone else's unit behave this way, or is this just a personal problem? I'll post another message regarding some "tips" about switching maps sets, changing navigation modes, etc - but right now, I'm late for a meeting! Thanks for any insight or experiences you can share, Billy (aka SnoWake)

Oh boy - why do I have the feeling I'm suddenly going to be very embarassed? Oh well - I'm always good for a laugh, so here goes: The SF Bay Area is pretty densely covered in hides - so a 500-cache GPX file doesn't cover that large of an area. Between the greater Bay Area, plus Tahoe, plus a couple of places I ride my dirt bike (these latter are 100-cache queries centered around my usual locations) - I end up using just about all 20 of the available PQ slots, staggering them throughout the week. Only by compiling these queries (which, of course, have some overlap) do I get a complete "not found" set of waypoints for loading into my GPSr and PDA. So, rather than load them one by one as each one arrives throughout the week (between 3-5 each day) - it seems simpler to just dump them into a common directory, and then "refresh" the GSAK database periodically (before an outing, for example - I usually end up doing this about every other day). Same concept applies (only more important, in my mind) in respect to finds. Until quite recently, it was easy enough to simply generate a PQ for each state (one time only for states I visit, and then a recurring one for my home state of CA) in order to get a total record of all my finds. Well, now that my CA finds have cracked the 500 mark, I'm not getting them all in a single PQ - so I'm having to slice/dice it (trying a couple different approaches - either by difficulty, terrain, date hidden - some way to break it into < 500 cache chunks). So, same theory - I want to place all these various "found" PQs (at least the few that I expect to change) into a directory, and unleash GSAK on it every couple days (okay, okay - EVERY day ) in an effort to have a database of ALL finds. I actually had accomplished this elusive goal a few weeks back, but I hosed my database (e.g. made some stupid mistakes) and had to start over - at least until Jeremy releases the new "all finds" special PQ. Anyway - does that make any sense at all? If there's a simpler way to accomplish this, I'm ALL for it.. I was just commenting on the apparent inconsistency between the two (file/directory) selection dialog boxes. Knowing that the "scan a directory" was an after-thought - I'm glad you had it! Hope this makes at least some sense. Time for some much-needed sleep... B

What can I say, ClydeE... you're my HERO! Hey, I just thought of a "feature request" - again, maybe I'm just missing something. For various reasons, I keep my GPX files sorted into a few folders, a couple layers deep off the "root" (C:\). So, when I do a File->Open, and am presented with the "Open GPX/LOC File" dialog... When selecting an individual file, I can, if desired, simply type it's path (and even file name), and the browse function seems to start at the same point indentified in the previously listed file. However, when I want to open a directory of GPX files (which is what I most often do) - I am forced to start at C:, and perform several layers of "drill down" to find the desired target folder - and then repeat this same process each time I want to load files from a different folder. Guess I can't figure out why this path isn't directly editable, or lacks the "Most Recent" feature found in the individual file selection process. Both these would be a BIG plus. I'm sure there's a very sound and logical reason for these differences - I'm just relating the "end-user experience" aspect of it. Keep up the GREAT work! Thanks again, Billy

Was: Hardware: Garmin eTrex Vista Palm m505 Software: Utopia GPX Spinner Plucker (yes, it takes a LONG time, especially at the depth required to include the hint) CacheMate Now: Hardware: Garmin 60CS Palm Tungsten C Software: GSAK Plucker (can be set one layer "shallower" for GSAK output w/ hint on same page - still runs slow, but fast)er CacheMate Then new Palm has plenty of memory, and I like having both CacheMate as well as "spun" web pages for the data - for those rare occasions where a photo may be required to solve a puzzle, provide a clue, etc. Of course, it's an ever-moving target, and there have been LOTS of variations along the way - but this is what I end up using most often... hth, Billy (aka SnoWake)

Just another option... I'm using GSAK for most stuff these days, but without USB support (and my laptop lacking a serial port by default, and GSAK doesn't seem to like my USB<->Serial adapter)... I do it like this: 1) Open Pocket Query (GPX file), or even .LOC file downloaded from geocaching.com, in ExpertGPSExpertGPS (yes, this is a registered program - but I really like the feature set, automatic aerial photo and topo map retrieval, etc, etc). The most recent beta version includes USB support for the 60CS. 2) Click the "Send to GPS" button Done. The downside to this very simple process is that you wind up with standard waypoint names like GCJ3DY. In just a few days of using the 60CS, I've already grown quite fond of the more meaningful "smart" concatanated names as exported by GSAK (but then I gotta go hook my laptop up to a port replicator and connect via serial port - a big hassle). If you want to compile a bunch of different GPX and/or LOC files together before sending, you can do this in GSAK (and save the result as a GPX file), directly within ExpertGPS, or even Utopia - depends on which other programs you're using (if any). That's how I'm doing it today - although I considered the options outlined above, as well (export from GSAK to MapSource, load from there - since that's where you'll load maps from, anyway) - I just went with the programs I was most familiar with, and found a combination that worked. I'm always looking for a better mousetrap though - so keep those suggestions coming. Come on, GSAK - let's get USB support!! Just my .02 cents - YMMV, Billy (aka SnoWake)