Estimating GPS vs BARO height - some thoughts

My Skywalker X-5 equipped with a MiniAPM 3.1 controller running latest ArduPlane V3.4.0.

ALT_MIX is still present in Mission Planner “Full Parameter List”, but missing in the documentation Obsolete?
ALT_OFFSET is present in both lists.
So far I have had no use of above parameters, and they are probably not going to help in the situation I shall try to describe.

Some days ago I run a mission high up in the mountains with my trusted X-5. Planning the mission I had to calculate the waypoint altitude in order to clear the highest mountain top. I suspected there might be some BARO height error, so I added 120m to the highest point, just to be safe. The flight started near MSL, ab. 3m above sea level.

Looking at the log after the flight, I noticed a discrepancy of 50m at the altitude of 880m - GPS altitude was 830m and BARO 880m (programmed waypoint height). Furrther investigation revealed that there was a linear function between the GPS altitude and BARO elevation, i.e. BARO indicating ab. 6% higher than GPS. I have seen this tendency before in other missions, resulting in one narrow escape. Now I became curious and looked at some other X-5 logs and also logs from my TekSumo with the same controller. About the same 6% scaling error showed up in all the logs! Except for my Bixler 2, Pixhawk Lite with Arduplane V3.5.2 - only ab. 2% scaling for a some flights.
All my BAROs are covered with foam, and I have not seen more than 2-3m BARO drift due to temperature/QNH during long flights, up to 20 minutes.
Please have a look at the graph below for the X-5 flight.

It has been argued in many posts that the GPS altitude may be incorrect and unreliable, but in this particular flight I think it is correct. Look at the picture below: The GPS indicates that the plane is at 762m ASL and altitudes from the maps aligned pretty good to the (foggy) horizion - suggesting that the M8N GPS is OK.

I know I am late to the table, and that FW updates for APM are discontinued. Still, would it not be nice to have a scaling parameter for BARO to compensate for this type of scaling error - both for APM and Pixhawk (1&2)? It will not take care of other height estimate errors like air pressure/temperature drift, but should make a better basepoint for a particular controller.
This is not a big issue for me now, but it may be problematic that the “inflated” BARO height results in missions not reaching the programmed altitude, specially in case of high altitude flying. It would have been better the other way around. I understand that other functions are at play here (based on EKF), but I guess GPS input is not used in altitude estimations?

The video may show some more detail about the flight. At 2:44 you can enjoy the look at the result of a bad AutoTune in calm weather - a bit too agressive pitch PID setting for windy conditions :-). PID values are now lowered manually for the next flight…

Happy flying!
Regards Jan

I have a similar problem. And I’m now very interested in this case.

In my case, BALO alt is 5% higher than rangefinder’s(SF11) alt.
i guess it was due to temperature.

My BALO alt was seems to be calculated by 22.5C,(GroundTemperature in my log file).
But actual ground temp. is 6 C.
After flying, i calculated by my self using BALO pressure and actual temp.(6 C).
This calculated alt is almost same value as RangeFinder’s alt.

How about your case?
Is BALO GroundTemperature much higher than actual temperature, or not?

“Arigato” for your reply, YANO!

Looks like you have similar tendencies in your case, baro reporting higher values than GPS (and even more for Rangefinder) depending on altitude. From your graph it looks like your GPS/BARO error is only ab. 3.3% - and your Rangefinder/BARO is ab. 6% (same as mine).

Sorry, I cannot follow you on your temperature reasoning. How did you calculate the altitude by baro pressure and “Actual Ground Temperature”?
On my X-5 the controller is enclosed in the plane. Even if the outside temperature varies, I think (in my simple mind :grinning:) the baro device temperature is more dependent on controller heating up inside the plane and in the controller case. I think the temperature inside the plane will only slowly change because of outside temperature and the influence of the big battery heating up during flight. BTW, the outside temperature decrease with height is only ab. 0.5°C pr. 100m (called “Lapse Rate”).
I don’t log baro temperature at the moment because of memory limits on the APM, I prefer to log other data for my purpose. But from my experience earlier I have not seen such big height fluctuations due to temperatures, but I my be wrong!

For my old APM my point is, since it looks like the ArduPlane’s altitude estimation is based on what the baro device is reporting, it should receive the best possible value - maybe by scaling the baro height with an observed value at different elevation(s). My observations also indicates that these values are pretty much linear and consistent.
In the newest hardware and firmware I think this is taken better care of with temperature control (PixHawk 2) and the use of EKF taking data from GPS.

OK, I’ll stop my rant now :slight_smile: - have a nice day!

Regards Jan

AFAIK the latest arduplane version is 3.8.4

