SnoWake

Team Blis- I have not had this experience. In fact - quite the contrary. First, I loaded up just under 2K caches - and was impressed by the unit's responsiveness, both startup and operationally when viewing cache data, etc. Cache icons are displayed on the map at varying levels (if set to Auto, which seems to work now), or always (if set to a max zoom level like 500miles). So, just for kicks - I decided to up the ante, a bit. I pushed all caches within a 50 mile radius of me, here in the SF Bay Area - which was just shy of 5K caches. Imagine my surprise when not only did it work -- but the performance was still snappy! This 5K worth of caches in contained in a GPX file that's over 24MB in size. I'm going to crank it up one more time - pushing my entire 11K NotFound database - and see what happens. Interesting: with 11116 caches pushed to the unit (via a single GPX file generated from GSAK, limited to 5 logs per cache), the unit definitely took noticeably longer to start up. Once it did - at first glance, I thought it actually WORKED - I saw caches on the map. But then, I realized - it was the same ~5K of caches I had loaded previously. Perhaps, this huge GPX file (over 54MB) failed to parse, on startup - and the unit simply defaulted to displaying what was already parsed and loaded into the Current.GPX file? Just as an experiment, I've removed Current.GPX, leaving my 54MB GPX file in place. Upon restart - I was surpised to find the same 'subset' of caches displayed. Looks like, given my current location and surrounding cache density - that I can load everything within about a 32 mile radius, or... whaddya know: Right around 2K caches. Guess those firmware release notes were not only specific - but correct! It's interesting to note that you can (or, at least, I'm able to) push a larger GPX file, but only the first 2K caches are parsed and displayed.

Just one guy's approach - but, after answering the same questions over and over from caching friends - I finally took the time to document my paperless caching approach. As documented, it involves PQs from geocaching.com, GSAK, CacheMate, and a 60CSx - you'll find my paperless caching wiki here: Paperless Caching Wiki Again - depending on your own needs and approach, your mileage may vary. Hope this helps, and I welcome any feedback on the resource. There's still lots of details that need to be added, and most importantly - the Colorado had just turned all of this on its ear, so my personal processes are evolving daily. Have a great day, Billy

It just struck me: GO$Rs must be frantic right now, updating the FAQ and Issues list! I think it's an incredibly valuable resource, to both owners, perspective owners, and even Garmin - so I say we keep it going. I've already seen some great confirmations of functionality, new features, and fixes in this thread. We should all 'pitch in' and try to help GO$Rs out by providing whatever updated details we can determine. Peace, Billy

Just got home from a LONG day in the city, and decided "Eh, why not check out what's up on the forums? But first: My daily ritual of checking the Garmin D/L page. What's this? New Firmware? Over here to the forums, where I see this thread. I start reading, and downloading, concurrently. Just finished the thread, and noticed that WebUpdater is complete - time to unplug, reboot, and feel the LOVE... While it took a little longer than I might have liked for this last release - they certainly incorporated more fixes than I anticipated. And it should just keep getting better from here. A bit concerned about at least the one report of increased crashing: Anyone else experiencing this? I'll be sure to report any 'increase' (while I wouldn't consider crashes frequent - they are definitely MORE frequent than, say, on the 60CSx under comparable usage). Software Loading... (Can't WAIT to see these reduced startup times) Loading Maps... (Can't WAIT to experience snappy response from viewing geocache data) Loading waypoints, routes and tracks... (Can't WAIT to load up 2K caches - and have the unit function!) I hate to disagree with a previous poster - and, nobody would be happier to be lugging around an entire SF Bay Area GPX file w/ 10K + caches... but: I really doubt the 2000 cache limitation is "arbitrary". If, by that, you mean to say that there's AMPLE storage on the device (and argument we've all had for years - what, I can put 2GB worth of maps in here - but I can only have 1000 waypoints?!)... then, I whole-heartedly agree. However, I suspect the 2K cache limit is an actual technical, or implementation issue. They've got to be building databases, and indexes, and loading arrays of information into memory... Again: I want 'unlimited' cache storing potential, as well - and agree that they should make it a priority to continue to increase this as the tune and optimize the software... All I'm saying is, I don't think the current limit is 'arbitrary'. I'll also say that 2000 in enough caches for MOST applications - even power cachers. When I went to Florida recently, I ran 4 PQs to cover the areas in/around Tampa where I'd be - and DID have to selectively load "the best 1000" for each day's excursion, based on which direction or how far away I was heading. But with 2K caches "in-unit" - this will meet most of my caching needs. Of course: more is ALWAYS better... ;-) WooHOO! It's loaded. Now time to go push some data, and measure some startup and cache viewing times. SWEET.

