## Recommended Posts

When I looked at the satellite page I was surprised to see the EPE in the 70-80' range. Based on my previous tracks I would estimate my position error was off by more than 300' ! At that point I stopped for a few minutes to see if things would settle out but there was no change. I had good strong lock on 7 satellites with one directly above, 3 at ~45 degrees and 2-3 closer to the horizon. I put the GPS in demo mode several times to see if that would bring it out of its funk but I got exactly the same results. Finally I power cycled the GPS and when it came back on I had EPE of 18 and the constellation/strength readings looked identical to me. My position on the map relative to previous tracks was exactly where I thought I should have been.

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.

4) Weak signal from foliage

5) etc....

Regards,

George

Edited by george_k

i am able to find the same BUG (not only one time, but it is not always)

my setting:

Compass off

WAAS off

Tones off

Altimeter on in variable altitude mode

NORTH up

Backlight limiting off

Displaying map continuously, with EPE and Battery

gps holding in hand during running

eneloop 2000 mAh 4 bars Battery-Symbol

detail info here: http://forums.Groundspeak.com/GC/index.php?showtopic=195145

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.

4) Weak signal from foliage

5) etc....

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. Edited by John E Cache
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.

4) Weak signal from foliage

5) etc....

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

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

Here’s my bit of totally baseless speculation:

As well as making their own GPS chips for some models (including the Colorado series, I believe), Garmin uses a number of different 3rd party suppliers for their GPS engines, including Sirf, Mediatek, ST Microelectronics, etc. Different chips are used in different product lines, but I imagine it would be a major job (impossible?) to put a Sirf chip in a unit that was originally built around a Mediatek, etc.

Presumably, the GPS engine makers modify their product line from time to time (bug fixes, minor improvements, etc), but if the pin-out and data in/out specifications are exactly the same, the new chip may be totally replaceable for the older one.

Deep down, the GPS engine looks for all the satellite signals it can get (up to a maximum of 12, for a 12-channel receiver), and applies its internal “smarts” to work out your 3D location and current time. This location and time data is presumably generated by the GPS engine hardware and its firmware. The GPSr designers could choose to receive just this processed information and pass it on to whatever device the “engine” is installed in and is “talking” to (e.g. the Garmin handheld GPSr that you buy), and that device can then simply process the output position and time data, treat this as the definitive location, and use that in whatever way it chooses (e.g. plot on a map, calculate a distance and bearing to a waypoint, etc).

OR …

The GPSr device COULD take “deeper” information from the GPS engine (e.g. the actual raw received data streams from the satellites) and do its own post-processing to determine its own location fix, essentially using the GPS engine to do nothing more than capture the signals.

What Garmin actually does in each of its product line is anyone’s guess. I wouldn’t necessarily assume the process is the same on all models – it is conceivable that not only do the more expensive 60CSx series have a more expensive Sirf chip, but maybe Garmin also do more of their own “post-processing” in the unit than on the cheaper Vista HCx with Mediatek chip. (Just speculation, as I said.)

To get a full 3D fix, you must get a minimum of 4 reasonable quality satellite signals. (You are trying to solve for 4 variables, being 3 coordinates, plus one time, so you need 4 inputs.) If you receive more than 4, there are a number of choices that COULD be implemented as to what to do with the redundant data – e.g. just take the four “best" signals, over-solve using all available signals weighted equally, or over-solve but apply some sort of weighting to each signal based on the “quality” of each signal.

However, when things start playing up with your location fix, and especially when this seems to be associated with a recent software or firmware upgrade (and you probably had to install both at once, so it is hard to determine which is to blame), there are several possible root causes:

1. Hardware bug in the GPS engine

2. Firmware bug in the GPS engine firmware

3. Hardware bug in the Garmin-designed hardware which “wraps around” the GPS engine

4. Software bug in the Garmin software.

5. Possibly others I haven’t even thought of

