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.
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.
One that old would certainly not represent the performance of current devices....no offense to Chris, who, among other things is the creator and maintainer of NAR's Contest Manager software (which, when given the launch time temperature, does the calculation I mentioned above as part of the data entry process).
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.
So that leaves the quality of the sensor used and the filtering of spurious data (the "secret sauce" I mentioned earlier). They all should be using the same equation...
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.
Don't know about various GPS (or Glonass or whatever) devices. I presume they have to have some kind of onboard data capture/filtering/recording software as well, so there is room, I would think, for some minor variation at least between devices. But I don't know that.

I've got LOTS of multi-manufacturer altimeter flights over the years....I just cite one particular one in the Apogee article (and in the NAR Member Guidebook). What I don't have are lots of multi-device flights much above 1000 feet, since I'm pretty much an LPR kind of guy.

Since I've been talking about it, here's the comparison graph (well, a .jpg version of it) that's in the Apogee Peak of Flight article. I've sent a version of this without the Adrel trace to go into the online version of the NAR Member Guidebook altimeter article (I don't talk about the Adrel in the Guidebook piece). This flight, for those who are keeping score, took place at Sixty Acres Park in Redmond, Washington. Per the data stored by the app for AltimeterThree, it took place at 2:14 PM from a point just a little south and east of the center of the north field at that park. I do not know (and don't really care) what the precise MSL altitude of my launch pad was that day.

Mini Hulstler flt 17 Comparison.png
 
Last edited:
In my humble opinion, for contest applications, estimation of the true altitude is less important that calculating the altitude the same way if using barometers. Every device should have the same systemic error. Otherwise there will be an incentive to select a device with the most positive bias of that estimation.

Barometric sensors are ill suited for determining true altitude. But they are very well suited for determining pressure difference from ground to apogee.
 
In my humble opinion, for contest applications, estimation of the true altitude is less important that calculating the altitude the same way if using barometers. Every device should have the same systemic error. Otherwise there will be an incentive to select a device with the most positive bias of that estimation.

Barometric sensors are ill suited for determining true altitude. But they are very well suited for determining pressure difference from ground to apogee.
I absolutely agree with this. And it's a darn sight better and more consistent than optical tracking, even with two stations manned by experts in using the equipment. (That ought to bring out a certain set of comments....:p)

