Delta between betaFlight and National Oceanic and Atmospheric Administration (NOAA) formula

[lida2003]

Describe the bug

I notised a delta between betaFlight and National Oceanic and Atmospheric Administration (NOAA) formula of baro height caculation, which is quite small.

Check https://en.wikipedia.org/wiki/Pressure_altitude for National Oceanic and Atmospheric Administration (NOAA) formula

But I hope some one can let me know WHY betaFlight is NOT using National Oceanic and Atmospheric Administration (NOAA) formula of baro height caculation?

Below I draw two lines, which are not big deal, quite close to each other. Even 1000meters high, there is just 60cm differ.

To Reproduce

Just code is enough.

https://github.com/betaflight/betaflight/blob/master/src/main/sensors/barometer.c#L348

static float pressureToAltitude(const float pressure) { return (1.0f - powf(pressure / 101325.0f, 0.190295f)) * 4433000.0f; }

Expected behavior

Expect an answer about current formula, where did this come from. Any history issues?

Diff configuration

No

Resources configuration

No

Flight controller

No

Other components

No response

How are the different components wired up

No response

Add any other context about the problem that you think might be relevant here

No response

[ledvinap]

IIRC the formula used in BF comes from some baro IC datasheet. IMO only reasonable change would be to use Taylor expansion, reducing accuracy and increasing speed.

[lida2003]

Yeah, historical reasons maybe, I think. I checked BMP280, which states temperature and pressure compensation, I didn't find this formula. I'll take time to check other spec later.

Hope anyone who has the info, just let me know.

[lida2003]

I did checked following chip spec. No clue to the formula.

1. BARO_BMP085
2. BARO_MS5611
3. BARO_BMP280
4. BARO_LPS25H
5. BARO_QMP6988
6. BARO_BMP388
7. BARO_DPS310

[TerribleKraal]

Hi,

This equation is in the BMP085 datasheet, on page 15.

Best regards.

[KarateBrot]

The baro cannot read absolute height values reliably and is a better tool to detect sudden height changes. In combination with a GPS this height offset is being corrected anyway. Differences in the formula arise when you put in slightly different constants.

If you can find out what the background of the NOAA formula is (why these specific constants were used) we can decide more easily which formula is better for us.

[lida2003]

Hi,

This equation is in the BMP085 datasheet, on page 15.

Best regards.

Thanks for the help, @TerribleKraal . That's great!

[lida2003]

Well, I'm NOT quite sure about GPS altitude's accuracy （10 or 5 meters???）. And I'm quite sure about baro's relative altitude accuracy flying just a few meters above the ground.

See my GPS resucre video: https://www.bilibili.com/video/BV1Ye4y1i7S7/

BF 4.3.1 FW(default), with M8N GPS, default settings: position_alt_gps_min_sats = 10 position_alt_baro_fallback_sats = 7

It gives wrong altitude -10.3meters (takeoff) and -6.5 meters (land), locked 11 stars, combined with + bmp280 baro.

I'm confued about this OSD values, NOT know WHY!!!

Any way, this thread is all about pressure altitude.

What I concerned is that "the slope of GPS altitude and baro altitude" might cause ground level vary positive or negative, when GPS altitude combines baro altitude in the air, especially high in the air.

Just like my video, let take a scenario for example:

1. GPS meets default condition (position_alt_gps_min_sats) at 100 meters(baro, give), actually GPS gives 90 meters.
2. GPS offset should be 90 - 100 = -10 meters
3. When quad decent to ground level GPS: gives altitude 0, which 0 - 10 = -10 baro: gives altitude 0
4. take gps_trust = 0.5 for example, we have 0.5x(-10)+(1-0.5)x0 = -5 meters.

[sugaarK]

You do know there has been a massive overhaul of the gps and imu code in 4.4 @lida2003 ? The 4.3 and older code is not so accurate

[lida2003]

I know 4.4 will introduce RTH features (well, let's say more advanced GPS resucure feature). That's gonna handle what I concerns above.

So is there any feature #??? avaliable, or related to this?

[sugaarK]

Have you tried the 4.4 master

[lida2003]

I will try when released, or this ticket is attached to specific git commit. Currently, I didn't follow the 4.4 master, so I'm NOT sure about the status of the development.

Hope to understand current code behavior on 4.3.1.

[sugaarK]

The 4.3 code doesn’t matter as it’s been superseded so it’s a bit of a waste of time for you to try and understand it when it had so many issues and it’s been fixed… pretty sure most of the gps stuff has been merged into 4.4 master…. Better use of every ones time including your own to help with testing the new code that doesn’t have lots of issues

[lida2003]

@sugaarK @KarateBrot I'll try 4.3.2 or 4.4 release, hope NOT to build myslef (which might be stable)

Well, I checked latest code in repo.

commit 813a02cb866643fa1b4017038776601d0533df48 (HEAD -> master, origin/master, origin/HEAD) Merge: 5403e41c1 3a0aea85a Author: J Blackman [email protected] Date: Thu Oct 6 12:10:11 2022 +1100

Merge pull request #11866 from KarateBrot/42688

Enhancements for ICM-426xx (gyro and acc)

It seems latest code removed below two variables: a) position_alt_gps_min_sats = 10 b) position_alt_baro_fallback_sats = 7

Nothing happend when calculation altitude, brings altitude_prefer_baro/absDifferenceM concept.

1. pressureToAltitude still uses BMP085 chip spec
2. code re-arrange, and still uses following concept a) offset for baro & gps b) hdop used as before, why NOT vdop??? which suggest vertical dilution of precision c) minimun 10% baro if baro existed d) zeroedAltitudeCm = zeroedAltitudeCm * gpsTrust + baroAltCm * (1.0f - gpsTrust);
3. Add prefer gps/baro concept
4. Add absDifferenceM concept

It seems they have noticed scenario what I have mentioned above with gps/baro concept and add absDifferenceM(100cm) save negative ground level issue.

It still not good for nice touching down, RTH feature (positve ground level), anyway, it's a good start.

If the slope of curve is close to GPS, and minimize the difference is the key point.

[sugaarK]

Lols it’s been worked on but it takes time… if you look at the prs we were in the past sampling the gyro and the baro at way to lower rates and not filtering the data properly.. these things have to be fixed one at a time. Remeber these things have nothing to do with racing drones and amazing flight dynamics which is projects focus… it’s all coming but it takes time. If it’s not fast enough for you then you are welcome to lend a hand 😉 after all this is how open source projects like Betaflight work.. people work on the things they want to see in the project

[lida2003]

@sugaarK Is there any way to export data to excel or text format from bbl log file? so that we can analyze the data?

[ledvinap]

https://github.com/betaflight/blackbox-tools/blob/master/src/blackbox_decode.c

[KarateBrot]

@sugaarK Is there any way to export data to excel or text format from bbl log file? so that we can analyze the data?

Export your log to CSV with the button on the upper right in the blackbox explorer

[lida2003]

@KarateBrot CSV works for me. Thanks.

[lida2003]

https://github.com/betaflight/blackbox-tools/blob/master/src/blackbox_decode.c

@ledvinap Well, that's great tool. I'll try if I have more data to look into. Thanks.

[github-actions[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs within a week.

[lida2003]

Current repo code of gps&baro fusion method is same as 4.3.1, which is NOT that Good. Hope new way of fusion method is selected, such as iNav.

Tests below in details. https://blog.csdn.net/lida2003/article/details/127460139

[haslinghuis]

https://github.com/betaflight/betaflight/pull/11958

[KarateBrot]

@lida2003 More interesting sensor fusion algorithms related to position estimations are coming in BF 4.5