What I find particularly interesting is that various users have reported similar problems with the Colorado, Vista HCx / Legend HCx, and the 60CSx, and the problems seem to have arisen at a similar time frame on previously reliable units (although reliability and performance of the Colorado series is yet to be demonstrated!), even tough these use different GPS engines. To me, this suggests very strongly that the culprit is likely to be the unit software, or possibly the firmware if Garmin writes the firmware for all their units.

What is also interesting is that on the eTrex line, the problems seem to be confined to the Vista HCx and Legend HCx models, but I have not seen any reports on the Summit HC or Venture HC, even though these reportedly use the same GPS engine as their big brothers. (This could be due to the fact that there seem to be a lot more Vista / Legend users out there, rather than any actual difference in behaviour.) Certainly, my Summit HC has not exhibited the problem at all, running latest software, but then it seems the problem only affects SOME (not all) Vista / Legend users too.

Whatever the reason, Garmin is really the only party in a position to resolve the issue, and I think they really need to quickly, or else they run the risk of causing huge damage to their fine reputation. Given that Garmin units have long been extremely reliable, it is a huge shame that so many uses are now discovering that they can no longer rely on their units to give them an accurate position fix.

OK, I see. If the sat is straight up the signal travels through less air than sats on the horizon which means the atmospheric delay is less. This said the EPE still depends on geometry. I'm not interested in the possible external causes for position error. The external error sources are the same for all GPSs. The thing that bothers me is that you can guess at several hardware and software faults, but most suspect faults would not go away if you power cycle so those suspects can be ruled out, in my opinion. The weird thing is that the GPS could know it has gone flaky by just looking at it's EPE.

Some Colorado units, at least, have the MediaTek chipset. This is shared with the HCx. Apparently, the chipset firmware is shared as well. HCx users started reporting the problem when upgrading to chipset firmware 2.60. Colorado users have reported the problem with chipset firmware 2.60, but with more than one version of the device firmware (at least 2.40 and 2.51 beta). Have not seen posts from anyone claiming to have seen this problem on the Colorado with chipset firmware earlier than 2.60. This would appear to eliminate the device firmware as the source of the problem, at least on the Colorado.

Of course, Garmin has yet to acknowledge that there IS a systematic problem -- at least on the Colorado. If you are persistent enough, they will offer an RMA.

In the meantime, power cycle early and often -- and don't depend on the device for backcountry navigation or anywhere else where lack of accurate location information might be dangerous.

...Have not seen posts from anyone claiming to have seen this problem on the Colorado with chipset firmware earlier than 2.60. ...

I have the Problem with colorado 300 and 2.51 beta

...Have not seen posts from anyone claiming to have seen this problem on the Colorado with chipset firmware earlier than 2.60. ...

I have the Problem with colorado 300 and 2.51 beta

That is not the chipset firmware. You probably are running chipset 2.6 if you are running the GPS firmware 2.51beta.

The Colorado was released around 1/18 with 2.5 GPS Software. On 1/23 Garmin made 2.6 GPS Software available.

Given the small number of users who had Colorados at that point combined with the many other issues the unit had, I doubt any of us would have noticed it. It is interesting to note that I started this thread on 2/1 which would have been about a week after upgrading to GPS Software 2.6.

GO\$Rs

Yes,

Beta Software 2.51

GPS-SW-Version 2.60

In the meantime, power cycle early and often -- and don't depend on the device for backcountry navigation or anywhere else where lack of accurate location information might be dangerous.
Good one. I'm sure using "dangerous" will scare Garmin... not. I had another thought. The power cycle does a hardware reset. I wonder if not reseting the hardware and just doing an initialize works. I mean the initialize menu item where you give your approximate position or state and the GPS reacquires the sats.

Good one. I'm sure using "dangerous" will scare Garmin... not.

