-
Notifications
You must be signed in to change notification settings - Fork 0
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Accuracy/Noise #2
Comments
Not sure I can help here, the combination of low-pass filter (which is the
LPF) and averaging is somewhat redundant. Averaging is, of course, simple
running averaging of the data in a buffer before reporting. The low pass
filter removes high-frequency noise, so is not an averaging process per se
but a filter. They both together result in a lower noise signal, one by
removing higher frequency noise and one by removing "all-frequency" noise.
In the end what matters most is the application requirements. Both the
LPS22HB and LPS22QS can discriminate height changes of ~10 cm or more with
little trouble. The specs of the QS look about 2x better in terms of lower
noise, and in fact I find the altitude estimate based on QS pressure data
with reasonable noise filtering 1 Hz, (16x averaging, LPF/9 filter quite
stable.
I am interested in ultra-low-power usage of these kinds of sensors so for
me running at 200 Hz sample rate with heavy averaging is not an option,
although this would be a good way to get an even more "stable" baro output.
I find the 1 Hz QS performance with modest noise filtering quite acceptable
at a cost of 3 uA or so. I think it is better than the HB at the same power
cost but I don't have a good way to quantify this.
If you want to understand the details of the noise filtering and what
reasonable expectations might be, I recommend you ask ST at their MEMS
sensor forum.
…On Sun, Feb 20, 2022 at 4:48 PM hpmax ***@***.***> wrote:
I'm curious how this (and the LPS22DF which seems to have similar
performance but lacks the 4 bar mode) performs relative to the LPS22HH.
They certainly quote much better performance than the LPS22HH, but there's
one thing I noted that seems odd...
The quoted accuracy for the LPS22HH is .65 Pa at ODR/20. Which is a lot of
filtering...
By contrast, the quoted accuracy for the LPS22DF/ILPS22QS is 0.34 Pa at
ODR/9 *BUT* they specify an AVG=512, and max ODR is 200Hz.
The way I see it, a noise spec is only meaningful as a function of
bandwidth. ODR/9 sounds like its more than 2x the bandwidth and almost half
the noise, which is awesome... But what does AVG=512 mean? Assuming true
gaussian noise, averaging 512 elements would be expected to reduce noise by
a factor of 512^,5. It's hard to understand how you could average the last
512 samples and still have a bandwidth of 11% of the output data rate.
—
Reply to this email directly, view it on GitHub
<#2>, or unsubscribe
<https://github.com/notifications/unsubscribe-auth/ABTDLKUCJAY2YL4HP4DEVWTU4GDW7ANCNFSM5O5FFUYA>
.
Triage notifications on the go with GitHub Mobile for iOS
<https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675>
or Android
<https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub>.
You are receiving this because you are subscribed to this thread.Message
ID: ***@***.***>
|
@kriswiner Thanks for the quick response. My take on it is that an averager is an FIR filter (essentially all taps have a 1/N coefficient) and it results in a low passfilter with a pole at DC. In the end, both act to quash high frequency response, and looking at the table in the datasheet the averager is critical to achieving the noise spec they are quoting. I think my interest in this is somewhat different from yours. Power consumption for me isn't a concern (or rather, the power consumption of an LPS22 is trivial compared to the rest of the system) and performance is a big deal, and I'm actually looking for accurate rate of change of pressure, so filtering is a big concern of mine. A bandwidth of 1/9th of ODR with an ODR of 100Hz or higher isn't a big deal for me, but I can imagine that averager really kills the bandwidth off fast. Probably wouldn't be hard to setup an experiment to see what the noise is just sitting there on both units, and what the step response is (although I'd probably need to turn down the ODR to get an accurat reading), but of course I don't have both units just sitting around that I can test. I actually posted a question about LSM6DSM to one of your other repositories since you've been so helpful in the past. If you can't figure it out, I may have to go to ST and see what help they can provide. I'll certainly ask them for more help on the LPS22 bandwidth. ST really seemed to go through a lot of effort to ensure the interface between the LPS22 and the LSM6 are fairly similar, and yet they spec out the noise bandwidth very differently between two remarkably similar parts. Kind bugs me... |
Figured I'd update this... It looks like the LPS22DF is indeed superior. The actual data stream is oversampled and then averaged down to the ODR. 512 samples takes 33ms, which means that max ODR is 25Hz. But if you set averaging to 128, the max data rate is 75Hz, which matches the max ODR of the LPS22HH in "low noise mode." I suspect the LPS22HH is also averaging, and it's selecting between a large value (when in "low noise" mode) and a small value (when in low power mode) as we see a trade off between noise and power in both settings, and low noise is only available at relatively low ODRs. Setting the LPS22DF to 128 Averaging we get a max ODR of 75Hz, same as the max ODR of an LPS22HH in "low noise" mode. However, noise is estimated to be 0.48 Pascals in ODR/9 on the LPS22DF versus 0.9 Pascals in ODR/9 on the LPS22HH. Tightening the filter to ODR/20 which significantly hurts response time, reduces noise to 0.6, but this is still worse noise performance than the LPS22DF at ODR/9. Under the same 75Hz sampling with 128 averaging, the DF part is typically consuming 639.8uA vs 726uA on the HH part. So it's got better noise performance with a wider bandwidth and lower power. Alternately, running at AVG=512, max ODR drops to 25Hz, power consumption goes up to 783uA. ODR/9 yields a bandwidth of 2.777 Hz, versus the LPS22HH at 3.75Hz but with .34 Pascals vs .6 Pascals of noise. If we change to ODR/4, we now have 6.25Hz bandwidth and have only increased noise to .44 Pascals. So, slightly lower bandwidth and noise vs 75Hz at ODR/9, but also less data to deal with. See tables 5-7 in https://www.st.com/resource/en/application_note/an5699-lps22df-lowpower-and-highprecision-mems-nano-pressure-sensor-stmicroelectronics.pdf I think this data is pretty definitive. |
I'm curious how this (and the LPS22DF which seems to have similar performance but lacks the 4 bar mode) performs relative to the LPS22HH. They certainly quote much better performance than the LPS22HH, but there's one thing I noted that seems odd...
The quoted accuracy for the LPS22HH is .65 Pa at ODR/20. Which is a lot of filtering...
By contrast, the quoted accuracy for the LPS22DF/ILPS22QS is 0.34 Pa at ODR/9 BUT they specify an AVG=512, and max ODR is 200Hz.
The way I see it, a noise spec is only meaningful as a function of bandwidth. ODR/9 sounds like its more than 2x the bandwidth and almost half the noise, which is awesome... But what does AVG=512 mean? Assuming true gaussian noise, averaging 512 elements would be expected to reduce noise by a factor of 512^,5. It's hard to understand how you could average the last 512 samples and still have a bandwidth of 11% of the output data rate.
The text was updated successfully, but these errors were encountered: