Altitude/Pressure calculus

The Rocketry Forum

Help Support The Rocketry Forum:

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

yo3ict

Member
Joined
May 31, 2021
Messages
15
Reaction score
10
To all the nerds out there...trying to figure out what is the general consensus in regards to getting the altitude from the pressure data.

On my flight computer, I use the hardcoded launch site altitude and the current barometric pressure to determine the sea level barometric pressure with the formula:

Current pressure = Sea level pressure / [(273+Temperature-0.0065*Altitude)/(273+Temperature)]^5.256

Then, with the known sea level pressure, I get the actual vehicle altitude during the flight with the backwards formula:

Altitude = -(273+Temperature) / 0.0065 * [(Current pressure/Sea level pressure)^0.190263 - 1]

, where many of the hardcoded numbers are coming from different parameters of the standard atmosphere model like the temperature lapse rate, universal gas constant, molar mass, etc.

What temperature to use in my calculations?

My barometric sensor also measures temperature, but it is the electronics temperature, not the environment.

If I am using the standard atmosphere model's 15C, then someone might legitimately argue why I'm not also using the standard atmosphere model's sea level pressure.
 
Where are you located? Do you have access to atmospheric sounding data?
 
Generally commercial altimeters assume 15 degrees C, and that's why we temperature correct in NAR competitions based on an at-launch-time air temperature.

I believe the usual approach is to calculate the current pressure altitude just before flight using the standard atmosphere, then use that as "0" for what follows. They then use the standard atmosphere with other pressure data throughout the flight.
 
I have played around with pressure to altitude conversion. No calculus required.
Lost count how many times I've seen a question raised on the internet involving rocketry and mathematics to which someone will spring up saying "you need calculus to answer that", when no calculus was actually required.

TP
 
Yeah, I get confused about temperature in the Standard Atmosphere Model, also. Here is one method for altitude vs. pressure. There is probably a 288.15K in those constants:

1632269504265.png
I like to "undo" the SAM from altimeter altitudes and recover the measured pressure via the equation above or similar ones (I wrote a VBA function in Excel for the 1976 Std Atm Model based on a NASA FORTRAN code I found). Then, I find the nearest sounding data on the University of Wyoming website, and do a table lookup for the altitude. This "correction" to the altimeter usually results in a 5%-6% increase in apogee AGL (on warm summer days) and aligns much more closely with GPS data.
 
Generally commercial altimeters assume 15 degrees C, and that's why we temperature correct in NAR competitions based on an at-launch-time air temperature.

I believe the usual approach is to calculate the current pressure altitude just before flight using the standard atmosphere, then use that as "0" for what follows. They then use the standard atmosphere with other pressure data throughout the flight.
The assumption is that the deviation from "actual" by using the STP model is going to be essentially the same throughout the relatively short flight of most rockets, so it cancels out when you subtract the rocket's ASL readings from the ground ASL reading. I don't know of any commercial altimeters that do an external temperature correction or allow you to input the launch site baro pressure and correct for that... but I could be wrong on that, of course. All of the digital baro sensors have an internal temperature sensor, but they're not very responsive.
 
jderimig : No access to sounding data.

UhClem, rocket_troy : Calculus as calculation, not as derivatives or integrals.

Buckeye : Right, but that involves sounding data. The formula is correct, and at first I apply it backwards, knowing the launch site pressure and altitude, to get the sea level pressure. I use it afterwards instead of the SAM's 1013.25. Is this a flawed approach?

BEC, cerving : Could you be more specific about the algorithm?

My altimeter calculates by itself the launch site sea level pressure, by knowing two things : the launch site elevation and the launch site pressure. Of course, calculating the sea level pressure involves the SAM, but the results are spot-on with the online data and with a Garmin altimeter-capable smartwatch.

Now, would applying the forecasted launch site temperature can improve the precision?
My baro sensor has a temp sensor as well, but it is located deep inside the avionics bay, so it senses the avionics temperature. But the barometer also senses the air at the avionics temperature...
 
Cris, The computer software that reads Adrel devices lets you put in the launch site temperature and adjusts its calculations to suit....but the easiest way to use this in NAR competition is to put in 15ºC regardless of the actual launch time temperature, then just use the temperature correction formula in the Pink Book on Adrel results same was as is done for all other contest-approved altimeters, which just assume 15ºC.
NAR Sporting Code said:
A competitor’s recorded altitude must be corrected for the effect of ambient air temperature by multiplying the uncorrected altimeter reading by a factor of (273.15 + T)/288.15 where T is the ambient temperature in degrees Celsius.

