george_k

I've used quite a few of those lanyards and badge holders over the years and I haven't broken one yet. I figure the plastic mount on the Colorado is gonna go first, since you have to take it off every battery change and when you use a R.A.M. mount. However, I mostly carry my GPS in hand with a small microfiber camera lens cleaning cloth attached to the plastic badge holder. The lanyard sees very little actual neck use. Hi Glen, I use a lanyard, too. My setup looks almost identical to yours, except that instead of the plastic badge holder piece, I just left on the original nylon strap that came with the Garmin plastic mount. It seems like that is much sturdier than the clear badge holder piece, and you don't have to worry about that snap coming undone. The only advantage I can see with the clear badge holder piece is that it is easy to snap on/off. However, I notice that your setup (like mine) has a spring-loaded latch mechanism that came with the lanyard, so that should suffice for that purpose. So I'm just curious -- why did you choose to go with the clear plastic badge holder piece in place of the original short nylon strap that came with the plastic mount? George

I'm continually amazed at the number of people that swear off the compass - both on the 60 series and the CO. I never have problems with the compass - simply make it a habit of calibrating it each time you change the batteries, and you should be good to go. Hey... finally! Someone else who also has been having consistently good experiences with the compass. I'm also amazed by how many people seem to dislike it so much. I posted about my positive experience with the compass before on a different thread, but have been laying low since then, since it seems like there are so many more people who dislike the compass than like it. I was beginning to think I was the only one who uses the compass all the time. Anyway, I just wanted to chime in that the compass is not as unreliable as one might be led to believe. I encourage people to give it a try (or second try). You may find you actually like it... Regards, George

I don't know if it's common, but I have seen others mention it on the forums before. I have personally never experienced it, but I may have been lucky in that I was a relatively late adopter, so by the time I got my Colorado, any earlier hardware or firmware problems that may have existed might have been worked out. I always have the compass enabled, because I don't like having to rely on the GPS for direction, because in order to allow the GPS to provide direction, you have to be moving at some threshold speed. I personally don't want to have to worry about whether or not I'm moving "fast enough" to get a correct reading. Therefore, I prefer the built in electronic compass. So what I do is: 1) As the instructions say, I *always* calibrate after replacing batteries. 2) After calibrating, I do a "sanity check" by bringing up the compass display, and making sure that it aligns properly (i.e. knows which way is north). For me, once I calibrate, it seems like it stays "in calibration" for the life of that pair of batteries. BTW, I'm using Sanyo Eneloops. I only mention that, because I don't know how well the Colorado maintains a steady voltage in the face of gradually declining battery voltage as the batteries discharge, so some brands/types of batteries might have a different discharge "profile". 3) As I do each geocache, I'll be aware of whether the map display, the north pointer, etc. is properly aligning itself as I move about or otherwise turn the unit, making sure, of course, that I am holding the unit level. Remember, as long as a) the geocache coordinates are accurate, your GPS is giving you an accurate position of where *you* are, and c) your Colorado is aligning itself correctly (knows which way is north), then your pointer to the cache should work. So far, as long as a, b, and c have been good for me, the pointer has never failed me, yet. George

Thanks for the suggestion, but I did try that map (and one other free one, too), and it's not bad for free, but unfortunately, it doesn't do auto-routing and I found that in several areas (including right where I live) there was a position offset between where the streets actually are and where the map was showing. So that's why I broke down and bought the 24k scale CA/NV map. So far it seems like the roads are spot on with this product. Thanks, George