Wasn't trying to scare Garmin. Either they care or they don't. More concerned with people who might be using the unit in truly ugly situations -- like on the water. A few hundred feet one way or the other might not be just an academic discussion for those folks. And proceeding up the wrong canyon might be more than a minor annoyance for a backcountry hiker.

Forcing it to reacquire the satellites might well work. But depending on how you do it, it might take longer than power-cycling. At least the power-cycle gets you a warm start. I'm also not sure that the menu option is available if the unit (thinks it) has a lock.

I mean the initialize menu item where you give your approximate position or state and the GPS reacquires the sats.

Several times when I've experienced the problem I've tried forcing an Autolocate by turning the GPS off, GPS on and then selecting Autolocate. The problem is that if the CO reacquires lock before you can perform the key presses to get to the Autolocation option it disappears from the menu (some sort of "intelligence" that assumes if you have lock there's no need to force an autolocation).

Toggling the GPS off/on did not fix the issue but I'm not sure that really that does anything to "reset" the GPS software engine, it feels more like a user interface function that just decouples the UI from what the GPS engine is doing.

GO\$Rs

Did just some testing

Problem also exists if BACKLIGHT is OFF

So it has nothing to do with Backlight off or on

I mean the initialize menu item where you give your approximate position or state and the GPS reacquires the sats.

Several times when I've experienced the problem I've tried forcing an Autolocate by turning the GPS off, GPS on and then selecting Autolocate. The problem is that if the CO reacquires lock before you can perform the key presses to get to the Autolocation option it disappears from the menu (some sort of "intelligence" that assumes if you have lock there's no need to force an autolocation).

Toggling the GPS off/on did not fix the issue but I'm not sure that really that does anything to "reset" the GPS software engine, it feels more like a user interface function that just decouples the UI from what the GPS engine is doing.

GO\$Rs

I don't think this is true. Toggling the GPS to off is supposed to save power buy disabling the GPS receiver and reducing the computation in the CPU. However, my guess is it keeps the latest relevant information, so that when the GPS is turned on it will obtain lock faster. Hence, if there is an error in that information, you still have it.

After being frustrated for three months with time and location errors on my 400t SN18z0036xx I returned it and two weeks ago received one with SN 18z021XXX. This week I found 18 caches all with a distance of less than .25 miles. I used the automotive mode to get to the parking and geocaching mode to find the caches. I also had my 60CS to verify the 400t's co-ords. I will not cache without the 60CS until I am sure the 400t is accurate. 18 caches with no deviations. I was a happy cacher. I have since gone to two caches that are over a half mile walk. In both cases the 400t started to diverge at about .4 miles from the parking. I got it to come back to the 60CS co-ords by cycling on & off. After that the walk to the caches was uneventful and the 400t and the 60CS mirrored each other. It is very frustrating not to be able to trust the GPSr to be right. Is that not why we have them? It is apparent to me that there still is a problem. Hope a fix comes very soon.

Anniebananie

So far on my Colorado 300 with 2.51 beta firmware and 2.60 Gps firmware I have not experienced it as of yet. I bring a 60CSx to make sure I do not go off course. So far its been on the money each time. My friend just got his colorado 300 yesterday and we are going out this weekend so I can run the tests with his also.

I've experienced accuracy issues with my Colorado 300 this evening. It may have been coincidence, but it seemed to be related to acquiring satellites. I was walking around some local woods (the larger paths are fairly wide, but the view of the sky is largely going to be along one axis). Here's a screenshot from Google Earth with my track overlaid (yes, I know Google Earth isn't necessarily 100% lined up, but the track log differed fairly majorly from what I've previously mapped there).

I was walking in an anti-clockwise direction. Heading south down a straight track, the accuracy started dropping from around 20ft to about 44ft. I flipped to the satellite screen and noticed it was trying to acquire a satellite that was near the horizon. The signal bar for that satellite was barely showing.

When I got to the end of the track and reached the track that runs WNW/ESE, the signal on that satellite improved and another satellite popped up with a full bar. I stood on the corner and let it acquire one of these satellites and the unit showed accuracy improving back towards the 20ft mark. I then headed ESE and noticed that the GPS track was heading steadily further away from what I'd previously mapped. As you can see from the screenshot it was out by about 110 feet, even though the GPS claimed accuracy was about 25ft.

I carried on walking and after about 10 minutes it all seemed to come back into line with what I expected. I'm not sure if the problem is the unit being inaccurate under certain conditions, or if it's that it's incorrectly reporting its level of accuracy.

WAAS was off, backlight was off.

Edited by Crid

I finally had this happen. Was hiking in marginal reception conditions. Came out into the open. Lots of satellites, EPE showed low, then bang 45 meter shift to the correct location.

GARMIN urgently has to fix the bug -

otherwise GARMIN should take back all Colorado units!!!

Has anybody tried the colorado with an external antenna?

How does the GPS perform with the external antenna, versus it's own internal one?

I find several faults with the Colorado:

1) The size and shape of the antenna should have been properly formed, being taller.

2) To see the screen better, the GPS usually is not being held as vertical as posible.