yo3ict (interesting screen name, are you in Wichita?): I am a user of altimeters, not one who writes the software, so I can't comment on the specifics of algorithms. They all, as far as I know, assume the standard atmosphere and store a local altitude based on it just before launch and treat this as ground level, then use the SAM in turn as reference for subsequent heights based on subsequent pressure measurements, as I mentioned before. As Cris noted, the assumption is that over the duration of a flight, this is close enough.

Your approach requires that wherever you fly you actually do know the launch site elevation (exactly where your pad is, as well as how far above the ground the rocket is on the pad), which you said earlier was hard coded. This seems pretty inflexible to me—do you always fly from exactly the same spot?—rather than doing as others do. The hard part is actually filtering out transients due to wind, sunlight falling on the pressure sensor, and the violent motions that occur especially at the ejection event which cause both mechanical stress on the sensor and transients in the static pressure wherever it is located. Those filters are the "secret sauce" that each altimeter maker has to cook up. The basic height AGL calculations themselves are relatively simple.
 
The simple answer is you cannot get accurate apogee height from any single sensor, the best you can hope for is a first order approximation. The more sensors your FC samples the closer you get to real altitude, but the math gets more complicated with each one. It's all an exercise in approximation.
 
The assumption is that the deviation from "actual" by using the STP model is going to be essentially the same throughout the relatively short flight of most rockets, so it cancels out when you subtract the rocket's ASL readings from the ground ASL reading.

For my high altitude flights (15,000-25,000 MSL) where I worry about this stuff, I noticed that the deviation of the SAM vs. sounding data seems to grow with altitude. I don't have an explanation for it. This is just an observation from a handful of my flights. So, the canceling out effect may not always be true.

1632311696826.png
 
For my high altitude flights (15,000-25,000 MSL) where I worry about this stuff, I noticed that the deviation of the SAM vs. sounding data seems to grow with altitude. I don't have an explanation for it. This is just an observation from a handful of my flights. So, the canceling out effect may not always be true.

View attachment 482975
That's definitely going to be true, the offset is based on a fixed number but the difference is actually going to grow exponentially. For sport flying, it's "good enough"... for competition, you get out the book and correct for launch site temperature, current baro pressure, and elevation.
 
Why not do what Joe Barnard does and NOT use a barometric sensor...use the accelerometer of an IMU instead...
Any comments???
 
The subject is baro altitude, but accelerometers have their own issues when used to determine altitude. The best IMU combination would be a 3-axis low-G accelerometer to determine initial orientation, a high-g z-axis altimeter to determine path distance, and a 3-axis gyro to compensate for movement in flight. Those 9-dof integrated units can only do that for low-G flights (under 16G, typically), such as the ones that Joe is doing. You need a combination of sensors to get it "right".
 
The "standard" convention for altimeters is to convert the pressure measurement to a pressure altitude from the standard atmosphere, assuming standard temp, and then use the difference between launch and apogee altitudes for flight altitude. The temperature correction can then be applied after the flight if desired. Beyond that with a baro sensor, you will need raw pressure measurements and sounding data. A (good) GNSS receiver can be far more reliable these days too.
 
The "standard" convention for altimeters is to convert the pressure measurement to a pressure altitude from the standard atmosphere, assuming standard temp, and then use the difference between launch and apogee altitudes for flight altitude. The temperature correction can then be applied after the flight if desired. Beyond that with a baro sensor, you will need raw pressure measurements and sounding data. A (good) GNSS receiver can be far more reliable these days too.
Yes Russ...glad to see someone who considers more than just a baro sensor for altitude measurements.
 
One thing that baro sensors have going for them (besides very low cost) is that they can generally be read up to 100x/sec. Accelerometers, too, can be read very quickly... in some cases, over 1000x/sec. Most GPS's read 1x/sec, and might be able to be set to 10x/sec. A baro or accelerometer can pick up things like deployment events that they didn't initiate, motor burnouts, etc. A GPS, not so much, even at 10x/sec. You are correct that a good GNSS GPS with a good antenna can detect altitude, and can be good for determining apogee; that's why TRA requires them for high-altitude records, along with some kind of non-removable recording mechanism.
 
