Jump to content

Creating x/y/z map with tourist-grade GPS


Recommended Posts

Hello,

 

I know that this question is not related directly to geocaching, but I thought that I may try ask it here.

 

Here is what I want to achieve (short version):

to create a map (x/y coordinates + height) of specific area

 

Here is what I want to achieve (long version):

There is a rural area, 5x5 km large. Not many trees, some low buildings, tourist paths and some dirt roads. Altitudes ranging from ~200 to ~250 m. GPS coverage seems to be good, I can easily get 5-6 satellites on my mobile phone. Central Europe.

I would like to create a map of the tourist paths and roads, with exact x/y coordinates, as well as altitudes along the paths. I don't want to create a grid of x/y/z values, it would look more as an irregular mesh or spider web. I don't want to have coordinates of every point in that area, just paths and roads.

 

I want to collect the data by just carrying the GPS device in my backpack, and walking with it in the terrain. Technical side of extracting the data from the device and then processing it further is out of scope of this post, I think that I can solve it myself.

 

I know that I could adapt data from existing sources, but I want to do this entirely on my own, just for fun.

 

I've been thinking about using devices such as Garmin Dakota, or Garmin eTrex - this type of devices, more or less in this price range. I don't need to have a military-grade resolution, but the more I can get from this kind of devices, the better.

 

Now here is the question #1: in order to achieve this goal should I get a device equipped with barometric altimeter? Will I gain much from having it in my device? Does it increase precision of measurements of altitude (or, to put it another way, does it provide better *relative* accuracy than pure GPS)? By "relative" I mean "I know that this point here has altitude 220m, I want to know the height of that point over there".

 

Question #2: how slow should I walk to ensure correct acquisition of data by such devices (devices in this class)?

 

Could you please share your thoughts on this topic? I will be grateful for any input and advice.

 

 

Edit: "as well as latitudes along the paths" -> "as well as altitudes along the paths"

Edited by StefanDarecki
Link to comment

For some (sorta) esoteric mathematical reasons, obtaining a good Z axis measurement using GPS isn't nearly as accurate as x and y. So yes, a correctly calibrated barometric altimeter is going to provide you with much more accurate results. Like any device of this type, entering the correct local pressure is critical in getting anything but relative results.

 

Your walking speed isn't going to be fast enough to upset things significantly. However, you may wish to slow down a bit in turns so that there's no 'overshoot' in the track that can come from certain position averaging algorithms being used on these devices.

 

Either of the devices you have noted (assuming you obtain the right model - not all Dakota and eTrex models have a barometric compass) are more than up to the task, providing you have, as you describe, a reasonably clear view of the sky across the area you are measuring. However, be advised that carrying the device in a backpack will guarantee that you have potentially shielded the device from a good bit of the constellation while you travel .. your body is just dandy at blocking a satellite signal. So you may wish to consider how else you might carry the device to get it a view of as much of the constellation as possible. That will improve the accuracy of the resulting track.

Edited by ecanderson
Link to comment

Yes, one with a barometer is what you want. To get good numbers, you will want to walk the paths multiple times on different days. Keep the GPS as high as possible to avoid obstructions including your body. If there are good aerial images of the area, these can be used for the main map creation.

Link to comment

GPS measured altitude is not very accurate. The barometer models use the barometer to calculate altitude and you get very accurate short term changes. The Garmin ones set to auto-calibrate will use the GPS altitude to calibrate the barometer altitude every now and then due to changes in barometric pressure.

 

For the OPs purpose, I would manually calibrate the altimeter at a know location and altitude each time he goes out.

Link to comment

I would seriously consider checking Google Earth's available data for the region being surveyed. Walk some or all of the paths and record a track, then compare the elevation profile of those tracks ase recorded with what Google Earth has. It's not ideal and there are holes in Google's coverage -- but overall it's a terrific resource that might fit the OP's needs.

Link to comment

To several:

 

As noted, Z axis positioning by GPS is inherently far less accurate than what you've all grown accustomed to for X/Y positioning. The physics and the math behind it don't allow for the same level of accuracy. As a result, a decent and properly calibrated barometric sensor system will always provide you with a better measurement of elevation.

 

What's nice about the Garmin approach is that if you do know the ASL for your start point, you can enter that in feet or meters and don't have to enter the barometric pressure. All changes after setting are assumed for a constant local pressure system (which of course, changes from time to time, so no baro sensor will remain accurate when 'weather' is changing the local barometric pressure).

 

As to drift ... On my Oregon 450, as an example, after setting ASL and leaving the device in a fixed location, instantaneous variations of about +/- 3 feet are normal. It won't ever behave any more accurately than that. I don't know if any of the more recent units are any more accurate than that. Garmin probably provides specs on this somewhere.

 

To Grasscatcher:

 

No. If the barometric sensor is enabled, those values calculated based upon that sensor will be reflected in log data instead of GPS altitude calculations.

