Barometric altitude filtering

[Raais]

Greetings,

Over the past few weeks, I've been exploring the various aspects of developing an avionics system capable of taking measurements and deploying parachutes. I am particularly interested in constructing my own flight computer, although my experience in electronics has never been applied to a rocketry project.

After studying a bit and checking different points of views of people that seems to have expireience on the field, I believe I have a relatively clear grasp of the fundamentals. My plan is to develop a flight computer primarily equipped with a barometer and a 6DOF IMU with a high-g accelerometer, alongside a GPS. For deployment control, I intend to primarily rely on barometric altitude readings, integrating IMU acceleration to get vertical velocity and prevent unintended deployments during the mach transition zone. While I'm uncertain if this is the most optimal approach, my research suggests multiple options, with this one appearing to be a reasonable choice.

However, the real problem for me lies in the aspect of measurement filtering. I've never worked with signal filtering, and I must admit, I'm a bit overwhelmed. I understand that implementing a Kalman filter to accurately process IMU measurements is essential, even though it's not an easy task. Nevertheless, I don't have the same level of certainty when it comes to the altimeter. Some suggest a simple low-pass filter, yet I'm unsure whether it should be a FIR, an IIR or something else. Others propose a moving average, while some recommend a basic Kalman filter solely based on barometric readings. I recognize that the ideal approach would involve fusing both the IMU and the barometer data with a Kalman filter. However, lacking experience, I'm unsure about going with this option, especially now that I am getting into this. Thus, I would greatly appreciate your recommendations or any advice on how you would approach this.

Apart from this, I would like to ask what temperature you use to determine altitude. I have read that sometimes the barometer inbuild sensor temperature is used (I plan to use a MS5607 barometer), but I am unsure how advisable this is, as the avionics module tends to be at a higher temperature, and the sensor is not exceptionally accurate. Others suggest using a constant temperature of 15 degrees. What would you recommend?

Considering everything mentioned, I would greatly appreciate your insights and approach to handling these matters. Any information you can provide would be highly valuable to me.
And of course, thank you in advance!

 

[Handeman]

I can't give you any advice on how to do this, but Altus Metrum is an open source altimeter. You might want to review their source code to see the methods they use to filter baro data.

 

[NTP2]

Should help. https://web.mit.edu/kirtley/kirtley/binlustuff/literature/control/Kalman filter.pdf

 

[burritoman1]

https://github.com/rlabbe/Kalman-and-Bayesian-Filters-in-Python
This explains everything you could possibly want to know about Kalman filters in plain english, along with plenty of example code and a python library for implementing your own filter.

 

[waltr]

Also, this topic has come up here so a search and reading of threads will turn up lots more info and links to source code.

I suggest flying the electronics without it doing deployment. Use standard Motor eject.
LOG the Raw data and any calculated data for Post flight analysis.

This way the Rocket has reliable recovery and you can test the Electronics and Code.

 

[jderimig]

For filtering baro data a simple exponential recursive filter is all you need.

https://blog.mbedded.ninja/programm...ilters/exponential-moving-average-ema-filter/
You do not use temperature to calculate pressure altitude. You use the standard atmospheric model to calculate pressure altitude which assumes a standard temperature profile in the atmosphere. To know pressure/altitude you need to know the 'weight' of the air column from where you are to 'space'. To do that you need to know the temperature versus altitude of the atmosphere to space. The temperature at the bottom of the column is not that.

 

[user 30299]

For filtering baro data a simple exponential recursive filter is all you need.

https://blog.mbedded.ninja/programm...ilters/exponential-moving-average-ema-filter/
You do not use temperature to calculate pressure altitude. You use the standard atmospheric model to calculate pressure altitude which assumes a standard temperature profile in the atmosphere. To know pressure/altitude you need to know the 'weight' of the air column from where you are to 'space'. To do that you need to know the temperature versus altitude of the atmosphere to space. The temperature at the bottom of the column is not that.

Good to know. Thanks!

 

[cerving]

For filtering baro data a simple exponential recursive filter is all you need.

