DBleess

The internal battery eventually wears out and they're a pain to replace. Anyone know if palm is going to come out with a unit that has a user replaceable battery more like their treo 650 phone?

You're almost as likely to destroy the older palms as get the successfully battery replaced on it unless you have excellent electronics skills. Anyone know if palm is coming out with a unit that has a user replaceable battery along the lines of their treo 650 phone?

Went caching last weekend, happened to set my GPS next to a tree while I logged and traded, and 5 minutes later when I picked it up, it had abandoned 35 and was hunting for non-local WAAS satellites again. I ended up powering off and back on the unit to get 35 back quicker so I could take my WAAS reading on the cache. So, my hard reset didn't fix it, and my "tests" must have been flawed. Just loaded 3.80 and I'll try to get a laptop interfaced to get screen captures of what I am seeing. Since there is no mention of it having been addressed in the update, I would guess the problem is still there.

If you've planned a route, they probably also figure you've planned your fuel stops. Then remember that on major travel routes fuel vendors tend to build stations right at the major intersections and put up signs that you can see from almost a mile away. Some even put up billboards and the state highway dept's put up a lot of blue services signs. On slower major routes, you can see the station signs along the road. If you look at your GPS and see a major intersection approaching, you can bet with fair certainty, you're going to find gas. I think it'd be more of a curiosity than a useful addition.

Add everything in this thread. Reorganised so it is easier to find and reduces duplication. Make it so followups to questions here become simply a 1-line referral back to the FAQ. Ideally, it should end up being a simplified version of the manual that is written around the most commonly asked questions and confused subjects. I've seen postings where people didn't even understand the notation and conventions we use to communicate how to program settings. An explanation of that is what I started with in my prototype page.

No kidding, this is just getting WAY too big. How about a little help? Maybe from some of you that have benefited, and those that we saved you from having to read the manual. Pick the best of it, code the html if you can, clean out the trash, make better screen caps, and send it along. [link deleted] (edit) disregard my link and see the established FAQ link below

1. Cable connected (USB to PC) 2. This is a classical error. Menu - Menu - Setup - Routung Guidance Method - Prompted When you are navigating to a cache, you must select "Off Road". It could also be the "lock on road" feature. MENU-MENU-SETUP-MAP-GENERAL SETUP (leftmost icon "N") - LOCK ON ROAD (off/on)

That answers my questions. Looking at the screen shot of your GPS's compass mode, mine matched completely except there was no red arrow showing the direction of the next intersection. Is there any option I need to turn on so the red arrow shows up in compass mode? Thanks a lot for the help. You need two things to have the arrow. A location fix from the satellites, (the GPSr has to know where it is) and a waypoint selected to navigate to. (it needs to know where it is supposed to go to. Without these two things, the arrow will not display. Take it outside, lock up the satellites, mark a waypoint, GOTO that waypoint, and you will see the arrow.

I'm not sure this question is phrased clear enough to answer but I'm going to make a few guesses about what was meant and take a stab at it. It is ALWAYS better to just take the unit outside and play with it and read the manual as you do so. Take each feature and understand thoroughly how it works and then build on that to understand how each next feature works. Explore each of the pages of information on the GPS screen and each setting involved with it. If you have questions, research it in the manual to see what it says it does, then go out and play (practice?) with it some more so you can see what it means in reality. You really don't want to just go running off looking for a cache first thing if no one has ever taught you how to operate your gps. Learn how to use the GPSr and most of its features, capabilites, and limitations first. Having said that, I'm going to have to assume that you are starting off more than about three miles from the cache. A distance that most people would rather drive or bike rather than walk and that is why you are talking about roads. So, to start off, take a look at this setting: MENU - MENU - SETUP - ROUTING - GUIDANCE METHOD (set this to PROMPTED) After doing this, you will be given two choices every time you select a waypoint to navigate to: Follow Road / Off Road "Follow road" will try to select a route via the GPS's loaded maps that will take you to your waypoint. The "geocache page" will not come up until you get to the very last leg of that curving and turning route. All guidance is in terms of smaller bites of the total trip divided up into segments bounded by intersections of roads. The pink route line will not always follow the roads exactly. It will normally just draw straight lines connecting the intersections that define the route. If you select "Off road" the unit will give you the straight line direct route "as the crow flies" to the cache. Since there is no complex route and no final turn, you are on the last leg already and the "geocache page" you mentioned that you are looking for will be instantly displayed. If you use this option, the navigation of getting to that waypoint is up to you. Use a roadmap, or common sense to get as close as you can and use the GPS only for direction and distance (not routing) information. Keep in mind that not all geocaches are near roads, and not all Garmin maps (including the default basemap and topo map 100k version) are very current or accurate as far as roads go, nor are they all completely routable. Only major roads on these maps are usable for routing. The GPSr will only plan a route and get as close as it can via the major roads that it knows on these maps. When it can get no closer, it may leave a gap or draw a straight line for the final distance. (Which can be humorous around here when the closest it can get is on a point on I-29 on the wrong side of the Missouri river.) Here's a sample: The nearest routable road is .5 miles away and you see the gap from the present position. This is the compass page I see that leads to the NEXT intersection on the route to the cache. If I select Off Road (Direct), this is what I see instead: If this doesn't answer your questions, try to be more specific and include screen captures using the garmin ximage software to illustrate what you mean.