The simple answer is you cannot get accurate apogee height from any single sensor, the best you can hope for is a first order approximation. The more sensors your FC samples the closer you get to real altitude, but the math gets more complicated with each one. It's all an exercise in approximation.
You can be certain of the altitude with one data point. More than that then you are never sure.
 
One thing that baro sensors have going for them (besides very low cost) is that they can generally be read up to 100x/sec. Accelerometers, too, can be read very quickly... in some cases, over 1000x/sec. Most GPS's read 1x/sec, and might be able to be set to 10x/sec. A baro or accelerometer can pick up things like deployment events that they didn't initiate, motor burnouts, etc. A GPS, not so much, even at 10x/sec. You are correct that a good GNSS GPS with a good antenna can detect altitude, and can be good for determining apogee; that's why TRA requires them for high-altitude records, along with some kind of non-removable recording mechanism.

Agreed, flight events are just looking for sign changes mostly. Even if your deployment altitude is 5% off nobody will notice. I mean even a few percent on apogee is generally not seen as a big deal either, thus the popularity of baro products.
 
Agreed, flight events are just looking for sign changes mostly. Even if your deployment altitude is 5% off nobody will notice. I mean even a few percent on apogee is generally not seen as a big deal either, thus the popularity of baro products.
Hummm....5% of 500 feet is 25 feet....5% of 1000 feet is 50 feet.. etc....someone should notice...
 
Why not do what Joe Barnard does and NOT use a barometric sensor...use the accelerometer of an IMU instead...
Any comments???


Well, Joe didn't calculate altitude with his IMU. As mentioned above, accelerometers have their own problems.
 
Agreed, flight events are just looking for sign changes mostly. Even if your deployment altitude is 5% off nobody will notice. I mean even a few percent on apogee is generally not seen as a big deal either, thus the popularity of baro products.

Nobody notices because most sport rocketeers think the baro altimeter measures the "actual" altitude in the "real world." The fact that baro altimeters use a model that is wrong most of the time is the best kept dirty secret in the hobby. Folks that complain about computer simulations not matching "reality" need to read this thread.

If you want good drogue and main deployments and an estimate of altitude, then the baro altimeter is cheap and reliable. If you want a more precise apogee measurement, then GPS (even the 1 Hz kind) is the way to go.
 
Nobody notices because most sport rocketeers think the baro altimeter measures the "actual" altitude in the "real world." The fact that baro altimeters use a model that is wrong most of the time is the best kept dirty secret in the hobby. Folks that complain about computer simulations not matching "reality" need to read this thread.

If you want good drogue and main deployments and an estimate of altitude, then the baro altimeter is cheap and reliable. If you want a more precise apogee measurement, then GPS (even the 1 Hz kind) is the way to go.

Thanks, Buckeye, for your candid (and truthful) comments about baro altimeters.

Therefore, a test is proposed.....
If anyone out there has multiple baro altimeters from multiple manufacturers (not the same mfg), then how about placing each one of them on the kitchen table (or equivalent) side by side, and seeing what altitude is displayed (flashes, beeps, LCD, etc) ...say...over an hour or two....and let us know the results.
 
Thanks, Buckeye, for your candid (and truthful) comments about baro altimeters.

Therefore, a test is proposed.....
If anyone out there has multiple baro altimeters from multiple manufacturers (not the same mfg), then how about placing each one of them on the kitchen table (or equivalent) side by side, and seeing what altitude is displayed (flashes, beeps, LCD, etc) ...say...over an hour or two....and let us know the results.
Not sure what that would prove. They would all just sit there as none of them would be triggered to start recording data. All of them require an altitude increase (the amount varies by maker, and for some how much the altitude has to change is configurable by the user) and some (Russ’ products) also require a minimum rate of change of altitude. Otherwise they remain in their “waiting to fly” state until they either power themselves down or run out of power (this also varies by maker). All of them would still be waiting to “ly after an hour or two unless the cells that power them were dying beforehand.

As I have noted elsewhere (the current NAR Member Guidebook and a recent article on altimeter venting in the Apogee Peak of Flight Newsletter are two places) and referred to here the results of different makers’ altimeters on the same flight generally differ very little in the reported apogee value. I have flown as many as six different maker’s altimeters at one time.

