Bias between different oversampling levels

[dinigo]

Hello! thanks a lot for your work here!

I'm trying to filter out this high frequency noise and, while analizing the data, ultra_low oversampling consistently sheds 20mBar less than ultra_high. I wonder whether this is normal.

Also, it's hard to characterise this noise. There's no spike in the spectrum (fourier transform) for any of the sampling methods. Only the band-base signal.

I'm thinking of the best way to filter out the noise. If you had some ideas (IIR/FIR/Kalman...) and also, maybe the reset(1) method can include this oversampling aware compensation

[RobTillaart]

Thanks for this issue. You have explored the sensor in far more depth than I have, so I do not have an answer.

(Thinking out loud modus) One possible cause that I have seen in the past is (partially) integer math. Best known are truncating effects in divisions (11/3 =3). Another is related. Oversampling means more samples and therefore more chance on canceling noise effect. This latter would show up as more spread, not perse changing the average.

[RobTillaart]

BTW This wider spread with lower oversampling is perfectly visible in your graph.

[RobTillaart]

Had a quick look at the data sheet, and so no indication of this bias. As it looks like a systematic error, can you tell about the setup used to make these measurements?

[RobTillaart]

I'm thinking of the best way to filter out the noise. If you had some ideas (IIR/FIR/Kalman...) and also, maybe the reset(1) method can include this oversampling aware compensation

to handle the bias.

As the bias seems constant, the simplest solution might be to use the offset functions:

• void setPressureOffset(float offset)
• float getPressureOffset()

A more elaborate version could have set a different offset for every resolution (oversampling rate) That would costs quite some RAM if done for both temperature and pressure. So better handled outside the library as not everyone will need it.

to handle the spread

The oversampling could also be done outside the sensor (if your processor has CPU to spare) I have two libraries that could help.

• https://github.com/RobTillaart/runningAverage
• https://github.com/RobTillaart/runningMedian

[RobTillaart]

4AM idea!

Can you make a graph of the temperature measured by the sensor for the different modi?

hypothesis

To calculate the pressure the temperature is needed. Making many measurements probably generates heat. This could affect the math for the pressure. More samples more heat more deviation.

Note:

• the offset for the temperature is not taken into account for the pressure math.
• a heatsink on the sensor could help?
• is the temperature of the air constant?

Todo check the formulas ( simulation? )

[RobTillaart]

Back to your original post.

ultra_low oversampling consistently sheds 20mBar less than ultra_high.

What is the unit of the y-axis? If it is mbar, the difference is 0.2 mbar consistently, (not 20) which is well within the error-band of the sensor

[RobTillaart]

@dinigo Any new insights?

[dinigo]

Hello @RobTillaart , didn't have much time this weekend. Your insights are really very valuable. I'll try:

Rising temp hypothesis

I'm using a sketch practically identicall to your test.ino. Except I'd remove delays to get the highest sample rate possible. Oversampling is used "round-robin" style, so the effect of temperature should be consistent. I'd get some temp data anyway 👍

What's the unit of the y-axis?

It's mBar vs millis

the difference is 0.2 mbar consistently, (not 20) which is well within the error-band of the sensor

True! it's ~10x smaller than expected accuracy at this temp (~20ºC). That's actually great!

Other interesting things about noise characteristics of samples:

Looking for the best possible filter I've gone through several steps, in case you're interested: Check whether there's some common noise component between different oversampling signals. Doesn't seem to (other than the base-band "intended" one)

Same for the spectrum (FFT). It's completely flat, not a single spike (other than the base band delta at 0, which is not visible)

And the spectrogram doesn't show anything other than background/wide-spectrum/white noise

[RobTillaart]

Thanks for this additional analysis. So in summary, the sensor behaves very nicely within the specifications (in I2C modus).

@dinigo Do you miss any (generic) functionality in the library?

[dinigo]

Not really, this 20mBar error is not such, but rather 0.2mBar (which, as you point out, is well within the error range)

Thanks for your work (on the lib) and your wise comments