Munin

So just out of curiousity, can anyone identify which brand/style the bear is? The shape and construction reminds me a lot of a Ty Beanie Baby bear, but the ones I've found online seem to be either darker or lighter than the one in the nest, and their neck ribbons don't seem to match. Ex: Clubby 1 (a bit too dark, wrong ribbon) Massachusetts the Bear (too light, wrong ribbon) Any Ty collectors watching this thread? Can someone come up with a closer match? (Hopefully not some multi-hundred-dollar ultra-rare one? )

Osprey Log, 20060815, 10:00 am: "I hate to sound paranoid, but I keep getting the feeling that the little box above the nest is ...well... watching me somehow. Must talk to shrink about this next week..."

I haven't had any problems with Custom POIs with my 76CSx running firmware 3.00/2.70 and using POILoader 2.32, but that doesn't mean there aren't problems - just that I haven't noticed any with my own POI files. I did see someone reporting a similar problem with a Legend Cx (TantalCZ over in the Poi Loader For New Garmin "x" Series thread), so I don't think you're alone in the world. Any chance you could put the .csv file that GSAK created on a server somewhere and provide a link where folks could download it to experiment with? I'd be game to try converting the .csv file and loading it onto my 76CSx to see what happens.

I'll take a stab at this - I'm not a GPSr tech guru, but I did stay at a Holiday Inn Express not too long ago. The GPS satellites are constantly moving, so the number of satellites and their relative positions at one time won't be the same as some other time. Perhaps on one day you power up your GPSr and maybe you've got an unobstructed view of half a dozen satellites evenly spread across the sky, and your GPSr slurps up the signals and gets a fix right away. Another day you fire up the GPSr, and you've only got a clear view of a couple of sats, weak/intermittent signals from a few more that are closer to the horizon, and still others where the signal is either too weak or too jumbled by obstructions for the GPSr to make heads or tails of it - and it takes longer for the GPSr to come up with a fix. You can get a feel for the number and relative position of the GPS sats by looking at the Satellite display on your GPSr - the closer a satellite is to the center, the higher it is overhead (a satellite in the center is directly overhead), and the further out a satellite is the closer it is to the horizon. (On the Garmins I've owned, the outer ring represents the horizon, the middle ring is 45 degrees above the horizon, and the middle is overhead.) By looking at the locations of the satellites on the display and comparing them to nearby obstructions (buildings, tall hills, etc) you can usually get a decent feel for why certain satellites are coming in weak or not coming in at all. (Maybe you see that #8 is off to the west and low on the horizon, and there's a big apartment complex just west of you - probably going to have some problems getting a good signal from #8 until it climbs high enough to clear the apartments. And maybe #16 is nearly overhead and there's no obstructions above you, so you'd expect to see a strong signal from #16.) Another possible cause might be storing the GPSr for (relatively) long amounts of time without batteries. I've noticed this with my 76CS - since it's no longer my primary GPSr, it may sit on the shelf for a week or three without batteries, and when I slap in some fresh batteries its clock will initially show a date from days or weeks ago. When it start searching for sats, it's scanning for the ones that it thinks should be visible based on the incorrect date that it thinks is the current time. It might get lucky and find that a few of the satellites actually do happen to be visible, update the clock from the information it receives from the sats, and update its predictions on which satellites really should be visible based on the new time, and proceed to get a lock. Or it might not get lucky, not see any of the expected satellites (from days/weeks ago), give up the search, and ask me if maybe I'm indoors right now since it can't seem to find what it's looking for. In that case telling the GPSr to do a New Location/Automatic can help - with an automatic location update, the GPSr will just start scanning for any satellites it can find, rather than only looking for the ones it expected to see - after it starts finding the real satellites it'll get the clock straightened out and get a position fix. Doesn't happen over short periods without batteries though - I've tried taking the batteries out for ten minutes or so and when I put them back in and fire the GPSr up it's still got the correct time.

It's still there - pretty much the same place as it was in Sparrowhawk's shot from Saturday. It's actually resting against one of the support posts for the nest - probably one of the more secure positions it's been in since it started shifting around last week.

Check the datasheets of benchmarks in your area (you can use the 'show nearby benchmarks' link on local cache pages). If the text below a particular benchmark's location says it's 'ADJUSTED' then its coordinates are far more accurate than any consumer-grade GPSr - when you're standing at such a benchmark, you are at that lat/lon. (A mark with an adjusted location should be accurate within a meter, sometimes even within a few centimeters for high-order stations. Compare that to your GPSr, which is rated to be accurate within 10 meters 95% of the time.) On the other hand, if the benchmark info says the location is 'SCALED', then it's not suitable for a GPSr test - a scaled location could easily be dozens or even hundreds of feet off. (A scaled location may well have been measured from a paper map, with the accuracy necessarily limited by the map's scale.) Taking a quick peek at benchmarks near some of your cache finds, NB1904 "1178 AZIMUTH MCGS 1969" might be suitable. The location has been adjusted, so it's very reliable. The description sounds like it's in a reasonably accessible area - the sidewalk of an apartment complex. The mark is a disk, which is one of the easier things to spot (compared to marks like tacks or drillholes). It's been found recently, so a high probability that it's still present. And the last finder uploaded a photo, so you'll have some idea of what to look for. There's several other benchmarks with adjusted locations within a few miles of this one, so you've got other choices if this one doesn't end up being useful for whatever reason. If I were doing this, I'd probably stand over the disk, mark a waypoint, and use the 'Avg' function to set the coords. Let it run for a minute or two (60-120 samples) or longer if possible, and keep an eye on the estimated accuracy. (It's normal to see the accuracy go up and down and up and down as more values are collected - it doesn't always just get better with each subsequent reading. ) If the estimated accuracy looks poor, you might either be getting too much interference from the nearby apartment buildings (although the 60/76 'x' models handle this remarkably well) or the satellites might not be well-positioned at that moment (the GPS sats are constantly moving, and some configurations are way better than others for getting a good reading). After you've averaged for a while, save the location and check it against the location on the datasheet. If you're within 30' (remember that "10 meters 95% of the time" accuracy rating for your GPSr), then everything is working just fine. (Although I'd expect a 60CSx to get much closer than 30' with an averaged result, but anything in that ballpark is reasonable. 300' off might be cause for concern. ) Averaging should give you a better result than just eyeballing the lat/lon display. As an example, here's a plot of readings I took at 30-second intervals over the course of an hour or so (there's two GPSrs in this plot - a 76CS and a 76CSx - I was running an informal 'jumpiness' test between the two). As you can see, at any given instant in time the position can hop around a fair bit, but the vast majority of the points are clustered in the center. If you were relying only on eyeballing the lat/lon display, you might catch an outlying point that's 30-100 ft away from the center. Averaging the location would help reduce the effects of the occasional oddball point and give a more stable result.