Here's an old map of the coverage footprints: http://www.gpsinformation.org/dale/dgps.htm#waasalmanac If someone has an update with the new birds, please post it. It bears repeating that the EGNOS system is still only just coming online, is still in testing and may not be reliable for a while yet. BUT when it does come online, you can expect precision to get into the 2-3 meter (6-9 foot) range as long as you have a clear view of the sky where the augmentation satellite is. http://www.esa.int/esaNA/SEM8M3SMD6E_egnos_0.html

Engnos and Waas satellites do not move on the sky like GPS satellite, they are geostationary (at a fixed position all time). (Like TV satellite, you don have to follow them with your parabolic antenna) As long as you got 2d fix, the GPS the know were to look for satellites 33 + http://www.esa.int/export/esaNA/GGGQI950NDC_index_0.html Exactly, which is why it is strange that anyone would even bother to program in an aqusition search that is active AFTER a 2d-3d position is computed. Which is what we are (were) seeing. The Garmin rep I was talking to couldn't reproduce the error on three different units so I did a hard reset* of my unit and have been putting it through the paces ever since and haven't been able to reproduce the problem. *hold ENTER and PAGE while powering up. You will LOSE all your user settings so record them first and save time to sit down and reset them back to what you want. http://www.gpsinformation.org/dale/secret.htm I never saw the route lockups and hangs, but this solution seems to have solved my WAAS satellite problems.

GA27c temporary magnetic mount on the roof of my truck cable fed out through the back swing-out window cruising down the interstate I get 6ft epe and every satellite above the horizon mark comes in at full or nearly full strength. http://shop.garmin.com/accessories_for_pro...ku=010-00322-20 Not sure why I need 6ft epe on the freeway, but there you are. Using the integrated antenna, and looking through my roof and windshield from my dash mount I don't get results as good and normally get 8-13 ft epe and a slower aquisition.