HAHAHAHA! Perhaps this is precisely the key. What a dork I am - I haven't even tried pulling tracklogs into MapSource (I don't use that app for much other than pushing map sets, typically). I'll have to load the tracklogs into it, and see how they're parsed: Can you then save individual ones (which would still feel like a hassle, compared to the automated process on the 60CSx)? I'm just trying to figure out how I could pull a day or two's worth of tracklogs, for selective use, without having the whole set that's presumably buried inside "Current.GPX"? More stuff to go try... thanks, Marky!

Just to echo this observation: When autorouting, with CN2008 on my Colorado 400t - I DO see street names - pretty much always. Not just for the street I'm turning onto - but for adjacent and intersecting streets, as well. Don't get me wrong: I absolutely agree with the severity of the 'bug', and am not disputing it's existence. Only commenting that under select circumstances, (at least my) Colorado is showing street labels.

Maybe because Garmin didn't want to deal with the legalities and licensing requirements for .gif? Let's here it for .jpg - wonder how the CO deals with .png?? I came across a few caches which would totally lock up the CO - consistently. What I haven't done is identify the specific elements within the page cause the lockup. Once I figure it out, I'll report back here.

So, are we suggesting that this file in the \garmin\remotesw folder conclusively identifies the chipset? As noted, I've got the same "Type M" GCD file - but, it seems from reading through the threads about clock drift, and logging of barometric data when the unit is off - that I think I'm seeing some conflicting 'clues'. On a related note: Do the other hardware differences (e.g. available RAM) also vary, by chipset - or are these unrelated (e.g. you could have more or less internal memory on a 400t with either chipset)? Thanks! Billy

Yes - this one really frustrated me, as well. You'll see that Anders attempted to explain the logic of how the CO saves tracklogs - actually, in several different threads, including this one. I'm still trying to wrap my head around what he's suggesting - but I share the opinion that the way the 60-series does it, generating a unique GPX file, by date - is a feature I'm anxious to see enabled in the Colorado. My reasons vary from pure archival (wonder where, exactly, I went on that day I took the high-speed train from Amsterdam to Paris and then cached my way around the city), to the functional: if I want to geotag photos I took last Tuesday, it sure it easy to go look for the 20080212.gpx file - rather than having to parse through the entire 'current' or archived tracklogs stored in the CO. Yes, let's hear it for bringing this feature to the Colorado!