Link to comment

@ECA,

Are you really ,really sure of your position on that?

OK if I respectfully disagree?

 

As you stated, you can recalibrate the altimeter by entering known elevation before you leave to get the two (Baro and GPS Elev) closer together. However, if you did NOT do that before you left, it would be the GPS elevation (calculated)data being used to gradually "correct" or "auto calibrate" the "Baro" elevation.......not the other way around.

 

Yes, the elevation axis is the "least accurate" axis vs the X and Y horizontal, but it is still more accurate than the Baro., and thus is (can be) used to "correct" it ...over time.

 

You can make the unit use one or the other in the tracklog by the setting "fixed or variable elevation".

Link to comment

I just turned on a Delorme PN-60,

-Set track recording at 10 second intervals

-Opened the blinds; got a fix

-Selected barometer elevation for track point elevation recording; disabled gps elev recording "calibration".

-Set an incorrect elevation calibration 1000 feet (~300+ meters) too high for an obvious large shift.

 

-Opened the gpx track log in Wordpad from PN-60 SD card in the device.

-Replaced the coordinate data values consistently by whole degrees to some place in Morocco. Saved file to computer scratch folder.

-Imported the short track file into Delorme Topo9

-Looked at the plan view of the track log expanded on a blank canvas without maps in Africa.

-Created a profile view of the track showing a constant 1000 foot elevation shifted display over the track log period of a few seconds.

 

Comment: Seems that the barometric pressure can be used for recording elevation values consistently for short periods of time, and that the Delorme Topo9 app and PN-60 device can be quickly set up to demonstrate elevation profiles or create flat trail layer vector lines without elevation values. It took much longer to get a fix and write about it than to do it.

 

Good luck with your mapping and profiling effort. The reason I shifted the coordinates to Africa was to verify that Delorme Topo9 North America would create a profile view in a distant continent.

Edited by 39_Steps
Link to comment

@ECA,

Are you really ,really sure of your position on that?

OK if I respectfully disagree?

But of course!
As you stated, you can recalibrate the altimeter by entering known elevation before you leave to get the two (Baro and GPS Elev) closer together. However, if you did NOT do that before you left, it would be the GPS elevation (calculated)data being used to gradually "correct" or "auto calibrate" the "Baro" elevation.......not the other way around.
Depends a bit on which GPS you have as to how the Setup works, but what I was saying is that it's easiest to just pop in the feet or meters IF you do know your ASL at the starting point of your trip. Then there's no guesswork. As far as what GPS is used for when the user selects to track with the barometric sensor, see down towards the bottom.

 

Yes, the elevation axis is the "least accurate" axis vs the X and Y horizontal, but it is still more accurate than the Baro., and thus is (can be) used to "correct" it ...over time.

No, over the short term ('short' being defined by local weather patterns), the GPS is less accurate than a well calibrated baro sensor of decent quality unless there's a fast change in local pressure due to moving weather fronts where one would necessarily adjust known ASL or pressure to compensate. When you get the pressure before landing an aircraft, that info is no good tomorrow, or perhaps even in a couple of hours. That's the rub with using a baro sensor to determine ASL.

You can make the unit use one or the other in the tracklog by the setting "fixed or variable elevation".

 

The 'fixed' or 'variable' relate to whether the device is being asked to {a} assume a constant ASL (no jumping up and down <g>), and display/record what is assumed to be a varying pressure, or {b} assume a constant local pressure, and display/record what is assumed to be a variation in the devices position ASL. In short, it assumes that either one or the other isn't changing, but it's still the barometer that's being used, not a calculated satellite ASL.

 

Where GPS comes into play in conjunction with the barometer is the 'manual' vs. 'automatic' calibration for the barometric sensor. 'Automatic' uses GPS calculated ASL to put a stake in the ground regarding local barometric pressure, and will push the adjustment of the barometer closer and closer to the calculated GPS value if it's off by enough. But you still don't get any closer to reality than the GPS calculation can get you, and it takes time. You would ONLY use this mode if you knew neither the ASL or pressure at your location. 'Manual' allows you to enter an exact ASL (e.g., 5016 feet) to obtain a more precise fix for starting the exercise.

 

All of this does, of course, pertain only to Garmin. I have no idea how the other manufacturers support or name these features and settings.

Edited by ecanderson
Link to comment

But wait.....there's more....now for some real data:

Ambient pressure change in my area equivalent to 100 feet in a four hour duration this morning.

 

http://w1.weather.go...story/KSNA.html

As noted in my longer discussion - weather fronts can and will whack out any attempt to use a barometric sensor for ASL calculation. In that case, you're flat stuck with GPS calculated ASL accuracy unless you have another source of reference for pressure or ASL (like a nice benchmark) to recalibrate. That's why airports will report local field pressure minutes before landing - not hours beforehand. If them doggone Canadians would keep their jetstream up where it belongs, life on the millibar scale would be a whole lot easier (not to mention warmer) here in Colorado this time of year!
Link to comment

