Go Down

Topic: Altitude from atmospheric pressure (Read 15554 times)previous topic - next topic

Fabio Varesano

Jun 11, 2011, 06:34 pm
Hi everyone,

I'm currently working on the MS5611-01BA high precision pressure sensor. I designed a breakout board for it and I've been able to solder it on the PCB.

I'm now writing an Arduino library for using it and, so far, everything went pretty smooth.. I'm able to read successfully its pressure and temperature readings. The pressure readings I've got are in line with the local meteo station so everything looks pretty good.

Now, I'm trying to get an altitude estimation from the pressure and temperature readings. I'm using a simple Hypsometric formula as explained in this webpage.

I converted that formula into the code below:

Code: [Select]
`float getAltitude(float press, float temp) {  return ((pow((sea_press / press), 1/5.257) - 1.0) * (temp + 273.15)) / 0.0065;}`

where sea_press is:

Code: [Select]
`const float sea_press = 1013.25;`

Unfortunately, these give out an altitude estimate which is pretty wrong.. last test give out 440m of altitude while a correct value may be around 250m. However, it seems that relative altitude estimation is good (eg: if I go upstairs I read a difference of about 3m from downstairs).

Do you guys have ideas or references to compute the altitude in a better way?

Thank you,

Fabio Varesano

BenF

#1
Jun 11, 2011, 10:30 pm
When using your formula, you're computing an altitude against the barometric average reference which assumes a temperature of 15C and zero humidity. For any other condition (weather, temperature, humidity) your calculation will be incorrect.  For the calculation to be correct, you would need to calculate and use a sea-level reference based on current atmospheric conditions. This would require knowing your exact altitude and so back to square one.

In short, you can not calculate absolute altitude from pressure and temperature. Relative differences in altitude can be calculated, but only while weather conditions remain constant between the two sets of readings.

MarkT

#2
Jun 12, 2011, 04:41 am
Especially in England where we have many many weather systems passing overhead on an all too frequent basis!
[ I will NOT respond to personal messages, I WILL delete them, use the forum please ]

Bobnova

#3
Jun 12, 2011, 08:50 pm
It's essentially impossible for you to turn the device on and have it get the proper answer, high/low pressure fronts, temp, humidity and other factors all change the atmospheric pressure, and the device isn't going to be able to calibrate them all out.
Temp it can, roughly.  Humidity it can, roughly.  Both require additional sensors.  Weather fronts of high or low pressure however aren't something that can be sensed.

What you'll need to do is calibrated it fairly often, then it will be accurate until the temp or weather changes.

Fabio Varesano

#4
Jun 15, 2011, 05:23 pm
Thank you guys for your explanation. I hoped it would have been easier..

However, for my application, accuracy only on relative measuring is enough. See my last developments with this sensor.

BenF

#5
Jun 15, 2011, 11:15 pm

However, for my application, accuracy only on relative measuring is enough. See my last developments with this sensor.

Averaged GPS altitude cushioned by pressure readings passed through a Kalman filter should give a reasonable estimate when weather conditions are stable. Tuning the filter right however is challenging as weather is such a dynamic and unpredictable process. A number of handheld GPS units (some models by Garmin at least) include a barometric pressure sensor for this purpose.

Altimeters on airplanes however use only a barometric sensor. This is what is used to maintain vertical separation between airplanes and so is based on relative measurements against a common reference (established through a pre-flight calibration procedure).

If you proceed to implement this, it would be interesting to see some facts, figures and conclusions.

PaulS

#6
Jun 24, 2011, 03:13 pm
Quote
Does that last post smell of imminent spam to anyone else?

Actually, I think I got a whiff of some non-prescription drugs...

Paul J

#7
Jun 26, 2011, 12:18 am
I have a barometric sensor in my cycle computer, and basically I can calibrate the current height when I start riding, and from there it calculates height throughout the ride. When not in use, it goes into sleep mode, remembering the height. When restarted, it calibrates the pressure at the remembered height, allowing it to cope with different air pressures as weather systems go through. I can also set the home height, and press a home button to return to home height.

You could incorporate something similar in your device.

For clarification, as far as aviation is concerned, the barometric pressure setting on the altimeter is usually one of three possibilities: QFE, QNH or QNE. QFE is the pressure setting at your airfield which results in the height display showing above the field (Field Elevation). QNH is the current atmospheric pressure at sea level (Nautical Height), so gives the height above sea level. QNE is 1013.2mb, and is used when following Flight Levels (FL) as opposed to height (Cat A airspace). This is how vertical separation is assured - all aircraft in the airway use the QNE setting, so if the atmospheric pressure drops they all fly a bit lower, but maintain the gaps.

Fabio Varesano

#8
Jun 26, 2011, 12:25 am
Thanks Paul, this helps..

AltairLabs

#9
Jun 28, 2011, 08:47 pm
Does not look like anybody commented on the obvious problem and solution so here goes:

Code: [Select]
`const float sea_press = 1013.25;`

That means you are calculating Pressure Altitude which is the altitude on a Standard Day.  Of course most days are non-standard so the first order correction is to use the actual barometric pressure, which is the pressure you would measure at the bottom of a hole dug to sea level.