3) Not having a motion sensor in the unit, the GPS seems to pick up alot of Dirty Data.

- A 3 Axis motion sensor would be a cool thing, but raise the price of the GPS to over \$1000.

- A position sensor would provide a Baseline, of what Signals to accept or reject.

- Also with a position sensor the GPS would not become a Garbage Can of Dirty Data.

As a side note, the GPS, with it's power hungry electronics, including the backlight, the GPS should have had no less than 3 AA batteries. With 3 AA's, the backlight would have worked better, and not be a drain on overall performance of operation.

It would take a 2-year degree in college, just to really understand GPS Technology, or at least 1 year, for some people

Edited by GOT GPS?

Having been out walking in woods again today, I must say I'm becoming increasingly disappointed with the Colorado's performance. This time I took my trusty 76CSx along too for comparison. It was a different wood to yesterday, with no clear view of the sky for most of the walk.

For about the first half hour or so everything was fine. Both units showed good EPE (around 20-30ft) and the track logs reflect this. But on the return leg the Colorado started to lose the plot with the EPE climbing and the map track differing more and more from what the 76CSx was showing. All the while the 76 was showing pretty consistent EPE. At the worst point the 76 was saying EPE was 27ft and the Colorado was saying 138ft.

At one point (when the Colorado was saying about 80ft), I checked the satellite pages on both units and they were both showing the same satellite locks with the same signal strengths. I don't know if the 76's chipset is better at rejecting echoes or something, but it seems mighty odd that the two units could be locked on to the same satellites with the same strengths and be showing such wildly differing figures). The track logs tally with the EPE - the Colorado's track is WAY off for the last 1/3 of the walk.

I swung by a geocache (a reasonable test, given that I bought the Colorado for geocaching). The 76CSx said I was pretty much on it, the Colorado said it was 275ft away!

As I headed out of the woods the Colorado's EPE improved and by the time I got back to the car it was saying 20ft and the track on the map was very close to the track on the way in.

It looks to me like the Colorado is OK for short periods in bad coverage, but over longer periods it simply loses the plot and has trouble recovering until you get out from the cover. The 76 seems to suffer much less from these issues.

Now if Garmin could come up with a Colorado that uses the 60/76 chipset, they'd be on to a winner. Right now I'm torn as to whether to return the Colorado. It's a lovely unit, but if it's going to take me 275ft away from a woodland cache it's not a lot of use.

Now if Garmin could come up with a Colorado that uses the 60/76 chipset, they'd be on to a winner. Right now I'm torn as to whether to return the Colorado. It's a lovely unit, but if it's going to take me 275ft away from a woodland cache it's not a lot of use.

Two things here, if Garmin made the antenna the proper shape and size, and put in the SiRF chipset, I would get the Colorado again. After 3 failed Colorados, I threw in the towel. The signal quality of my 3rd Colorado (400t), was so bad, that I decided I am going to wait till they fix the hardware and software issues.

