• AVR Freaks

Hot!From pressure to altitude

Author
Airborne
New Users
  • Total Posts : 16
  • Reward points : 0
  • Joined: 2018/02/12 05:13:02
  • Location: Italy
  • Status: offline
2020/05/22 00:14:36 (permalink)
0

From pressure to altitude

 MPLAB X IDE v5.30
 mpasm (v5.86)
 PIC16F19156
 
Hi, I am building an altimeter with a BMP280 pressure sensor from Bosch, which provides the current pressure in Pa.
Now from the pressure I have to get the altitude in m giving the pressure at sea level with this formula:
 
H = 44330 * [ 1 - (P / p0) ^ (1 / 5,255) ]
H = altitude (-100~44330 m)
P = measured pressure from the sensor (0~107900 Pa)
p0 = reference pressure at sea level (87000~107900 Pa)
 
How can I do it without using the floating point?
Thank you all Smile: Smile
 
#1

18 Replies Related Threads

    du00000001
    Just Some Member
    • Total Posts : 3850
    • Reward points : 0
    • Joined: 2016/05/03 13:52:42
    • Location: Germany
    • Status: offline
    Re: From pressure to altitude 2020/05/22 01:44:14 (permalink)
    0
    airborne
    <...snipped...>
    H = 44330 * [ 1 - (P / p0) ^ (1 / 5,255) ]
    H = altitude (-100~44330 m)
    P = measured pressure from the sensor (0~107900 Pa)
    p0 = reference pressure at sea level (87000~107900 Pa)
     
    How can I do it without using the floating point?
    ...



    One might think about using a lookup table for the exponential (root) function - interpolating between entries.
    Although I wouldn't bet my life on a barometric height metering device: even the most professional ones have errors of some tens of meters.
    If you want a very simple calculation within a limited height difference, you might get away with the very simple calculation of -100 Pa per 30 ft of height difference. While looking less "scientific", this is easily set up (no need to calculate the p0 (at NN and 15 °C) and to get the precise air temperature). This one will give you a reasonable approximation of the height above ground (once zeroed at ground).

    PEBKAC / EBKAC / POBCAK / PICNIC (eventually see en.wikipedia.org)
    #2
    upand_at_them
    Super Member
    • Total Posts : 585
    • Reward points : 0
    • Joined: 2005/05/16 07:02:38
    • Location: Pennsylvania
    • Status: online
    Re: From pressure to altitude 2020/05/22 04:30:46 (permalink)
    0
    That PIC has a ton of program space.  As mentioned, I would definitely use a lookup.  Exclusively!  If you're measuring this sensor with an analog input...10-bit precision is only 1K lookup entries.  You can afford that.  Heck, don't calculate anything, you can afford a 12-bit precision lookup: only 4K of program space.  You've got, like, 1.21 jigawatts left!
    #3
    du00000001
    Just Some Member
    • Total Posts : 3850
    • Reward points : 0
    • Joined: 2016/05/03 13:52:42
    • Location: Germany
    • Status: offline
    Re: From pressure to altitude 2020/05/22 04:36:01 (permalink)
    5 (1)
    upand_at_them
    That PIC has a ton of program space.  As mentioned, I would definitely use a lookup.  Exclusively!  If you're measuring this sensor with an analog input...10-bit precision is only 1K lookup entries.  You can afford that.  Heck, don't calculate anything, you can afford a 12-bit precision lookup: only 4K of program space.  You've got, like, 1.21 jigawatts left!



    No - you haven't gotten it: the BMP280 is a digital sensor. And P as well as P0 may change. So it's not about a mere 1k table entries.

    PEBKAC / EBKAC / POBCAK / PICNIC (eventually see en.wikipedia.org)
    #4
    crosland
    Super Member
    • Total Posts : 2017
    • Reward points : 0
    • Joined: 2005/05/10 10:55:05
    • Location: Warks, UK
    • Status: offline
    Re: From pressure to altitude 2020/05/22 06:59:28 (permalink)
    0
    What accuracy do you need?
    What performance do you need?
    Why have you ruled out floating point? Performance? code space?
    #5
    Airborne
    New Users
    • Total Posts : 16
    • Reward points : 0
    • Joined: 2018/02/12 05:13:02
    • Location: Italy
    • Status: offline
    Re: From pressure to altitude 2020/05/22 07:21:53 (permalink)
    0
    What accuracy do you need?

    the maximum offered by the sensor
    What performance do you need?

    I have to measure variations of 0.1 m, I need them to measure the changes in altitude in m / s and view them on an LCD display together with the altitude
    Why have you ruled out floating point? Performance? code space?

    To be honest I am new to the assembly and I have wasted a lot of time learning it, I would not want to waste as much time with the floating point. I see the realization of the project further and further away and I am thinking of returning to xc8. Don't hate me
     
    post edited by Airborne - 2020/05/22 07:26:52

    Attached Image(s)

    #6
    crosland
    Super Member
    • Total Posts : 2017
    • Reward points : 0
    • Joined: 2005/05/10 10:55:05
    • Location: Warks, UK
    • Status: offline
    Re: From pressure to altitude 2020/05/22 08:32:21 (permalink)
    0
    Ah, I missed the mpasm bit. But the question stands, does floating point use up too much code space, or perform too slowly for you?
     
    By performance I meant how fast do the calcs have to be? I.E. what display update rate do you want?
     
    I use nothing but XC8, why would I hate you :)
     
    Given what Microchip have done to mpasm (dropped it), I would definitely consider XC8.
     
    #7
    du00000001
    Just Some Member
    • Total Posts : 3850
    • Reward points : 0
    • Joined: 2016/05/03 13:52:42
    • Location: Germany
    • Status: offline
    Re: From pressure to altitude 2020/05/22 08:32:26 (permalink)
    1 (1)
    Airborne
    ... returning to XC8. ...

     
    Wise idea! Unless forced to use assembly (speed, meory space, DSP instruction use), I wouldn't even consider to implement a whole project in assembly: too much time, too little advantages.
     
    @Gort....
    I know, I know. There are some assembly freaks out there. It's just that I'm wandering between architectures (PIC16, dsPIC, AVR, Arm - just to name a few). While all these are quite similar using C, assembly would be a challenge.

    PEBKAC / EBKAC / POBCAK / PICNIC (eventually see en.wikipedia.org)
    #8
    Airborne
    New Users
    • Total Posts : 16
    • Reward points : 0
    • Joined: 2018/02/12 05:13:02
    • Location: Italy
    • Status: offline
    Re: From pressure to altitude 2020/05/22 09:54:14 (permalink)
    0
    But the question stands, does floating point use up too much code space, or perform too slowly for you?
    By performance I meant how fast do the calcs have to be? I.E. what display update rate do you want?

    The rate is not a problem, 2 readings per second, and there is a lot of space. The problem is that I have to waste other hours of time as a self-taught, with fragmented sources and in another language (I'm Italian)
    #9
    upand_at_them
    Super Member
    • Total Posts : 585
    • Reward points : 0
    • Joined: 2005/05/16 07:02:38
    • Location: Pennsylvania
    • Status: online
    Re: From pressure to altitude 2020/05/22 10:57:31 (permalink)
    0
    If P0 doesn't change often, and you can tolerate updating the firmware when it does, you could calculate a lookup table on your desktop computer with, say, Python and drop the table into the PIC code, compile, and upload.  With your accuracy needed it looks like 2K of lookup would be fine.  You'd have to decide if that works for you.
     
    #10
    Airborne
    New Users
    • Total Posts : 16
    • Reward points : 0
    • Joined: 2018/02/12 05:13:02
    • Location: Italy
    • Status: offline
    Re: From pressure to altitude 2020/05/22 11:08:44 (permalink)
    5 (1)
    Unfortunately P0 changes every time the device (called variometer) is used. In aeronautics it is called QNH and is supplied to pilots from the control tower before taking off. The pilot inserts it into the altimeter so he knows exactly his altitude.
    #11
    du00000001
    Just Some Member
    • Total Posts : 3850
    • Reward points : 0
    • Joined: 2016/05/03 13:52:42
    • Location: Germany
    • Status: offline
    Re: From pressure to altitude 2020/05/22 11:10:05 (permalink)
    0
    @ up_and_run_away
    P0 changes by the minute. Updates would be required at the very least daily. Most likely "in the field".
    And you won't want to have a reasonable height calculation error when being airbone  :(

    PEBKAC / EBKAC / POBCAK / PICNIC (eventually see en.wikipedia.org)
    #12
    JPortici
    Super Member
    • Total Posts : 1114
    • Reward points : 0
    • Joined: 2012/11/17 06:27:45
    • Location: Grappaland
    • Status: online
    Re: From pressure to altitude 2020/05/22 11:36:13 (permalink)
    0
    I still can't understan the issue at hand..
    I wanted to chime in that there is no point in looking for absolute performance because you can live with a few readings per second, and because of that just use soft floating point in C.
    but you already covered that..
     
    I see you already know that unfortunately P0 vary by the minute and by the meter if you move around :(
    some of my mountaineering buds use watches with altimeters (which of course work with the same principle), i use the gps, can't stand wearing watches.
     
    Saluti dal monte grappa
     
    Edit: Of course, i missed the fact that this is the MPASM subforum
    post edited by JPortici - 2020/05/22 11:42:04
    #13
    GlennP
    Super Member
    • Total Posts : 780
    • Reward points : 0
    • Joined: 2009/03/29 15:04:55
    • Location: El Paso County, CO, USA
    • Status: offline
    Re: From pressure to altitude 2020/05/23 01:26:40 (permalink)
    5 (2)
    Dear Airborne:

    I have a few comments on the project as a whole and one WRT the actual question.  In no logical order:

    The equation shown is only valid up to 11,000m.  Above 11,000m is the Tropopause and the relationship between P and H is of a completely different form because the temperature is assumed constant.  This means that you can ignore pressures below 22632 Pa and that might lead to the ability to simplify your calculations.  [OR you need to consider flight above 11,000m (36,089') and your life is more complicated.]

    The exponent shown (1 / 5,255) is not the one I've seen.  I might not matter, but look up various authorities.  The value I've used is 1 / 5,255876.  [Note to some readers: 1 / 5.255876.]  I don't think it makes much difference, but why not get it right?

    The sensor can produce 20 bits of pressure data.  But it has about 15+ bits of accuracy.  So generally, you should keep a few guard bits more than the 15+ bits of accuracy.  18 bits is likely more than enough.  16 is likely OK but expect a loss of accuracy after a few calculations.

    Note that the sensor's specification for relative altitude accuracy is +/- 1m and absolute accuracy is +/- 8m.  I assume the use case is something like a Variometer, the absolute accuracy is of lesser importance.

    I'm a bit surprised Bosch doesn't allow you to send P0 and do the altitude calculation internally.  But maybe the 380 series will.

    Consider producing a VSI output without first calculating the altitude.  I haven't done the algebra and/or calculus, but delta-P should give delta-H pretty well if scaled by a factor related to P.  Traditional VSIs (the leaky kind) never used altitude - just pressure change.  I assume altitude is of secondary importance especially if flight is in VFR conditions.  If you don't need accurate altitude, then P0 isn't critical.  Separate what you can do from what you need to do.

    Write a spreadsheet to check if there is a simple way to have a small LUT (say every 160 Pa) to linearly scale (in segments) deltaP into deltaH with reasonable accuracy.  Such a table would have less than 512 entries in the range of interest and be indexed by nine HO bits of P.  And the entries might be (appropriately scaled) bytes or even 14-bit entries in the program space.  If this works out, you could get vertical speed with just a table lookup and a multiply of the scale factor and the deltaP (raw).

    A numeric readout is fairly terrible way to communicate with a busy pilot.  Modern sailplanes usually have audio output (higher frequency meaning greater rate of energy increase).  This allows the pilot's vision to be used to avoid granite clouds which are frequently near updrafts.  It's easy to have a PWM produce varying frequency audio.  A "steam gauge" display (even if it's digital implementation) is next best.  Numeric outputs are last on my list of things I want to look at while flying.  Look at any "glass cockpit" and there will be a tape, clock, or arrow along with most numbers.

    Although floating point is easiest to program, beware of delays.  In any control system, feedback delay is a very negative characteristic and can lead to oscillation.  More so if a salt-water-based life-form is part of the control system.  This may also mean you want to sample P fairly frequently.

    Read the Wikipedia article on Standard Atmospheres if you haven't already: https://en.wikipedia.org/...al_Standard_Atmosphere .  Most use the ICAO standard but there are others.

    Read the Wikipedia article on Variometers if you haven't already.  https://en.wikipedia.org/wiki/Variometer

    Without knowing airspeed (or the inputs that can be used to determine it), you cannot produce the "total energy" information that is, I assume, what you really want.  It's at least what sailplane (glider) pilots want.  The Variometer article has details and equations.

    Finally, there are quite a few approximations that you might be to use.  If you can keep things scaled and integers, speed will usually improve.  That's true in any language on this level of hardware.

    GP

     
    #14
    crosland
    Super Member
    • Total Posts : 2017
    • Reward points : 0
    • Joined: 2005/05/10 10:55:05
    • Location: Warks, UK
    • Status: offline
    Re: From pressure to altitude 2020/05/23 05:00:34 (permalink)
    0
    glennp17321Although floating point is easiest to program, beware of delays.  In any control system, feedback delay is a very negative characteristic and can lead to oscillation.  



    Where's the feedback loop?
    #15
    GlennP
    Super Member
    • Total Posts : 780
    • Reward points : 0
    • Joined: 2009/03/29 15:04:55
    • Location: El Paso County, CO, USA
    • Status: offline
    Re: From pressure to altitude 2020/05/23 05:30:43 (permalink)
    5 (1)
    crosland ...
    Where's the feedback loop?



    Generally when flying in thermals, the pilot is trying to keep the rate of energy increase as high as possible.  S/he does this by keeping within the highest ROC** in the thermal.  That, in turn, is aided (if not directed totally) by the variometer.  So the loop is: variometer -> pilot -> controls -> aircraft movement -> variometer.
     
    Instrument delay is a fairly big deal when the thermals are small.  Good pilots (don't ask me about this) can sense this.  The phrase "Seat of the Pants" comes from the ability to sense yaw via your buttockal region.  [Forest Gump-ism]  Glider pilots tell me they can sense the thermal lift well enough w/o the variometer.  I cannot.  [Thermal lift isn't the same as yaw, but the same region of the body is used to detect both.]
     
    **ROC = Rate of Climb.  It's actually a bit more complicated because you can trade speed (kinetic energy) for altitude (potential energy).  Modern gliders have such an instrument which yields the sum of K+P.
    #16
    du00000001
    Just Some Member
    • Total Posts : 3850
    • Reward points : 0
    • Joined: 2016/05/03 13:52:42
    • Location: Germany
    • Status: offline
    Re: From pressure to altitude 2020/05/23 06:09:20 (permalink)
    5 (1)
    glennp17321
    crosland ...
    Where's the feedback loop?



    Generally when flying in thermals, the pilot is trying to keep the rate of energy increase as high as possible.  S/he does this by keeping within the highest ROC** in the thermal.  That, in turn, is aided (if not directed totally) by the variometer.  So the loop is: variometer -> pilot -> controls -> aircraft movement -> variometer.
     
    Instrument delay is a fairly big deal when the thermals are small.  Good pilots (don't ask me about this) can sense this.  The phrase "Seat of the Pants" comes from the ability to sense yaw via your buttockal region.  [Forest Gump-ism]  Glider pilots tell me they can sense the thermal lift well enough w/o the variometer.  I cannot.  [Thermal lift isn't the same as yaw, but the same region of the body is used to detect both.]
     
    **ROC = Rate of Climb.  It's actually a bit more complicated because you can trade speed (kinetic energy) for altitude (potential energy).  Modern gliders have such an instrument which yields the sum of K+P.



    Even with some float calculation, I'd guesstimate the possible update rate on an 8 MIPS current PIC16 to be >= 10 Hz (way too fast for a numerical display to be readable). At the same time I doubt that control actuation faster than @ 1 Hz would give any favorable result (while g-forces might exceed the reaonable).
    Even the "Popometer" (German - translates to "butt feeling") will take its time for sensing  :)

    PEBKAC / EBKAC / POBCAK / PICNIC (eventually see en.wikipedia.org)
    #17
    GlennP
    Super Member
    • Total Posts : 780
    • Reward points : 0
    • Joined: 2009/03/29 15:04:55
    • Location: El Paso County, CO, USA
    • Status: offline
    Re: From pressure to altitude 2020/05/23 06:40:47 (permalink)
    0
    du00000001...
    Even with some float calculation, I'd guesstimate the possible update rate on an 8 MIPS current PIC16 to be >= 10 Hz (way too fast for a numerical display to be readable). At the same time I doubt that control actuation faster than @ 1 Hz would give any favorable result (while g-forces might exceed the reasonable).
    Even the "Popometer" (German - translates to "butt feeling") will take its time for sensing  :)



    While I certainly cannot do it, studies of fighter pilots indicate "upset" reaction times of about 1/4 second when they are concentrating on the task.  Think of the various service aerobatic demonstration teams flying in formation.  Now the aircraft they fly are designed to be responsive.  They are not long-winged gliders nor passenger-carrying transports.
     
    When flying in light planes, I can generally tell if the pilot has flown high-performance aircraft.  Their control loops are much tighter and smoother.  [Even more off-topic: But their vision is what is most amazing.]
     
    But my point is add as little delay as practical.  While a floating operation or two isn't going to be a show-stopper, logs and exponents can be lengthy.  And I think they are not needed.  I was tempted to actually do the spreadsheet I suggested, but I have other tasks at hand.
     
    --
     
    I hope the OP will not use a numerical display.  They are not very helpful as they slow the cockpit scan significantly.  There is a very good reason audio is used in modern gliders.
     
    "Popometer" is new to me and I'm better off for having learned it.  Thanks.
    #18
    Gort2015
    Klaatu Barada Nikto
    • Total Posts : 3984
    • Reward points : 0
    • Joined: 2015/04/30 10:49:57
    • Location: 0
    • Status: offline
    Re: From pressure to altitude 2020/05/23 07:05:38 (permalink)
    1 (1)
    Just a means really.  I am confident in many languages.
     
    @Gort....
    I know, I know. There are some assembly freaks out there. It's just that I'm wandering between architectures (PIC16, dsPIC, AVR, Arm - just to name a few). While all these are quite similar using C, assembly would be a challenge.




    MPLab X playing up, bug in your code? Nevermind, Star Trek:Discovery will be with us soon.
    https://www.youtube.com/watch?v=Iu1qa8N2ID0
    + ST:Continues, "What Ships are Made for", Q's back.
    #19
    Jump to:
    © 2020 APG vNext Commercial Version 4.5