I ran several PQs this morning, and all of them came back correctly sorted by distance from the search origin, not sorted by GC waypoint ID (although I did get some GC-sorted PQs a week or so ago). Anyways, it's working for me!

Whoops, my bad! Thanks for the correction, webscouter!

When the 2GB microSDs came out last week, Quoddy confirmed (over in the 2gb MicroSD Is Here thread) that there's still a limit of 2025 map segments total, even if the card still has sufficient room to store more. Shouldn't be an issue unless you're combining City Nav with vast tracts of another map product that uses lots of small segments (like US Topo/Topo 24K). The SanDisk press release from a bit over a week ago that announced the 2GB microSD cards indicated that Verizon Wireless stores have exclusive sales rights within the U.S. for the first 60 days, supposedly for a price of $99. (Although one of the early 2GB adopters, zookc, said it cost him $89.99 (+tax), and that was at a Verizon store.)

Glad some of you can make use of this - I'd surely have beaten myself silly trying to figure out Custom POIs in the first place if it weren't for all the tips and workarounds that I got from the forums! One other bit of trivia that I came across while playing with this: you can create subdirectories under the \Garmin\Poi\ directory and move various POI files into various subdirectories and everything continues to work fine. Looks like the firmware is loading all .gpi files that it finds anywhere under the \Garmin\Poi\ directory. Might come in handy if someone ends up creating scores of individual .gpi files and needs to add another layer of file organization. (And before anyone gets too excited, using subdirectories on the microSD card does not result in some sort of indented/hierarchical listing in the GPSr's Select Database menu - it's still just a simple list of whatever names it found in whatever .gpi files it found.)

Well, no respirator - have you ever tried to find one that'd fit a beak as big as mine?!?! But I try my best - here's a photo of me preparing to test my GPSr after renaming the first database:

I don't remember seeing this covered in previous threads for the Garmin Custom POI, and since there's going to be a number of pictures I thought it'd be best to start a fresh topic rather than dumping this beastie into the middle of an existing thread. Okay, so we all know that POILoader sucks in one or more GPX/CSV files, munches and crunches the data, and spits out a file called poi.gpi into the \Garmin\Poi\ subdirectory on your microSD card, right? ...Ever wonder why they created a whole subdirectory to store one file...? ...Ever wonder if you could put more than one file in that folder...? ...Ever actually tried putting more than one file in that folder...? For tonight's edition of "Silly Garmin POI Tricks", I'll use the POILoader program and the GPSr's USB Mass Storage interface to create multiple Custom POI files on a 76CSx, and along the way perhaps manage to justify this as something more than an effective treatment for chronic insomnia. I'm not sure about everyone else, but I've got several sources of Custom POIs - benchmarks, places I want to find easily on business trips, well-reviewed restaurants I want to try .... oh yes, and caches - musn't forget those caches! Previously, I'd been tossing an assortment of GPX and CSV files into a folder, firing up POILoader, and letting it munch and crunch its way through all the files. It worked fine, but it was also kind of sad knowing that poor little POILoader was digesting 7000+ benchmarks - which I'll only update every month or two - just so I could get my much smaller geocaching POIs updated after the morning's PQ arrived. If only there was some way to separate infrequently-changing POIs (like benchmarks) from frequently-changing POIs (like caches)... For tonight's experiment, let's start by taking my benchmark file (since it's benchmarks for Massachusetts, I've been super-original and named it "MA Benchmarks.gpx"), tossing it into its own folder, and having POILoader chew it up and spit it out to the GPSr. Firing up the USB Mass Storage option afterwards, I see the expected file in the expected location on the microSD card (which shows up as Drive E on my Windows box): So, I wonder what would happen if I simply renamed the 'poi.gpi' file that POILoader created, and called it something else...? Well, let's tell Windows to unmount the drive, hop over to the GPSr, and see what's listed under Find -> Custom POI ... will the POIs still show up, or will they not show up at all, or will my GPSr perhaps explode into flames...? Hey, those actually look like benchmark PIDs! (If you haven't benchmarked, just trust me on this - benchmark PIDs are kind of like the GCxxxx waypoint IDs for geocaches.) I guess I can put the fire extinguisher down now... With only one POI database loaded, there's no Select Database option available, so I can't yet tell what the GPSr thinks my database is named - I'll check this a few steps further down. Okay, now let's fire POILoader up again, and this time point it to a small group of POIs that I use on trips to Virginia - this one called (with my usual originality) "VA Trips.gpx". Now when I use the GPSr's USB Mass Storage option, I see two files in the Garmin\Poi folder: So let's once again try renaming the "poi.gpi" file that POILoader created - since it contains VA-related info, I'll keep it simple: Unmounting the USB drive and heading to the GPSr's Find -> Custom POI section again, I find that I can now bring up the Select Database option, where I see both of my POI files listed: Note that the filenames I used when renaming the "poi.gpi" file are irrelevant - Select Database names the entries the same as the source files, not the filenames on the actual microSD card. (Which is expected, since POILoader works that way even when it's combining everything into a single file.) And let's do one more, just for good measure. I'll toss all my caching-related POI sources into another Windows directory, which will then contain the results of a "My Finds" PQ along with a bunch of other PQs that have been glued together by GPSBabel into a master "Unfound Caches" file. Fire up ye olde POILoader again, mount the GPSr as a USB drive again, and see what I've got: Looks good - still have my previous renamed files, and the most recent 'poi.gpi' that POILoader created from my caching files. In this case I'm not going to bother renaming the 'poi.gpi' file, since this is the data that I'd expect to overwrite every few days anyways. Taking a quick peek over at the GPSr's Find -> Custom POIs section, I now see a mix of benchmarkd PIDs and cache waypoint IDs in the list, and Select Database shows the names of all the different source files I used: In reality, this could all be done a lot quicker - either pop the microSD card into a USB drive, or hook up the GPSr with the USB cable and use the USB Mass Storage option, so that Windows and POILoader see the microSD card as a removable drive, run POILoader on the benchmark file, rename it, run POILoader on my VA business trip file, rename, run POILoader on the caching files, unmount drive, and voila. All the malarky with unmounting the drive between each transfer to check the GPSr was only done to see if each step was working like I'd expected. And now, as updated PQs arrive, I can just toss them into my caching POI directory, rerun POILoader (which only has to digest several hundred cache entries, instead of all that plus thousands of benchmarks and dozens of other non-caching points), and - voila - seconds later there's a new "poi.gpi" file with the latest/greates caching info inside, and I've still got the separate "*.gpi" files sitting on the card for those infrequently-changing databases. So, as Joel and the 'bots would say to the mad scientists after an invention exchange: "What do you think, sirs?"