Two things here, if Garmin made the antenna the proper shape and size, and put in the SiRF chipset, I would get the Colorado again. After 3 failed Colorados, I threw in the towel. The signal quality of my 3rd Colorado (400t), was so bad, that I decided I am going to wait till they fix the hardware and software issues.

I'm not convinced it's an antenna issue. In my tests this evening the Colorado was fine for the first half hour or so in woodland. The GPS track is pretty much the same as the 76CSx. If it was an antenna issue I'd expect the EPE and/or location to go bad as soon as I got under cover.

I'm not sure if it's some kind of cumulative error upsetting the maths in the unit, or if after a certain amount of time satellites near the horizon drop out of sight and it has trouble acquiring new ones while under cover. But when I checked while having bad EPE the Colorado was locked on to the same satellites as the 76CSx with pretty much the same signal strengths.

That has been my experience as well. The 60csx and Colorado will be locked onto the same satellites with the same (relative strengths) but the Colorado will be 100-700' off. In the worst cases I've even brought the Colorado back into the open with clear view of 10-11 satellites and the error persists.

GO\$Rs

Just wanted to add a 'me too' experience. After half an hour walk on a path through light woods but still with a reasonably good satellite reception and EGNOS 'D'-s on each of them, following a compass needle to a GC to a couple of meters of indicated distance, the location seemed weird enough to warrant a double check with a Nüvi. To my surprise I was 140 m (460 ft) from the correct location, while EPE was claimed to be about 7m (23 ft). Luckily the NiMH batteries needed replacing, and after powering up the Colorado 300 with fresh batteries, it picked up the correct position in no time. I guess the slow walking through non-ideal terrain was the main contributing factor, as I haven't noticed such a dramatic error so far. Using 2.51(beta) and 2.6 fw.

I'm not convinced it's an antenna issue. In my tests this evening the Colorado was fine for the first half hour or so in woodland. The GPS track is pretty much the same as the 76CSx. If it was an antenna issue I'd expect the EPE and/or location to go bad as soon as I got under cover.

I'm not sure if it's some kind of cumulative error upsetting the maths in the unit, or if after a certain amount of time satellites near the horizon drop out of sight and it has trouble acquiring new ones while under cover. But when I checked while having bad EPE the Colorado was locked on to the same satellites as the 76CSx with pretty much the same signal strengths.

Try a power cycle. If turning off and on fixes it, you have "the problem" and it can not be the antenna because the antenna doesn't change during a power cycle. You may be having the normal reception problems.

i also think i is not an antenna problem.

power off/on always solves the BUG.

But this is not an solution.

Under heavy tree cover you can simulate the bug very easily.

Driving with a car under clear sky i did not have the bug

Edited by freeday

This was probably dicussed earlier, but I've noticed that Garmin is offering up Software Version 2.5Beta. I'm showing on my 400t software version 2.40 and GPS software version 2.60. I too have been experiencing the same difficulties as many of you have indicated and wondered if the 2.5 Beta is worth a shot.

Thoughts?

Good stuff, guys. Just bought a Colorado 300. Have since a couple of days. Any news on updates from Garmin?java script:emoticon('', 'smid_7')

No news from Garmin other than some emails from tech support indicating that an update should be available "real" soon, whatever that means.

2.51 does not fix the issue. I still see the same problem with 2.51.

As many people are speculating (including myself) this issue may not be in the Garmin Software, more likely it is in the GPS Software since it seems to be a common issue across units which use the MediaTek chipset running GPS Software 2.6. So it may be that we really want GPS Software 2.7 to fix this issue.

