Altimeters vs. GPS?

[cls]

The geometry and number of satellites determine location and altitude accuracy. My test location varies around a 10 meter radius. The altitude varies +/- 20 meters.

My experience, also. Had the patch antenna at the same place on the roof for many years. Presently, the U-blox 7 CEP is under 2 meters, but the altitude varies by +/- 10+ meters over time.

I don't have a handy reference explaining the math behind altitude solutions. But this link shows the many systems designed to improve the altitude solutions

https://en.m.wikipedia.org/wiki/GNSS_augmentation


Bottom line to the naysayers above: learn the difference between precision and accuracy. GPS $GPGLL may have an altitude reading to the meter, but that string doesn't show the errors bars of the numbers. Don't let it fool you.



I maintain that barometric measures with correction for atmospheric conditions are most accurate of the alternatives, unaugmented GPS, and integrated accelerometer (noisy data). But practically, any of these may be good enough for your mission... If you understand where the numbers come from

 

[kjhambrick]

So it wasn't really 5 g's for 12 seconds, which would have been surprising. I'd like to see what sort of grain could deliver enough rising thrust to do that.

I should let @Adrian A speak for himself but I can't help myself

In addition to the plots above, Adrian posted a great Launch Report and he also posted his raw Blue Raven and GPS Data in another thread: Taking a Shot at the G Record ( starting at post #145 )

I've been playing with his data a bit because I love to play with data

As you noted, @lr64, the net acceleration during the thrust phase was much less than 5 Gs. This is Raw Axial Acceleration -vs- Velocity for the flight.


I understood what Adrian was saying -- the motor produced 5 G of acceleration, but as lr64 noted, the acceleration on the system was reduced by drag so the net acceleration due to the motor thrust was 'tilted down' from 5 G at the onset of the sustainer thrust phase to about 2 G at burnout ( and drag actually exceeded thrust near burnout ).

Note that the anomolous air density does not affect acceleration nor vice-versus -- the data sets are independent ...

So back to Pressure Altitude -vs- GPS Altitude ...

I am not exactly sure where Adrian's "Half Fast" rocket was launched nor the actual altitude of the site ...

Adrian reported that the Launch Site Temperature was about 50 F when the rocket was launched.

The Blue Raven reported that the air pressure was 0.83000 atmospheres / 840.99 mb or about 5,064 ft just before liftoff.

Note that my Air Density curve in the Acceleration -vs- Velocity Plot is distorted because there was a pressure port anomoly at higher velicities during the thrust phase ( working on a new feature in my data redux scripts to extrapolate reasonable air density when the raw pressure readings are so affected ).

Anyhow note that the Raw Pressure Altitude ( 14,824 ft ) is lower than the GPS Altitude ( 15,080 ft ) but that the Density Altitude of 16,057 ft exceeds the GPS Altitude by a bit for the 50 F Launch Site Temperature reported by Adrian.

Whee ! I love data !!

-- kjh

 

[cls]

Anyhow note that the Raw Pressure Altitude ( 14,824 ft ) is lower than the GPS Altitude ( 15,080 ft ) but that the Density Altitude of 16,057 ft exceeds the GPS Altitude by a bit for the 50 F Launch Site Temperature reported by Adrian.

Hi, what altitude does the integrated accelerometer give?


I think the baro altitude is the long leg, and the accelerometer is the hypotenuse, of a right triangle. So by Pythagoras we can figure the short leg, that is the distance downrange at apogee (not landing).

So the accelerometer is really a "distance traveled" a long some angle off vertical, not an altitude.

Yeah, data is fun!

 

[kjhambrick]

Hi, what altitude does the integrated accelerometer give?

Integrated acceleration that I came up with is IAlt = 16,239 ft ( see the altitude plots ).

I reintegrated via the Trapezoid rule using AXIAL acceleration only and subtracting the AXIAL 1-G offset just before liftoff when the rocket was on on the pad.

None of the off-axis acceleration data went into tmy IAlt calc.

I think the baro altitude is the long leg, and the accelerometer is the hypotenuse, of a right triangle. So by Pythagoras we can figure the short leg, that is the distance downrange at apogee (not landing).

So the accelerometer is really a "distance traveled" a long some angle off vertical, not an altitude.

Yeah, data is fun!

Yes, I ignored off-vertical components.

There are a few other users who calculate tilt angle vs time using integrated altitude and pressure altitude but I've not explored that yet so I can't comment

And I've not thought about it much but it seems that the pressure altitude should be the vertical side and the inertial should be the hypotnuse if one factors in the 3-d accelerometer readings ( actually a curve, not a line ), because an off-vertical rocket will travel a little farther along the flight path than the absolute vertical altitude would indicate ?

-- kjh

 

[Adrian A]

Integrated acceleration that I came up with is IAlt = 16,239 ft ( see the altitude plots ).

I reintegrated via the Trapezoid rule using AXIAL acceleration only and subtracting the AXIAL 1-G offset just before liftoff when the rocket was on on the pad.

None of the off-axis acceleration data went into tmy IAlt calc.



Yes, I ignored off-vertical components.

There are a few other users who calculate tilt angle vs time using integrated altitude and pressure altitude but I've not explored that yet so I can't comment

And I've not thought about it much but it seems that the pressure altitude should be the vertical side and the inertial should be the hypotnuse if one factors in the 3-d accelerometer readings ( actually a curve, not a line ), because an off-vertical rocket will travel a little farther along the flight path than the absolute vertical altitude would indicate ?

-- kjh

The Blue Raven integrates the gyro readings to calculate the attitude quaternion real-time during the flight, and then uses that to integrate the accelerometer readings to calculate the 3D velocity and position relative to the ground. As I discussed a little in that launch report, there was a time early in the flight when the rocket went through some weird dynamic oscillations that exceeded the 500 Hz sample rate of the gyros, and then later the roll rate exceeded the gyro max range. The combination of those on this flight resulted in an estimated tilt that was too high, as you an see from the inertial estimate for horizontal velocity vs. the GPS horizontal velocity measurement.

On other flights with more benign motion, the inertial navigation compares quite closely with the GPS measurements. Here you can see the gyro hit its range limit when the roll rate exceeded 2200 deg/sec:

 

[les]

I always heard GPS is less accurate in elevation than Lat/Long

I found this on the web...

Generally, Altitude error is specified to be 1.5 x Horizontal error specification. This means that the user of standard consumer GPS receivers should consider +/-23meters (75ft) with a DOP of 1 for 95% confidence. Altitude error is always considerably worse than the horizontal (position error).

 

[jderimig]

Barometric differential pressure altitude individual reading accuracy is superior to GPS altitude when near the ground. Pressure altitude error increases smoothly with gained altitude.

GPS altitude precision accuracy is independent of altitude. As altitude increase GPS altitude error will become a smaller fraction of the altitude. At some point, GPS altitude error will be less than pressure altitude error.

Barometric pressure apogee detection will always be superior to GPS apogee detection (as long there is significant air density) because barometric pressure error is monotonic, GPS altitude error is not.

 

[DaddyB]

Did you launch in a hypothetical air column at mid latitude? Your baro altimeter thinks so. Baro altimeters use a Standard Atmosphere Model.

GPS is more accurate for apogee. You may lose lock during high speed ascent, which may explain the gap in your data.

The SAM model can be replaced with the nearest balloon sounding measurements from the University of Wyoming, and thus become more accurate and closer to GPS.

View attachment 642576

Except the gap lasts about three times as long as the ascent, and it begins reporting again at apogee. I can't square that circle easily...

 

[rocket_troy]

Barometric pressure apogee detection will always be superior to GPS apogee detection (as long there is significant air density) because barometric pressure error is monotonic, GPS altitude error is not.

Obviously not the case for some RTK type systems, but I wonder if it's also the case for Galileo (which is supposed to be the most accurate of the various sat nav systems)? I know many modern baro sensors are sensitive (not necessarily accurate?) to very small changes to elevation, but I'm not convinced the base offset itself is terribly accurate. I made one altimeter with 2 identical baro sensors last year and there was a 3 mBar difference in offset between the 2.

TP

 

[jderimig]

Obviously not the case for some RTK type systems, but I wonder if it's also the case for Galileo (which is supposed to be the most accurate of the various sat nav systems)?

RTK is a different animal, and not used in any GPS unit commonly used in hobby rocketry today. I don't know enough about RTK to know how each receiver each maintains using the same constellation which I think is required. With GPS there is always altitude shifts as solution constellation evolves especially at startup. After that constellation is stable GPS altitude has decent accuracy and itself it is stable. Baro pressure differential is always stable. SAM errors accumulate as the vehicle ascends.

I know many modern baro sensors are sensitive (not necessarily accurate?) to very small changes to elevation, but I'm not convinced the base offset itself is terribly accurate. I made one altimeter with 2 identical baro sensors last year and there was a 3 mBar difference in offset between the 2.

TP

True, but rocketry altimeters commonly use a differential means for determining AGL. Weather alone can result 150m drift worth of barometric pressure.

For the sensors you used did the 3mbar difference conform to the spec sheet?

 

[Buster]

Yes !

Every TRA and NAR club needs one of these !
View attachment 642571



-- kjh

two or more!

 

[Buckeye]

Except the gap lasts about three times as long as the ascent, and it begins reporting again at apogee. I can't square that circle easily...

Nothing to square. As mentioned a few times in this thread, GPS losing lock when the rocket is going very fast is normal behavior. Then, the GPS reconnects when the rocket is moving more slowly near apogee. My data above is circa 2010 rocket GPS technology. In Adrian's more modern example, just a brief loss of data occurred.

If you need the complete flight profile from launch to touch down, then use your baro altimeter. Keep in mind that you will get discontinuities in that data as the rocket moves through Mach 1.

 

[rocket_troy]

For the sensors you used did the 3mbar difference conform to the spec sheet?

Yeah, looks like it ie. within the rather broad accuracy tolerance range. They were BMP180 sensors which I must admit aren't great sensors. Have since changed (MS5611), although still get quite an uncomfortable variance in offset. Trying Adrian's MS5540C or whatever it was next. Hopefully better luck there.

TP

 

[kjhambrick]

Just for fun, these are PAlt, DAlt and IAlt for Adrian's record breaking F10 flight in "Half Fast" on Oct 15, 2023.

Adrian's Build and Flight thread is here on TRF: Taking a Shot at the G-Record

To see the record entry, log into the TRA site, then see: Single-Stage F - Single

The punch line: the official GPS Altitude for the flight was 10,136 ft -vs- density altitude corrected for Site Temperature and Pressure was 10,408 ft:

Adrian reported that the Site Temperature was 55 F and the Blue Raven recorded the Site Pressure as 0.73810 atm / 747.87 mB / 8,162 ft.

Once again, like the calculation for the G12 flight, IAlt ( 9,958 ft ) is based on Axial Acceleration and the vertical 1-G offset only.

For completeness, this is the Acceleration -vs- Velocity cycle for the thrust and coast phase:


Note the very slight inflection at about 825 ft/sec in the density -vs- velocity curve during the thrust phase -- there may have been a slight pressure sampling anomoly in the F10 flight similar to the G12 flight around 825 ft/sec ...

-- kjh

EDIT: fix some grammar

 

[ihbarddx]

Temperature correction can make a substantial (substantial) difference in barometric altimeter accuracy. We tend to launch on warm days (above 15 degrees C), and on warm days, altimeter read-outs are short. On very cold days, altimeter estimates are long. There is a discussion of the issue to be found on the NAR website, in a document called _Care and Feeding of Altimeters_ by Dan Wolf. It can be found here (I hope)

https://www.nar.org/wp-content/uploads/2020/12/Care-and-Feeding-of-Altimeters.pdf

 

[cls]

Once again, like the calculation for the G12 flight, IAlt ( 9,958 ft ) is based on Axial Acceleration and the vertical 1-G offset only.

I'm going bald from scratching my head, trying to figure out, how could Ialt be so much smaller than Balt or Dalt?

 

[ihbarddx]

Barometric differential pressure altitude individual reading accuracy is superior to GPS altitude when near the ground. Pressure altitude error increases smoothly with gained altitude.

GPS altitude precision accuracy is independent of altitude. As altitude increase GPS altitude error will become a smaller fraction of the altitude. At some point, GPS altitude error will be less than pressure altitude error.

Barometric pressure apogee detection will always be superior to GPS apogee detection (as long there is significant air density) because barometric pressure error is monotonic, GPS altitude error is not.

Yes. Yes - although baro gets squirrelly around the tropopause.

 

[ksaves2]

Yes. Yes - although baro gets squirrelly around the tropopause.

Agreed. I think the baro reporting from just about any altimeter is more accurate than GPS reporting for sport fliers. Sure, if one is carrying a ground GPS on their person and walking around, the unit has time to get good fixes and can tell one's height above sea level with a decent degree of accuracy. A rocket is at apogee for less than a second, maybe more with a stupid arching trajectory. There is not enough time to get a good fix at apogee. Might be close but no cigar. I always tried to get my rockets to go as straight up as possible. I trust my deployment devices that record data more than GPS. GPS is to find the danged thing when it's down to recover.

Most of the time, it entailed pointing the rail a few degrees downwind for HPR. The wind would weathercock the rocket to go upwind thus actually keep the rocket as close to the pad as possible taking a curving path to apogee. The rocket would start going downwind but the wind would weathercock it to go upwind. Works better with HPR than modrocs. Even better when one gets to learn the launch characteristics of a particular rocket. Takes time if the rocket survives launches but I found I could get it dialed in over time. Takes time to get the hang of it at pointing the rail downwind. Just takes a couple of degrees maybe 3 or 4 in higher winds but it works.

Modrocs doesn't matter much. I'll aim my modrocs a few degrees into the wind and have decent flights. Since the rockets are smaller, the weathercocking effect is less. Depends on size and fin area. Kurt

 

[jderimig]

Yes. Yes - although baro gets squirrelly around the tropopause.

That's all accounted for in the SAM, PV=nRT is very very repeatable. Weather with respect to the SAM is not.

 

[ihbarddx]

The issue is temperature lapse with altitude (which is in the model). In the troposphere, temperature drops with increasing altitude. In the stratosphere, temperature, at first, doesn't change, and then rises with altitude - because of short wave UV absorption by ozone. The SAM model therefore changes at tropopause. Where the stratosphere starts varies seasonally, and diurnally.

 

[sr205347d]

This discussion of altimetry is interesting to me because of my background in aviation. I know little about the baro, GPS, and inertial sensors carried in rockets, though. Maybe what I add can help, I hope, rather than confuse.

In airplanes with the best air data computers and such, altitude precision is great, and it has to be so that airplanes aren't colliding. Accuracy of true altitude (MSL or AGL), though, isn't so great, and doesn't have to be, as long as all aircraft in the local sky are reporting the same. Accuracy isn't great because the reported altitude will vary from true altitude with pressure and temperature. Just as the surface pressure and temperature can change, so does the rate of change of pressure and temperature with altitude (lapse rate).

For most aircraft, the only time true altitude must be accurate is when close to the ground on approach and landing. Even with the correct field pressure set into the altimeter, a higher than standard temperature will cause an aircraft to be actually higher than indicated, and, with low temperature the aircraft will be lower than indicated, until touchdown. For this reason, minimum altitudes on approach must be increased if it is too cold. As the saying goes, high to low, look out below.

I flew aerial survey for six years. In this mission, the true altitude along with lateral position had to be determined with accuracy measured in centimeters in order to get survey quality results for the customers. Lidar sensors were used to map terrain and structure elevations. To get terrain elevation accuracy, the true altitude of the aircraft was crucial. The on-board equipment used GNSS sensors including GPS with WAAS. There were times, however, when the satellite geometry gave poor precision, and we had to hold our data collection until the satellites moved into good position.

But just on-board GPS wouldn't give centimeter accuracy. GPS base stations were set up nearby on pre-surveyed monuments to record the GPS errors during the missions. In post-processing, the measured error was subtracted from the position recorded in flight to get the best results.

Having said all that, it seems to me that the most accurate true altitude would come from good GPS equipment if it has a lock on the satellites at apogee, and the satellite geometry remains good.

 

[sr205347d]

Having said all that, it seems to me that the most accurate true altitude would come from good GPS equipment if it has a lock on the satellites at apogee, and the satellite geometry remains good.

I should clarify this sentence to say ". . . good GPS equipment with WAAS . . ."

I have no idea if WAAS equipment is available for our hobby rockets.

 

[Adrian A]

I should clarify this sentence to say ". . . good GPS equipment with WAAS . . ."

I have no idea if WAAS equipment is available for our hobby rockets.

WAAS support is enabled in the Ublox 10 modules used in the Featherweight GPS Trackers.

https://content.u-blox.com/sites/default/files/documents/SAM-M10Q_DataSheet_UBX-22013293.pdf

https://www.faa.gov/about/office_or...nits/techops/navservices/gnss/waas/howitworks

 

[sr205347d]

WAAS support is enabled in the Ublox 10 modules used in the Featherweight GPS Trackers.

https://content.u-blox.com/sites/default/files/documents/SAM-M10Q_DataSheet_UBX-22013293.pdf

https://www.faa.gov/about/office_or...nits/techops/navservices/gnss/waas/howitworks

"The M10 platform supports concurrent reception of four GNSS (GPS, GLONASS, Galileo, andBeiDou). The high number of visible satellites enables the receiver to select the best signals."

More satellites, more better!

 

[ksaves2]

GPS should be used to find rockets on recovery. The Featherweight Ublox 10 is probably good for really crazy flight altitude attempts were baro doesn't work well but the regular run-of-the-mill U.S. GPS system always found my sport rockets on recovery hence I still use "old stuff" successfully. It's that last transmitted position packet when the rocket is 50 to 100 feet in the air that's key. I had an integrated system that would put a position fix on a photomap and that was the cats meow back in the day. Using APRS and later when I figured out how to get Featherweight positions on a live map in realtime was really great.
Nothing like seeing that one's rocket landed to the side of a barn or missed a tree was really great from a computer or Android device photomap.

 

[Adrian A]

Using APRS and later when I figured out how to get Featherweight positions on a live map in realtime was really great.
Nothing like seeing that one's rocket landed to the side of a barn or missed a tree was really great from a computer or Android device photomap.

The Featherweight UI phone app has been doing this for quite a while now.

 

[ksaves2]

The Featherweight UI phone app has been doing this for quite a while now.

I hacked some proprietary software before there was a Featherweight phone app. If I start flying again, I'll download it.

 

[ksaves2]

Oh one other thing. When flying with GPS tracking try to put a noise maker on the harness too. I was close to a rocket one time but still 20 feet away.
Stupidhead here increased the zoom on the photomap program and I was able to walk to it. If I didn't have the sense to do that, a noisemaker on the harness is a heck of a tracker to use ones gray matter between their ears. Ears are really good for the terminal phase of effecting the final recovery. Of course that depends on the room that's in the rocket. Some rockets I have only have room for an RDF tracker and that's it. Kurt

 

[ihbarddx]

Tangentially related... I think...

Noticed something interesting in Adrian’s F10 data. Here is a graph of the Blue Raven’s rendering of vertical velocity (BR VY), and also, the numerically-differentiated barometric altitude/time curve (Baro VY). Notice that the barometric curve is above the inertial curve until cutoff, at which point it falls precipitously.


Next, I took the sines of the tilt angles (BR Sine), and also the ratio of the BaroVY values (above) and inertial total speeds (ratio labeled BaroSine). Both should estimate trajectory sine. Here’s what I got:



Things come together near apogee; however, before that, the barometric sine seems to have an acceleration curve imprinted in it.

FWIW, This may be evidence that barometric altimeters are affected, not only by aerodynamic processes at the static ports, but also by acceleration. (Or maybe everyone knew that. I always suspected it...)

 

[rocket_troy]

I had 3 flights over the weekend of my own hybrids which I intentionally run crazy unstable. I'm still developing my own flight electronics, so there was a bug in the code of the backup timer and they all deployed prematurely (just as well for the L flight) from that backup timer. Nevertheless, I was impressed with the correlation between the Ublox M9N and the MS5611 Baro sensor.

TP