GPSlug

There's nothing wrong with a good patch antenna. It's used in a lot of professional-level equipment. You actually don't want your elevation roll-off to be too low because it would let in more ground multipath. That, and a more predictable phase center (point on the antenna where the measurement applies) make it a better choice than quad-helix. For consumers, the trade off may be that if the direct signal is too weak, sacrificing some accuracy by letting some extra multipath in could mean the quad-helix has better availability. But with high-sensitivity receivers, that isn't really necessary.

I don't know about on the Colorado itself, but in MapSource you just have to select the tracks you want to join, right-click and "Join the selected tracks".

It's sort of like there are three sets of tracks on the 60C(S)x. 1. Optionally stored tracks on the microSD. These aren't truncated, but they aren't the ones that show on your screen or are downloaded to MapSource. They are only accessible through the USB mass storage mode or putting the card into a reader. They are stored as one file per day. 2. The active (unsaved) tracks that are stored in the unit memory. These show on your screen and can be downloaded by MapSource. I don't know if they have in-between points removed (I don't think so, though), but they are capped by a maximum number of points. I had thought it was just a cap of the last 10,000 points, but it could be a 20 x 500 limit -- I haven't looked at it that closely. But I know if I go a long time between downloading and clearing the track memory, it will lop off the earlier part of the tracks. The microSD tracks are still intact, though. 3. Saved tracks in the unit memory. Decimated and limited to 20 x 500. I never use these so I don't know how they interact with the memory used up by the active tracks.

"Mark" makes a waypoint for the current position. Holding down "Enter" makes a waypoint for the position of the map pointer, which will be different from your current position if it was moved with the arrow keys.

The temperature function is undocumented because it's not useful to the user. It's main* purpose is to partially correct for the internal oscillator's temperature-dependent drift. It only cares about the temperature inside the unit. *I suppose it could also be used for to detect over-heating. There wouldn't really be any point in trying to use it for better troposphere modeling.

I think it's interesting that it mentions "HotFix". Is that just Garmin's name for SiRF's InstantFixII? Does that mean the Oregon's will go back to SiRF? Or are they just licensing the patent? I don't think InstantFix in itself will be accurate enough for geocaching, but I hope it's an indication they are dropping the MediaTek chips.

Just to not confuse any download matters, my success was done with a complete manual download (my only option since I can't make McAfee work with the updater) and copy to the appropriate directories, followed by running MapUpdateBeta with all the files already in place.

This worked for me: 1. Changing Families\NTDBData\ID to "7F 00" makes the install error go away, but I still can't see the detailed maps. 2. Then deleting Families\NTDBData\MDR fixes everything. The same changes happen when I delete Families\NTDBData and re-run MapUpdateBeta I get street names everywhere I've looked in Alberta and BC. Which is apparently as expected.

No case there. The plane's system is using the same frequency as your unit.

I think what's really happening is that when you go to turn on the backlight, your hand covers the antenna enough to cause a lock break on at least some of the problem ranges. If anyone is in a situation where this is happening, could you try an experiment? Cover up the antenna well enough to break lock on the satellites. It might be enough to just wrap your hand around it or stick it into a mylar chip* bag for a couple of seconds. See if your position snaps back to where you expect. *On preview, I realize this could be read two ways. One of those anti-static bags that memory chips or circuit boards come in would work too, but I just meant something like Baked Lays. You're actually pretty close to what the problem likely is. Part of the standard bag of tricks to get a smoother position is to smooth out the noisy pseudorange measurements with the carrier signal. But you can only do this as long as you don't break lock on the carrier and lose track of how many wavelengths have gone by. What I suspect is happening is that when there the reflected signals are too strong, it's messing up this carrier smoothing or something equivalent like carrier updates to the filter or whatever else the chip is doing that's basically the same idea. This could be because it's not detecting the lock breaks because of the high multipath, or that it loses the signal and picks up a direct reflected signal (where it can't see the unreflected signal at all, as opposed to most multipath which is a blend of the true signal and the reflections) and that makes the smoothing initialize incorrectly. Even in the latter case, it should detect it as a lock break when the direct signal is visible again. It's really MediaTek's problem, but if anyone's in contact with customer service and can get something passed back to engineering, tell them that they are getting too many undetected cycle slips in high multipath environments and it's messing with the carrier smoothing.

Or use another river?Another desert? Another battleship? Another Chevy truck? Do we know for sure it was named after the state of Colorado?

1 minute(or second) of longitude = 1 minute(or second) of latitude * cos(your latitude) (spherical approximation is close enough)

It sounds like it's routing off the base map. What sort of maps did you load? If either (a) the maps don't support auto-routing, or ( you didn't check the little "Include route calculation data" box* when loading the maps, it will create a route using the sparse base map rather than the detailed map. *In MapSource, on the bottom of the Maps tab in the left pane. It will be greyed out if the maps don't support it or, in the case of NT, can't be left out.

mil-spec pringles

If there are enough GPS satellites visible to fill up all the channels, it will choose those over WAAS. Are all the slots filled up?

Interesting post GPSlug. Aircraft receivers have two separate systems which are monitored and if they do not jive both are considered not reliable and are kicked off the line. The last time I checked they had finally decided that for WAAS approaches (much lower landing minimums) there would also have to be two separate antennae or two GPS systems. (which would mean 4 actual receivers) Now I am not an aircraft radio person so this is the dumbed down pilot version. The requirements* would apply to all of the receivers. They're not going to be as stringent as military receivers, though. Consumer units have no applicable requirements. *(part of RTCA DO-229 and, I believe, some other test procedure document)

Certified aviation receivers have interference rejection requirements, so they aren't as bad off as handhelds. (side note, I doubt this is what's happening) A number of years ago, there was a particular signal amplifier used in Radio Shack TV signal boosters and other products that could go flaky and start putting out a bunch of in-band GPS interference. In one instance, the U.S. Coast Guard was hearing complaints about not being able to get GPS in a particular harbor, but it was very intermittent. They were eventually able to track it down to a personal boat that had one of the TV amplifiers, but the interference would only be in-band when his TV and exterior lights were on at the same time. But if it's a difference between in and out of the car, it could be some interference inside the car. I can watch my satellites blink in and out more when I'm in the car when I turn the CD player on. It's especially noticeable when I'm doing a cold start (old ephemeris). Acquisition is considerably better with the CD player off. My brother's XM-Radio receiver is even worse. On my old Legend, you could watch the bars drop to half of what they were when you turned the XM on and they were in the same area of the dashboard.

...when using properly written firmware. (is your head exploding yet? can you post pictures?)

Were you tenting your fingers and chuckling malevolently when placing it? Are you grinning while your eyebrows are pointed down? Do you employ henchmen? Do you have a goatee? That might explain it.

Now that's a reality check!

Isn't it a little early to be PWD (posting while drunk)? (edit) <Checks location> OK, well maybe not too early.

How dare they not allow limited food items! Can I bring unlimited food items?

What is urushiol? The oil from poison ivy. I may be mistaken (I'm more of a west coast guy and recognize poison oak much better), but isn't that what he's slithering around in? Or are they just berry vines?

Make sure the Legend is set for the Garmin interface (main menu / setup / interface). Another way you could test the port is to set the interface to NMEA out, start HyperTerminal and set it to that com port using 4800,8,None,1,None, and see if any text is coming out. The Legend may need to be actually positioning for anything to come out.

Talk about adding insult to injury, considering the fact that the snake is probably covered in urushiol, that sounds like it could be a bad day all around.