But that doesn’t, I suppose, address what you’re trying to get at….
 
Therefore, a test is proposed.....
If anyone out there has multiple baro altimeters from multiple manufacturers (not the same mfg), then how about placing each one of them on the kitchen table (or equivalent) side by side, and seeing what altitude is displayed (flashes, beeps, LCD, etc) ...say...over an hour or two....and let us know the results.
There is a NAR R&D report by Chris Kidwell from when he flew a mess of altimeters in a rocket around 20 years ago. A little searching ought to turn it up.
 
Not sure what that would prove. They would all just sit there as none of them would be triggered to start recording data. All of them require an altitude increase (the amount varies by maker, and for some how much the altitude has to change is configurable by the user) and some (Russ’ products) also require a minimum rate of change of altitude. Otherwise they remain in their “waiting to fly” state until they either power themselves down or run out of power (this also varies by maker). All of them would still be waiting to “ly after an hour or two unless the cells that power them were dying beforehand.

As I have noted elsewhere (the current NAR Member Guidebook and a recent article on altimeter venting in the Apogee Peak of Flight Newsletter are two places) and referred to here the results of different makers’ altimeters on the same flight generally differ very little in the reported apogee value. I have flown as many as six different maker’s altimeters at one time.

But that doesn’t, I suppose, address what you’re trying to get at….
Oh, yes...I recall your Apogee Newsletter article...and without any prior knowledge of the requirements for flight triggering on my part, my "static" (non-flight) test proposal seems undo-able at this point. However, what I'm trying to understand is the amount of repeatability, if any, there is from one altimeter mfg to the other at any given altitude...I guess we'll never know....but we certainly can with GPS from mfg to mfg.

So the choice comes down to cost, precision, repeatability and accuracy (GPS) versus (baro)...all comments are welcome.
 
To all the nerds out there...trying to figure out what is the general consensus in regards to getting the altitude from the pressure data.

On my flight computer, I use the hardcoded launch site altitude and the current barometric pressure to determine the sea level barometric pressure with the formula:

Current pressure = Sea level pressure / [(273+Temperature-0.0065*Altitude)/(273+Temperature)]^5.256

Then, with the known sea level pressure, I get the actual vehicle altitude during the flight with the backwards formula:

Altitude = -(273+Temperature) / 0.0065 * [(Current pressure/Sea level pressure)^0.190263 - 1]

, where many of the hardcoded numbers are coming from different parameters of the standard atmosphere model like the temperature lapse rate, universal gas constant, molar mass, etc.

What temperature to use in my calculations?

My barometric sensor also measures temperature, but it is the electronics temperature, not the environment.

If I am using the standard atmosphere model's 15C, then someone might legitimately argue why I'm not also using the standard atmosphere model's sea level pressure.

In short, I would say use the temperature from your barometric pressure sensor.

In long, here is my method which requires multiple sensors:

1) Get the base altitude of the rocket while on the pad from the onboard GNSS unit
2) Using the base altitude, barometric pressure and barometric temperaturre, correct for the sea level pressure
3) Use the corrected sea level pressure along with the barometric pressure and temperature to estimate the in-flight altitude
4) Combine this with a weighted average combining the IMU integrated altitude and GPS if the fix is good enough (often not)

The result usually looks like the graph below

Flight Profile.png
 
Thanks, Buckeye, for your candid (and truthful) comments about baro altimeters.

Therefore, a test is proposed.....
If anyone out there has multiple baro altimeters from multiple manufacturers (not the same mfg), then how about placing each one of them on the kitchen table (or equivalent) side by side, and seeing what altitude is displayed (flashes, beeps, LCD, etc) ...say...over an hour or two....and let us know the results.
Not conclusive but I have had customers fly Marsa's with MW, Perfectflite and Ravens and they all reported the same apogee altitude. So I am guessing those 3 are using the same SAM pressure to altitude equation. Pressure to altitude equation is pretty much 'settled science' by now.
 
Richard Nakka tackles this on one of his web pages, may be a worthwhile read.

http://www.nakka-rocketry.net/apogee.html

Dave

Dave,

Very good data!!

If the interpretation is right, it looks like the correct temperature is the key to accuracy with a baro.

Also, GPS (the American version) is probably not accurate enough for altitude since the VDOP (Vertical Dilution of Precision) is not in the centimeter range as are some of the newer types up there.
 
Back
Top