GPX and LOC are both XML file formats. LOC is the bare-bones version - cache name, owner, waypoint ID, latitude, longitude, and whether you've already found the cache. Enough info for basic cache management and to download coords to your GPSr - not fancy, but it works. Regular members can download multiple caches at a time in LOC format from the search pages, or individually from each cache's page. GPX is the deluxe model - everything that LOC contains, plus the full text from the cache description, difficult/terrain ratings, type of cache, size of container (if known), hint (if provided), most recent log entries, and names of any TBs/geocoins logged into the cache. This is incredibly handy for people who bring a PDA or laptop along on caching trips, since they can bring up all the textual information from the cache page without having to hop online or make printouts. Regular members can download individual caches in GPX format from the cache's page, but can't download multiple caches all at once in GPX format. (Programs like EasyGPS and GSAK can be used to manage all the individual GPX files.) Premimum members can retrieve large numbers of caches at a time in GPX format using "Pocket Queries" (aka PQs), which are basically a way of querying the cache database using a wide variety of criteria (caches within 10 miles of home that are terrain 3 or less and difficulty 2 or less, etc etc etc), with up to 500 caches matching those criteria sent back to the user via email. PQs are pretty consistently rated as the #1 benefit of getting a premium membership.

Got your paddles packed, Planet?

It's spelled "SiRF", but it's pronounced "Throatwarbler Mangrove". . . . Actually everyone I've heard say it aloud (so that's like me and maybe 3 other cachers in the world where conversation turned to this subject ) has pronounced it "surf".

If you installed and unlocked the older version of CN/CS after the release date for CNv8, then you get the update DVD for free and your unlock codes are free - it's a completely free update. The $75 charge for new unlock codes only applies if you installed+unlocked an older CN/CS before the CNv8 release date (i.e., before April 5th).

Just grabbed this area from CN8, downloaded it to a spare microSD, and tossed it onto my 76CSx. (How did we Garmin users ever live without swappable memory cards? ). Yep, I see the ...ummm... whatever-the-heck-it-is. Blue flag is simply a waypoint at erkrupa's coords - the rectangular thing under discussion is below the waypoint flag. Notes: Oddity does not appear in MapSource CNv8 at any zoom level. Shows up on my 76CSx starting at 1.2mi, disappears at 0.5 mi, reappears below 0.5 mi. Not selectable with the cursor, although POIs behind the rectangle remain selectable. Only shows up on CNv8 layer - disappears if CNv8 is hidden. Detail level must be "Less" or higher - oddity disappears with "Least" detail.

Getting sunglasses with interchangeable lenses can be helpful, since you can swap in progressively more transmissive lenses as the light levels decrease. I've been using Smith Slider 01 glasses for the last few years - dark brown lenses for most of the day, yellow for low light or deep shade, and clear lenses at night. Interchangeables can also be handy for mountain biking and bushwacking - protecting your eyes from dust and small branches while still letting you see the terrain ahead. Definitely test out different companies/frames to get a comfortable fit though - my Sliders would slide right off my g.f.'s head, and her Julbo glasses clamp down so tight on my head that I'd have a migraine if I wore them for a day.

Perhaps another attribute in the 'Groundspeak:travelbug' element? <Groundspeak:travelbugs> <Groundspeak:travelbug id="71106" ref="TB115C2" type="Travel Bug Dog Tag"> <Groundspeak:name>Tennis anyone?</Groundspeak:name> </Groundspeak:travelbug> <Groundspeak:travelbug id="253101" ref="TB3DCAD" type="West Tennessee Geocoin"> <Groundspeak:name>C4's West Tennessee Geocoin</Groundspeak:name> </Groundspeak:travelbug> </Groundspeak:travelbugs> A new attribute should be backwards-compatible with existing GPX applications, so (hopefully ) nothing would break, and the developers could eventually add explicit support for manipulating the information. A much more complex approach might be to include detailed TB info in a separate/supplemental XML file, along the lines of the "-wpts.gpx" file. I'm picturing a "-trackables.tbx" file that contained info on each trackable listed in the caches contained in the main PQ results file, with the XML including trackable name, type, cache location, owner, description, goal, and maybe the last few log entries. That'd help with trackables that don't have a laminated goal sheet (pull up the PQ "trackable" info, read goal) or which might have gone AWOL from the cache (pull up PQ "trackable" info, see that someone posted a note six months ago about the TB not being in the cache). It'd also support targeted searches by icon enthusiasts - they could search/sort the trackable type info to locate ones they haven't encountered before, then use the cache location info to plan their trip. Or browse the goal info before a caching vacation to see if there's any TBs trying to get to the same area. Obvious downsides: needs new XML syntax to support the detailed info, potential to break apps by introducing a third file inside zipped PQs, more coding to do the database queries and generate the XML, higher processing load on the PQ machine.