Long answer short, NO!!! You can show more/less detail, but you will lose minor road detail as you lose contours. If you want to see only roads, you'll need to load a road only map such as City Navigator. Aw, man! Not what I wanted to hear, but thanks for answering the question for me and saving me from more fruitless searching for a non-existing capability... Thanks also for the tip about using CN, but I was hoping to get by "on the cheap" by using the Topo U.S. 24k (California and Nevada version) map, since it's just about perfect for my uses (I rarely travel outside CA, do mostly geocaching and hiking, and some road navigation. This product has detailed roads and auto-routing like CN (only for two states though) and the higher resolution contour lines for hiking. I guess I'll just learn to live with the slower redraw... Thanks, George

Hi all, I searched the forums, and I read all Colorado threads pretty religiously, so I hope this hasn't been answered already. Please pardon me if it has. My question is: Is there a way to disable the topo contour lines from the map display? When I'm in the automotive profile, I don't really care about topography, and I would like the display to redraw as fast as possible. For instance, sometimes I let the unit compute a driving route, then I want to scroll around to see which streets it has picked. If it's a fairly long drive, then I usually zoom way out, scroll over, then zoom back in near the destination area. In particular, the zooming out and scrolling while zoomed out seem to take forever to redraw on my Colorado 300. I was thinking that disabling the topo information would be one way to speed things up. Of course, any other suggestions for speeding up map re-drawing would be appreciated as well. I'm using: - Colorado 300 - 2.7 firmware - basemap disabled - Topo U.S. 24k (California and Nevada version) enabled Thanks, George

Since the majority of the world uses metres (sic) I chose to make this the default. At present you can change this to feet by projecting a waypoint and selecting the "feet" option from there - not entirely obvious I grant you. I might enhance the cartridge to provide a setup facility as well to enable you to select your preferences. Obviously metres/feet is one that would be of interest - what other preferences would people find most useful? It would be nice if I could figure out how to get the preferences from the host GPS itself but that is probably device dependent and therefore not practical. Geofellas, Nah, leave it the way it is. You're right, the majority of the world uses metres (or meters, as Americans like to spell it). Considering that even the British themselves have largely switched away from "English" units, yet Americans stubbornly still cling to this archaic system, I think you should "force" Americans to adapt! Besides, meters are almost the same as yards, which Americans are comfortable with. BTW, lest I be accused of being an "America basher", I am an American (just one who is embarrassed that we haven't gone metric like most of the world). George P.S. Geofellas -- Nice bit of "thinking outside the box" on your clever Wherigo solution! As a software engineer, I wish I would have thought of that...

Actually, I believe that the only reason you can see shaded relief on the 400t is that it comes preloaded with the Topo U.S. map that includes the DEM data. Other than the internal memory difference that Storm180 mentioned, the hardware and software for the 400t and 300 should be the same. The WA/OR 24k Topo map that the OP mentioned also provides DEM data, so even with the 300, you should be seeing shaded relief for those two states (not the rest of the U.S. though, because I think that the base map that comes with the 300 does *not* provide DEM data). George