This is the method used in aviation, it will be correct at the runway elevation.  Either of two methods are uzxed: The baro setting is set to the value given by local ATIS or tower by dialing the pressure into the Kollsman window of an old altimeter or a menu page or knob for newer integrated digital avionics.  The other method is to set your altimeter to read the known runway elevation before you take off.

Both methods should give the same result, entering the pressure into the Kollsman window should cause the altimeter to read actual elevation, or setting the altimeter to read actual alavation should cause the local baro pressure to be displayed.

By setting sea_press to the actual baro pressure you eliminate the largest by far altitude error.

This causes your actual day to match Standard day at the ground elevation where the barometer is located.  Since the slope is different the altitude error slowly grows from zero at field elevation to many meters at altitude.  By convention, aircraft do not further correct their altimeters but since all good altimeters are the same it is not problem.  At cruise altitudes rather than dialing in baro setting for every point hey overfly, instead they revert to Standard day, as you do.  This is called "Flight Level" Again, all good altimeters show the same so every one is consistent.

If you want to take it further, it is possible to turn pressure altitude into density altitude, correct for gravity and the non-spherical geoid, etc., and eventually you can parlay pressure to get pretty darn close to geometric altitude anywhere.

So first make this simple change to set sea_press to your actual daily value and most of your error will disappear.  If this is not sufficient then hit me back and I will give you some more complicated corrections to get even closer.

BTW in the 1980s I did some precision altimetry using MCS-52 processor with a 20-bit dual-slope integrating ADC by Intersil, of type used in digital multimeters.  It was slow, only read at 1 Hz but had plenty of precision.  Calibration and temperature drift had to be strictly controlled.  Fortunately i lived across the road from the flight line so the local ATIS was a good baro standard.  Whenever a freight train passed there was a distinct "N" wave of pressure amounting to several ft, and on windy days the pressure distribution around the apartment building caused errors.

gerg

#10
Jul 13, 2011, 03:52 pmLast Edit: Jul 13, 2011, 04:00 pm by gerg Reason: 1

This causes your actual day to match Standard day at the ground elevation where the barometer is located.  Since the slope is different the altitude error slowly grows from zero at field elevation to many meters at altitude.  By convention, aircraft do not further correct their altimeters but since all good altimeters are the same it is not problem.  At cruise altitudes rather than dialing in baro setting for every point hey overfly, instead they revert to Standard day, as you do.  This is called "Flight Level" Again, all good altimeters show the same so every one is consistent.

I'm going to nit pick a little here. That's true only at >= FL18. Below 18,000 MSL, pilots must constantly update their Kollsman window with the current, local barometric pressure. Its so important, with just about every initial call to ATC they will provide current pressure. This is a requirement because typically the only aircraft flying at such altitudes are both pressurized and very fast. Which means, setting your altimeter would become an extremely tedious chore for pilots who need to be spending their time doing more important tasks. Since the majority of the world exists below FL18, errors induced by setting the altimeter to 29.92 at or above FL18 is not very likely to result in a collision; whereby they are already flying on instruments (IFR) anyways. Interestingly enough, class A airspace begins at FL18, which requires an IFR ticket for the pilot and certified IFR capabilities for the aircraft.

If you want to take it further, it is possible to turn pressure altitude into density altitude, correct for gravity and the non-spherical geoid, etc., and eventually you can parlay pressure to get pretty darn close to geometric altitude anywhere.

IIRC, you also need current temp and humidity.

So first make this simple change to set sea_press to your actual daily value and most of your error will disappear.  If this is not sufficient then hit me back and I will give you some more complicated corrections to get even closer.

Just as a reminder, barometric pressure can change rather rapidly from simple atmospheric changes. For example, with a front moving through, significant deviation can be measured in as little as five minutes (though likely high winds would be obvious). Without some source of altitude reference, you'll have no way of knowing if the pressure change was observed from altitude deviation or simple weather change. Likely you can begin to make some estimates so long as you have a reliable temp/humidity sensor and compensate accordingly for temp/humidity with altitude changes. Though this is exactly why pilots are required to constantly update their altimeter; as what is suggested here is extremely unreliable over time.

Determining altitude from barometric pressure without a calibrated reference is an extremely error prone approach. If accuracy over anything other than very short periods of time is required, I would encourage you to explore other paths.

Another approach might be to create your own ground based weather station, whereby altitude is fixed over time, which can then correct for temp/humidity and then transmit that to your aircraft, which can then correct accordingly. This scheme would be exactly like what pilots do by updating their altimeter. In this way the error will also be marginalized to +- xx-feet, based on the accuracy of the sensors involved.
http://maniacalbits.blogspot.com

AltairLabs

#11
Jul 16, 2011, 11:06 pm
Howdy Gerg!

Yes, I did mention Flight Levels, you even quoted me on it:
Quote
At cruise altitudes rather than dialing in baro setting for every point hey overfly, instead they revert to Standard day, as you do.  This is called "Flight Level" Again, all good altimeters show the same so every one is consistent.