No, pressure sensors are routinely used for determining elevations and every plane uses this principle for its altimeter. But it is correct that the measurements will be affected by changing weather patterns and therefore barometric altimeters need to be recalibrated fairly frequently. When hiking this is usually done when reaching points of known elevation (summits, passes, trail junctions shown on a topo map, etc.). Pilots get information to calibrate their altimeters when they approach an airport so it'll read accurately in the vicinity of the runway. During cruise flight they just set it at a standard calibration (29.92"Hg @ sea level) which works fine for assuring proper airplane separations since all other pilots will also be using that standard calibration. The benefit of combining a pressure sensor with a GPS, like the 60cs, is that one can get the benefits of both measurement methods. The GPS is subject to rather sudden random fluctuations and sometimes can't measure altitude at all (if receiving less than 4 satellites). OTOH, it is unaffected by weather and gives good readings when averaged over a period of time. The pressure sensor has good short-term stability and doesn't need satellite reception but is affected by weather. So if you set your 60cs to auto-calibrate the altimeter it will monitor the difference between the pressure-based and GPS readings and gradually calibrate the pressure sensor over about a 30 minute period. BTW, lower pressures would correspond to higher elevations. To oversimplify it, think of air as a liquid. The deeper under water you get, the heavier the volume of water you have overhead, and the higher the pressure you experience. The higher in altitude you get, the less air you have above you and the lower the pressure. Since air is a gas, humidity (water vapor is less dense than the equivalent amount of drier air), weather patterns, (low pressure systems can be thought of like the vortex in a draining bathtub) and temperature can all have a pronounced effect. I've never seen the utility of using a barometric pressure altitude reading on the ground outside of curiosity. Reversing it would be of more utility to me. If I know point altitudes via surveyed points or GPS reports, and could reverse this data to figure out local sea level barometer readings over time, wouldn't that give me an indication of the pending weather systems and their relative strength? http://www.intellicast.com/Local/USNationa...v=none&pid=none If you look at the isobars, (the lines of pressure measured in millibars in this map) you can see the changing sea level pressure reported around the country. For aviation, since you're moving 100-600 mph, you are crossing many different pressure readings over the course of the flight. Airplanes use it for a common reference between flights to keep them separated in 3D space and to determine proximity to the ground, and there are built in safety margins generally of 500-1000 FEET. If you are looking for altitude data to the nearest FOOT, air pressure isn't the way to determine it because there are so many variables involved. Use the GPS's 3D calcs and look for a high EPE. You'll probably be down around 12-30 foot accuracy. On the ground, the movement rate is 2-20 mph (biking/hiking) and 5-45 mph (offroad driving) and the pressure changes are driven by the movement of weather more than the movement of the person recording the weather. Doing it the other way around is less useful because you have one thing going for you. You're already standing on the ground, and you know your location. If you have a topo map, or topo data loaded into the GPS, (preferably both) you already know your altitude. For aviation, the common 29.92" standard is used only at or above 18,000 feet. See FAR91.121 This is because there are not many places to land with an elevation of 18,000 feet so your primary concern is air traffic separation at higher speeds over a broader geographic area. Below that, pilots use local barometer settings provided to them by enroute traffic controllers, automated airport weather reporting systems, (ATIS, AWOS, ASOS) or Flight Service Stations which are regional pilot weather services that can be contacted by radio. The point here is that you are looking for ground obstruction clearance and traffic separation, both at generally lower speeds. There are even more high-tech aviation weather reporting systems on the horizon that may eventually be small enough for the outdoors too. (Like what happened with GPS) FAR91.121 http://ecfr.gpoaccess.gov/cgi/t/text/text-....2.4.11&idno=14 Airman's Information Manual (AIM) FAA weather services. http://www.faa.gov/ATpubs/AIM/Chap7/aim0701.html#7-1-2

Not sure what you mean - I download tracks from Garmin GPS's all the time . A normal, plain old track is 2-D data. 3D as in latitude, longitude, and *altitude* ALL plotted in a 3d rendered space. DeLorme's topo5 is capable of 3-D terrain plots, http://www.delorme.com/topousa/images/samp...vils-stairs.jpg it could be useful to see a 3D tracklog plot above the ground for many things, my personal favorite would be a flight path over terrain. Good for flight training applications so you could review a flight after the fact. Check smoothness of a glide slope on landings and how well you hold altitudes enroute or during maneuvers. You could plot high bridges over deep terrain, and who knows what else. People are imaginative. With 2d, if you plotted crossing something like a suspension bridge, the plot would show you descending into the canyon and crossing on the surface of the water or valley.

Delorme's instructions page has been moved: http://www.delorme.com/support/multi/multi...&K=&P=8125&C=19

Took the advice and emailed support, I'm getting the "deer in the headlights" response. This rep doesn't seem to know what I'm talking about. I left them my work number in the response tonight. Since I work for a Garmin Avionics distributor (and I told him), they might actually take me seriously and call me and gather some information. We shall see.

Hmmmmm, when (if?) Delorme (ever) adds Garmin support for their topo software, I wonder if they might be able to incorporate a 3d tracklog too? That'd be fun.

I don't know about the 60C but 60CS is capable of calculating vertical Feet/Second. Also they are not certified for air navigation but are capable of it so true speed (horizontal and vertical combined). 60C has a vertical speed field too. Now you have me wondering. Do you suppose there is altitude data coded into the track log too? I have downloaded several flights into Delorme's topo v5 but have always wanted the altitude to code also so I could 3d model instrument approaches. Time to figure out how to run some experiments.

