Altimeter vs. GPS altitude comparison

The Rocketry Forum

Help Support The Rocketry Forum:

This site may earn a commission from merchant affiliate links, including eBay, Amazon, and others.

Buckeye

Well-Known Member
TRF Supporter
Joined
Sep 5, 2009
Messages
3,532
Reaction score
1,655
After a bunch of file format manipulation, I plotted altitude (AGL) vs. time from an altimeter along with GPS. The altimeter is PerfectFlite MAWD, and the GPS is Big Red Bee 900. Both are several years old and not on the cutting edge of technology. I am quite pleased with the agreement.

Data was collected from the BRB900 in two ways. One was the recording on the onboard flash memory of the transmitter. The second was to connect the LCD receiver to a com port and interface with u-center software for real-time NMEA recording during flight. u-center is nifty freeware for all kinds of plotting and analysis, making for a decent poor-man's telemetry link. It is fun to replay the data stream after the flight. This pic shows the rocket landing in a woodlot. (It was recovered from the top of a 40 ft tree.)

20180901_135438.jpg

Here are the altitude comparisons. The BRB900 transmitter lost GPS lock for the first 12 seconds of flight. The base station receiver lost signal for the first minute or so. The apogee recordings agree to about 700 ft. All my OR simulation variations bracket these values, too. Pretty good.

Interestingly, the recordings differ the most at high altitude and are very close at low altitude. I am wondering if the lack of temperature correction on the MAWD may be understating the altitude. It was a hot, 85 deg F day, far warmer than the standard atmosphere model.

Capture1.PNG Capture2.PNG
 
Last edited:
Edit: I just noticed that things do match at lower altitude so you probably already did this....


Have you accounted for your launch site elevation? Your altimeter reset ground level at power up and measures altitude AGL, while the GPS is measuring from the modeled WGS84 ellipsoid.


If you want to compare the AGL height, you'd need to determine the elevation of your launch site, preferably from a Digital Elevation Model (DEM) and subtract that from the GPS data.
 
Edit: I just noticed that things do match at lower altitude so you probably already did this....


Have you accounted for your launch site elevation? Your altimeter reset ground level at power up and measures altitude AGL, while the GPS is measuring from the modeled WGS84 ellipsoid.


If you want to compare the AGL height, you'd need to determine the elevation of your launch site, preferably from a Digital Elevation Model (DEM) and subtract that from the GPS data.

Yes, I think I am doing this the best I can. The BRB900 transmitter reports the MSL elevation (datum is 34.6 m below the WGS84 ellipsoid for my site) from the NMEA strings. While the rocket is sitting on the pad, I average the MSL readings and call that the "ground." I then subtract this ground from all future MSL readings during rocket flight to achieve AGL.

Not familiar with DEM. I'll have to look that up. This is fascinating stuff.
 
I'm certainly no expert, but I would expect the GPS to be more inaccurate until it has been plotting for a while, when it's closer to ground.
While doing Geocaching, I've found that GPS tends to improve in accuracy the longer it's turned on and tracking satellites. I assume that has something to do with firmware/software and updating the satellite track data.