One practice that is imperative in technical discussions it to use accepted definitions for terms.

For example, one will not pass a course in engineering mechanics while using the terms stress and strain synonymously and interchangeably.

 

To enhance clarity in this discussion, I would suggest the following source for defining accuracy and precision:

http://en.wikipedia.org/wiki/Accuracy_and_precision

Link to comment

@ECA,

Are you really ,really sure of your position on that?

OK if I respectfully disagree?

 

As you stated, you can recalibrate the altimeter by entering known elevation before you leave to get the two (Baro and GPS Elev) closer together. However, if you did NOT do that before you left, it would be the GPS elevation (calculated)data being used to gradually "correct" or "auto calibrate" the "Baro" elevation.......not the other way around.

 

Yes, the elevation axis is the "least accurate" axis vs the X and Y horizontal, but it is still more accurate than the Baro., and thus is (can be) used to "correct" it ...over time.

 

You can make the unit use one or the other in the tracklog by the setting "fixed or variable elevation".

 

From the Garmin website (Dated 9/10/2013):

"GPS heights are based on an ellipsoid (a mathematical representation of the earth's shape), while USGS map elevations are based on a vertical datum tied to the geoid (or what is commonly called mean sea level). Basically, they are two different systems, although they have a relationship that has been modeled.

 

"The main source of error has to do with the arrangement of the satellite configurations during fix determinations. The earth blocks out satellites needed to get a good quality vertical measurement. Once the vertical datum is taken into account, the accuracy permitted by geometry considerations remains less than that of horizontal positions. It is not uncommon for satellite heights to be off from map elevations by +/- 400 ft. Use these values with caution when navigating."

Link to comment

To the original poster,

GPS units without Baro sensors of course can only report GPS elevation. That is a calculated value from satellite position, just like horizontal position, but is the least accurate of the three axis due to being the most sensitive to satellite position and quantity of sats..

 

GPS units WITH Baro sensors can report both GPS and Baro elevation. However,the Baro MUST be calibrated before it can report any useable information. You must calibrate it by using (user input) either the known baro pressure at your current location or the known elevation at your current location.

 

So, the accuracy of the Baro elevation that your unit reports is TOTALLY dependent on the accuracy of the data that YOU INPUT. That is true at the start immediately after calibration. If you use the unit's "auto calibration" feature, you should still manually calibrate it to a / the "known" current elevation. It's not mandatory that it be exact, but the closer to actual, the better. Why ?, because that means that there will be less "error difference" to be corrected by the unit's "auto calibration" feature. Auto calibration is not an instantaneous "full error" correction.The correction"s" occur gradually , over time ......minutes/hour"s".

 

Based on your baseline input, and the pressure that the unit's sensor detects, the unit reports a Baro elevation. The unit also calculates a GPS elevation from sat data for every trackpoint ,just like it does for horizontal position. With "auto calibration" ON, if the unit detects a difference between those two values, it will use the GPS value to know which direction it needs to "tweak" the Baro Elevation value to get it in agreement with the GPS value.

 

Since this correction occurs over time and in small increments, it has a visual "smoothing" effect on the instant to instant calculated GPS elev results. That's why you really need to calibrate carefully at the start (that gets both values together) and then leave "auto calibration" ON so that weather related pressure changes aren't erroneously reflected as elevation changes. Baro elevation will never be any more accurate than the GPS elev. value that is calculated by your unit.....because that's the value that it is calibrated "with".

 

Walk at a steady normal walking speed when recording data. Steady = more consistent and accurate data collection.

Link to comment

For Garmin users...that don't believe that the user has control over which data is reported in the tracklog....

 

Intentionally "mis" calibrate your unit altimeter by 1000 ft higher than actual.

 

Use "variable elevation" setting.

Use "auto calibration"

 

Start walking and recording a track. Watch your Baro elev. It will decrease more and more the further you go. Look at the difference between Baro and GPS Elev values on your unit as you walk.

 

Now, stop and change your setting to "Fixed elevation". Save a waypoint then continue walking further while recording the track.

 

Stop and save the track.

 

Go back home and download the track you just recorded.

 

Analyze the trackpoint data. The elevation recorded before the waypoint is Baro elevation. The elevation recorded after the waypoint is GPS elevation.

 

Also, assuming that you walked far enough for the auto calibration effect to kick in, you'll notice that your starting (erroneous)elevation was constantly being adjusted downward toward the calculated GPS (correct) value.

Link to comment

Thank you all for your comments. Based on them I think I will do the following:

 

1. I will get GPS unit with barometric altimeter. It looks like the GPS is not as accurate when it comes to altitude as it is for x/y coordinates. I hope go get better *relative* results with the barometric altimeter.

 