Greetings, ConcreteInterface. I hear and understand your frustration - but I don't quite share the same viewpoint. With regards to "function the way a $500 should" - I guess it's all relative. I just sank $91K into a new concrete foundation that doesn't SEEM to function any better than the one it replaced (in fact, in some cases, at least cosmetically - less). So - if it's a matter of value: The Colorado does the basic functions of your 60-series, and is poised to replace your $500 Palm Tungsten C you lug around with CacheMate (oh, wait - that's me ;-). You've listed a couple of the current shortcomings of the unit - and of course, there are more. However, you CAN sort POIs by type - to a level even greater than on a 60-series (for example, I can look at just "Solved Mystery Caches", not just ALL mystery caches). That's wicked cool, when out hunting solved puzzles. At any rate - not sure how early of an adopter you were with the 60CS, or the 60CSx - but I had both, very early on in their lifecycle - and each had some pretty major flaws. My 60CSx would lock up completely, and require battery removal, every time I found a cache, went to navigate to the next, and then changed navigation from "off road" to "follow road". EVERY time. I had to adapt my use of the device to avoid that 'feature' -- until they fixed it in firmware. As others have commented - if you're really dissatisfied with the unit, you always have the option of returning it, and spending your hard-earned cache on other things. As for me, I'm really enjoying the Colorado, even with its current shortcomings - and I know, from past experience, that it's just going to get better. I sure would go for (even just an incremental) firmware upgrade - but I guess they're trying to pack as many fixes as possible into the next release. Just one guy's perspective, Billy

I've had some slightly-related difficulties with my Colorado. The scenario was: Try acquiring satellites somewhere with lots of cover (indoors, a parking garage, etc). Then, move to an area with clear view of sky - and the CO just would not lock. It wasn't until it finally 'errored out', and I told it to resume acquiring - that the bars finally started appearing, and in just a few seconds, I had a lock. I'm interested about the time-drift problem. I turned my CO on here in the house the other day - and noticed the clock was HOURS off. I've never experienced this with any of my 60-series or earlier units. Repeating the experiment just now - it seems the device keeps the time of when it was last powered off - until it re-acquires satellite lock. That's absolutely LAME. I still haven't quite figured out how to determine 'which chipset' I have - nor, which one I would want to have. Sounds like battery life, clock drift, barometric pressure logging - these are all things that vary by chipset - but yet, no easy way to determine which is which? I've got an early unit purchased the first day they were available at REI - serial number starts with: 18Z00xxxx Fortunately, my unit doesn't seem to have trouble locking, even when the clock is, for example, 9 hours off - but maybe it will be a different story when I travel. Looking back at a recent trip to FL with the CO, it seemed to behave okay there - but I had only had the unit a couple of days, and was still struggling with its basic operation, data limitations, etc.

Ahhh, yes: The sticky disk. I forgot about that - I've been apprehensive to sticking these things to my dash in the past, but at this point - I don't seem to have another (legal) choice. Thanks for the reminder!

Greetings, webscouter! Interesting. Actually, my experience has been a little different than that - but I'm not doubting what you say. I've charged my BB (a couple of them, over the years - currently, a Verizon 8830e) with methods ranging from a provided 12vdc car charger, a direct USB cable connected to my laptop USB 2.0 port, and a variety of wall chargers (both BB-specific, as well as another USB charger for a Motorola Bluetooth communication device. I never thought to check (or worry about) the current output of the various USB chargers. I just naively assumed that they'd have a common pinout on the mini USB connector, providing 5vdc on VCC. While I know that if a device tries to draw more current than a supply can provide - bad things happen. But - if the charger can provide, for example, 500mA, but the Garmin's charging circuit only wants to draw 300mA - would it really cook the load, or just draw less from the source? Guess it depends on how both sides are built... Anyway, it was an interesting lesson for me to learn, as I've used these things completely interchangeably, in the past. No more - I've got not one, but two Garmin 12vdc adapters for the Colorado (though I assume it would work with a Nuvi, or ... ?). I'll have to see how the Blackberry responds, when plugged into the Garmin USB charger. I'm also going to look at my wall chargers, and see if they have current ratings printed on them. I'm pretty confident that the 12volt charger does not. Thanks for the insight! Billy

Hi Sue! Does "pdxsue" mean you're from Portland? Beaverton is my "home town"... ANYway: Regarding getting both geocaches, AND waypoints, into the 400t: Yes, it's a bit annoying right now: Loading in a GPX file full of geocaches (for example, a Pocket Query from geocaching.com) should provide both the goecaching information, as well as icons on the map which you can visualize and select. I'm sure that will come. For now - you'll have to push the information twice: First, by placing a GPX file (or files) into the device in: [Drive Letter]:\garmin\gpx Next, to get some sort of icons to display on the map - you can create waypoints in a variety of ways. As you mentioned, you can load a GPX file in MapSource, and then send the waypoints to the unit. Alternatively, you can use GSAK and a special macro to generate "waypoint only" GPX files (the won't load as geocaches, but rather, as waypoints - this is how MapSource works under the covers, as well. Alternatively (and this is what I've taken to doing, for now) - you can push the caches as Points of Interest. It's a bit more cumbersome, since you have to use Garmin's POI Loader program - as well as something to create them (again, there's another slick GSAK macro to do all of this - but I realize there's a big learning curve to all of that). I'm sure we can walk you through it, without all the techie/slang - but you'll have to be patient, and explain where you're getting stuck, or when someone describes a process you don't understand. Let us know if this helped answer your question - or if you're more confused than ever. I'm sure that collectively, we can get you up and operational with the 400t, while Garmin works on getting us some updated firmware. ;-)

Greetings, ConcreteInterface! I, for one, am not defending the Colorado - in fact, I think you'll find that I, too, am fairly vocal in expressing my opinion about features that should be there, and aren't. However, that being said: I am a satisfied Colorado owner. Is it perfect? Far from it. Does it do everything my 60CSx does? Nope. Does it do things my 60CSx will never be able to? Absolutely. As a big paperless cacher, my ultimate 'requirements' for this unit are STEEP - if it is to replace my Palm Tungsten C w/ CacheMate. However, even given today's functionality - I'm already doing 80+% of what I use the Palm for - all within a single, waterproof unit. If you've got questions about the various ways you can load information into the Colorado: As Geocaches, as Waypoints, or as Points of Interest - there are lots of threads, both here and in the GSAK forums, as well as the FAQ, which go into all the detail you could want/need. If that seems like too much trouble, you can always continue doing what you're doing: Loading GPX files into MapSource, and pushing them as Waypoints. I believe apersson850 already advised you how to delete waypoints in bulk - and you can do the same with geocaching data, when the device is attached via USB, by just selectively deleting files from the unit. Hope this helps - and don't hesitate to ask if you've got any specific questions.

I didn't see the option when I purchased my 400t. Of course, I already owned CN2008, so probably wouldn't have purchased it even if I DID find it, but... When I found the 'automotive' kit - it only included a 12vdc adapter, and a suction-cup mount for the Colorado. I have two questions / observations about this: A) According to California Vehicle code 26708a, as also referenced directly by Garmin here - a suction-cup window mount is illegal. I've got both a bean-bag dash mount (used most often) and suction-cup mount for the 60CSx - but it appears that only the latter is currently available for the Colorado? What are us California and Minnesota drivers to do? I've got no shortage of 12vdc USB power adapters: My Blackberry uses this 'same' charger. So - the day I got my Colorado - I went ahead and plugged in the BB power adapter... and about cried. It caused the unit to 'glitch', and eventually shutdown. I couldn't understand how the pinout would be so significantly different - but I was really worried I'd cooked the Colorado. Fortunately, removing the batteries "brought it back to life" - and I didn't try plugging in a 12vdc adapter until I obtained the 'auto kit' for the CO which included a Garmin one. Any idea what gives, here? On a slightly-related note: One time, the CO went into 'USB mode' when attaching it to the 12vdc car adapter - but just once. Unplugged the unit, powered it back on, and re-connected - and everything was fine.