Here's link to a recent comparison between a 60csx and a Colorado 400t. The reference track is black -- starts in the upper right corner and loops counter-clockwise back to the start. The 60csx is the red track which is hard to see because it tracks under the reference most of the time. The Colorado is the blue track -- about 300' off. The reference track is averaged from about 40-50 individual tracks from the Colorado and 60csx over a 2-3 week period only when PDOP was less than 2.5. I ran about 10 comparisons around the same course and saw two failures like this one, although this was by far the worst. I'll post the entire test results in a few days on this thread.

GO\$Rs

It sounds like most the location problems could be that WAAS is not fine tuned to the new chipset and may be over/under correcting due to poor signal strength.

Edited by AF Bmet

I notice that when I am using City Navigator and I zoom in, the triangle is off the road quite a bit here and there. Is this the same issue, or could this be chalked up to bad mapping??

location problems also occure if waas is disabled

i am not sure if garmin really knows about that bug.

I notice that when I am using City Navigator and I zoom in, the triangle is off the road quite a bit here and there. Is this the same issue, or could this be chalked up to bad mapping??

His Evshro, I have the same questions. I just evaluated my track this morning and I was off the road >400' according to my tracks. I'm concerned that I'm going to have similar issues whilst trying to geocache.

Let's hope Garmin is able and willing to address this issue.

I notice that when I am using City Navigator and I zoom in, the triangle is off the road quite a bit here and there. Is this the same issue, or could this be chalked up to bad mapping??

His Evshro, I have the same questions. I just evaluated my track this morning and I was off the road >400' according to my tracks. I'm concerned that I'm going to have similar issues whilst trying to geocache.

Let's hope Garmin is able and willing to address this issue.

Topo2008 road accuracy is a different issue. Topo2008 roads are off by 300-500' from their actual location in many places, the problem has been discussed at length in other threads and Garmin is aware of the issue but their standard response is go buy City Nav maps if you want accurate road data.

The issues discussed in this thread don't use Topo as a reference, in my case I'm using locations marked with other GPSrs over many days.

GO\$Rs

I'm encouraged by what I read in the HCx accuracy thread (same chipset), that downgrading to GPS firmware 2.30 (from 2.60) appeared to fix the accuracy problem. Hopefully that means the problem will be fixable with a firmware upgrade (rather than it being a hardware problem with the chip itself). Downgrading probably isn't an option for Colorado users, but I'll take it as a good sign nonetheless.

I just saw the HCx post as well and it would be interesting to see if this works on a Colorado -- I believe the GPS Software load for both units is the same. What isn't clear is whether the Web Updater will allow the update to a Colorado using this region file. I'm not sure if these are generic files or if they are specific to a certain unit.

I might try it this afternoon if I get up the courage.

GO\$Rs

I might try it this afternoon if I get up the courage.

I tried this and even though it seems to do something the update doesn't seem to happen on the Colorado. Still reporting GPS Software 2.6.

GO\$Rs

My today's walk through woods managed to acquire 375 m (1230 ft) of offset by the end of the trail! The conditions were tougher than last week: a one hour walk through a rather dense forest. Luckily this time I was prepared for the problem, and before a final approach to a GC the Colorado was power cycled, which fixed the ridiculous offset right away and provided a precise guidance to the target. This amount of accumulated offset is quite an achievement, I'm amazed and much displeased. I hope Garmin is working on a solution.

I notice that when I am using City Navigator and I zoom in, the triangle is off the road quite a bit here and there. Is this the same issue, or could this be chalked up to bad mapping??

His Evshro, I have the same questions. I just evaluated my track this morning and I was off the road >400' according to my tracks. I'm concerned that I'm going to have similar issues whilst trying to geocache.

Let's hope Garmin is able and willing to address this issue.

Topo2008 road accuracy is a different issue. Topo2008 roads are off by 300-500' from their actual location in many places, the problem has been discussed at length in other threads and Garmin is aware of the issue but their standard response is go buy City Nav maps if you want accurate road data.

The issues discussed in this thread don't use Topo as a reference, in my case I'm using locations marked with other GPSrs over many days.

GO\$Rs