https://blog.mbedded.ninja/programm...ilters/exponential-moving-average-ema-filter/
You do not use temperature to calculate pressure altitude. You use the standard atmospheric model to calculate pressure altitude which assumes a standard temperature profile in the atmosphere. To know pressure/altitude you need to know the 'weight' of the air column from where you are to 'space'. To do that you need to know the temperature versus altitude of the atmosphere to space. The temperature at the bottom of the column is not that.

I concur, and EMA filter works just fine.

All of the digital baro sensors have an integrated temperature sensor that is read as part of the pressure routine. They aren't horribly responsive, however, so the "actual" pressure may not be quite accurate. Plus, the ambient temperature in an enclosed AV bay may not be quite the same as the outside temperature... particularly in hot weather. However, since you're looking at pressure changes during the flight, not the actual pressure, the incorrect temperature readings cancel out.

 

[NTP2]

My dad is in AI and teaches a class that has a lot of filter’s including the Kalman.

 

[waltr]

Download and read carefully the Baro data sheet:
https://www.mouser.com/c/ds/?marcom=132144897
There are calibration coefficients that require reading from the Baro's internal PROM and used in the calculations.

FACTORY CALIBRATION
Every module is individually factory calibrated at two temperatures and two pressures. As a result, 6 coefficients necessary to compensate for process variations and temperature variations are calculated and stored in the 128-bit PROM of each module. These bits (partitioned into 6 coefficients) must be read by the microcontroller software
and used in the program converting D1 and D2 into compensated pressure and temperature values.

Page 8 describes the read/calculate sequence. There may be additional App Notes with more details. There is mention of AN520 on how the Cal value's CRC is done.

If using this for Dual Deploy then Absolute Altitude is not required. First is detection of Apogee, when altitude start to decrease. Next is a pre-set altitude for Main chute deployment.
Also, what ever the Altitude calculated at launch is subtracted from all further altitudes so that it is the Altitude from the launch pad that counts.

Again, I suggest flying the sensor package and log all RAW data. Then you can determine if and how much filtering is required during Post-flight analysis.

 

[Raais]

I can't give you any advice on how to do this, but Altus Metrum is an open source altimeter. You might want to review their source code to see the methods they use to filter baro data.

I will check it for sure. It is always good to see how the commercial systems handle all of this in a reliable way.

Should help. https://web.mit.edu/kirtley/kirtley/binlustuff/literature/control/Kalman filter.pdf

https://github.com/rlabbe/Kalman-and-Bayesian-Filters-in-Python
This explains everything you could possibly want to know about Kalman filters in plain english, along with plenty of example code and a python library for implementing your own filter.

I will check both files. In fact, some weeks ago I started reading the "Kalman and Bayesian Filters in Python", however I'm still currently reading it as I would like to understand it well. But yes, it explains everything pretty well and the examples give you the prespective of what you are reading.

Also, this topic has come up here so a search and reading of threads will turn up lots more info and links to source code.

I suggest flying the electronics without it doing deployment. Use standard Motor eject.
LOG the Raw data and any calculated data for Post flight analysis.

This way the Rocket has reliable recovery and you can test the Electronics and Code.

Yes, my idea is to fly it as a payload and use a commercial flight computer for the deployment, as well as to collect data for comparison with the data taken from my flight computer. I think it is the best way to test it.

For filtering baro data a simple exponential recursive filter is all you need.

https://blog.mbedded.ninja/programm...ilters/exponential-moving-average-ema-filter/
You do not use temperature to calculate pressure altitude. You use the standard atmospheric model to calculate pressure altitude which assumes a standard temperature profile in the atmosphere. To know pressure/altitude you need to know the 'weight' of the air column from where you are to 'space'. To do that you need to know the temperature versus altitude of the atmosphere to space. The temperature at the bottom of the column is not that.

I concur, and EMA filter works just fine.

All of the digital baro sensors have an integrated temperature sensor that is read as part of the pressure routine. They aren't horribly responsive, however, so the "actual" pressure may not be quite accurate. Plus, the ambient temperature in an enclosed AV bay may not be quite the same as the outside temperature... particularly in hot weather. However, since you're looking at pressure changes during the flight, not the actual pressure, the incorrect temperature readings cancel out.