I've actually had some interesting experiences, with regard to turn-by-turn auto-routing. One feature I miss from the 60CSx is the 'intersection view' that appears right before the turn. This is because I'm a "north-up" orientation kind of guy (I find having the map "swing around" me very disorienting) - and I realize that with the Colorado, at least in Automotive mode, defaults to "Track Up", so this is less of an issue. Still - I enjoyed the 'zoomed in' view of the upcoming intersection, and your required turn, upon approach. Secondly - and this is what I find very interesting: I was using both the 60CSx and Colorado the other day on a blitz up to Yuba City. Both are loaded with CN2008. Along the way, I made some 'detours', forcing both units to re-route. What I discovered was quite interesting: At one point - the 60CSx and the CO had totally different 'opinions' of the right way to go. This went on for quite some time - with the 60 continuing to suggest "making a U-turn" and heading back to the freeway. I'm really glad I followed the CO - based on the overall route information: The CO was predicting a 5-mile shorter route, with a 7 minute earlier ETA. So - while I've pondered it before - I've never really put much thought into the actual algorithms used in these units (or ANY routing software - Google Maps, MS Streets & Trips, etc). It would appear that, all other things being equal (map data, location, etc) - that the 60CSx has a penchant for freeways. It happened several times during the day - it would want to route me out of the way to get to, or back on, a "highway" - even one like Hwy 99 through the CA central valley (which has plenty of 'slow' sections). Anyway - it was just an interesting observation to see the two units making different decisions, based on the same data.

Using both the 60CSx and Colorado 400t side-by-side in the field for several weeks now - I have an observation, and wonder if anyone else is experiencing the same? Here's the situation: Arrive at a cache. Using the Colorado, I DNF it, just zero'ing out in the middle of the grass. So, I grab the 60CSx from the dash, calibrate the compass in BOTH units, and then hold one in each hand while I search. I'm very familiar and comfortable with the 'refresh rate' on the 60CSx. Both the compass, and distance, seem very 'dynamic'. However, it would seem, on the CO, that this information is either 'refreshed' less often, or the unit simply lacks the calculation accuracy (I seriously doubt the latter). Holding both units straight out in front of me: As I walk, the 60CSx shows the distance to cache changing rapidly - while the CO seems to have a 'lag'. Similarly, as I turn, the compass arrow on the 60CSx tracks with the movement - whereas on the CO, it seems more 'jumpy'. Not wrong, per se - just... less frequently updated?? Anyway - just an observation from using the two units together. I know there's been LOTS of discussion around the compass - but this seems a bit different. Anyone else notice anything like this?