I just used 2.3.2 to transfer 7000+ POIs from a mix of GPX and CSV files, some with custom icons and some without - looks like it worked fine, even using 'Express Mode'.

Just to toss another idea out on the table, I've read some other threads where people had sporadic problems with their GPSr apparently caused by loose batteries - the contacts would be okay much of the time, but if the GPSr got jostled around a bit the batteries would sometimes lose contact for a moment and trigger various odd behaviors. Any chance you experienced the compass oddities while hiking/biking over very uneven terrain, or maybe driving down a bumpy/potholed road? (Edit: Dang, looks like sayter liften beat me by a couple of minutes with that suggestion. )

I'm currently using a DigiCam EC-741 Battery Tester. No particular reason other than Thomas Distributing was tossing them in for free with the battery chargers I was buying that day. (You can't get much cheaper than free. ) Seems to work fine, results are pretty much in agreement with what the battery charger and GPSr show for the battery strength, more than sufficient to tell whether my little NiMH's need to spend some "quality time" in the charger before I head out. Something I noticed when I was looking up the link for the DigiCam tester is that Thomas Distributing is selling a battery tester under the Maha/Powerex brand name, the Maha/Powerex MHS-BT100 Battery Tester, which looks rather similar to the Radio Shack tester: Might be that these are the same tester, just sent out with two different company logos on the front. If that were the case, then I'd expect the Radio Shack version to be okay. (If only because Maha and Thomas Dist don't seem to be in the habit of selling cruddy gear.)

Looking at a couple of the iFinder user manuals from the Lowrance website, it looks like you'd do Menu -> Menu -> (scroll down to) GPS Setup -> ENT -> (scroll down to) Coord System -> ENT, then choose Degrees/Minutes from the list of formats. Edit: I swear that one of these days I'm going to learn how to read. Sorry JeepcrewX5 - your post was clear as can be about this being a software issue, not a GPSr question.

Yeah, I'm thinking the same thing - both my original and 1GB microSD cards have worked fine, both in the GPSr, and also under WinXP and Linux using that SanDisk adapter with a couple of similar USB readers. Did you buy the 512MB card somewhere where an exchange is an easy thing? (If it was a local store, I'd be tempted to try bringing your GPSr along when you take the card back, explain what you've tried and how it failed, and see if they'll let you try the replacement card out in your GPSr while you're right there in the store. If the GPSr doesn't freeze up with that "reading" message when you power it up with the new card, then you could feel pretty confident that the old card was fubar'ed and the new card is functioning correctly.) You should have no trouble downloading using your USB reader if you want to - depending on your computer and the card reader it may be much faster than sending the data through the GPSr. And it's very easy - what'll happen is that when you click on the "Send To Device" icon in MapSource is that you'll see the USB reader's drive letter show up as a target instead of your GPSr. MapSource already knows which GPSr IDs you've unlocked the maps for (assuming the maps are locked in the first place), so when it writes the map files to the card it'll mark them as usable by those IDs - it doesn't need to talk to your GPSr first. The POILoader program (for creating Custom POIs) works the same way - if you hook up your reader with the microSD+adapter and then run POILoader, it'll give you the option of saving to the USB reader's drive letter instead of the GPSr. You're quite welcome, misteraceman!

No, definitely not - I can remove the microSD card completely and when I power back up the basemap is still displayed. (On my 76CSx, there's actually two maps built into the unit - the regular (road-oriented) basemap, and the Americas Marine Point basemap. Both of these are always present even when the microSD card has been removed.) Not sure what's going on with your card. When I first put my new 1GB microSD card into my GPSr, it powered up normally - no "Drawing" message, no freezing/lockup. I was then able to hook the GPSr into my computer and download the City Nav and Topo maps via MapSource, just like you were expecting to do with your GPSr. Do you have a microSD or SD compatible drive on your computer that you could use to look at your 512MB card? I'm wondering if Windows (or whatever your favorite OS is) can access the card, and/or if it'll think the card is unformatted? "TransFlash" is just another name for "MicroSD". If I remember my geek history right, "TransFlash" was what SanDisk called this particular form-factor before their design was accepted by the SD Card Association as an official SD card standard, at which point it became known as "MicroSD". Same electronics, just a matter of whether a card was manufactured before the SD Card Association officially "blessed" SanDisk's teeny-tiny design or after the blessing.