But I passed over it briefly, since this thread by @Fabio Varesano seems to deal with ground altitude rather than flying.  @Fabio Varesano biggest error source by far is failing to use the baro setting, surprised nobody else caught it.

This one change can give surprisingly good results for ground elevations.  One old timer in our ham radio community would measure terrain height for an antenna location by waiting for calm weather and laying his precision barometer (mechanical) on the county court house steps, setting it, then driving it to the tower site, usually along with a car load of grandchildren and dogs.  Once we came to see a real survey crew set a pin near a tower we had already built and they got an altitude over 20 ft different than his barometer, he advised the surveyors to check again and he was right.

@Fabio Varesano can indeed get accurate terrain elevation from a barometer, but you do have to accurately account for the local pressure.

retrolefty

#12
Jul 16, 2011, 11:20 pmLast Edit: Jul 16, 2011, 11:25 pm by retrolefty Reason: 1
Quote
@Fabio Varesano can indeed get accurate terrain elevation from a barometer, but you do have to accurately account for the local pressure.

It's all about having access to an independent real time absolute pressure reference (barometric pressure) to 'adjust' your own barometer. If you can get your hands on a cheap portable radio that has "Air Band"  (air-band uses the frequencies between 108 MHz and 137 MHz AM) most (even small) local regional airports broadcast continuous real time temp, pressure information on a automatic audio loop for their local location. So using that location and looking up the elevation of their runway location, one has all the information to 'calibrate' one's own barometer.

gerg

#13
Jul 16, 2011, 11:46 pmLast Edit: Jul 17, 2011, 12:01 am by gerg Reason: 1

Howdy Gerg!

Hello!

Yes, I did mention Flight Levels, you even quoted me on it:

Please note I said I was going to nit pick - meaning being needlessly, overly critical. I was simply adding to and slightly clarifying the use of 29.92 on the altimeter at >= FL18. I did not mean to offend. It was more of an, "if anyone cares", level of detail. And even then I could have been less ambiguous in what I stated.

But I passed over it briefly, since this thread by @Fabio Varesano seems to deal with ground altitude rather than flying.  @Fabio Varesano biggest error source by far is failing to use the baro setting, surprised nobody else caught it.
...
@Fabio Varesano can indeed get accurate terrain elevation from a barometer, but you do have to accurately account for the local pressure.

I thought I had and addressed it. You can get an accurate altitude, but only so long as weather remains constant. In most places, this simply doesn't happen for very long, especially in the summer months. Even the heating and cooling of the day will change the reading. If you have an error of 2' when you're 1000' in the air, no one cares. But if you are 4' off the ground, that's a 50% error.  And that's exactly why when above FL18, everyone uses 29.92 because you're not likely to run into the ground at that altitude and everything else flying close enough to hit you should have the same error +- 50'. And so while your true altitude may be off by hundreds of feet, you're still so high its still not a noteworthy concern.

In this case, chances are his craft will be spending the majority of its time close to the ground. In fact, much closer than most private aircraft which spends most of its time < FL18 (average something like 6k-8k MSL), whereby pilots do constantly, manually, correct for barometric changes. There's a very good reason for that - weather happens and is rarely static for long.

So yes, absolutely, you can get accurate altitude, but only reliably for short periods of time. The further out you go from your baseline reference, the greater the probability of induced error and greater the error is likely to be. Accordingly, from the aircraft's perspective, it has no way of knowing if the induced error is because of a change in altitude or a change in weather. Now you can attempt to correct some with a temp/humidity sensor, but even that is only going to lessen to probable rate of decay over time rather than mitigate the error entirely. This may allow for enough compensation over a large enough window to not worry about things, unless you know some type of pressure system is moving through.

Furthermore, on days where fronts are moving through the area, even at a slow pace, the change over a span of fifteen minutes to an hour can still be significant, especially if beginning at mid morning whereby rapid heating is also likely to soon follow.

Long story short, unless you're willing to move forward knowing you have a very long list of caveats and an error which is very likely to grow over time, such a method for an aircraft is far from ideal without using a reference station as I previously outlined.

I don't recall reading anything about flight durations, but IMOHO, if they are around or over fifteen minutes or so, I wouldn't trust it without at least temp/humidity compensation. And beyond that, I wouldn't trust it for but maybe another fifteen or so; or at least not without a close eye on current weather and fixed altitude barometric readings so that you know with what error you're actually flying.
http://maniacalbits.blogspot.com

dc42

#14
Aug 22, 2011, 09:30 pmLast Edit: Aug 22, 2011, 09:32 pm by dc42 Reason: 1
I have a couple of small quibbles with gerg's post:

- when he says flight levels start at FL18 he really meant FL180 (approx. 18000 feet)
- but, while that is the case in US airspace, it is by no means universal. Here in UK the Transition Altitude (the level at which you switch between altitude above mean sea level and Flight Levels) is between 3000ft and 6000ft depending on where you are.
Formal verification of safety-critical software, software development, and electronic design and prototyping. See http://www.eschertech.com. Please do not ask for unpaid help via PM, use the forum.

Go Up

Please enter a valid email to subscribe