That is really good to know. I will check the EMA filter. Regarding the temperature, I understand that I should follow something like this: https://www.grc.nasa.gov/www/k-12/rocket/atmosmet.html
I assume, as Cerving said, that using the temperatures from the barometer would work as well, considering that my main goal is to check for differences in the readings, since I want to make the deploy. However, if I utilize the standard temperature profile, I would obtain more accurate absolute measurements, or I'm understanding somethin wrong?

Download and read carefully the Baro data sheet:
https://www.mouser.com/c/ds/?marcom=132144897
There are calibration coefficients that require reading from the Baro's internal PROM and used in the calculations.


Page 8 describes the read/calculate sequence. There may be additional App Notes with more details. There is mention of AN520 on how the Cal value's CRC is done.

If using this for Dual Deploy then Absolute Altitude is not required. First is detection of Apogee, when altitude start to decrease. Next is a pre-set altitude for Main chute deployment.
Also, what ever the Altitude calculated at launch is subtracted from all further altitudes so that it is the Altitude from the launch pad that counts.

Again, I suggest flying the sensor package and log all RAW data. Then you can determine if and how much filtering is required during Post-flight analysis.

Yes, I have read the datasheet since I have already been working with the driver. I was aware of the coefficients, and this concerns me because I expect that if the avionics bay has a different temperature, that it will, the pressure readings will differ from the outside. That would't be a problem since what I really want for doing the deployment is the difference between current altitude and the land site one. However, to determine the absolute altitude it would be a problem, I suppose. I will take a closer look at this, and since I have some sensors, I will test them out.

Thank you a lot for your answers!

 

[cerving]

If you want a "real" temperature reading, you're going to have a sensor on the outside of the rocket, and make corrections based on the difference between what the baro sensor's thermometer says and the outside one says. Again, there's a slew rate issue... it's going to take a fairly expensive thermistor using analog circuitry, and a good A/D converter to get this to work. Good luck... NONE of the commercial flight computers do this, it's really unnecessary for hobby rocketry flights.

I would not get too hung up on the "absolute" values of pressure/pressure-altitude and temperature... again, you only care about the AGL value of pressure-altitude, so subtracting whatever pressure-altitude the baro says you have at ground level from your in-flight readings will be fine.

 

[jderimig]

peratures from the barometer would work as well, considering that my main goal is to check for differences in the readings, since I want to make the deploy. However, if I utilize the standard temperature profile, I would obtain more accurate absolute measurements, or I'm understanding somethin wrong?

Yes. You follow the datasheet on how to calculate pressre from the coeffs, T, and P registers. For deployment you simply look for the point where pressure stops decreasing and starts increasing.

 

[cerving]

Almost... if you're going transonic you need to account for the "Mach dip" in pressure-altitude that you'll see as your motor is burning. There are a number of ways to account for this... I'll leave that as an exercise for the OP.

 

[waltr]

Since you will be running a commercial altimeter then you can compare measurements.
If they agree within a couple percent then that is as good as you probably can get.

Then integrating the Accel data to Velocity and again to altitude is another check. Just remember that the Accel Altitude should be higher due to it is actually 'distance' the rocket traveled which is greater if not perfectly straight up.

 

[ksaves2]

My opinion is if one is an electronics maven and wants to "roll their own" deployment altimeter well, "God bless'em." I sure couldn't do it.
It shows how good rocket people are as some answering this thread market deployment altimeters! Rocket folks are "good" people and willing to help anyone if you ask me.
I would say don't do it as there are many great products out there already but again, if one is adept in electronics, can make the investment and build their own, have at it. I think, and the experts can confirm this or not, any system needs to be calibrated before flying? Is that easy or hard to do? Kurt Savegnago

 

[Aeva]

Should help. https://web.mit.edu/kirtley/kirtley/binlustuff/literature/control/Kalman filter.pdf

With Kalman filters, I find they add a slight "lag" to the data if you have the filtering set strong enough (the altitude tends to be lower than what the sensor value currently reads). For any filtering, it would be wise to get existing altimeter data and see how it effects it before using it for trigger conditions.