If one wants the true altitude (and defining relative to where exactly would have to be part of that discussion, I would think) clearly some kind of sensor fusion approach as has been discussed here makes sense to me. Which takes us back to the beginning and the OP (who hasn't reappeared) and his suggesting that he's hard-coded in the actual altitude of his flying site into his flight computer for the starting point.

What is the actual objective, one wonders.
 
Last edited:
I absolutely agree with this. And it's a darn sight better and more consistent than optical tracking, even with two stations manned by experts in using the equipment. (That out to bring out a certain set of comments....:p)

If one wants the true altitude (and defining relative to where exactly would have to be part of that discussion, I would think) clearly some kind of sensor fusion approach as has been discussed here makes sense to me. Which takes us back to the beginning and the OP (who hasn't reappeared) and his suggesting that he's hard-coded in the actual altitude of his flying site into his flight computer for the starting point.

What is the actual objective, one wonders.
Temperature corrected SAM is pretty darn good, and relatively simple. Simple SAM should get you within 5% 2 sigma, temp corrected SAM probably 2%. Beyond that sensor datasheet variance will be the limit.

GPS error is dependent on the constellation geometry at the time of fix. Good be good or terrible on any given flight.
 
You really need an external temperature sensor, the ones internal to the baro sensors aren't very responsive. They're fine for weather stations that don't move... rockets are a different animal. I'm not aware of any hobby altimeters that have one, though... again, for sport flying, the baro sensors are "good enough". Most flyers are more interested in getting the laundry out and getting a reasonably good apogee figure than high accuracy; accuracy costs a lot more and is a lot more fiddly. Do the contest-certified baro altimeters use an external temperature sensor? If not, you're back to correcting for temperature and site baro pressure manually... you could do that with any baro altimeter.

And yes, GPS altitude accuracy can be variable too... seen plenty of that.
 
You really need an external temperature sensor, the ones internal to the baro sensors aren't very responsive. They're fine for weather stations that don't move... rockets are a different animal. I'm not aware of any hobby altimeters that have one, though... again, for sport flying, the baro sensors are "good enough". Most flyers are more interested in getting the laundry out and getting a reasonably good apogee figure than high accuracy; accuracy costs a lot more and is a lot more fiddly. Do the contest-certified baro altimeters use an external temperature sensor? If not, you're back to correcting for temperature and site baro pressure manually... you could do that with any baro altimeter.

And yes, GPS altitude accuracy can be variable too... seen plenty of that.
Contest approved altimeters do not have an external temperature sensor (at least none of the current ones do). As I noted a couple of times before, at contests the procedure is to note (on the flight card), the ambient temperature (in the shade) when the model is checked in before a flight and then that temperature is used to correct the altitude score, using the formula I quoted earlier. At a given contest there is no attempt to correct for the at-flight-time site barometric pressure. Since whatever it is, at liftoff it is used to set the reference zero height (within a very short time before the flight, per the requirements in the rules—see section 20.2 here), it doesn’t really what that pressure is as all we’re interested in is how high above the starting point did the model go, not the absolute MSL value of that altitude.

Yes, conditions can vary over the duration of the contest, but barring severe weather, it’s not going to mess with things that much.
 
And that's the point... it's all relative. Unless you're going real high, the error is going to cancel out. Even then, the error isn't a whole lot compared to your altitude... maybe a few percent at most. For contests, it matters... for sport flying, not so much.
 
Contest approved altimeters do not have an external temperature sensor (at least none of the current ones do). As I noted a couple of times before, at contests the procedure is to note (on the flight card), the ambient temperature (in the shade) when the model is checked in before a flight and then that temperature is used to correct the altitude score, using the formula I quoted earlier. At a given contest there is no attempt to correct for the at-flight-time site barometric pressure. Since whatever it is, at liftoff it is used to set the reference zero height (within a very short time before the flight, per the requirements in the rules—see section 20.2 here), it doesn’t really what that pressure is as all we’re interested in is how high above the starting point did the model go, not the absolute MSL value of that altitude.

Yes, conditions can vary over the duration of the contest, but barring severe weather, it’s not going to mess with things that much.
I think this is the best you can get. I would distrust the implementation of temperature sensors on the altimeter. Av-bay temperatures can be quite different than atmospheric temps. Too late now but if I had a magic timestone I would request contest approved altimeters to simply report pressure.
 
I think this is the best you can get. I would distrust the implementation of temperature sensors on the altimeter. Av-bay temperatures can be quite different than atmospheric temps. Too late now but if I had a magic timestone I would request contest approved altimeters to simply report pressure.
This is essentially what the Adrels do. The Windows app does pretty much all the rest of the work from there.

Of course in contest models there are seldom “av bays”, but at the same time we generally don’t just stuff the altimeter in with the recovery bits without some kind of separate compartment.

If all they did was report pressure, how would you then generate an altitude value/score?
 
In my humble opinion, for contest applications, estimation of the true altitude is less important that calculating the altitude the same way if using barometers. Every device should have the same systemic error. Otherwise there will be an incentive to select a device with the most positive bias of that estimation.

Barometric sensors are ill suited for determining true altitude. But they are very well suited for determining pressure difference from ground to apogee.

It works for airplanes. While on the ground we get a current altimeter setting from the AWOS or ASOS. Some uncontrolled fields don't have AWOS or ASOS so you go with what the closest field that does has. In flight the altimeter and GPS rarely (as in not quite never) agree perfectly. Once you get to the FL180 (18,000), everyone sets the altimeter to 29.92. I don't because if I'm at 18,000' in the airplanes I fly an alien ship has put me in a tractor beam and hauled me up there. So far, as far as I know, that's never happened.
 
It works for airplanes. While on the ground we get a current altimeter setting from the AWOS or ASOS. Some uncontrolled fields don't have AWOS or ASOS so you go with what the closest field that does has. In flight the altimeter and GPS rarely (as in not quite never) agree perfectly. Once you get to the FL180 (18,000), everyone sets the altimeter to 29.92. I don't because if I'm at 18,000' in the airplanes I fly an alien ship has put me in a tractor beam and hauled me up there. So far, as far as I know, that's never happened.
But for airplanes altitude accuracy is just needed at the runway elevation which is what you calibrate to. Once you are in the air keeping planes at different atmospheric pressures will keep them apart. The report altitude is just a number that correlates to a given pressure. The reported altitude will have error because the calculation is still using SAM. SAM error can be +/- 5% easily.

When ATC asks you to maintain FL180, they are in effect asking you to maintain a pressure corresponding to the SAM model pressure at 18000 ft. As weather changes your actual altitude is going to wander up and down.
 
Last edited:
But for airplanes altitude accuracy is just needed at the runway elevation which is what you calibrate to. Once you are in the air keeping planes at different atmospheric pressures will keep them apart. The report altitude is just a number that correlates to a given pressure. The reported altitude will have error because the calculation is still using SAM. SAM error can be +/- 5% easily.

Picking nits but when I fly from KFMN, field elevation of 5,507', to KPKV, field elevation of 32', VFR, or even KLXV, field elevation 9,934' (haven't done that in over a decade), and I don't get flight following, it's on me to get an altimeter setting enroute. And it's easy to forget to do that. Even ADSB goes off of the altimeter. Below 3,500' AGL we don't have to fly a specific altitude so, in theory, the setting error could cause issues. Like is said, picking nits, but it is an important number. Less so for local flights. Airlines are always IFR and have rules to keep them away from each other.

Besides all that...I am amazed that we have rocketry electronics as good and as small as it is.
 
SAM calculator app.
In that case, how would you filter out the spurious data to figure out which pressure datum to use in the calculator app? There is a bunch of it in even a nominal rocket flight, and a bunch more when the ejection is early (common in altitude competition because long enough delays aren't available). This sort of thing generates all kinds of spikes and noise in the raw pressure data. That filtering is key to getting an apogee value that is a good representation of what actually happened on a given flight.

I've done flight testing for more than one altimeter vendor where refining that filter was one of the key things that needed to be done, and for which more than one version of firmware was needed to get to something that worked well enough.
 
It works for airplanes.

Well, I would say it differently. Our airspace system has been designed to accommodate the inaccuracies of barometric altimeters. Nobody will know or care if you're 5% off in the pattern. Things that really matter like MOCAs have big margins. Even a standard approach with vertical guidance will only get you down to 200' DH. Beyond that, you switch to a radar altimeter. I'm not sure if the FAA actually defines what uncertainties they keep for altimeters but it's built into everything.

I've done flight testing for more than one altimeter vendor where refining that filter was one of the key things that needed to be done, and for which more than one version of firmware was needed to get to something that worked well enough.

Thanks @BEC! I'll also add that different applications may have different, even competing, filtering goals. A deployment controller trying to time an apogee event is different than a competition altimeter looking for a peak altitude. Messy data just complicates everything.
 
In that case, how would you filter out the spurious data to figure out which pressure datum to use in the calculator app? There is a bunch of it in even a nominal rocket flight, and a bunch more when the ejection is early (common in altitude competition because long enough delays aren't available). This sort of thing generates all kinds of spikes and noise in the raw pressure data. That filtering is key to getting an apogee value that is a good representation of what actually happened on a given flight.

I've done flight testing for more than one altimeter vendor where refining that filter was one of the key things that needed to be done, and for which more than one version of firmware was needed to get to something that worked well enough.

Two methods:
1. Manually. The eye brain does a good job of separating the ballistic pressure curve from the noise.
2. Standardize on a digital filter or Kalman filter knowing that apogee events are low frequency content and a well selected low pass filter will do the job automatically that method 1 does.

However for 2 there would need to be a selection process to standardize the algorithm and someone with signal processing knowledge as part of your standardization team.
 
Is your model rocket baro altitude "correct" or "consistent"??

In re-reviewing this great link from Dave http://www.nakka-rocketry.net/apogee.html#Introduction....thanks again, Dave...it appears that is has been "deemed" that the Base Temperature must be 15 degrees C for baro altimeters. And any mfg that deviates from this number with their own temp sensor "may" be more correct in flight, but not consistent with the others in terms of altitude. IMHO this means that competition flights may all be wrong as far as a correct altitude reading, but consistent with one another...thus a winner would be one who have the highest (wrong) altitude based on a fixed 15 degree C input to the equations. This makes sense if you're NAR or some other governing body that holds these competitions.

But now comes GPS with sub-meter, or better, precision at any altitude or speed (https://www.u-blox.com/en) and all of a sudden things change. Welcome to the 21st Century. What to do now? Stay with the cheap (baro) solution or upgrade to something more accurate?
 
2. Standardize on a digital filter or Kalman filter knowing that apogee events are low frequency content and a well selected low pass filter will do the job automatically that method 1 does.
I will speak only about the Kalman filter but similar arguments apply to other filter types.

The Kalman filter does not do a great job of filtering out apogee events because it isn't really designed for that. The primary filter assumption is that all noise is random with a gaussian distribution. The apogee event doesn't fit those assumptions.

For a constant gain Kalman filter of the type that I wrote my R&D report on, the filter is going to add a fixed percentage of the latest sample, noise and all, into the current estimate. That percentage can be quite large particularly with low sample rates. So a lot of that apogee event can and will make it past the filter.

Digging into some notes I made while looking into the MicroPeak altimeter I found that it had this problem. The Kalman gain for altitude was ~0.38. Yikes. Multiply that by the error (difference between current estimate and measurement) and add to estimate. Which means that 38% of the apogee event makes it through.

You aren't going to beat the Mark 1 Eyeball that way.
 
Is your model rocket baro altitude "correct" or "consistent"??

In re-reviewing this great link from Dave http://www.nakka-rocketry.net/apogee.html#Introduction....thanks again, Dave...it appears that is has been "deemed" that the Base Temperature must be 15 degrees C for baro altimeters. And any mfg that deviates from this number with their own temp sensor "may" be more correct in flight, but not consistent with the others in terms of altitude. IMHO this means that competition flights may all be wrong as far as a correct altitude reading, but consistent with one another...thus a winner would be one who have the highest (wrong) altitude based on a fixed 15 degree C input to the equations. This makes sense if you're NAR or some other governing body that holds these competitions.

But now comes GPS with sub-meter, or better, precision at any altitude or speed (https://www.u-blox.com/en) and all of a sudden things change. Welcome to the 21st Century. What to do now? Stay with the cheap (baro) solution or upgrade to something more accurate?
*sigh*

Consistent, first. And as you note, in a competition setting, that's really all we want. The actual value of the score is less important (save for record-setting) than that the model which flew the highest in the event at that contest is the one declared the winner.

As I've noted several times in this thread already, in competition the altitude scores are temperature-corrected post-flight using a temperature recorded when the model is checked in before the flight based on the 15ºC baseline temperature. One maker allows the user to do this in the application which reads the pressure data and input a temperature (Adrel) but after going back and forth about how to deal with that at NARAM-60 the procedure at a contest is to input 15ºC into the Adrel's Windows program and then treat an Adrel like all the others.

Right now there are two competition-approved altimeters that weigh under 1.6g as loaded aboard the model (including the cell to power it)—the FS Comp is just under 1.0g. I wonder when anything that uses satellite data can get anywhere near that. It could happen, I suppose....though I am not going to hold my breath as to when, nor how soon the price of such a device would be low enough that I'd risk it in a model rocket flight, especially for the higher total impulse classes, where I might not ever get it back anyway....

Manually. The eye brain does a good job of separating the ballistic pressure curve from the noise.
Actually, given a time vs. pressure plot I would tend to agree. I've looked at some raw pressure data, as well as some calculated altitudes where the filtering didn't filter obvious spurious data, and it is indeed generally very straightforward to spot the real apogee (or the datum closest to it, which at 20Hz is probably close enough).
I will speak only about the Kalman filter but similar arguments apply to other filter types.

The Kalman filter does not do a great job of filtering out apogee events because it isn't really designed for that. The primary filter assumption is that all noise is random with a gaussian distribution. The apogee event doesn't fit those assumptions.

For a constant gain Kalman filter of the type that I wrote my R&D report on, the filter is going to add a fixed percentage of the latest sample, noise and all, into the current estimate. That percentage can be quite large particularly with low sample rates. So a lot of that apogee event can and will make it past the filter.

Digging into some notes I made while looking into the MicroPeak altimeter I found that it had this problem. The Kalman gain for altitude was ~0.38. Yikes. Multiply that by the error (difference between current estimate and measurement) and add to estimate. Which means that 38% of the apogee event makes it through.

You aren't going to beat the Mark 1 Eyeball that way.
Keith worked on the MicroPeak's filter quite a bit in the first couple of years of the device's existence. One would wonder which version of the firmware your comments are based on. But I have not tried to understand the details here, so your analysis may well be up to date. I just know that current MicroPeaks, when flown alongside others (PerfectFlite's devices seem to be considered the most reliable/consistent/correct in this context, which is, I suppose, why they are the only choices for TARC) are generally right in there, as the graph I posted overlaying six different ones earlier shows. All bets are off if the MicroPeak's pressure sensor gets a burst of sunlight on it at the wrong time, though.

Also, to my mind, at least, you're not trying to filter out the apogee, you're trying to filter out the stuff that is around apogee that will result in an artificially high reported value, leaving the true apogee data in place. Ejection events and the associated violent motions (especially when it's early) as well as the resulting pressure transients around whatever portion of the model the altimeter is riding in can generate all kinds of spikes in the data in both higher pressure/lower altitude and vice versa.

I have to say that this has been a fun discussion, and I suspect the OP got rather more than he bargained for.... :)
 
Is your model rocket baro altitude "correct" or "consistent"??

In re-reviewing this great link from Dave http://www.nakka-rocketry.net/apogee.html#Introduction....thanks again, Dave...it appears that is has been "deemed" that the Base Temperature must be 15 degrees C for baro altimeters. And any mfg that deviates from this number with their own temp sensor "may" be more correct in flight, but not consistent with the others in terms of altitude. IMHO this means that competition flights may all be wrong as far as a correct altitude reading, but consistent with one another...thus a winner would be one who have the highest (wrong) altitude based on a fixed 15 degree C input to the equations. This makes sense if you're NAR or some other governing body that holds these competitions.

But now comes GPS with sub-meter, or better, precision at any altitude or speed (https://www.u-blox.com/en) and all of a sudden things change. Welcome to the 21st Century. What to do now? Stay with the cheap (baro) solution or upgrade to something more accurate?

I think we've drifted a bit from actual application... Specifically for NAR competition where we're talking under a few thousand feet from the surface, a temperature corrected standard atmosphere is darn close enough to be considered "right". As @BEC mentioned, it will be a long time, possibly never, before a sat based system will be competitive with current altimeters. Above 30k, TRA requires GPS for records where it's harder to use the std atmosphere model and barometers really start to struggle. In-between is a gray area and I think the next few years will start to bring GNSS more into mainstream use and not just for tracking.

The Kalman filter does not do a great job of filtering out apogee events because it isn't really designed for that. The primary filter assumption is that all noise is random with a gaussian distribution. The apogee event doesn't fit those assumptions.

Any filter will struggle with a big spike from an ejection event. In practice, it is helpful to pre-filter the data before the Kalman. You can reject any obviously wrong samples, propagate the model and just wait for the next time step. The Kalman filter works quite well after that.
 
Back
Top