Altimetry oddities

[buzz53]

I flew for the first time yesterday with my PAW classic and was a bit puzzled by the altitude logging in the track file. I wonder if somebody can help me understand what's going on? See the attached spreadsheet data. The $GPGGA columns are the MSA altitude from the corresponding records, in meters and then converted to feet for comparison with the figure from the $PGRMZ records, also in feet. I presume the $GPGGA records are just copies of the GPS, and the PGRMZ seems to be calculated from the onboard pressure transducer. The remaining columns are the calculated altitude difference, the corresponding pressure difference using 30 ft / mb, and finally the back-calculated QNH.

The first line is on the ground and everything here is perfect - the airfield height is 246ft, matching very closely the GPS altitude, and the calculated QNH is exactly as given by local ATC.

However as I climb the altitude difference changes drastically and in proportion to height. Obviously this is not going to match exactly due to the various altimetry subtleties, but a discrepancy of over 200 feet in 2000 feet seems excessive. What am I missing? My understanding is that the pressure altitude is used for collision avoidance so this seems quite important.

Alan

[grahambaker]

There are two (possibly three or four) factors to take into account here, bearing in mind that GPS altitude itself is a reasonably accurate true height above a datum.

1) The onboard pressure transducer will be calibrated to 1013; the QNH was 996 so that accounts for 510' of difference.
2) The temperature was well below ISA. This will mean that any altimeter will over-read against a true altitude by about 4' per 1000' of indicated height per degree of deviation below ISA.

These two factors need to be applied when comparing an altimeter against any measure of true altitude.

The third factor is that of Geoid undulation, which is a local adjustment to the WGS84 GPS datum. Lee will have to comment on whether this is a factor as some GPS chipsets know this stuff and apply it; some don't, but the nav device in which they are embedded may.

The fourth is that your altimeter may have some inaccuracies itself - within its tolerances, but nevertheless present.

[Ian Melville]

Cabin pressure may also differ to the outside pressure where your altimeter plumbed into

I must confess that I don't understand these 'chip' barometers. Flyer forum has a thread covering these as well. How do they self calibrate?

[buzz53]

Thanks, Graham.  Your first two points pretty much confirm my understanding of how it should all work, and in particular the sort of errors to be expected due to deviation from ISA. They are more than I had expected but still much less that what I saw. Assuming ground temperature of 5 degC, that's 10 less than ISA I believe, and would by your figures result in an overreading of 40 feet at 1000 feet, whereas I was seeing more like 100 feet per 1000 feet.

Regarding your third point, I think the Geoid correction is handled correctly as the GPS altitude very closely matched the airfield elevation. On the last point, I didn't fly for long at any set altitude so can't comment. Next time I'll fly some stepped heights to see how it compares to the altimeter.

Ian, I wondered about that but in that case I'd expect a fairly constant difference once I'd accelerated, but in this case it seems mainly dependent on height rather than airspeed. Actually I should probably plot the curve to see. I have used probably the same type of sensor in helium balloon trackers, and they are simply absolute pressure sensors, and in my experience very accurate. Any conversion to altitude must be done in the app.

Alan

[grahambaker]

Given the technologies involved, I’d suggest your pressure transducer is more likely to be dodgy than GPS dongle. It would be interesting to see your altimeter readings as well.

[buzz53]

I gathered some more data this weekend. This time l flew at stepped heights and the results are attached (it seems you need to log in to see them). There were various points of interest (well to me anyway).

1)   Taking Graham’s hint on the need to compensate for temperature, I corrected my altimeter reading (post-flight) accordingly (first table, column 4). Encouragingly the resulting calculated true altitude is a very good match to the GPS altitude (column 5). Whew!

2)   Next I looked the $GPRMZ data which seems to be the QNE (altitude referred to 1013mb) from the internal pressure sensor. The data sheet for the sensor is a little ambiguous as it talks of temperature compensation, but I don’t think this compensation is in the altimetry sense. So I think this is an indicated altitude, just as you would see on an altimeter. I therefore converted this to QNH by adding the appropriate offset for the day (300ft) and then calculated the difference between this and the altimeter reading. I would expect this to be small and fairly constant but in fact the PAW altitude sensor reading seems to increase too quickly – an error of about 130 feet at 3000 feet. The 1000 and 2000 foot data are a bit anomalous but maybe just noise in my data.

3)   I noticed while flying that PAW displays a QNH value on the home page. This was correct on the ground but  varied hugely during the flight. I assumed this must be back-calculated from the GPS altitude and the QNE from the pressure sensor. I also assumed the PAW cannot not know the deviation from ISA temperature. The second table shows my calculation of the QNH without temperature compensation and it matches what the PAW displayed (I only noted the QNH display at 1000 and 3000 feet). So I think my assumption is correct.

4)   Finally for fun I did the same QNH calculation with temperature compensation (table 3). This is better but still quite a bit out. This is just another effect of the (apparent) over-reading of the pressure sensor (in my case anyway).

Conclusions, based obviously on my experience only:

