cancel
Showing results for 
Search instead for 
Did you mean: 

What is the peak-to-peak 'g' expected on a IIS3DWB accelerometer when device is completely stationary?

GPart.1
Associate II

Hello

Sampling data from the IIS3DWB accelerometer over the course of a couple of seconds, when the device is completely stationary, on the 16g range, the peak-to-peak readings on each axis are:

p2p x = 0.0566g

p2p y = 0.0634g

p2p z = 0.1215g

These seem to be quite excessive detected movements; and assumed it was the noise floor (!!!) of the device. A bit of digging on these forums suggested enabling the LPF2; which I did, at ODR/100. The results improved, to:

p2p x = 0.0151g

p2p y = 0.0122g

p2p z = 0.0166g

But these too still appear quite large given the completely static nature of the device.

Are these results to be expected? Is this the noise floor of the MEMS device, ADC, other internal circuitry?

Kind regards

Gary Partis

1 ACCEPTED SOLUTION

Accepted Solutions
GPart.1
Associate II

HI Eleon

Many thanks for your reply.

Instead of using our product, we purchased a STEVAL-MKI109V3 "motherboard" for trying out the accelerometer with quick changes to settings; and found that enabling the high pass filter, with a low cut-off frequency (ODR/800); then the noise was roughly equal above and below the zero point, allowing for an average of almost zero.

This allows our Vrms calculations to work nicely on our product, although we are now virtually "deaf" to very low frequencies.

We are making all filter settings configurable from a user front end to add flexibility.

Kind regards

Gary

View solution in original post

5 REPLIES 5
Eleon BORLINI
ST Employee

Hi Gary @GPart.1​ ,

consider please the datasheet, p. 5.

The declared Linear acceleration zero-g level offset accuracy is typically ±60mg, with maximum range [-180mg, +180mg].

So, considering these specifications, the values you are measuring on the 3 axis are in spec.

You can improve the values in a couple of ways:

  • using the LP filter, as you have already implemented;
  • write the measured offset in the X_OFS_USR (73h), Y_OFS_USR (74h) and Z_OFS_USR (75h): this value will be internally subtracted from the acceleration value measured on the 3 axis.

If my reply answered your question, please click on Select as Best at the bottom of this post. This will help other users with the same issue to find the answer faster.

-Eleon

GPart.1
Associate II

Hi Eleon.

Many thanks for your answer.

We also perform offsetting of all 3 axes, but after data has been read from the device; to allow for varying installation orientations.

Essentially, is there any magic that I may perform to remove the random "jitter"? Is this from ADC noise etc?

Kind regards

Gary Partis

Hi Gary @GPart.1​ ,

if you have no current consumption constrains and your target is only to improve the "resolution"/repeatability performances, you can try by averaging the output data in your code: in this way you'll smooth the signal variations and decrease the noise too.

Regarding the noise floor, you can check the datasheet p.5: it is down to 75 µg/√Hz in 3-axis mode / 60 µg/√Hz in single-axis mode 

-Eleon

GPart.1
Associate II

HI Eleon

Many thanks for your reply.

Instead of using our product, we purchased a STEVAL-MKI109V3 "motherboard" for trying out the accelerometer with quick changes to settings; and found that enabling the high pass filter, with a low cut-off frequency (ODR/800); then the noise was roughly equal above and below the zero point, allowing for an average of almost zero.

This allows our Vrms calculations to work nicely on our product, although we are now virtually "deaf" to very low frequencies.

We are making all filter settings configurable from a user front end to add flexibility.

Kind regards

Gary

Thanks Gary for the feedback!

That's good

-Eleon