While I agree that this is way too low - I only wish that I was sharing your same experience, with all caches (assuming a dataset of less than 1000) were appearing in the Colorado. I've written extensively about my experiments - mostly over in the GSAK forum, as that's the tool I typically use for exporting data to my CO. I found your description interesting as to how you confirmed that all the caches were showing up. I've tried both loading up the unit with a single GPX file (containing < 1000 caches) - as well as pushing hundreds of individual GPX files (per Marky's Performance Experiment. The latter results in dramatically improved performance (response time of the unit when selecting and viewing geocache data, reading hint, etc). However, this approach (pushing, for example, 250 individual GPX files) results in lost data - and, it seems to vary by application. For example: Yesterday, I pushed 200+ single-cache GPX files "closest to home" - and my spot checks of data seemed to show that all the caches appeared (though I was less thorough than what you describe above). Contrarily - when coming home from Tahoe the other day, I pushed 244 GPX files, that "lined the route" (within .5 mile of the arc between Tahoe and the Bay Area). When the unit started up, and I went to the nearest "geocache" - it was over 78 miles away. I had loaded an identical set of POIs, for comparison - and there was a whole slew of caches missing - even though I was WELL below the 1000 cache "limit". However, I pushed a single GPX file containing these same 244 caches... and all seemed to be included (though again - I was less thorough in my evaluation of that - but I can say that the 17 caches I 'sampled' on the drive home, spread across some distance - all appeared to be in the unit). Unfortunately, I suffered the performance lag that accompanies large geocache datasets (at 995 caches, the performance hit is almost unbearable). I'm still working the 'experiment', and trying to determine what criteria cause caches in GPX files to 'not appear'. I'm reporting my results either here, or in the Performance Experiment #1 thread, or in the GSAK with the Garmin Colorado thread, depending on the nature of the experiment and findings. Thanks for sharing your 'verification process' - I think I'm going to try it, both for a 'cluster' of caches around home (of varying sizes), as well as 'caches along a route' (which seemed to yield quite different results). When is that new firmware going to be delivered? Has Garmin learned nothing from the Internet, agile development, and iterative releases ala Flickr, Google Maps, etc? Just give us what you've got - at least, assuming it doesn't make things worse. If there was a formal beta testing program, I'm sure many of us would qualify, and be willing to 'take one for the team' with buggy software, and document and report our findings. I was so encouraged when the first firmware update was released within days of purchasing the unit - but now, it's been close to a month since the last release. I remember some pretty significant bugs in the 60-series (and, as just a gentle reminder - I had my 60CSx "lose it's mind" the other day while out chasing #6K - suddenly, while driving down the freeway, it threw a 'route calculation error - no route to destination' - why? Because it had suddenly 'lost' all its maps. In my experience, the only recovery from this problem is a power cycle). I've said it before, but - I, too, and a very satisfied 400t owner. I've been trying to use the unit exclusively, though I have kept the 60CSx with me - trying to leave it behind in the car when I go after the cache, though. I've been successful in this in all but a few cases. That reminds me of another issue - but I'll create a separate post for it.

