Barometric Pressure Altimeter Noise

The Rocketry Forum

Help Support The Rocketry Forum:

This site may earn a commission from merchant affiliate links, including eBay, Amazon, and others.
Joined
Jun 3, 2024
Messages
5
Reaction score
1
Howdy folks, I'm a software guy trying to get into electronics for rocketry and had a question about expected sensor noise.
I ran a simple experiment on my desk the other day as I was testing out my prototype flight logging computer.
Using a MPL3115A2 barometric pressure altimeter I logged the readings in altimeter mode to a SD card.

setup.jpg

I'm not so much concerned about the value drifting (my room was likely just getting hot from the sun and this was over a couple minutes) as much as the noise.
This sensor has a high resolution mode to internally reduce noise which I am utilizing at the full 128x oversample rate. The datasheet claims the pressure reading noise in this 128x oversample configuration will be 1.5 Pa RMS, which should correspond to less than a foot of deviation on average but my data is showing constant jumps of almost 10 feet. Are there techniques necessary to reduce the noise in these sensors? I've seen other threads where people mention that they will cover their sensor in foam in the rocket itself and apply a kalman filter, but I would think based off the datasheet that the raw output would be a little better, is this copium?

chart.png
 
How do you know its noise? Take an FFT of the data and see what you got.
 
Is your sensor in the dark?
Do you have any HVAC running?
Any sound in your environment?
Any vibration where its is mounted?
Any electric fields nearby?
Running off a battery or bench supply?
 
How do you know its noise?
You got me there, that was just my assumption from looking at the spikiness of the data. I did this test in my home office that had both HVAC, light, a running PC, and using a battery as the power source. I suppose it would be better to do this in my garage with the electricity shut off
 
You got me there, that was just my assumption from looking at the spikiness of the data. I did this test in my home office that had both HVAC, light, a running PC, and using a battery as the power source. I suppose it would be better to do this in my garage with the electricity shut off
Light can affect the reading. Just cover the sensor.
Putting the boards in a jar will eliminate any air currents.
Otherwise a recursive digital low pass filter in your code will smooth out the readings.
 
Yeah, dunno. What we usually see in the lab is the sensor maybe clicking up or down a foot every so often. For instance, take an AltimeterOne and put it in realtime mode and you raise it up and will show 1, 2, 3 and lower it down and it will show 2, 1, 0, -1, -2, etc.

Certainly no instantaneous error of 10 feet, and we don't use anything like 128x oversample. Offhand I think it's more like 32x or something. Something like that, or lower. No experience with that particular sensor you are using, we have relied on ST sensors lately.

Sorry I can't be of more help. Maybe I'd check the math that you are using to make sure it's not aliasing and amplifying noise?
 
Sorry I can't be of more help. Maybe I'd check the math that you are using to make sure it's not aliasing and amplifying noise?
^ This. Lets see your pressure readings. Are you in Denver or mile high on your bench?
 
You got me there, that was just my assumption from looking at the spikiness of the data. I did this test in my home office that had both HVAC, light, a running PC, and using a battery as the power source. I suppose it would be better to do this in my garage with the electricity shut off

Hi Kevin, I am simply curious about the use of Raspberry Pi Pico. I not have used that type yet and I haven't coded in about 7 years or so.

What are the reasons, advantages of using Pico over say small/Tiny STM-32s or Arduino Tiny types etc. ?
 
we have relied on ST sensors lately
I wasn't aware of the ST pressure sensor lineup, in fact there seems to be a lot of alternative sensors I missed when looking up what to use at first. Looking at the ILPS22QS for example the relative pressure accuracy and noise looks really good! +/- 0.015 hPa relative accuracy for this sensor compared to the +/- 0.5 hPa relative acuracy of the MPL3115A2.

I found this example of someone who did a desktop test of the ILPS22QS and was able to get relative readings within 1 foot as you have mentioned.
https://github.com/kriswiner/ILPS22QS

Are you in Denver
Yes I am in Colorado, will try to attend more NCAR launches this summer!

I am simply curious about the use of Raspberry Pi Pico.
I am fairly new to the world of microcontrollers, I have noticed the popularity of STM32/ESP32 but was attracted to the Pico by the price and straightforwardness of the getting started documentation provided by the pi foundation. My only prior experience was with the PIC16 microcontrollers when I was in school but I remember those being a pain to order. I ended up picking up several of these Seeed Xiao RP2040 boards that are some of the tiniest MCU packages I have found for $5 a pop.

Anyways, my prototype was not working reliably. It would randomly shut off and I haven't been able to get SWD debugging to work to figure out where things are failing. When hooking up the pico debug probe I would get some error about multidrop failing in OpenOCD when I tried to flash. I took a step back and went with a simple approach first mindset instead of exploring a bunch of new things all at once.

My first test setup was using the Rust programming language with the rp-hal library for embedded development on the software side, and solder traced protoboard for the connections. I had gravitated towards Rust because I've used it in many non-embedded hobby projects before and felt somewhat comfortable in that environment. This was also my first time making a circuit using protoboard and it took a long time and was very messy.

I switched to using Arduino IDE and putting everything onto a breadboard and am now getting results more like what I was expecting to see; no more 10 foot jumps! the readings are now within a foot of eachother when sitting on the table.