The displayed QNH value is not, and cannot be accurate even if the internal presusre sensor was accurate. I don’t think this is used for any other technical purpose so probably doesn’t matter hugely provided you know about it as it is confusing and obviously you wouldn’t want to be using it in flight!

My pressure sensor altitude is out by about 130 feet at 3000 feet. I suppose it’s not a lot (within tolerance I believe for certified transponder reporting) but it seems well outside the specified tolerance of these sensors and should be better. I doubt the sensor is wrong so my only other idea is cabin pressure difference. I would expect that to be dependant only on speed, which doesn’t match my data, although I didn’t actually record my airspeed. I suppose I could work that out from the log.

To do next: either find somebody with a balloon, or a mountain to take it up. The former is probably easier in Suffolk. Meantime, if anybody has a transponder with altitude display it would be interesting to hear how this compares at height with the QNE figure on the PAW homepage (it’s in the pressure sensor data).

Alan

[Seanhump]

To do next: either find somebody with a balloon, or a mountain to take it up. The former is probably easier in Suffolk. Meantime, if anybody has a transponder with altitude display it would be interesting to hear how this compares at height with the QNE figure on the PAW homepage (it’s in the pressure sensor data).

I'll take a look tomorrow - all our's have Garmin GTX 3xx's with ALT displayed ,...

[JCurtis]

The classic, I think, used the MPL3115A2 sensor from NXP.  This is accurate to 0.3m, I've tested one before just going up and down stairs and watched the reported value change.

They have internal temperature compensation, so if in altimeter mode they will give you your height in m with reference 1013.25 and are normally very accurate.

[buzz53]

Yes, it is indeed the MPL3115 and another look at the data sheet left me no wiser about interpretation of the "temperature compensation". However I found a really good app note at:

https://www.nxp.com/files-static/sensors/doc/app_note/AN4528.pdf

which explains it really well. It seems the compensation is for the internal mechanics of the MEMS sensor, to ensure an accurate pressure measurement over a wide range of temperature, it's not to handle atmospheric deviation from ISA. The altitude readout is therefore an "indicated altitude" with reference to 1013.2mb and assuming 15 degC. Considering the intended applications for the device, it seems this raw value would be more useful than a compensated one in most cases (e.g. if you wanted to make an actual altimeter with it, you'd need to undo the temperature compensation to get the same indicated altitude that everybody else is using).

This interpretation also gives the closest match to what I saw in flight. If the readout was compensated (true) altitude then (after adjusting for QNH) it would be even further in disagreement with the GPS and (nearly identical) altimeter indicated altitude.

That still leaves the matter of the increasing error with height on my unit. It's possible to individually calibrate the sensors, overriding the factory values, but I doubt PAW does this, nor would I have thought it was necessary to do so to get much better accuracy than what I am seeing. It may yet turn out to be cabin pressure, I'll investigate further.

Alan

[JCurtis]

Yes, the temp is only for internal use within the sensor.  You cannot really opt to use anything other than factory calibration, unless you are willing to run a calibrated pressure chamber in which to do it.  That takes quite some effort, and the factory calibration is basically spot on.

GPS altitude isn't that accurate either, and will be different to that from an altimeter, even with differential GPS.  This document explains it quite well... http://www.borgeltinstruments.com/GPSvsPressurealtitude.pdf

The PAW MPL3115 altitude should be a pretty good match an altimeter set to 1013.

You cabin will have some pressure, as any forward speed you have will come through vents etc. If you could hover (I'm a rotary pilot) then I suspect it would be spot on.  You could try adjusting your airspeed, and see if it changes the readings at any given altitude show up as a result.

[Robski]

If you could hover (I'm a rotary pilot) then I suspect it would be spot on.

In a hover wouldn't the whole area under the rotor disc be a high pressure area?

[Seanhump]

Fraid not … otherwise the altimeter wouldn't work!!

[JCurtis]

If you could hover (I'm a rotary pilot) then I suspect it would be spot on.

In a hover wouldn't the whole area under the rotor disc be a high pressure area?

Only in ground effect, which is only up to 1/2 the rotor disk diameter in height.  Even then it wouldn't cause a problem.

[Paul_Sengupta]

I had an issue with the pressure sensor on the first bridge board I bought. I got sent a new bridge board which was fine, and my faulty board is now used as part of my OGN-R station (which doesn't need the pressure sensor). 

[buzz53]

Finding this quite an interesting topic, I've been intermittently doing some more work on altimetry. The main thing I have learned is that, not being test pilot material, it really needs two people to fly accurately enough while writing stuff down! Until that happens I don't want to publish any more data but what I have seen so far has been quite an eye opener. For example, it appears that in my RV6, accelerating from 90 to 160 kts causes the discrepancy between GPS and baro height to change by about 100 feet at 2000 feet and 130 feet at 4000 feet. What's more, and rather surprisingly, this affects both the PAW sensor and the baro instruments driven by the official static which obviously raises several questions.

Now that the temperature is more ISA-like than when I first posted, the effects due to that are not so noticeable but as summer comes on I presume they will return in the opposite sense.

When I get some presentable data I'll report further.

Alan