Phoenix2001
-
Posts
103 -
Joined
-
Last visited
Posts posted by Phoenix2001
-
-
Pikes Cave Cache Challenge
Dave, the outdoor reporter for the Colorado Springs Gazette, needs someone to go along with him on a challenging geocaching adventure. This adventure is about finding caches and the clues they contain on Ormes Peak, Mt. Esther, near Howard's Rock, Mt. Arthur, and Gray Back Peak. Next you complete the clues to get the coordinates for Pikes Cave Cache and go find it.
The goal is to do it in one day. Note that it is easier to find a cache in daylight.
The hiking (and running?) involved will total about 25 miles, depending on which routes are taken, and about 9,000 feet of elevation gain.
If you don't mind being in a story in the paper and you are fit enough to do this, let me know.
If you can't do it for one reason or another but know someone who can, please let them know about this challenge.
-
I believe "saving" the active log to one of the storage areas causes a new GPX file to be started on the memory card. Is this out-of-time-sequence occurring in a single file or after two files have been combined?
If you have track logging set to "Auto" have you ever changed the interval (least, normal, most, etc.). Perhaps a change such as this (or something similar) causes the error.
-
By the way, does anyone know what happened to IndyJpr? Before I started working on the CO trails and POIs, I emailed him and his geocaching.com profile says he has not logged on since March. I sure hope he is OK.
forums.Groundspeak.com and geocaching.com are different systems.
Some of us don't have a lot of time for spending on forums. He could easily be too busy with work, etc.
-
I spoke to a Garmin rep again today about the accuracy issue and....you guessed it....he never heard of the issue. We talked for a while about the issue and he mentioned that he owned a Vista HCX and uses it regularly without ever running into the issue that we are seeing. This leads me to my question.....given the significant number of units that Garmin has sold that use the same GPS chip and the relatively small population of people that are complaining about this issue, isn't it possible that this could be a manufacturing defect (i.e. GPS chip) that does not effect all units? Has anybody exchanged their unit for another one and experienced the same problem?
[snip]
So far I haven't seen the problem described. Yes the versions are 2.60/2.60.
I have Metroguide versions 4 and 6 loaded, Topo (not 2008), and miscjunk custom maps for Colorado loaded. I have lock to road OFF so the receiver won't be changing the position to match the maps anyway.
The receiver was purchased around Sept./Oct. It certainly could be a problem with a certain hardware version of the MediaTek chip.
-
Not doubting your methods (although coming from Australia, I don't know what the "NED" dataset is, although I can hazard a guess), but if you don't have good topo maps for your area, you can get some idea of true elevation using a couple of free tools on the internet:
1: Try Google Maps (maps.google.com), and click the "Terrain" button on the top right of the screen. This will turn on a topo contours layer. (I am guessing this data comes from the NASA SRTM dataset).
"NED" stands for National Elevation Dataset and is the most accurate available here. It is better than the SRTM data.
-
You didn't state whether you know the true elevation of your test sites - I would suggest something like 5,010 feet at TP19, and 5,000 feet at TP20 - doe that sound reasonable?
[snip]
I generated 10 foot contour lines from the NED (Horz: NAD83, Vertical: NAVD88). The two locations are between the 4960 and 4970 foot contours. Since the 4970 line is on the "mesa top", which is fairly "flat", I'll give both locations an estimate of 4968 ft. (favoring the mesa top).
The average of all the trackpoints for TP19 is 5,000 and is 4999 for TP20. Three feet was subtracted from the two receivers on the handlebars and six feet from the receiver with the antenna on my helmet to get the ground level elevation.
The accuracy and datum of the table that Garmin uses to convert the ellipsoid height to the geoid height is unknown to me.
Oh, and yes, I have too many GPSrs!
-
Here’s an example of the effect of gusty (gust: a sudden, strong rush of air or wind) winds on the barometric altimeter. I don’t mean breezy (lower wind speeds) conditions or steady winds. The peak speeds are above 30 km/hr (19 mph).
The graphs below are from track logs; recording at once per second, while standing at two different points for almost three minutes during a bike ride. The GPSmap 76Cx and eTrex Vista HCx were mounted on the bike handlebars. The GPSmap 76CSx was connected to an external antenna on top of the helmet and the receiver was in a holster on my belt. The ride was in the South Shore area of Lake Pueblo, Colorado. It could be described as on top of a mesa since it is mostly grassland and flat on top with a clear view in all directions (except for me in the case of the two receivers on the handlebars). Cliffs drop down to the reservoir. At the time of the recordings, the wind was gusty. For brief moments, the wind could be fairly still. Strong gusts were very noticeable, perhaps in the 50 km/hr (31 mph) vicinity, give or take around 10 km/hr (6 mph).
Here's some data that shows that the barometric altimeter stabilizes the elevation under calmer conditions:
Results for a eTrex Vista HCx (barometric altimeter slowly calibrated by GPS elevation)
Test runs are indoors so there is no wind but satellite reception has interference:
Points are recorded at one per second. Meters (Feet)
Run Number of Pts, Mean Elevation, Max. Elev., Min. Elev., Range, Standard Deviation
8/31/2007 10049 1891 (6204) 1894 (6215) 1886 (6188) 8 (27) 1.73 (5.66)
8/30/2007 10063 1887 (6191) 1891 (6204) 1883 (6177) 8 (27) 2.10 (6.88)
8/31/2007 13053 1890 (6202) 1893 (6212) 1888 (6193) 6 (19) 0.90 (2.96)
9/30/2007 9999 1890 (6202) 1897 (6223) 1886 (6188) 11 (35) 2.15 (7.07)
Number of Times Elevation Changed from one second to the next:
8/31/2007 No Change: 4013 By 1 foot: 4774 By 2 feet: 1120 By 3 feet: 127 By 4 feet: 11 By 5 feet: 3
8/30/2007 No Change: 4150 By 1 foot: 4647 By 2 feet: 1124 By 3 feet: 134 By 4 feet: 7 By 5 feet: 0
8/31/2007 No Change: 5465 By 1 foot: 5946 By 2 feet: 1451 By 3 feet: 174 By 4 feet: 16 By 5 feet: 0
9/30/2007 No Change: 5582 By 1 foot: 1795 By 2 feet: 2339 By 3 feet: 238 By 4 feet: 37 By 5 feet: 7
-----------------------------------------------------------------------
Results for a GPSmap 76Cx (no barometric altimeter)
First three below were run at the same time as the first three above.
Test runs are indoors so satellite reception has interference:
Run Number of Pts, Mean Elevation, Max. Elev., Min. Elev., Range, Standard Deviation
8/31/2007 10048 1893 (6211) 1915 (6284) 1858 (6096) 57 (188) 6.96 (22.83)
8/30/2007 10060 1891 (6204) 1914 (6278) 1877 (6159) 36 (119) 5.40 (17.71)
8/31/2007 13055 1891 (6205) 1925 (6317) 1872 (6141) 54 (176) 6.04 (19.82)
8/30/2007 8711 1892 (6208) 1907 (6256) 1882 (6174) 25 (82) 4.75 (15.58)
8/31/2007 No Change: 7110 By 1 foot: 2487 By 2 feet: 246 By 3 feet: 99 By 4 feet: 50 By 5 feet: 32
By 6 feet: 11 By 7 feet: 6 By 8 feet: 3 By 9 feet: 1 10 or more: 2
8/30/2007 No Change: 7685 By 1 foot: 2217 By 2 feet: 102 By 3 feet: 33 By 4 feet: 12 By 5 feet: 6
By 6 feet: 3 By 7 feet: 1
8/31/2007 No Change: 9976 By 1 foot: 2872 By 2 feet: 122 By 3 feet: 31 By 4 feet: 23 By 5 feet: 14
By 6 feet: 4 By 7 feet: 6 By 8 feet: 4 By 9 feet: 1 10 or more: 1
8/30/2007 No Change: 6663 By 1 foot: 1931 By 2 feet: 88 By 3 feet: 21 By 4 feet: 5 By 5 feet: 1
By 6 feet: 0 By 7 feet: 1
-
Normally the GPS calibrated barometric altimeter smooths out the elevation data as your tests demonstrate.
However, gusty winds can cause rapid pressure changes on the barometric sensor resulting in fluctuations in the elevation data. Changing the direction of the receiver within the airflow (sensor opening into the wind then rotate 180 deg. so that opening is away from the wind) can exacerbate the fluctuations.
On a day with gusty winds, the GPS elevation can be more stable than the output from the barometric altimeter especially if WAAS (or equivalent - EGNOS) is available.
-
The MediaTek chipset in the Garmin "H" series receivers is the least consistent I've seen. In terms of the tracklogs I'm recording, I don't see a noticeable difference between the last three firmware versions. The last three versions have made noticeable improvements in the low speed problems (1 to 2 mph) so that the odometer now records fairly close to the actual distance. The moving time still undercounts. The examples shown are older versions but the latest still does the same in terms of positions.
See the following examples for some Garmin receiver tracklog comparisons:
-
You might be able to fix some of the errors before sending the information to IndyJpr.
How would we know what to fix? I might know my local area, but that 's probably less than 1% of the California data. Do you have some detailed steps on how one might go about fixing the errors?
Note that this doesn't apply to the NED (DEM) data that most of you are downloading.
If you only know a small area then there is that much less work to do but anyone going to that area would appreciate the correct data.
One person suggested the POI data from the Topografix web site. This is GNIS data converted to GPX format. It can be loaded into Nat'l. Geo. TOPO! and the points compared with the background topo maps. I once found a summit POI that was 1/4 mile away from the actual summit (I reported it to the GNIS manager and it was fixed). Sometimes the feature type is wrong. I.E. "Blue Lake" is actually a lake but the feature type is "stream". I found something like 20-30 errors just scanning around a bit. To find type mismatches, I wrote a program that tried to figure out the feature type from the name and then compared it to the listed type. It output a list of records that needed to be checked.
I'm willing to generate a feature type check list for the GNIS data if someone else will check them and get the corrections to IndyJpr in whatever data format he is using.
I was particularly thinking of the shape file data for Montana. That's probably similar to the data I can download from the Colorado DOT web site or the USGS SDTS data at:
http://mcmcweb.er.usgs.gov/sdts/index.html
In my area I can usually pick out a few reservoirs that aren't anymore. One of the problems I noticed almost immediately with the Colorado topo. was the road going to the top of Pikes Peak going off the north cliff face. A little more scrolling around and I found a road going almost over the top of Ormes Peak instead of around the "base". In mountainous areas, check to see if the curves in the road seem to reasonably follow the contour lines. Those that have a program that can view the data (for instance shapefiles - ArcGIS, ArcExplorer, Global Mapper, etc.) before IndyJpr converts it, might be able to spot some of these problems.
Look for data that doesn't make sense - a road through a lake. Maybe it's an old road that was flooded by the reservoir. Maybe the road is drawn in the wrong place. Look for duplicate sets of data.
-
For those of you who are sending IndyJpr information other than NED data, it would be helpful if you could check at least some of the POI's, lakes, etc. The data from the USGS (which is often where the state got some of the data) is often out-of-date and sometimes in error. Summit POIs may be a ways off the summit, old reservoirs may be indicated when they no longer exist, etc. That road in the backcountry may not exist anymore. You might be able to fix some of the errors before sending the information to IndyJpr.
Thanks to all who are helping!
-
To put a lot of your own trail maps (or water routes) on the receiver you should get to know cGpsMapper and/or one of the GUI front ends such as gpsMapEdit. Create your own transparent trail map to overlay on whatever maps you are already using.
For making your own trail maps, the small number of saved track areas is good for short trips. Use the map memory for more extensive trail maps.
-
If you had a good view of the sky and a nice distributed satellite constellation (so the HDOP was low), I'd say the Colorado wasn't doing a very good job.
If the sky view wasn't very good and there were good reflecting surfaces to create multipath then what you are seeing isn't unusual.
I could take your 60CSx and put it in a location where it would record a range on the order of 50 ft. with one type of satellite constellation and 250 ft. with another. It could even record spikes out to 400 ft. or more.
-
I got this response from Garmin:
"I am happy to help you with this. This is a known issue and is
attributed to the high sensitivity receiver and what is known as drift.
Garmin is working to resolve the issue. "
The response from Garmin would suggest that I'm not the only one that finds this annoying.
You have complained about it recording trackpoints with the GPS receiver OFF. This has nothing to do with the "high sensitivity receiver". The tech. support person didn't understand what you were complaining about.
-
[if bogus track points were produced on all Garmin GPS's then I'd accept that I'm fighting against designed funtionality and that would make it operator error. Since the bogus track points don't show up on my GPSMap60Cx I'll will continue to assume that it's a sloppy implementation by Garmin with their Etrex series (and others?).
Giving me a work-around that hides the problem isn't an answer to me.
How many times have you gone on an outing and forgotten to turn your track logging back on? For me, turning track points off is just too risky. I rely on those tracks to get home!
I don't turn track logging OFF because I've forgotten to turn it back ON and, because my primary use is mapping trails, the track log is very important.
IMHO, I agree - it's a sloppy implementation. The Vista should at least have the ON/OFF setting that the 76S has. All the barometric models should also have a "Use GPS Elevation" / "Use Altimeter Elevation" setting. On a gusty/windy day with a fairly clear view of the sky, the GPS elevation is better than the barometric altimeter - wind gusts send the elevation up and down. The barometric altimeter can also be a problem in pressurized cabins although some models will use the GPS elevation instead of the barometric when there is a great difference between them.
[Edit]...
I always clear the track log just before heading out on a hike. That gets rid of any bogus points at the beginning. At the end, I usually turn the unit OFF. When the tracks are downloaded, the hike is usually in one log and any following logs in the track list are short and a result of the barometric logging. I usually view them to make sure and then just delete them.
-
The Vista HCx has a barometric altimeter. It will log trackpoints to the tracklog so that you can get a pressure graph when the GPS receiver is OFF (unit is ON of course). Most of the Garmin receivers with a barometric altimeter do this.
I also have a GPSmap 76S. It has a command in the setup menu to turn OFF the barometric altimeter. When this setting is set to OFF , the 76S won't log trackpoints to the active log when the GPS receiver is OFF . When this setting is set to ON , the 76S will also log points with the GPS receiver OFF . The Vista HCx doesn't have this setting. The altimeter is ON all the time. When the GPS receiver is OFF, it is logging current elevation values at the last location so you can get a atmospheric pressure graph.
-
Phoenix,
In making my track library I have discovered several interesting facts... Some roads on Topo maps are simply not there any more. ... [snip]
Hi n0wae,
Yes, I've known about the state of topo maps for about 40 years or so. I'm also generally aware of the accuracy of government data sources such as the Tiger database. This product shows the problems IndyJpr has to deal with using the "local" and "forest" data from CDOT.
-
Indy Jpr,
Just found your threads last night and loaded your map sets into MapSource for a look see. Wow, what a pleasant surprise to see up-to-date data and 40ft contour intervals! I'm a member of the Trailridge Runners 4x4 Club and have been mapping Colorado 4x4 roads for years. Would you like the road track library that I've made? (Could you add it to your maps?)
Adding these roads would be a great improvement!
The quality of the information for other than the contours varies. I see a number of duplicated roads in the National Forest areas. One road is usually correctly named and the other isn't. One road is usually closer to accurate placement.
For instance, Rampart Range Road (South, near Rampart Reservoir) is marked with two polylines. One is labeled "Fs Rd 300" the other is "3". Sometimes they are close, sometimes not. The one named "3" seems to be close to the actual location whereas "Fs Rd 300" is wrong at times.
"FS Rd 302" incorrectly goes over the top of Ormes Peak whereas road "1008" (incorrectly labeled FS 302) is more accurate.
Same with the Pikes Peak Highway (FSR 334) to the top of Pikes Peak. It goes off the northern cliff just before reaching the top of the peak.
Perhaps you might consider layers. If you would provide the contours in one transparent map set and the other data sets in other transparent map sets, the user could decide what they want to include. Also the contours could be overlayed on say Metroguide road maps.
Thanks for doing this and donating your time!!
-
What will the actual improvements be for us civilians?
I can see a need for a new system/signal for military and aviation. Something that is difficult to jam, less susceptible to interference, and something that will be reliable for aviation.
For my use, I just want to see improved performance and reliability in mountains and valleys, tree cover, in and between buildings. Having accuracy that is better than 3 meters would be great for caching, and perhaps provide the ability for a GPS to tell you exactly what lane you're driving in. But I haven't heard anything that explicitly says those areas will be improved.
The old GPS had one civilian frequency, L1. The future GPS will have two more civilian frequencies, L2 and L5. L5 is considered a "safety of life" civilian use signal (especially for aviation) and has a higher transmission power than L1 and a longer spreading code than the C/A code on L1. Block III satellites generally have increased signal transmission power.
I believe there are currently four block IIR-M satellites, which support the new L2C signals. This gives us civilians a second frequency to reduce the error from the ionosphere. Different frequencies travel at different speeds through the atmosphere so the ionosphere can be better modeled (note that if you can receive WAAS signals - these also help correct ionosphere caused errors). L2C has a CM (moderate length code) and a CL (civilian long length code). They are not as long as the current military P code but better than the C/A code we have now. All of this will help us a little when consumer receivers start supporting the additional signals.
The biggest cause to poor accuracy is a poor view of the sky caused by mountains or buildings, etc. and few satellites in view because they aren't distributed in the parts of the sky that you (your receiver) can see. The EU Galileo system is designed to be compatible with GPS (NAVSTAR) so that manufacturers can also receive its signals with a minimum of additional work. A dual system receiver would be more likely to have a set of satellites in view with a "good" geometry (A slot canyon will never have good geometry) in mountainous/urban canyon situations. This would provide the "best" improvement.
Unfortunately the EU member countries are squabbling resulting in delays for Galileo and even possible cancelation. The Russian GLONASS is another possibility for additional satellites and is currently being "upgraded" but it was not designed to be compatible with GPS so it's more difficult to incorporate. Some dual system receivers using GPS and GLONASS exist but are expensive survey grade receivers. A GPS/Galileo receiver would be many years in the future but would provide you with the most noticeable improvement in poor sky view situations.
-
While reading the below linked article, I wondered what if any changes would come to GPS as a result of Block III deployment, and more specifically, if it would affect and/or obsolete gear now in our hands. I'm shopping for a GPS unit, & long story short, don't want to get stuck with another BetaMax!
Anyone 'up' on the technology, & can say what the future holds?
An old GPS receiver that still runs would work with the newest satellites. They just won't use the newer features. The future holds better performance.
-
The GPS receiver won't recharge batteries in the unit.
I use NiMH batteries even when snowshoeing or skiing.
Batteries lasting around 18 hours is normal for GPS receivers as opposed to many weeks in other kinds of equipment. If new alkalines or fully charged NiMH of at least 2000 mAh only last a few hours then something is wrong with either the batteries or your receiver. The receiver's circuitry to detect when the batteries are "dead" is off.
-
Touch screen so we don't need the big ugly button.
But then I couldn't call it the "Cyclops".
-
I don't have time to play with it so I don't know if there's a way or not...
With older models you could select a waypoint in a route and do a "GoTo" and the receiver would continue the route with that waypoint as "next".
-
Hi
Yesterday I updated my Legend HCx to the new software version 2.40.
I find that as a result of doing a direct update (not using updater) that
it has played havoc with my unit.
My guess is that software version 2.40 also needs the MediaTek chipset update version 2.3. The chipset update is not listed as a download as I write this. Unfortunately, only Webupdater will download the chipset update.
Colorado Springs - Pikes Cave Cache Challenge
in West and Southwest
Posted
So far I haven't received that email. Try danderson2004 [at] hotmail.com.
Yes, it's a tough day. Dave runs the Pikes Peak Ascent so it'll be a somewhat "easy" day for him.