Calculating Variometry

David Kissick

It's been awhile since I've touched my project, but I'm getting back into it. I'm building a flight instrument for hang gliding. I have figured out how to calculate altitude using a pressure sensor. Now I'm trying to calculate my variometry (rate of climb or decent). What I wanted to do was store my last altitude, then subtract it from my present altitude to get the change. Atlitude is recorded every one second and altitude is given in feet. This calculation would give the result in feet per second. The final result needs to be feet per minute and will be displayed on a LCD. This would be easy except that values can be negative. So the question is how do I need to deal with this math in the Stamp's integer math world without it getting confused. If someone knows a better way to calculate my variometry, I'm open to new ideas. Thank you in advance for any help on the matter.

David

Mike Green

16 bit addition and subtraction (that the Stamp does) works just as well with signed 15 bit numbers. Given that you have just one signed value (change in altitude), it might be easier to separate the sign and work with positive numbers only. Given a current altitude and previous altitude, try:

if current > previous then ascending
change = previous - current
dispSign = "-"
goto continue
ascending:
change = current - previous
dispSign = "+"
continue:
result = change * 60
serout pin,baud,[noparse][[/noparse]dispSign,DEC result]

Tracy Allen

Hi Dave,

The main thing you have to watch out for with the signed math with integers is division. Addition, subtraction, and multiplication all work fine with the twos complement numbers, and you can display the negative numbers using the SDEC modifier.

So
feetChange = feetNow - feetPast
DEBUG SDEC feetChange * 60
feetPast = feetNow


The issue with twos compliment negative numbers comes with division, including / and //, and */ and ** operators. There are special tricks for division, or if the display needs a decimal point, but I doubt if that is a issue with data in feet.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Tracy Allen
www.emesystems.com

David Kissick

To Mike,
Thanks for the suggestion. I might use that if I have to.

To Tracy,
If I did a comparison, would the stamp know that a negative number was lower.

Example, I want audio to turn on if my rate is over 100 feet per min. If the rate is -200 feet per min, would it see it as 100>-200 or would it see it the other way around? I'm trying to make sure I keep any unusual behavior down. Thanks again!

David

steve_b

Have you thought of using an accelerometer? Put it in an "up/down" orientation and when you pull on the stick and your nose goes up, you'll have more positive g's....once again you'd be stuck for doing some fancy shmancy calculations to sort out....

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
·

Steve

"Inside each and every one of us is our one, true authentic swing. Something we was born with. Something that's ours and ours alone. Something that can't be learned... something that's got to be remembered."

bobledoux

Also consider using long period integration, with a period of 5 to 20 seconds. This is the technique used in some classic sailplane variometers. You can use a lot of memory creating a first in, last out, stack to calculate rates of change, digitally.

Tracy Allen

The IF statement does not know about twos compement, so any negative number turns out "greater than" any positive number.

If you want both ascent and descent with the same threshold, use absolute value.
IF ABS rate > 100 THEN ...

One easy way handle separate thresholds cleanly is with a positive offset:
SELECT rate + 10000 ' <- offset makes it positive.
CASE < 9900
' descending
CASE > 10100
' ascending
END SELECT

The number 10000 is arbitrary. But if your descent is faster than -10000 ft/m, you're in serious trouble!

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Tracy Allen
www.emesystems.com

David Kissick

Tracy said...
The number 10000 is arbitrary. But if your descent is faster than -10000 ft/m, you're in serious trouble!

Yeah, that would work fine. Oh, and you're very right on the 10,000 ft/min thing. I've felt 2,000 and that's scary enough!

The period averaging would be a great thing to add. How should I go about storing and averaging values over a selectable period of time? A good range would be 0 - 20 seconds, but can be made shorter if possible.

Thanks to everyone for the great help so far. I hope this becomes useful for someone else too.

David

Tracy Allen

Dave, here is a smooting routine. Every time you acquire a new altitude, run it through the smoothing routine, and the output is the smoothed value that you use to calculate the variometry for the past and present values. The subroutine works up to 8047 feet altitude. The routine maintains a slosh variable, "smoothFeet".

smoothFeet VAR word

initialize_smoothing ' at the top of your program
      gosub findFeetNow  ' get present value 
      smoothfeet = feetnNow * 8     'initialize, note multipication * 8

' subroutine, enter with present unfiltered value of feetNow, return with smoothed value
' uses exponential filtering, smoothed value = 7/8 * accumulator + 1/8 * raw value
smoothing:   
      smoothfeet = smoothfeet ** 57345 + feetNow           ' smoothing function
      feetNow = smoothFeet / 8
      RETURN

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Tracy Allen
www.emesystems.com