I wish I had a better idea of why things looked so wild in the first test, but will take this small victory.

setup2.jpg
 
Last edited:
Attached is data from one of my BMP280 altimeters sitting on my desk running at 16x oversample rate, internal IIR filter, and 2Hz data rate. The altitude value from the MPL3115 can only be read every 512 ms at the 128x oversample rate. Since I do not have an MPL3115's to test, I suggest you lower your oversample rate to 64X or 32X and retest. If you are reading the output register faster than 2Hz you could be reading corrupted data.
 

Attachments

  • BMP280 Drift.png
    BMP280 Drift.png
    86.6 KB · Views: 0
Hi Kevin, I am simply curious about the use of Raspberry Pi Pico. I not have used that type yet and I haven't coded in about 7 years or so.

What are the reasons, advantages of using Pico over say small/Tiny STM-32s or Arduino Tiny types etc. ?
Art, I find the RP2040 runs code very efficiently for a 133 MHz dual core. The XIAO pcb format is great for small LPR BT-20/BT-50 flight computers. I saw that Adrian flew a DD altimeter in a BT-20 rocket. I'm prepping a 900Hz flight computer, using a RP2040, for a 2-stage BT-20 flight.
 
Art, I find the RP2040 runs code very efficiently for a 133 MHz dual core. The XIAO pcb format is great for small LPR BT-20/BT-50 flight computers. I saw that Adrian flew a DD altimeter in a BT-20 rocket. I'm prepping a 900Hz flight computer, using a RP2040, for a 2-stage BT-20 flight.

Very nice, and much smaller then the first one posted.
 
Very nice, and much smaller then the first one posted.
Art, if you want to start, I recommend the Adafruit QTPY or Seeed XIAO SAMD21 or the RP2040 processors. Your coding skills will quickly return. As a former Z-80 Assembly developer, it only took me 4 months to go from beginner C++ to flying a 400Hz flight computer.
 
Art, if you want to start, I recommend the Adafruit QTPY or Seeed XIAO SAMD21 or the RP2040 processors. Your coding skills will quickly return. As a former Z-80 Assembly developer, it only took me 4 months to go from beginner C++ to flying a 400Hz flight computer.
I'm not familiar with the quantification of flight computer rates. When you say it is a 400Hz flight computer what does that actually mean? Is it sampling sensors at that rate or is it computing its position at that rate?

Thank you for providing the BMP280 data, I'd like to do a comparison with a similar setup (x16 OSR 2Hz) for the MPL3115A2 and the DSP310. I will post the results here when I get around to testing that.

I was able to get things working using the Pico C SDK and am interested in seeing how much power savings I can achieve by using a dormant mode wake interrupt approach instead of direct polling. I am not sure yet how to measure the power consumption though.
 
I'm not familiar with the quantification of flight computer rates. When you say it is a 400Hz flight computer what does that actually mean? Is it sampling sensors at that rate or is it computing its position at that rate?

Thank you for providing the BMP280 data, I'd like to do a comparison with a similar setup (x16 OSR 2Hz) for the MPL3115A2 and the DSP310. I will post the results here when I get around to testing that.

I was able to get things working using the Pico C SDK and am interested in seeing how much power savings I can achieve by using a dormant mode wake interrupt approach instead of direct polling. I am not sure yet how to measure the power consumption though.
My definition for flight computer speed is the "average" data capture rate for a specified number of sensors. My 400Hz flight computer recorded the CPU millisecond time and three accelerometer sensor readings every 2 milliseconds. It also recorded barometric pressure, temperature, and altitude every 200 milliseconds. The internal SD Flash static buffer could hold 200 milliseconds of data before I had to write it to the Flash memory cells. The SD library requires ~25 milliseconds to write a large block of data to the Flash cells and there are other processor housekeeping chores that also consume milliseconds of time. All these milliseconds of time lost reduces the capture rate to an average of 400Hz.

Today, I've learned to apply data buffers with DMA when the SD Flash card is busy writing data coupled with the faster SdFat library to achieve 500 - 1000Hz for most of my applications. Using the Teensy 4.X you can capture 6 - accelerometer channels and 3- gyro channels at 1600Hz. Determine your quaternion position at 100Hz with time to spare.

Unless you plan on selling a competition grade altimeter, running a comparison between altimeters is not worth the effort. The 1-foot resolution and repeatability of specific products is a marketing sales ploy. I was an engineer for the Marketing department for two companies. I had to give the salespeople the truth about our competitors' products and what was the best sales approach for specific customers. As you go higher and faster, altitude values become less important. Air pressure, temperature, density, and drag coefficients are of higher value than altitude.
 
Unless you plan on selling a competition grade altimeter, running a comparison between altimeters is not worth the effort.

I can't say I have a good reason for wanting to do these comparisons other than I think its really neat. I'm actually having fun reading these datasheets and noticing differences in how manufacturers do things. I got the DPS310 in the mail today and my initial test of it is extremely impressive to me. The data just looks clean. I lowered the device by 31 inches and the sensor stabilized to 27.6 inches below the initial average.


DPS310 Indoors Test.png
 
Inches should be easy to do. My landscaper has a barometer based gadget to check grading. Inch resolution is not a problem with it.
 
Back
Top