Yes, correct for PixHawk! Not for APM controllers :slight_smile:


You do know that the old FW is no longer under development. We do accept PRs on top of the old branches, but we will AFAIK not make any release with those, nor actively work on that.

Hi, Jan Hindoy. Thank you for your “arigato” in Japanese. Yes, I’m Japanese.

In ArduPilot, altitude can be gottten by following formula.
alt = 153.8462f * temp * (1.0f - expf(0.190259f * logf(scaling)));

  • temp = ground_temperature + C_TO_KELVIN(273.15);
  • scaling = pressure / base_pressure;

If you can use GoogleSpreadSheet use this formula.
(sorry i don’t have microsoft Excel…but I believe similar to this one.)

Using this formula, different between 5C and 25C is 7% as you can see below.

This figure shows that how to change altitude from BARO in each temperature, the effect of temperature is not so small.

I think (in my simple mind :grinning:) the baro device temperature is more dependent on controller heating up inside the plane and in the controller case.

Yes, i think so too. so i think this is a problem.

In the newest hardware and firmware I think this is taken better care of with temperature control (PixHawk 2)

unfortunately, I’m using PixHawk 2.1.and ArduCopter 3.5.4 (sorry i’m copter.). no old Hardware and FirmWare.

Right now, I don’t know, how to avoid it.
Mounting external temperature sensor?
Setting intended ground temperature from GCS(MissionPlanner)? (now, not exists. i think)

If needed, i’ll try adding temperature setting in GCS for calculating alt.

Hi again Hiroyuki,

Thanks for taking the time to explain your calculations. Since my APM can load Arduplane 3.4.0 only, the altitude control is solely based on baro input (I think). Because of that, I must be more careful planning high flying missions, considering any possible measuring errors. Just an extra step by increasing the planned altitude by 1.06 (in my case), and not a big issue.

I guess many other Arduplane users have the older APM controllers.
My intention with my post was to find out if others have observed the same as me (you did!) and giving a heads up just in case. Hinting about a new parameter for the old APM FW was not well thought out, but perhaps a tip for the ongoing Pixhawk versions?

Your Pixhawk controller gives you many more parameters and options to control your copter. By using these I think you will be successful with your programming, also by reading and picking up tips from the user groups and the “Complete parameter List” for copters.
By searching the list for “baro” I found several parameters relating to altitude control for Pixhawk - have look at

    Sorry if you already knew all this… :slight_smile:

Have a nice day!

Regards Jan (who have visited Japan many, many years ago. Very nice people!)


Thanks for your answer!
Please see my reply to Hiroyuki…


Hi, Jan. Thank you for your reply.

I must be more careful planning high flying missions, considering any possible measuring errors

I think so too. And if this (several percent higher in baro alt) comes from temperature difference(i think so :stuck_out_tongue_closed_eyes:), it is likely to occur in winter season (because, in arudupilot, max temp. for calculating baro alt is defined as 35C).

Thank you for your hint for altitude control parameters.
I will check and use those parameters if possible. :slight_smile:

Thank you again for your long reply for my poor English.
You have visited Japan? Good. Come visit again someday with your plane :grin:

Hello again,

Your English is fine!

Developers here may comment on baro altitudes based on 35°C environment temp. For your mission planning with Pixhawk and latest FW i think baro altitude is not significant, actual altitude is calculated based on other sources as well…
Lucky you!


1 Like

Hi, I did some test with my pixhawk to determine the influence of OGN_HGT_MASK.
As I understand this is to compensate changes in pressure due to weather with the GPS alt.
So I activated this and put my Pixhawk on my balkony for the night to see the change:

The pressure drop was 64 Pa in the night, equaling about 5,4m in altitude. (11,8 Pa/m derived from ISA Standard Atmosphere)

You can see the POS.alt is following the GPS.alt and the baro.alt is not changing at all.
Also you see that the variation of the POS alt is much more then the 5.4m that the maximum error to pressure change would have been. So for this test the GPS alt compensation didn’t do what it was supposed to -> making the altitude error smaller.

My question now is where does this values here come from:

Its the data from exactly the same log. But the POS altitude you see here is nothing like the POS altitude from the screenshot above. Much less deviation. What data is this then?


Would you happen to know how the formula for the altitude was derived?


Hello Marcsay,

You need to ask Hiroyuki about that emoticon_smiley.png

I have taken a break with this hobby and don’t remember much…


------ Original Melding ------

1 Like


I know it’s an old thread, but I am trying to find out if Mission planner offers “Programable Altimeter, Units mmHg or inHg”?

On a real aircraft, pilots reset their altimeter based on MSL number provided by the tower.