2. I won't carry the unit in a backpack. In order to not to obstruct the view of satellites, maybe I will fix it discreetly on my neck, or maybe under a baseball cap (I hope it won't look suspicious or ridiculous :) ). Of course I will subtract my height from the recorded data. But since I'm more about relative altitudes (relative to some starting point with well-known altitude), this shouldn't be a big problem.

 

3. I will carefully read instructions for calibrating the altimeter, and do as many tests before actual measurements as needed. One of the tests I was thinking about was to start walking from point A, go uphill to point B and return down to point A. In theory when returning to point A I should have the same altitude recorded as at the beginning. If the path is short enough I should avoid (or minimize) the negative impact of changes of atmospheric pressure.

 

4. I will also try to make the measurements on days when weather forecast predicts stable atmospheric pressure. Avoiding the measurements in the morning and evening seems to be a good idea.

 

Thanks again to all commenting people. I will continue to watch the discussion about calibration of barometric altimeter.

Link to comment

Thank you all for your comments. Based on them I think I will do the following:

 

.........

 

3. I will carefully read instructions for calibrating the altimeter, and do as many tests before actual measurements as needed. One of the tests I was thinking about was to start walking from point A, go uphill to point B and return down to point A. In theory when returning to point A I should have the same altitude recorded as at the beginning. If the path is short enough I should avoid (or minimize) the negative impact of changes of atmospheric pressure.

 

4. I will also try to make the measurements on days when weather forecast predicts stable atmospheric pressure. Avoiding the measurements in the morning and evening seems to be a good idea.

 

Thanks again to all commenting people. I will continue to watch the discussion about calibration of barometric altimeter.

I support your efforts to create your own data; similarly, I have also generated extensive data in the past regarding the performance of my GPSr and characteristics of the data.

 

However, before I continue with my suggestions and presentation of my data, I feel obligated to post a disclaimer regarding my ability to understand the functionality of a GPSr device regarding determination of elevation and my knowledge of scientific testing and data analysis in general. The disclaimer refers to a discussion of the same subject matter several years ago during which thread another poster became quite emphatic regarding my conjectural disagreement with his opinions. Well, read for yourself:

http://forums.Groundspeak.com/GC/index.php?showtopic=189245&view=findpost&p=3438512

 

Briefly, it implies that I am totally unknowledgeable in the subject whatsoever. :shocked:

Edited by Team CowboyPapa
Link to comment

Briefly, it implies that I am totally unknowledgeable in the subject whatsoever. :shocked:

Likewise. Fortunately the Delorme PN-60 AND associated software may be a little smarter.

 

The PN-60 that I was using for experimental elevation offset of Plus 1000 feet, based on pressure, got placed in the pocket of a bag in the back seat of the car and forgotten while it was driven 50 mi down and 50mi up the coast off and on for five hours.

 

Barometric track log maintained an approximate elevation offset of 1000 feet from topo contours for the trip, but the same coordinate point baro elevation is shown as being 28 feet higher at the end of the return trip than at the beginning of the outbound trip.

 

Neither rain nor snow interrupted the appointed rounds, and I am just reporting data, for I think I will turn the TV weather report on in 4 minutes and then immediately switch channels as usual while the weather person drones on for another quarter hour as usual.

 

As to the "arguments" that each poster has presented in this thread, perhaps they are each relevant and not necessarily mutually exclusive to the topic focus of others. For instance, it is my experience that use of gps satellite elevation logging on an automobile road will usually provide better accuracy than absolute pressure ga(u)ges.

 

But it perhaps more satisfying and educational to have a device that will display, if not record, both pressure and satellite elevation data independently and simultaneously.

Edited by 39_Steps
Link to comment

...

Likewise. Fortunately the Delorme PN-60 AND associated software may be a little smarter.

 

...

Actually, that disagreement of almost 6 years ago was back in the PN-20 era:

1. People would ask what to buy,

2. Many became a my Chevy is better than your Ford argument,

3. A Garmin user declared his device as a superior alternative as it had a barometric while the PN-20 did not and that the barometric was far more precise (see Wiki definition above),

4. My doubt was how was the barometric any better when atmospheric conditions continually change in spite of the lower precision of the GPS derived elevation,

5. The answer was that the Garmin also included an auto-calibration function that corrected for ambient pressure changes,

6. Admittedly, I was totally clueless at that time regarding this capability and inquired as to what data was used for the auto-calibration,

7. Now, understanding that the Garmin models used the far less precise GPS derived data to correct the barometric data, it seemed like making a silk purse from a sow's ear.

 

Now, in the fullness of time with a DeLorme PN-60, I have accumulated about 200 data points and hypotheses based on them tend to corroborate my prior opinions which garnered all the negative criticism of my analytical capabilities here:

http://forums.Groundspeak.com/GC/index.php?showtopic=189245&view=findpost&p=3438512

Edited by Team CowboyPapa
Link to comment

Looking back, I think I may have noted something that is confusing people about how Garmin makes use of the baro sensor, and why ONE of the settings noted above is so important to get right depending upon how you intend to use it. It is essential to correctly set the "fixed or variable elevation" mode correctly to get the desired result in the output.

 

All the barometric pressure sensor knows is pressure. It cannot know if pressure is changing due to changes in weather, or due to the fact that it is being hauled up and down hills vs. ASL. The meaning of the pressure change has to be defined for it.

 

The baro sensor can be used EITHER as a barometric pressure sensor (like the sort on your wall) OR as a vertical position sensor ASL. But it must be TOLD which it is being asked to do.

 

If to be used as a simple barometer, it will assume that you are NOT hauling it up and down hills. It assumes a fixed distance ASL and records/displays the difference in barometric pressure that is occurring at that height ASL as a difference in barometric pressure.

If it is to be used to determine height above ASL, then it assumes a fixed local barometric pressure and records/displays the difference in pressure as changes in height ASL as 'altitude'.

Link to comment

Post #14 above is absolute proof in writing that many so called "experienced" GPS users DO NOT UNDERSTAND how their GPS units work or how to obtain accurate data from them.

Care to elaborate on how my GPS does work with regard to GPS vs. Altimeter readings, then?

ECA, this appears to be somewhat of an echo of my post #18.

 

I too, would like to see some quantitative data, so I offer as a related request:

1. I assume that the OP, 39 steps and myself are the three here that do not have Garmin handheld GPSrs of any model,

2. If so, could any of the other posters to this thread contribute such qualitative data?

3. As a believer in the concept of turnabout is fair play, I will post my personally acquired, with my DeLorme PN-60, quantitative data in a short while.

 

Also, it sure would be convenient if the accuracy and precision data presented can be described consistent with these accepted defintions:

http://en.wikipedia.org/wiki/Accuracy_and_precision

Edited by Team CowboyPapa
Link to comment

I don't use Elevation data but I found this thread interesting and Googled the subject. I found an interesting article which included this information:

 

Garmins always reference the height above the geoid, not the ellipsoid. Some Garmins without pressure sensors, and all MLRs, have no barometric capability at all. These instruments can only display and record GPS height.

 

Other Garmin GPSs with a pressure sensor are commonly used in free flight. The 76S and 76CS(X) and the 60CS(X) are popular first instruments.

 

The units display geometric height on the satellites page as ‘GPS Elevation’. Barometric elevation is displayed as ‘Elevation’ on the Elevation page and is a selectable field on all other pages. It is this barometric Elevation that is recorded in the track log.

 

Significantly, there are two methods of calibrating the barometric altimeter. In Auto calibration mode the altimeter is continually, but slowly, updated with the GPS height. When a Garmin 76S was, as an experiment, set 200 m too high it took 90 minutes to autocalibrate.

 

In effect the ‘Elevation’ displayed is a combination of GPS height and barometric altitude: it is the GPS height with the more sensitive changes of barometric pressure superimposed.

 

This combination of GPS and Altimeter height makes the information recorded ambiguous. It is probably best to leave autocalibration off and calibrate the altimeter manually.

 

In Manual calibration mode the pilot must set the height or pressure (QNH or QNE) for the day. After this, the Elevation displayed, and recorded in the track log, is based on the altimeter.

 

The full article is here.

 

Bob

Edited by BobMorphew
Link to comment

@ECA,

