DBleess
-
Posts
188 -
Joined
-
Last visited
Posts posted by DBleess
-
-
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?
-
I never saw the route lockups and hangs, but this solution seems to have solved my WAAS satellite problems.
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.
-
I have a new request that I thought of a few weeks ago and then promptly forgot. When I'm traveling down the road and I'm looking for an upcoming gas station there is no way to find something upcoming. You can look by exit but what if you don't know what exits are upcoming. You can look for nearest but that includes things you past and North and Sound bound exits. This goes doubly for Rest Areas which are usually only accessible from one side of the highway or the other. There should be a way to search for upcoming POI especially if you are following a route in which the GPS knows where you are heading.
Also it would be nice to be able to limit POI to within a certain distance of your route. Sometimes your nearest gas station on a route is 2 miles east of the highway when I could have gone 3 miles down further on my route and had one right on the highway.
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.
-
If you like for me to add anything there, please let me know.
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.
-
There should be a FAQ..
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) What is the little thing in the top row of the display, between the 3D (or not) icon and the backlight bulb ? It looks like a star in a circle.
2) Yesterday I left my car and set off on a trail. The unit popped up with something like "you are leaving the road, is this OK" (I wish I'd written it down). The choices were "Yes" and "No", and there was a box to check saying "Don't ask me again". Like an idiot, I checked this, so now I have disabled "some feature". I presume I can get it back via the menus, but what exactly did I disable ?
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)
-
This is the compass page I see that leads to the NEXT intersection on the route to the cache.
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.
-
When I clicked 'Go To' in the geocache page it brings up the map and tries to navigate me to the geocache when it doesn't even show a road.
When i go to the compass page, it does not change it to the geocache navigation page, hence i do not know which way to go to find the cache.
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.
-
For Garmin users here are the EGNOS/WAAS satelite numbers that appear in the display:
33 EGNOS AOR-E (Inmarsat 3 F2) 30 200 Atlantic Ocean Region - East
35 WAAS AOR-W (Inmarsat 3 F4) Atlantic Ocean Region - West
37 EGNOS Artemis 27 152
39 EGNOS IOR-W (Inmarsat 3 F5) 26 147 Indian Ocean Region - West
42 MSAS (Japan)
44 ESTB IOR (Inmarsat 3 F1) 6 110 Indian Ocean Region - East
47 WAAS POR (Inmarsat 3 F3) Pacific Ocean Region
50 MSAS (Japan)
AOR = Atlantic Ocean Region, IOR = Indian, POR = Pacific
In the UK (South Wales) I can pick up 33, 39 (low) and 37.
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.
-
If EGNOS birds aren't in the almanac, then
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 +
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.
-
So am i right in saying the barometer is not acurate enough for measuring elevation because its a slave to how dense the air is at the location?
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.
-
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.
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
-
I am in total agreement. To suboptimize accuracy for the vast majority (I would guess 99% of more) of the Garmin customers who do not use EGNOS sats seems backwards to me as well. Please tell Garmin. They've heard it from me.
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'd bet you were going faster, I don't think the software computes the downward component vector (altitude loss) in its calculations
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.
-
Mini USB. Mine started to pull out the other day so I called Garmin and have to send it in to either get repaired or get a new one. We'll see what happens.
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.
PS: Using the 60CS for downhill skiing is a blast. Recording top speed is great fun. I Broke 50mph on one run and my brother cracked 60mph.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
-
I'd ask them when they are going to come out with a in car unit that has a large enough hard drive to store Topo Maps (USGS Style not the reduced) and Street Maps for at least a very large area.
I've was looking at the Street Pilots and they don't show them as compatible wth Mapsource topo and that's not as detailed as I'd like but it's better than just City Select.
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.
-
I received a reply from Garmin Engineering today regarding the original topic here it is:
This is in fact the expected behavior of the search process. First, the
satellites with almanac are looked for. If they are not found, a scan is
started for all other possible WAAS satellites (33 - 51). This search will
not include the satellites with almanac that were already looked for. Only
after this scan is complete will the satellites with almanac (47, 35) be
looked for again.
The reasoning behind this is best illustrated by a potential situation that
could happen in Europe with the EGNOS system which contains 4 satellites.
Say a user had almanac for two EGNOS satellites (33 and 37), however these
satellites were for some reason unhealthy or had stopped transmitting
altogether. It is not desirable to continuously look for these satellites
when there could possibly be others out there with a usable signal (44 or
39). This is the reason for the scan when the satellites with known almanac
are not found.
If the user misses 47 and 35 on the first try the scan will start so the
order of the search I would expect to see is:
47,35,33,34,36,37,38,39,40,41,42,43,44,45,46,48,49,50,51, and then back to
47 and 35 again. A user will need to wait a little longer for the scan to
complete before 47 is tried again. To avoid the scan, waiting until you
have a clear view of the sky to turn the unit on is beneficial. This will
help with GPS acquisition time as well as WAAS acquisition time.
Let me know if you have any further questions on this.
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.
-
I'd add my vote for changing the font sizes on the map page on the 60CS (range). The Legend (B&W) has a slightly larger display area and with smaller fonts so more map.
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.
-
If you don't receive a signal from 35 or 47 within the first 45 seconds, the 3.70 firmware starts searching for other SBAS/WAAS signals (33-51) and appears to give up on 35 or 47. I turned on my unit and after 45 seconds the "47" was replaced by 33. I put the unit in plain view of 47 and it was a no-go, even after 10 minutes. With 3.61 it would keep 35 and 47 on the satellite page, and instantly reflect a signal.
I think Garmin messed up on this. It appears that they added it just before release since it was not on the 3.61 beta (check the release notes for 3.61 and it is not there, but it is for 3.70.) Tsk tsk, Garmin. That's what betas are for.
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
Whats The Deal With Pda's?
in GPS technology and devices
Posted
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?