By the KISS principle, a simple pulse transmitter in an RDF system will be much more reliable (won't cut out during acceleration for one thing) then the much more complicated GPS trackers which need multiple satellite inputs, data packet transmission and reception, and other technologies to all work. With that said, there is a minimal learning curve and skill level needed to use the GPS vs an RDF system, and like most things, since the GPS systems have been out for some time, they are becoming cheaper and easier to use even if they are more dependant on more complicated technology. That still doesn't mean they are the most accurate or reliable form of measurement, just the easiest.

Call me old fashioned, but I still carry a compass in my backpack when I hike, even if I haven't used it in years. I know I can depend on it, it will work and won't have a dead battery when I need it.
 
By the same token, GPS can get wonky the longer it is turned on, too. While the rocket was waiting on the pad, the coordinates started to drift many meters, then re-centered themselves. In flight, there is no time for user averaging. You get only one GPS measurement every second!

We are talking about altitude measurement, not finding the rocket. Can RDF do that?
 
Last edited:
By the same token, GPS can get wonky the longer it is turned on, too. While the rocket was waiting on the pad, the coordinates started to drift many meters, then re-centered themselves. In flight, there is no time for user averaging. You get only one GPS measurement every second!

We are talking about altitude measurement, not finding the rocket. Can RDF do that?

No, RDF will not do altitude, although if done right, it can confirm an apogee event.

The point is that I would trust the purpose built altimeter to be more accurate than a GPS system when measuring altitude.
 
The point is that I would trust the purpose built altimeter to be more accurate than a GPS system when measuring altitude.

I am no expert on this, but I think GPS can be the better choice. Airplane guys all seem know that barometric altimeters measure pressure, and that pressure is affected by local weather conditions. The more the local weather deviates from the Standard Atmosphere model, the less accurate the barometric altitude prediction. This fact is rarely discussed in this model rocketry forum, however. Guys read their Missileworks, Perfectflite, and Eggtimer devices and assume that is the "actual" flight. Not true.

Even if the GPS elevation error is 10-20 meters (I read that somewhere), that can be far less than a couple hundred meters of barometric error (like on a very hot day).
 
The answer is Sam errors can be on the order of 100 - 150 meters (at 4000m). Compare atmospheric sounding data from buffalo NY and key West Florida and see for yourself.

However that Sam error is only 2.5percent. There are as large errors in the rest of the chain also. Be happy if your altimeter is within 10 percent of true. Expect 5 percent.
 
Last edited:
Be happy if your altimeter is within 10 percent of true. Expect 5 percent.

Right. That is why "adjusting" your sim to match "reality" by fudging with drag coefficient is a waste of time. The simulation is already very good in its native form. OR, RS, and RAII all adjust the Standard Atmosphere Model with local conditions, making them more accurate than altimeters in this regard.
 
Most of the time the SAM error is small, especially if you are flying 5000 ft or less because the altitude is a difference calculation and some of the error is cancelled out. If you get a significant error in your sim to flights less than 5k then it's more likely your sim is not accurate.
 
I wonder if a chipset that uses both GPS and GNSS constellations would have better vertical altitude accuracy. It seems that positioning error is less with both systems being used. Kurt Savegnago
 
I wonder if a chipset that uses both GPS and GNSS constellations would have better vertical altitude accuracy. It seems that positioning error is less with both systems being used. Kurt Savegnago

What is the vertical accuracy of GPS? My casual Google searching says 10-20 meters, and that was several years ago. My BRB900 says this: "It also programs the high performance 50 channel ublox 7 GPS chipset putting it into "air mode" for reliable altitude reporting (which some similar products do not)" Seems to me that GPS is as good or better than baro in many cases.
 
Well a way to find out is to put the GPS on a table and log altitude readings for 24 hours and see what range of reported alts are. During that time you will probably sample most of the constellations.
 
What is the vertical accuracy of GPS? My casual Google searching says 10-20 meters, and that was several years ago. My BRB900 says this: "It also programs the high performance 50 channel ublox 7 GPS chipset putting it into "air mode" for reliable altitude reporting (which some similar products do not)" Seems to me that GPS is as good or better than baro in many cases.

The problem is with the geometry. To improve the altitude reading you need data from a satellite below the horizon. As it is, the best you can hope for is to get data from one directly overhead and one near the horizon. With a few more scattered around of course.

VDOP tends to run about twice HDOP.

Air mode trades tracking for accuracy.

It does that by opening up the loop filters so that the GPS system can track better during high vehicle dynamics. The ublox 7 has several such settings but the highest dynamics one is still for accelerations less than 4G.

Increasing the loop filter bandwidth decreases accuracy so position error will increase.
 
Good info. Thanks.

This article says GPS elevation error is less than 5m @ 95%, and talks a lot about sub-meter precision. The baro errors are one to two orders of magnitude worse than that, depending on altitude. We are not talking extreme altitudes, either, but regular sport flying. I am gonna process some more data, but GPS looks like the winner to me.
 
. ,. Xx r
Good info. Thanks.

This article says GPS elevation error is less than 5m @ 95%, and talks a lot about sub-meter precision. The baro errors are one to two orders of magnitude worse than that, depending on altitude. We are not talking extreme altitudes, either, but regular sport flying. I am gonna process some more data, but GPS looks like the winner to me.
But that may not be the error with consumer grade electronics. There is a reason that there is a market for $500 GPS chipsets compared to the $8 dollar ublox chips that we use.
My table test with a high end rocketry GPS system has a range of 120 meters perfectly still.

If you average over several minutes the accuracy is much better but you do not have that luxury at apogee. You can't control if you will have a good or bad constellation as your flight approaches the top. Baro is much more accurate because you can correct the result with atmospheric sounding data if needed. You cannot correct a gps reading.
 
Last edited:
This is discussion is good. Because of it I will add the ability to retrieve the pressure reading at apogee (from Marsa alimeters), then you can look up the actual altitude based on the nearest sounding data from https://weather.uwyo.edu/upperair/sounding.html

Good idea, but Adrian beat ya to it on page 12, and I just implemented it in my measurements in post #1. :)

https://www.featherweightaltimeters.com/uploads/1/0/9/5/109510427/raven_users_manual_2014may20.pdf

I "undid" the Standard Atmosphere model in the altimeter data and replaced it with the nearest sounding measurements. Now I have nicer agreement between the MAWD and the uncorrected BRB900.

Capture3.PNG
 
So Baro is accurate after all.

Heh. It is accurate after fixing the atmosphere model. No baro altimeter offers that function out of the box (hint, hint). Who is going to do the fix manually, other than a data dork like me?

For the casual hobbyists (who don't live in hypothetical air columns at mid latitudes), they are getting ripped off in apogee altitude by 5% or more by default from their altimeter! Then they blame Rocksim ... :rolleyes:
 
Yes if you want a record, fly in cold!
Yep, and the effect is pretty significant even if it's not common rocketry knowledge. On a really hot day the standard atmospheric model will underestimate altitude by more than 10%. Any flight using baro-based altitude with sea-level temperature over 55F is getting an underestimate of the altitude, even if the altimeter functions perfectly. When it's cold and the air is denser than the standard atmosphere assumes, then a rocket at the same actual altitude will get above more air mass, and so experience lower pressure because there is less air above it pressing down.

Although it's true that a rocket flying in hot weather with less-dense air will benefit from having less aerodynamic drag losses for the same altitude, the gravity losses are the same for hot and cold, and so the cold-weather reporting benefit wins out.
 
Let me say I know next to nothing about GPS. (That’s why I’m posting about it on the internet.) I have been unimpressed, in the past, with GPS renderings of known elevations. On one occasion, I even watched myself ascend ~120 feet (according to GPS) whilst sitting on a park bench. OK. Maybe that was the instrument.


That said, if you’re flying to very high altitudes – near or beyond the tropopause (which varies locally, seasonally, and diurnally), the pressure/temperature/altitude regime changes, and your pressure altimeter readings incur more errors. (Some instruments don’t even account for this change.) Meanwhile, the errors in GPS readings have nothing to do with the atmosphere, and they get to be a smaller percentage of altitude as altitude increases, since GPS errors are bounded, at least probabilistically.


So the higher the flight, the more I’d personally prefer to eat the GPS errors in favor of the pressure altimeter uncertainties. Lower altitude flights? Temperature-corrected altimeters hands down.
 
Altimeters don't correct for weather on purpose (it's not just ignorance). Meaning all manufacturers know about it but have chosen/been told not to do it.

Reasons:
1. So that altimeter results can be compared to each other fairly
2. Because altimeters can't sense weather (you'd have to manually assist the altimeter with that, or the altimeter would have to go online to fetch it, which most can't)

When I first demo'd AltimeterThree at a NARCON, that version demonstrated Google lookup of elevation and weather. But it didn't make it into the final version, because "weather correction" would have been controversial ("Which version should I use for a record?" and "I'll use whichever version looks best"), and data is not always available at remote fields with no data connection.

Other hobbies like RC gliding routinely do—and expect—weather correction for records, but it's never been a thing in rocketry.

In my opinion the best, ultimate way to do it (and I've suggested this) is that records should be submitted as time-series data of uncorrected pressures, along with time and location. It allows the facts (pressures sensed, location, time) to be post-processed in whatever way makes sense, along with looking up the recorded weather that day at that location.

On the other hand, if you just submit the altitude, or just the altitude graph, you've incorporated all of that implied processing in the submission. One can try to "back into" the original pressure if we assume the SAM was used correctly, but that's an assumption. Better to just submit the base facts (pressure, location, time), and do all of the weather correction later. Which can be redone if new info or algorithms become available.
 
The RRC3 does record and log pressure (vs. altitude) and independently (both the altimeter and the mDACS PC app) applies the NOAA pressure-altitude conversion to this recorded pressure data. In addition, RRC3/mDACS users can optionally apply the NOAA geo-potential conversion using a "linearized" temperature profile (since we don't have accurate air temperature) and a static RH%. While not perfect by any means, it does provide an alternate means of post flight data correction for weather.
 
The RRC3 does record and log pressure (vs. altitude) and independently (both the altimeter and the mDACS PC app) applies the NOAA pressure-altitude conversion to this recorded pressure data. In addition, RRC3/mDACS users can optionally apply the NOAA geo-potential conversion using a "linearized" temperature profile (since we don't have accurate air temperature) and a static RH%. While not perfect by any means, it does provide an alternate means of post flight data correction for weather.

Just a tangential comment concerning linear temperature profiles:

Although the temperature lapse *rate* with altitude changes seasonally, locally, and diurnally, the linear model for the profile is usually pretty good – and when it diverges radically, the entire theoretical basis for altimeters falls apart. Also, there is a thermodynamic basis for linear temperature lapse in the troposphere. The dry air lapse rate is straightforward to derive – and it’s somewhat higher than the NOAA standard. Not to say there aren’t exceptions. Indeed, every cloud is a local exception. Everything above the troposphere is an exception!


Anyway, back in 2005, I was on a flight from Beijing to Newark. The plane had a display, which displayed, among other things, GPS altitude and outside temperature. Having little to do for 14 hours, I collected the data. Naturally the plane was traveling laterally as well as vertically… That said, you don’t see many lines that straight in nature.
 

Attachments

  • Beijing Temperature Lapse.png
    Beijing Temperature Lapse.png
    14.6 KB · Views: 73
  • Newark Temperature Lapse.png
    Newark Temperature Lapse.png
    14.5 KB · Views: 48
Just a tangential comment concerning linear temperature profiles:

Although the temperature lapse *rate* with altitude changes seasonally, locally, and diurnally, the linear model for the profile is usually pretty good – and when it diverges radically, the entire theoretical basis for altimeters falls apart. Also, there is a thermodynamic basis for linear temperature lapse in the troposphere. The dry air lapse rate is straightforward to derive – and it’s somewhat higher than the NOAA standard. Not to say there aren’t exceptions. Indeed, every cloud is a local exception. Everything above the troposphere is an exception!


Anyway, back in 2005, I was on a flight from Beijing to Newark. The plane had a display, which displayed, among other things, GPS altitude and outside temperature. Having little to do for 14 hours, I collected the data. Naturally the plane was traveling laterally as well as vertically… That said, you don’t see many lines that straight in nature.

EDIT: To be clear: The data were taken on takeoff from Beijing and landing at Newark. That is, they were not taken at random moments of the flight.
 
Back
Top