Every experience I've had from Garmin suggests that they will warranty exchange it for a remanufactured unit as long as you haven't left signs of abuse or tampering with it. I'm going to try to remember to treat my USB connector with care if they seem to be at all fragile. That connector is definitely a tight fit. Let us know how it goes. I did 125km/t = 75mph with my downhill ski I'd bet you were going faster, I don't think the software computes the downward component vector (altitude loss) in its calculations, I'd bet it only does the 2-D map component. Unless you have some flat parts of your run, you might have even better bragging rights

USGS data doesn't seem to be updated often enough yet for my tastes. I'd prefer to find a way to dump DeLorme's data in instead.

MORE time watching the road, LESS time watching the GPS. I crank the radio too loud, I'd never hear the audible warning.

The more I ponder that explanation, the more I think it doesn't make any sense at all. Satellites don't just appear out of nowhere. It takes time to move them to cover losses and outages, and almanac data can be updated as fast as they are moved. Once you have both an updated almanac, and a 2d or better fix, you have an absolute sense of what is in the sky above you. The almanac is constantly getting updates, and for all intents and purposes has to be considered always to be correct once it has a current load. (at the very least for the USAF birds) If EGNOS birds aren't in the almanac, then a. they need to be added somehow or b. the software has to be written to use the 2d position fix to discount the need to go hunting for them under the almanac-covered area of the USAF birds flying over North America. In the western hemisphere, if the almanac is loaded, listed as current, and you still manage a 3-d fix that doesn't agree and says your almanac is wrong; say it says that you shouldn't see the satellites it does see above you, then the system is FUBARed anyhow, isn't it? Look at the position side of the constellation. If I'm driving along with a 3d fix and can only see 6 of 10 "normal" satellites, the system isn't going to start hunting for different birds with the no-signal slots. Why? Because someone in the GPS system design process said something like this: "We have an almanac, we know they are there, we will simply patiently wait for the signal to become "audible" to the receiver and not go frolicking about looking for birds we already know we cannot see" Get my point? There's two different logics now being applied between the position birds and the augmentation birds. You shouldn't go hunting for something that the almanac says either doesn't exist or is over the horizon and out of sight. I'm already seeing operationally that the new augmentation logic is flawed and actually can HURT performance rather than enhance it. You delay higher accuracy signal by wandering off looking for something the almanac should already be telling you isn't there. On the ground in a cluttered world, it is easy to lose signal on a satellite. So when the GPSr stops looking for a bird simply because it loses signal lock, you're only going to make a bad problem worse if you go looking for something that isn't there in favor of something that alamanc knows is there. Logic should follow that it is just a temporary obstruction-caused loss of signal. Once that signal is audible again, if you are "on the wrong channel" and not even listening for it, you miss the opportunity to quickly reaquire it. Doesn't that seem incredibly stupid to anyone else? The system logic needs to be set back to the "patiently wait" concept that was abandoned for flawed reasons. If there really is a reason to go looking for these other satellites, it shouldn't be made to override the need to "keep looking for what you KNOW" first. Add a logic routine to determine where in the world you are that blocks looking for augmentation birds that aren't there in favor of using the almanac to search for what should be there instead. How complicated can that be? It has to be easier than it was to add the code that "broke" the system in the first place.

This reminds me, not so much smaller fonts, though an option for that would be nice too, TRANSPARENT (or semi-transparent) DATA BLOCKS, to make the map display bigger with numbers merely overlaid on it so you don't wipe out a third of the map display for data fields. It could be done with an outline font, black on white / white on black reversable for day/night

No lockup when I try that. TopoUSA maps installed.

I suspect the same. Once the GPS has a 2d or better navigation solution, it should have a point to derive almanac data to know exactly what satellites are in view. After that, the GPS should only be searching for satellites it *knows* are overhead in order to speed aquisition of the highest accuracy position, and recover accuracy quickly after passing places of sky obscuration. (Heavy cover, bridges, structure, etc.) This is how the previous firmware loads seemed to work. They knew where the local WAAS bird(s) was (were) and only bothered to look for and reacquire it (them). I'm beginning to wonder if the almanac data for the WAAS birds is getting corrupted somehow and if that is the cause of the weird behavior. I'd bet the change is undocumented because it is a "break" and not a "fix" that got by their testers. Hopefully someone from Garmin is monitoring the boards and sending out word to their engineers to work an immediate repair. Expect a quick 3.71