I understood and wasn't questioning the need to recalibrate after a battery change. What I was trying to learn was whether after the batteries are changed and before recalibration if you experience/see errors of 90 to 180 degrees or not? It sounded like you didn't and if that is true then maybe Garmin still needs to tighten up something in the software if these wild errors could be eliminated? (If I'm beta testing Garmin's Colorado at my expense I'm going to be anal about it.) Hi Ratsneve, Okay, I think I understand what you were asking now. To answer your question -- I have never even had an opportunity to witness an error of 90 to 180 degrees of error prior to a recalibration, because out of habit, I *always* recalibrate immediately upon inserting new batteries. I figure it needs to be done for every battery change, so why not take care of it right away so that later I'm not out doing geocaching or whatever, and should the compass start acting up (which, BTW, has not happened to me yet), I won't have to wonder to myself whether I had remembered to recalibrate on this set of batteries or not. Yes, I'm very anal about these things, too... George

Hi George, It sounds like you are saying that even after you replace the batteries but before you calibrate your 300 you never experience this 90 to 180 degrees off situation? ...That calibrating just gets the compass spot on regardless of what the voltage changes occurred from changing out the batteries? No. Sorry if my wording made it sound that way, but what I meant is that I always calibrate the unit immediately after a battery change, but then once I do, I don't find it necessary to do it again until my next battery change. And, during this period, I do not experience any 90 or 180 degree off situations. I always calibrate immediately after a battery change, because I figure if Garmin says in its manual to do so, and everyone in this forum seems to concur that it's a good idea, then it seems like the prudent thing to do. George

Hi Ratsneve, Just another data point: I have a Colorado 300, serial number 169053xxx, and so far, the compass seems to work fine and has never given me any false readings (at least not anything noticeable like 90 or 180 degrees). I just need to calibrate it after a battery change, and then regardless of how many times I turn it on or off after that, the compass continues to read accurately until that set of batteries goes dead. When I calibrate, I try to do it away from electric/magnetic sources. So I don't ever do it in my car, because of all the electrical/electronics systems there, and also, since if you think about it, you're in a sort of partial Faraday cage, so even if there wasn't stuff *in* the car to mess you up, you might not accurately detect the magnetic field coming from *outside* the car. In the house, or outside, I also try to be as far from electro-magnetic sources as well. Then after I've calibrated, I do a sort of "sanity" check by holding the unit level and rotating it around a bit to see if the compass aligns itself appropriately. If it does, then it seems to hold those settings for the life of that set of batteries. Finally, I have a theory about what might be causing problems for some people. Note that this is only a *theory* based on my own knowledge and experience. I've actually written software for calibrating two-axis electronic compasses before, and although I don't know if the one used in the Colorado is the same, the "spin around two times" method, which we also used, makes me suspect that it is at least similar. Anyway, the method I used to calibrate a compass (using the recommendations of the part manufacturer), was to simply sample the readings for each axis and save away the max and min readings for each axis while the unit was being slowly turned two times. Then you just adjust these max and min readings so that they are centered around zero. For instance, if you got reading from 2 to 22, you would treat that as the range from -10 to +10. Also, you would scale the reading from the two axes so that they both would fall in the exact same range. Then later, when you are reading the compass to try to determine your heading, you just take your two measurements (one from each axis, and adjusted so they would fall between -10 and +10 in this example) and do a simple arctan calculation. The reason I'm explaining this is that since it involves getting a max and min, skewing the range, and also scaling, I was thinking that if the voltage to the compass was not constant, it could throw off the readings. Numbers that were stored and calculated might be valid right after calibration, but might not yield valid results later. For instance, in my example, where the min and max were 2 and 22, respectively, what if later on, when the batteries are weaker, you only get readings in the range 2 to 15, or something like that? The numbers that were stored earlier for skewing these values to center them about zero, and for scaling them to make the two axes' readings consistent with each other, would no longer be valid. The bottom line would be: How good is the voltage regulator in the Colorados for maintaining a constant voltage to the compass as the battery voltage changes over time? With that in mind, I will also add that I am using Sanyo Eneloop batteries, so maybe they provide a more constant voltage? I have no idea if my theory (changing voltage affecting compass readings) is right, and I have no idea whatsoever as to which type (alkaline, NiMH, hybrid NiMH, etc.) or brand of batteries have what sort of profile as far as voltage variation goes. I just thought I'd throw this out there as a possibility. Regards, George

Ahhh... that explains it -- thanks! The name "topo" threw me off. I thought that the topo map only provided topographical information (i.e. those elevation line things). I didn't realize that it also included extra street details. Thanks for the clarification -- it was driving me nuts trying to figure out whether I had to tweak a setting or if perhaps I was missing some file(s). Thanks, George

Hi all, Forgive me if this has been answered already. I've been reading all the Colorado threads for months, so I hope I didn't miss it. Also, I couldn't find the answer on g-o-casher's website. M2 in the Maps section doesn't seem to indicate any difference in the level of detail of the "base" map. Anyway, a friend has the 400t, without any City Navigator software -- he just has what came in the 400t box. Likewise, I have a 300, also nothing extra (just what came in the box). The 400t shows much greater street detail -- i.e. it shows all the residential streets. My 300 only shows the major streets (around here, in L.A. and Orange Counties in CA, that means the streets on a one mile grid), and none of the residential ones. I only see the orange colored main streets, but none of the grey colored minor (residential) streets. Is something wrong with my 300? Am I missing some map files or something? I just got my 300, and haven't loaded or deleted anything, yet. In fact, I have not even connected it to my PC, yet. Do the 300 and 400t have different detail levels for city streets? BTW, I did find the options that let you specify the level of detail for the maps. It started at "Normal" and so I bumped it up to "Most". I tried this from both the Automotive profile and the Geocaching profile. I am running software version 2.50 (that's what it came with). Okay, I just hooked up the unit to my PC, and see that the main map file, gmapbmap.img, is about 93 MB. Any help would really be appreciated. Thanks, George

Yeah, I'm disappointed at how long it's taking to fix the location problem, too. I'm still anxiously waiting so that I can buy a Colorado as soon as I know I'll have something that gives me a reliable position almost all the time. However, I suspect that it is neither a hardware issue nor a Garmin firmware issue. I believe it is most likely the GPS chipset firmware. Given that Garmin appears to be switching over to the MediaTek chipset in more and more products, hopefully they will forward the various problem reports from the customers over to MediaTek and perhaps apply some pressure on MediaTek to upgrade *their* firmware. That's why more than waiting for a replacement for the 2.51 beta firmware, I am more anxious about an upgrade to the 2.6 MediaTek firmware. When that comes out, and it starts getting confirmed that position is much more reliable, that's when I'll take the plunge and get a Colorado. I can live with the other minor issues left in 2.51, but I think I would be extremely annoyed if I couldn't rely on the position. George

Wow, that *is* a good price -- please share with us where to get that deal! Thanks, George

Is it just me or do you guys find it odd that there is no info about 2.50 on the website, and also that when you use the webupdater, that it doesn't download and install 2.50? I mean I can understand webupdater not grabbing 2.51, since it is a beta release afterall. But if 2.50 is what is being shipped in all the new units, then why wouldn't Garmin want to make it so that webupdater will install that onto the units that the earlier customers bought? Doesn't the fact that Garmin is shipping 2.50 with new units imply that it is a "stable", released (not beta) version? Just wondering... George

Those things all contribute to the position error. I get that part. How do you assign a number to atmospheric effects, for instance. The EPE is calculated, not measured, right? Yeah, I never thought of it that way, but I guess I would agree that it is calculated more than it is measured. Hmmm... I have to think about that one... Atmospheric delays are usually based on models of the ionosphere and troposphere. Like most models, they represent an idealized situation. Some parts of it are fairly easy to model, like the fact that a signal coming from directly overhead goes through much less atmosphere than one coming from near the horizon. It would probably also be fairly easy to model the higher density of the air closer to the ground compared to higher altitudes. Also, in the case of the ionosphere, the delay is greater during the day than at night due to the amount of ionization going on due to the sun's rays. Right on the boundary between night and day is where it gets complicated, and the models tend to give less accurate (less predictable) estimates. Therefore, a good ionosperic model might give a higher error estimate if the signal is passing through this "twilight zone" (hmmm... I wonder what Rod Serling would have to say about that? ) compared to a signal during the middle of the day from a satellite directly overhead. This would reflect that the atmosperic delay is more difficult to estimate accurately under these conditions. That's about all I can recall, but I'm sure you can search the internet for much more info on ionospheric delay, URE, EPE, etc. There should be a wealth of info out there. Regards, George

My understanding is that the GPS only knows the distance from a sat which puts you on a sphere around the the sat. Two sphere intersect in a circle. The third sphere intersects the circle at two points and the forth gives you one point. In other words spherical geometry is used, not plane geometry. Also, I thought EPE is calculated by "3) geometry" only. The algorithms used are protected secrets so we will never know for sure. I just felt that they picked the best 4 sats and stopped. It is only a wild guess. You have to admit my guess would explain why turning the power off fixes the problem. The GPS is forced to pick new sats. The solution you describe about the intersecting spheres is the "classic" way that solving a GPS solution is often explained. However, keep in mind that it is used to explain why 4 is sometimes considered the minimum number of satellites required to get a 3D solution. In actuality, you can usually get a 3D position with only three, because once you get it down to the last two points, one is usually not on the surface of the earth and can often be eliminated. However, I digress... Whether 3 or 4 satellites is the minimum required, every GPS receiver I've ever heard of will use all possible satellites that it can (within channel and processing limitations, of course). Generally speaking, whether you're using a Least Squares or Kalman Filter (or something else), the more measurements that you can incorporate, the better your accuracy should be. Also, remember that if you only use the minimum number of satellites, it makes it near impossible to determine that one of your range measurements is "bad". This is because it makes it difficult or impossible to determine that one of your measurements is inconsistent with the others. Your solution will tend to look "perfect". By "over solving", you can determine that one or more measurements is inconsistent with the others, and thus eliminate it from the solution, or perhaps give it less weight in your filter. Also, EPE is not based on geometry only. It also includes User Range Error (URE) and User Equipment Errors (UEE). These include atmospheric effects, errors in ephemeris data, clock errors, multi-path errors, signal noise, and other things. George

I know this is an old post, but I was linked here from another thread. Has anyone thought of the why the EPE is bad? Don't they base the EPE of the four sats they use for the calculation? The sats move and the sat directly above is totally worthless. Maybe that sat was picked before it moved and not thrown out when moved straight up. I wish they showed the constellation they use and not just all of the sats they see. Although you need a minimum of 4 sats to get a solution, I believe most (if not all) GPS receivers will use every satellite that it sees (assuming of course it has enough channels to accomodate them all). Also, the satellite directly overhead is *not* "useless". In fact, if you have only 4 satellites available, then supposedly the optimal constellation would be three satellites near the horizon (120 degrees apart), and the fourth satellite directly overhead (thus forming a tetrahedron of sorts). Another "rule of thumb" way to look at it is that you can think of each satellite being at the vertex of a polyhedron, and the more volume that you can enclose with this polyhedron, the better the GDOP, and hence the better the EPE. Of course, if you have more than 4 sats, you form a larger, more voluminous polyhedron. As to your question about why the EPE was bad, your guess is as good as mine. It could be a lot of things: 1) WAAS corrections not available for all or some sats 2) Low satellites, although often good for geometry, sometimes bad for having the most atmospheric delays. Also, low satellites can give the worst kind of multi-path error -- the ones where the bounced path is only slightly longer than the direct path, thus making it harder to detect as a multi-path measurement. Often the larger multi-path errors (like bouncing off a building on the opposite side of the GPSr from where the satellite is) are easier to detect and throw out. 3) Bad geometry 4) Weak signal from foliage 5) etc.... Regards, George

Hi SimbaJamey, Yes, that is helpful. Those are interesting numbers for the EPE comparison for horizontal versus vertical positions for the Quad Helix antenna. Based on that, I think a good way of homing in on caches would be to use the compass (holding the unit horizontally, of course) just to get near -- say within 50 feet or so. Then after that, perhaps ignore the compass, switch to holding the Colorado vertically (to get the better EPE), and just use the old "tried-and-true" method of going one way, observing if your distance to the cache goes up or down, backing up when the number starts increasing, then changing directions to a different axis and repeating -- i.e. just home in without the compass. Thanks, George

Hi everyone, Thanks a lot for all the feedback. LifeOnEdge, Regarding your advice regarding "If you're anal..." -- yeah, I probably am a bit anal, but I don't think I'll go to the extreme of mounting the unit on a pole (or even my idea of an external patch antenna). However, I probably will try to keep the unit as unobstructed as possible. Probably just higher on the body or in a backpack or fanny pack. I'm sure that even at belt level, I won't ever lose position completely, but I figure the more satellites in view, the solution should be that much better (better GDOP and all...). I just want to avoid getting track logs where the trail has portions where it "skews" for a while, and then later snaps back to a more accurate position. Thanks again for the feedback guys, George

I've also been wondering about something along the same lines, especially as it relates to the various threads where people have been complaining about poor track log results. When you're not holding the unit in your hand, where is a good place to carry the unit? It seems like clipping it close to your body, say at belt level, would basically cut off about half the sky (sort of like placing the unit next to a wall. Maybe higher on your body? Clip the unit to something at chest level or higher? This might give a little less obstructed view of the sky. Clipped on the top of a backpack would seem ideal, but I usually just do very light hiking where I'm not even using a backpack (just a fanny pack with a bottle holder). The fanny pack might be okay, too, since at least in there, the unit is not *right up against* your body, so again, a little less obstructed view... Finally, how about an external patch antenna? You could place it on top of your shoulder or something. Yeah, I know, this sounds stupid/nerdy, but actually, this is what we did at this company I was working for where we built these little GPS modules for skiers to wear. The unit would just do track logging, which would then get overlaid on a 3-D map after you returned to the lodge. This map was meant to be a souvenir of your visit to this particular ski resort. Any suggestions? What have you folks found to work well for you? Thanks, George

I second that idea! I suggest something like this: 1) Have columns for serial#, f/w version, date purchased, and then separate columns for each known hardware problem. 2) The table would be sorted by the serial# column. 3) For each of the hardware problem columns, you could put: O = no problem, X = problem, blank = not known (not tested) 4) Probably need a separate table for each model (300, 400t, etc.)? Just guessing on this one -- I have no idea how the serial numbers are sequenced. Then, ideally, this table would show in each problem column, many X's near the top of the table, then at some cut-off point (presumably when the problem got fixed), much fewer X's towards the bottom of the table. This way, we could kind of visually see if/when each hardware problem got corrected. The firmware version column would just be for reference, because some of the hardware problems might be "fixed" or worked-around by firmware updates. Date purchased would also just be for reference, too. Does anyone else think that such a table would be useful? George

Hi all, I've been reading all the Colorado-related threads with great interest for a while in anticipation of buying my own soon. I see lots of anecdotal references to serial numbers, as in "mine has such and such problems -- it is serial# xxx" or "mine works fine -- it is serial# yyy". It seems like the general consensus is that some of the earliest shipped units seem to have a much higher frequency of problems reported, although it appears that many good units were shipped early, too. For instance, some have mentioned being one of the first to get one (such as in January) and have a unit that seems to function just fine. Anyway, I was wondering if anyone has collated any of this data and figured out something like "starting with serial# zzz, it seems like all the hardware issues have been resolved". i.e. starting at some serial#, there seems to be hardly any problems reported for these later shipping units. I guess I don't want to go through the same ordeal that many have reported with having to exchange their units (sometimes multiple times) before getting a good one. I want to just check the serial# right in the store, or in the case of an online order, call the merchant and ask them to identify the serial number for me, so that at least I will have decent odds of getting one of the later units. Has anyone figured out roughly what serial# is the "threshold" for when the hardware issues got resolved? I'm particularly interested in the 300 model. Thanks, George

The time drifting would be annoying alright (for instance, if you use the alarm feature). However, it should *not* affect the GPS function, since time is one of the things being solved for (besides your position on 3 axes). The only negative effect from an incorrect internal time would be if it was off enough that it could slow down your initial acquisition of satellites, since it could make your GPSr try to track ones that weren't even visible. BTW, and it's a good thing the GPSr doesn't rely on the internal clock, because every nanosecond would equate to roughly one foot of range measurement error. George