The white line is the reported altitude (based off the configured sealevel pressure), yellow the difference between the ground altitude and current reported altitude, and cyan/blue is a weak Kalman filter. This is from my gui's processing of the data, so the flight computer doesn't see it. There are parameters I can tweak to iron out the noise from the EC, but it also effects the less noisy data. Personally I didn't like the caveats of Kalman filters, and had perfectly good results without it anyway using other filtering checks with the unfiltered data.

I'm using a BMP390, and I typically lean on analysis of the current unfiltered data from the sensor. I'll eventually integrate the accelerometer as a safety, but for now it has been fine with 30 seconds before armed at boot, a "minimum safe" altitude, a value for a range the EC is active while it's within +/- a distance from the desired deployment altitude, and "minimum safe" fall speed. As it's falling, if the altitude is +/- a range from the desired altitude, and the current fall speed average (over the last 10 points or whatever I configure it to) is faster than -5m/s (my configured fall speed parameter). I don't see much noise from it... at worst it's a meter or two off from the expected value. Each deployment I've done has gone off within 3meters of the configured altitude.

The times I see spikes are usually from the ejection charges. I notice my printed plastic doesn't seem to be airtight so the bulkhead lets the slightest amount of pressure through causing a momentary spike. Easy to fix on the design. I managed to eliminate the spike from my electronic EC, but the motor EC still seems to be an issue. There should be spikes from mach speeds when I get to the point, and I think the conditions I used for deployment should prevent it from premature detonation of the EC.

You may also want to check @SparkyVT's codebase on git. He shares his stuff on git, so you could fork it, or you could just use it for reference. I don't know what he does for filtering (I have been pretty busy and haven't dug into the code yet, had a few things to get done with my own), but I have seen his rockets fly successfully on his set up so it for sure works when it matters lol.

 

[jderimig]

With Kalman filters, I find they add a slight "lag" to the data if you have the filtering set strong enough (the altitude tends to be lower than what the sensor value currently reads). For any filtering, it would be wise to get existing altimeter data and see how it effects it before using it for trigger conditions.

Your Kalman filter should incorporate the dynamic model of flight and not just utilize the KF to filter common cause noise. Things like ejection spikes would effectively be filtered out because those implied motions would be very unlikely(Impossible) to happen (unless it was a UAP).

 

[Aeva]

Your Kalman filter should incorporate the dynamic model of flight and not just utilize the KF to filter common cause noise. Things like ejection spikes would effectively be filtered out because those implied motions would be very unlikely(Impossible) to happen (unless it was a UAP).

Yeah, that's just visible data on my GUI, not what the rocket's flight computer sees. It currently does a few things to analyze the vertical speed and altitude, as well ignoring data with anomalous conditions without using Kalman. I was mostly saying I've been able to get good results without leaning on the Kalman filter specifically. My rolling average stuff could probably be replaced with the Kalman filter and achieve similar results, but it works well without it... if it ain't broke don't "fix" it.

 

[ihbarddx]

For filtering baro data a simple exponential recursive filter is all you need.

https://blog.mbedded.ninja/programm...ilters/exponential-moving-average-ema-filter/
You do not use temperature to calculate pressure altitude. You use the standard atmospheric model to calculate pressure altitude which assumes a standard temperature profile in the atmosphere. To know pressure/altitude you need to know the 'weight' of the air column from where you are to 'space'. To do that you need to know the temperature versus altitude of the atmosphere to space. The temperature at the bottom of the column is not that.

Nope. If you look at the standard model, everything is multiplied by a mysterious 288.15. This is 15 degrees Celsius in kelvins - the model assumes a temperature of 15 degrees at the bottom of the column. It uses a standard tropospheric temperature lapse with altitude of 6.5 kelvins/km - that is baked into the column-weight model you refer to (hydrostatic equilibrium). So, yes, the temperature at the launch site is relevant.

If the launch site temperature is different from 15 degrees C, then you have to use the correct temperature in kelvins instead of the one above or multiply all altitudes by (RealKTemp/288.15). This, BTW, is external temperature, and not temperature inside the AV bay.

There is a wrinkle in all this. Some instruments assume 15 degrees C at sea level, rather than at launch - then the correction process is more complicated.

Basically, on warm days, the unadjusted pressure altitude will be low, and on very cold days, it will be high.

The NAR has temperature adjustment instructions somewhere.