You answered your own question(in #26) with your post in #27.

 

Go back and carefully read #20 & #21 and you will see several conflicts in #14.

 

The importance of user settings cannot be overstated. based on why certain settings are made and for what purpose the unit is being used.

(Perfect example of that is Post #29.... completely different "ballgame") Note: ATIS info is broadcast continuously and the broadcast phonetic ID is changed every hour on the hour so that pilots can be assured that the info they have is current.

 

Your post #27 is correct and does not conflict with anything I've posted....... except, I wouldn't use the term " assumes". The unit displays exactly the data that the USER has told it to do by settings. The user must understand what settings affect what. Again, #27 is correct.

 

You do know how to read both GPS Elev AND Baro Elev on your GPS even if your model doesn't have an available GPS Elev "data field" don't you?

 

Here's a "quick and dirty" real world application since I don't participate in pseudo intellectual stuff.

 

On your way to the trailhead, turn your unit on and let it "settle in" with a good "lock".

 

At the trailhead, clear it's brain and calibrate the altimeter by using the GPS elevation value.

(Be sure you are using variable elevation and auto calibration)

(Think about that, since the GPS elev value is the value that the baro elev is going to be adjusted toward all day, why not start there?)

 

As you hike all day, up or down 2000-3000 ft, have a weather front come through or not, whatever...the auto calibration feature compensates or "adjusts" for all of both variables. Both Elev values will be very reasonably close to being the same. That's the purpose of the feature, to compensate for variables that can easily be mis-interpreted.

 

When you arrive at camp for the night, immediately change unit to "Fixed Elevation". Now it is a barometer, and you can tell in the morning if the pressure has dropped drastically and maybe you should go back down, or if it's steady or rising and you can continue on.

 

In the morning, look at the Fixed Elev value. It should be the same as the evening before. Remember that number, because before you start hiking again, you need to change back to "variable elevation" setting. Note that when you do change that setting, if there has been a weather pressure change over night(very probable), your Baro elevation displayed will be incorrect.

 

Calibrate it using your known actual value and you're back on the trail again.

 

From start to finish, using only data/equip you have with you, no outside calibration data,etc, your tracklog will reflect accurate elevation data.

Link to comment

Well, I mentioned some quantitative data and here are the significant values and the conditions under which they were gathered:

1. Objective: To determine the effectiveness of the Auto-Calibration function in correcting the atmospheric pressure changes as they affect barometric elevation readings.

2. Device: DeLorme PN-60.

3. Location: My backyard (see note 1.), elevation of 8 to 11 ft AMSL. Abiding by the scientific of testing cause and effect by changing only one independent variable at a time, it serves no purpose to complicate the study by dealing with pressure changes due to both weather effects and elevation changes.

4. Observed data family: 40 sets of data collected over a 50 day period (see note 2.) with no more than one set per day, sufficient time was allowed for device stabilization after bootup,

4a. Raw atmospheric pressure,

4b. Equivalent elevation determined from raw atmospheric pressure,

4c. GPS determined elevation,

4d. Auto-Calibrated elevation,

5. Results calculated by means of MS Excel,

5a. Accuracy of the GPS derived elevations as their average: -1 ft,

5b. Accuracy of the auto-Calibrated elevations as their average: -2 ft,

5c. Precision of the GPS derived elevations as their standard deviation: 13 ft,

5d. Precision of the auto-Calibrated elevations as their standard deviation: 19 ft.

 

Notes:

1. Backyard location: Fairly unobstructed view of sky, stationary testing eliminates variability due to changing view impediments.

2. Data gathering time scale: I saw no value in collecting a statistically significant number of data groups every 10 seconds for 3 minutes during which the ambient pressure may change less than an equivalent of 50 feet. I did not see that as being a sufficient pressure range over which to assess the ability of the auto-calibration function to perform as expected.

 

Unfortunately, they do not corroborate some of the non-quantitative data based opinions above. However, further unsubstantiated opinion is not unexpected. Let the anti-quantitative data disparaging dialog and the belittling back-biting begin.

 

I’ll return after football to summarize the quantitative data and suggest their impact on operational concepts.

Link to comment

Now that's what we like .. hard numbers. Wish the hard numbers from your last sentence were better, though. Would have preferred to see Cincy here instead of San Diego next week.

 

Can you give a hand with item 5a, please? When you say "accuracy" and "as their average" at -1 feet, this is of a known elevation? And when you use the word "precision" in 5c, you're saying that the standard deviation of all of the data points used for the 5a average was 13?

 

While I can be convinced that a very large data set can produce the numbers you are showing (just as a lot of data points averaged over many days are more likely to reduce to more accurate coordinates in X/Y), to compare this to real life (none of us will be running that many samples in the field!), it's the 5c number that is of interest. It may provide the best guide as to what one might expect when attempting to use the baro feature for 'Z axis' position numbers in real life circumstances.

 

On any given day, over the course of at most 1 hour (I doubt many have the patience to wait even that long), can you elaborate on what your 5c numbers looked like from the DeLorme? My experience with Garmin units isn't nearly as good as 13' SD over a typical hour of measurement. I tend to get a lot wider drift. I haven't run a set of numbers since doing so on my old Summit HC. Perhaps it's time to fire this up on the Oregon 450 to see if things are any different now?

Link to comment

Over the last two days I poked around the Delorme PN-60 elevation calibration menus, and then reset the PN-60 elevation to gps values in height and gave up. I did away with the slow automatic calibration and my user induced +1000 foot deliberate error above the actual +150 contour line that I hang around on.

 

Then today I looked at the gps while sitting on a park bench and saw a gps Elevation of 1008 ft, or thereabouts. I was somewhat dismayed, until I remembered that I had just driven over a mountain pass an hour earlier and had really descended to an elevation of 950-1000 feet. I am old, so maybe we can blame senility.

 

Back home at the +150 contour line level another hour or two later, I set the PN-60 outside for a 20 minute soak. By reverse engineering the displayed results, I determined that the NOAA Weather.gov manometer down at the airport at sea level was within 1/100th of an inch of mercury of being correct, so I am calling it a day. In fact I am calling it an entire year.

 

Thanks for all the inputs. Now back to the regularly scheduled statistical analysis.

Link to comment

OK, analysis of the quantitative data in post #33 provides the information that the OP was requesting regarding Z-axis, or elevation, determinations.

 

The two items presented there, elevations presented as items 5a. and 5b. and standard deviations presented in 5c. and 5d., are all that are required for the operational concept definition requested.

1. The calculated elevations, averages of 40 observed data points, -1 and -2 ft represent the accuracies of the GPS derived data and the auto-Calibrated data, respectively. With only a 1 ft difference between the two, these data mutually cancel as selection criteria.

2. Fortunately, the standard deviations, 13 ft and 19 ft represent the precision, or repeatability of the GPS derived data and the auto-Calibrated data, respectively. With a substantial difference, ca. 33% better for the GPS derived, or 50% greater for the lesser repeatability of the auto-Calibrated barometric data, it is obvious that the GPS method is preferred for determination of elevation.

 

I realize that the quantitative data presented herein and the conclusions derived from them contradict some of the qualitative opinions expressed above. Nevertheless, hypothesis developed as result of analyzing real, valid, and applicable quantitative data always take precedence over speculative, qualitative opinions.

 

Consequently, I see no capability deficit in using a GPSr without a barometric pressure sensor for the usage described by the OP.

Link to comment

I would be happy to answer these questions. Note that there was in post #30 a negative comment regarding participation in pseudo intellectual stuff.; however, if that is what my response entails, so be it.

Now that's what we like .. hard numbers. Wish the hard numbers from your last sentence were better, though. Would have preferred to see Cincy here instead of San Diego next week.

 

Can you give a hand with item 5a, please? When you say "accuracy" and "as their average" at -1 feet, this is of a known elevation? And when you use the word "precision" in 5c, you're saying that the standard deviation of all of the data points used for the 5a average was 13?

I am using the definitions from here:

http://en.wikipedia.org/wiki/Accuracy_and_precision

 

Yes, both families had almost the same averages, and accuracies, but significantly different standard deviations. Specifically, my best estimate of the elevation, AMSL, in my back yard is 10 ft (so it is my known elevation). Consistent with that definition in Wikipedia, they call it the Reference Value. I took 40 readings of the GPS derived elevation and the average of those was -1 ft. Consequently, the error, or measure of accuracy is 11 ft. (No, although I live 1 1/2 crow miles from the beach, my feet stayed dry).

The degree of scatter in a group readings is called precision in Wikipedia. It can also be considered to be repeatability. The standard deviation of the data group is the quantitative description of the group, the smaller the better (usually). Think of 10 rifle shots at a bulls eye, with the group contained by a minimum circle of 10 inches. Moving some of the shots between 2 and 4 inches from the center outward by two inches will increase the standard deviation, and then moving some from 3 to 4 inches inward will decrease it. In general, the larger the scatter, the larger the standard deviation. Usually, but there are exceptions, the range of the data also is indicative of the scatter. It is true in this case as the GPS data with the standard deviation of 13 has a range, maximum elevation - minimum elevation, of 68 ft while the auto-Cal's std. dev. of 19 ft has a range of 96 feet. The std. dev. is considered to by the most representative characterization of data scatter.

After calculating the average of the data points, each data value is has the average subtracted from it. Then all these differences are squared and these squares summed and then divided by their number, here 40. The std. dev. is then the square root of that sum.

 

Bottom line: Although both sets of 40 values have the same average, or error from the accepted, reference elevation, the GPS data are less scattered, more tightly contained if you wish. Therefore, they are considered to have greater precision as a family.

If you had a standard laboratory weight of one pound and weighed it 20 times on scale A for an average of 1.1 lbs. and a std. dev. of 1.3 lbs. and 20 times on scale B for an average of 1.1 lbs. and a std. dev. of 1.9 lbs., would you not consider scale A to be the superior of the two?

 

Hey, getting late....I'll finish tomorrow.

Link to comment

 

While I can be convinced that a very large data set can produce the numbers you are showing (just as a lot of data points averaged over many days are more likely to reduce to more accurate coordinates in X/Y), to compare this to real life (none of us will be running that many samples in the field!), it's the 5c number that is of interest. It may provide the best guide as to what one might expect when attempting to use the baro feature for 'Z axis' position numbers in real life circumstances. ...

Yes, with the average of the elevations in 5a and 5b being essentially the same, the standard deviation, 5c and 5d, is the criterion by which to select the best method of determining elevations.

Link to comment

Well, let's see now......my inference in Post #4 was that a "barometer model" wasn't required to do what the OP planned.

 

In excess of 30+ posts later, you came to the same conclusion.

 

Conclusion: Common sense and real world experience is just as accurate and is faster than pseudo (un)scientific dribble.

 

(and wastes fewer pixels)

Link to comment

...On any given day, over the course of at most 1 hour (I doubt many have the patience to wait even that long), can you elaborate on what your 5c numbers looked like from the DeLorme? ...

OK, I will address the time line for data acquisition.

 

Firstly, I'll look at the short end of the spectrum:

1. I get my standard atmospheric data here.

2. It shows standard atmospheric pressures of:

2a. 29.92 inHg at SL

2b. 29.81 inHg at 100'

2c. 29.71 inHg at 200'

3. Imagine that the carnival has come to the Oxnard oceanfront,

4. I get on the 100' diameter ferris wheel, and my barometric reading (auto-Call set OFF) is 29.92 inHg,

5. 50 seconds later I check the barometer at the top (100 ft higher),

5a. If it reads 29.81 inHg, OK because that is what is expected,

5b. If it reads 29.71 inHg, I toss it when I get down as a weather change will not cause a pressure change in the equivalent of 100 feet in 50 seconds!

 

The other end of the spectrum:

1. I wanted to test the effectiveness of the auto-Cal function in compensating for pressure variations over a large range of pressures,

2. Of the two independent variables affecting pressure:

2a. Physically changing elevations under constant weather conditions was not practical,

2b. Testing over a 50 day (not seconds) span at constant elevation, was very practical,

3. Taking 40 points of data, no more than I per day, seemed sufficient to me.

 

Calculating Results:

1. Considerations of statistical significance indicate that taking the average of 5 data points, as an example, is of little value,

2. The same is true for calculating the standard deviation of a data set, perhaps even more so,

3. Consequently, I used MS Excel to make those calculations only when I had collected 40 data points.

 

Final conjecture: If you were testing the effectiveness of snow tires, would you test in 1/16" or 4" of snow?

 

... My experience with Garmin units isn't nearly as good as 13' SD over a typical hour of measurement. I tend to get a lot wider drift. I haven't run a set of numbers since doing so on my old Summit HC. Perhaps it's time to fire this up on the Oregon 450 to see if things are any different now?

 

As I said above: "turnabout is fair play".

I sure would love to see some corresponding data from a Garmin! :D

Link to comment

Fair enough. I'm buried in another GPS beta for someone else at the moment (some 'live drive' time, some bench time), but as soon as the next public code release is wrapped, I'll take my more current unit (an Oregon 450) and rerun an old Summit HC test with an added component or two since the 450 is a bit more configurable. Of interest, unless you had one of their baro equipped units back in the old eTrex days, they didn't even bother to offer an Altimeter Page with associated plots. That remains true, I believe. For example, the Dakota 10 without baro had no elevation plot. The Dakota 20 with baro did. I still assume this was because they didn't believe the Z axis GPS calculation was accurate enough to be useful? When we did that test, we had to pick the GPS Z axis data off of NMEA sentences -- there wasn't any other way to get at it. There was and is no obvious method for shutting off the barometric Z axis measurement in the UI of a baro equipped Garmin in order to view only GPS Z data. I'm not familiar with the Delorme or how it is configured to provide and either/or output in this regard - just that Garmin doesn't support it directly.

 

My 'real life scenario' testing of the Summit was centered around a 2 hour use test. It assumed two use models, and I picked days to test where barometric pressure was relatively stable so as not to confuse the issue. I'll dig up the old test plan and added a few items for this test (Summit had no Auto Calibration, for example). The two use models centered around the fixed mode vs. changing elevation modes. In the latter case, it was 10 minutes at origin with known Z, a 45 minute trek to the destination passing by two additional known Z waypoints, 10 minutes at the known Z destination, reversing 45 minute trek, again past two known waypoints, and a final 10 minutes at the origin. The 10 minute wait times were to observe any drift or over/undershoot. In the fixed case, it was a simple matter of leaving the unit in a fixed position and observing Z values for GPS and pressure on the barometer.

 

It will be interesting to see how it all looks on a newer unit.

Link to comment

I look at a lot of tracks. I've seen many side by side tracklogs of units with barometers and units without. The barometer units provide a better elevation log. Smoother and more accurate. You need to understand the data to realize what can be happening due to general atmospheric pressure change, but most of the time it can be used as is. For the OP's purposes, it ill work better as long as he understands the limitations.

Link to comment

Looks like I missed all the fun. Oh well. A couple of points should be made:

 

1. The geoid model in your GPS is only good to an accuracy of about 1m.

2. The barometric altitude for most consumer-grade GPS devices has about a 45-sec to 1-min lag because of the diameter of the hole that equalizes pressure while allowing the device to claim it is waterproof. It's easy to see this effect: watch the barometric elevation in a car as you go over a pass. It will sometimes even keep going up while you are going down.

3. I would never use a consumer-grade GPS alone to create an accurate xyz map of anything. Use the satellite radar altimeter data and do intelligent interpolation.

Link to comment

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.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
×
×
  • Create New...