Thanks for the "heads-up". I was worried for a while. Feeling much better thanks!

I upgraded my 400t to the latest 2.54/2.60 software, and went out hiking this weekend since the forest has finally re-opened after extreme fire danger (now we're just at "very high" danger ).

It looks like I hit the location problem twice within 30 minutes of each other.

The first time, I noticed the EPE sitting at 70 feet for a little while, where it is normally 30 or less feet. See my notes in the attached picture. (On this one, I don't know WHEN the 1,504 or 1,850 foot jump happened at Steps #2 through #5):

Just for fun, I turned off the compass and kept going. Within 30 minutes, I think I hit the problem again:

The terrain is heavily forested mostly throughout, but some open areas off and on. On the map I show what I assume to be the "correct track" colored in cyan. This is my return track as I hiked back down the trail. I only have the 400t GPS, so I assume this is the "correct track", but... uh.... I don't know for sure since I don't have a lot of faith in the 400t. (Or at least my version of 400t since it is an early unit.)

This is a pretty awful problem that Garmin has .... and now (some of?) us.

EDIT: Note that my backlight is set to auto-turn off at 15 seconds, however I had set it to "FULL BACKLIGHT" when I started the hike. But I was only checking the 400t periodically and wasn't using the backlight very much.

Edited by jmedlock

I upgraded my 400t to the latest 2.54/2.60 software, and went out hiking this weekend since the forest has finally re-opened after extreme fire danger (now we're just at "very high" danger ).

It looks like I hit the location problem twice within 30 minutes of each other.

The first time, I noticed the EPE sitting at 70 feet for a little while, where it is normally 30 or less feet. See my notes in the attached picture. (On this one, I don't know WHEN the 1,504 or 1,850 foot jump happened at Steps #2 through #5):

The terrain is heavily forested mostly throughout, but some open areas off and on. On the map I show what I assume to be the "correct track" colored in cyan. This is my return track as I hiked back down the trail. I only have the 400t GPS, so I assume this is the "correct track", but... uh.... I don't know for sure since I don't have a lot of faith in the 400t. (Or at least my version of 400t since it is an early unit.)

This is a pretty awful problem that Garmin has .... and now (some of?) us.

EDIT: Note that my backlight is set to auto-turn off at 15 seconds, however I had set it to "FULL BACKLIGHT" when I started the hike. But I was only checking the 400t periodically and wasn't using the backlight very much.

I honestly think this problem is inherit in a lot of the earlier units. I think there might have been some hardware issues somewhere along the line which they fixed or replaced in the newer units. I have not seen this issue as of yet and I hope I don't. My friend who bought a 400T when they first came out complained of the same issue and they immediately sent him a replacement with a later serial number and they told him that they had a memo to replace any Colorado or people complaining of the drifting issue. I have no idea if it was just for the 400's or not. I have a 300 and my other friend has a 300 also which were bought within 3 weeks of each other and neither of us has had the drift issue. As for my buddy with the 400T he has not experienced the drift again with his new 400T.

The location drift error has been reported by several people with "newer" units. It might be more common on the older units but I've heard of 2-3 reports of the same problem on Colorados that were received in the last month or two.

GO\$Rs

Yup. My Colorado was bought less than 2 months ago (admitedly I don't know how long it had sat on the shelf). I am experiencing drift issues, although so far it hasn't been in the range of several hundred feet. But I haven't really been in HEAVY woodland.

The location drift error has been reported by several people with "newer" units. It might be more common on the older units but I've heard of 2-3 reports of the same problem on Colorados that were received in the last month or two.

GO\$Rs

A newer unit doesn't signify when you bought it, it could have been sitting in a warehouse shelf for since february but you bought it only a month ago. I would be curious on the serial numbers of the units and whether it is a colorado 300 or 400 that are experiencing the drift problem.

## Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

×   Pasted as rich text.   Paste as plain text instead

Only 75 emoji are allowed.