So, I tried to take Marky's original experiment a few steps further, in trying to identify limits/thresholds. Once I finally managed to cobble together a GSAK macro to walk through a database and spit out a unique GPX file for each cache - I was ready to experiment. So - Marky determined that with 1900 caches - either in one large, single file, or as 1900 individual GPX files - resulted in 'data loss' (e.g. caches that were pushed to the unit, not appearing under 'geocaches'. Trying to identify the limit, I tried some tests with a dataset of 990 caches. First, I pushed them as a single file (which I've been doing since I got the unit) and was surprised to find that there were caches missing (I hadn't experienced this in my day-to-day use). BTW: My 'test' for quickly determining if all caches are appearing is this - I push the same dataset as POIs (which seem to have no problem with tens of thousands of points). Then, I go to "geocaches", scroll down the page a bit (say, to the 10th cache, listed by distance). Then, go to the Custom POI database, and list the nearest points - and I see that the cache I selected is more like 20th on the list. I can identify specific caches from the POI list that SHOULD be shown in the geocache list. Okay - so 990 in a single file is a dropping data. So - I then pushed 990 individual GPX files. This takes some time - best to be done the night before. You sure don't want to be waiting to head down the hill from Tahoe for a blitz through Reno while this process crunches (about 45 min). Once completed - I found similar results. What I didn't determine was if it were the exact SAME caches missing from the list. Nonetheless, there were plenty of gaps/missing caches. On the other hand - once the unit finally booted up, the response time when viewing geocaching data was, as Marky observed at the beginning of this thread - impressive. Cache descriptions loaded within a second - the type of performance we've come accustomed to. So - 990 was too many. I then pared back my dataset even further: I repeated the experiment with just 203 caches. Once more - both the single file, and 203 inidividual GPX files, both resulted in missing cache data. :-( Let's see what happens when the next firmware release hits - and in the meantime, I'm going to try some more detailed experiments to see if there are particular caches that won't load - e.g. some special character in the description or logs that is choking the parser, or ??? Just a quick report out - I'll post any further findings as I make them. Have a GREAT day! Billy

I'm also running 2.3 / 2.6, and have the same file, 006B073300.GCD, in my RemoteSW dir. As noted, it contains strings like "MKTGPS". My unit's serial # 18Z001078.

Yet another happy 400t owner, here. I almost wrote 'satisfied' - but, as noted (and discussed at great length, in various threads) there's still a lot of fixes to be made. None the less - coming from a LONG line of Garmin GPS receivers, and caching with first a Vista, then a 60CS, and prior to the Colarado, a 60CSx. I'm emphatic about my paperless caching - and while the unit still needs a fair amount of work in this area, I've already used it extensively, out in the recent rains, while my Palm Tungsten C stays nice and dry in my pack. Yes - definitely a Happy 400t owner. And, when I think back to some of the bugs that would crash the 60-series units when they were new to market - past history makes me confident that Garmin will follow through, and make rapid improvements on the 'must fix' list (geocaches not showing on map, no way to mark as found, etc), and some of the nice to have requests - and they'll probably surprise us with a feature or two we might not have considered. Now then - when IS that new firmware going to be delivered, that Marky and others experienced on the demo units at the recent Saratoga Meet and Greet??

I would concur - that's how it behaves for me, as well. But then again - that's exactly how my Cx and CSx operated, as well. Calibrating the compass was pretty much an 'every time you get out of the car' activity - which means, I didn't do it very often. Typically only if I got to the cache site (or a particular trail interesection, or ...) and decided I needed the compass to point me those last few feet, or towards the right trail, etc. I haven't specifically noticed the compass going wacky at low power levels - though, I wouldn't be surprised, given the other power management uses. Maybe Garmin decided to cycle the compass on and off with a 50% duty cycle, in an effort to conserve power (similar to the backlight, or "battery saver mode" in the 60-series).

Just wait until the next update. The performace of the units at the REI event was awesome. --Marky I eagerly await it's arrival, with baited breath!

I've been bouncing around using Waypoints (coming from the 60-series, this is what I was most comfortable with), then POIs, then both - and now alternatively one then the other. At the same time, I'm putting the unit through a variety of paces: auto navigation, hiking, navigating from one point to the next, etc. There's one additional difference, which may be irrelevant, but I thought worthy of mentioning: There are additional 'facilities' for managing waypoints, as opposed to POIs. It's a separate, dedicated list, as well as a dedicated bit of functionality ("Waypoint Manager"). FWIW- I'm using the "GarminCsvPoiExport.gsk macro, v1.8, and successfully generating 11K POIs each with the respective GC.com icon, by type. This macro optionally generates additional 'hint' POIs. Oh, one last comment, since I was catching up on a lot of posts on this thread. I share Marky's opinion about the choice of button label. "Spell..." ? Certainly, I knew what it mean, and it was more concise than "Find by name" as used in the 60-series, but... c'mon. I dunno - perhaps my usability designer fiance would tend to disagree with us, Marky. Ever read Cooper's book "The Inmates are Running the Asylum"? I think you and I (and likely, most of us in this forum) fall into a particular category... ;-) Thanks SO much to everyone for all the shared research and results. I think the trade-offs between initial load time and performance are very interesting -- if ONLY it weren't for the 'missing caches' phenomenon. Marky, with regards to your question: I don't know if it would be useful to the guys at Garmin - but it would certainly be useful to the community at large, if we knew there was a certain threshold after which, we would start losing caches. I've pushed single GPX files of < 1000 and my random sampling has shown that I've got all the data. However, performance is less than ideal - and that 20-30 second lag can feel like an eternity in the field - especially, if you have to suffer it several times. I'm keeping a careful watch on this thread - and will contribute back any additional tests or findings. Thanks!