How to get correct acceleration values from LSM6DSOXTR Sensor?

Shivam Paliwal · ‎2021-09-29

We are using LSM6DSOXTR Sensor for getting the acceleration,

Its datasheet says

(4.6.2- Zero-g and zero-rate level Page no 17)"A sensor in a steady state on a horizontal surface will measure 0 g on both the X-axis and Y-axis, whereas the Z-axis will measure 1 g."

but we are getting below values,

X Y Z

13 65531 64541

13 65532 64542

6 65530 64539

8 65531 64540

Can anyone suggest

1)Why we are getting this much high values?

2)How to achieve the value "0" in the X, Y-axis when the sensor is put on a flat non-moving surface?

It will be more helpful if someone shares a sample code which is showing the settings and process to get correct acceleration data.

Thanks

Eleon BORLINI · ‎2021-09-30

Hi @Shivam Paliwal ,

please note that the data you are getting has to be converted from LSB to physical units (in this case, milli-g) through two's complement conversion.

You can find example of these conversion formulas in C on Github driver page --> lsm6dsox_reg.c

Supposing you have configured your device in Normal mode, and with a +-2g FullScale (is this assumption correct?), you have:

float_t lsm6dsox_from_fs2_to_mg(int16_t lsb)
{
  return ((float_t)lsb) * 0.061f;
}

Data output:

X axis --> 13 LSB = 13 DEC = 0.8 mg [correct]

Y axis --> 65531 LSB = -5 DEC = -0.3 mg [correct]

Z axis --> 64541 LSB = -955 DEC = -60.7 mg [this is low, should be around 1000 mg. Are you applying some filters?]

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

View solution in original post

Eleon BORLINI · ‎2021-09-30

Hi @Shivam Paliwal ,

please note that the data you are getting has to be converted from LSB to physical units (in this case, milli-g) through two's complement conversion.

You can find example of these conversion formulas in C on Github driver page --> lsm6dsox_reg.c

Supposing you have configured your device in Normal mode, and with a +-2g FullScale (is this assumption correct?), you have:

float_t lsm6dsox_from_fs2_to_mg(int16_t lsb)
{
  return ((float_t)lsb) * 0.061f;
}

Data output:

X axis --> 13 LSB = 13 DEC = 0.8 mg [correct]

Y axis --> 65531 LSB = -5 DEC = -0.3 mg [correct]

Z axis --> 64541 LSB = -955 DEC = -60.7 mg [this is low, should be around 1000 mg. Are you applying some filters?]

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

Eleon BORLINI · ‎2021-10-06

Hi @Shivam Paliwal ,

do you have any news about this issue?

-Eleon

Shivam Paliwal · ‎2021-10-07

Hi @Eleon BORLINI ,

Thank You so much for your response ...

and apologies for the delayed reply..

Your reply helped us a lot.

Below is the raw data that we got from the sensor (Physical condition of PCB- Accelerometer PCB is not moving and put flat on the plastic table)

8bit	 8bit	 8bit	 8bit	 8bit	 8bit
X-low	X-high	Y-low	Y-high	Z-low	Z-high
29	0	34	1	76	192
223	0	35	1	177	192
54	1	175	0	41	193
6	1	99	0	116	192
143	0	141	0	103	193
35	1	155	0	227	186
204	255	27	2	250	191
126	0	18	1	87	194
167	0	12	1	44	192

same data in combined 16 bit

16bit	16bit	16bit
X-combined	Y-combined	Z-combined
29	       290	    -16308
223	       291	    -16207
310	       175	    -16087
262	       99	    -16268
143	       141	    -16025
291	       155          -17693
-52	       539	    -16390
126	       274	    -15785
167	       268	    -16340

and after multiplying it with Sensitivity +-2g (i.e 0.061)

We got the below values..

X in mg	Y in mg	Z in mg
1	    17	-994
13	    17	-988
18	    10	-981
15	     6	-992
8	     8	-977
17	     9	-1079
-3	    32	-999
7	    16	-962
10	    16	-996

I am assuming it is in mg..

Can you please tell

1)Is my understanding correct for the conversion process and unit of X Y Z??

2)When we convert this data in mm/sec2 (1 g = 9806.65 mm/s2.), We get the below values

X in mm/s2	Y in mm/s2	Z in mm/s2
9.80665	     166.71305	     -9747.8101
127.48645	166.71305	-9688.9702
176.5197	98.0665	       -9620.32365
147.09975	58.8399	       -9728.1968
78.4532	       78.4532	       -9581.09705
166.71305	88.25985	-10581.37535
-29.41995	313.8128	-9796.84335
68.64655	156.9064	-9433.9973
98.0665	      156.9064	         -9767.4234

Do you think these values are correct even if Accelerometer PCB is just lying on the plastic table??

Used below function from lsm6dsox_reg.c for getting raw acceleration data from the sensor.

/**
  * @brief  Linear acceleration output register.
  *         The value is expressed as a 16-bit word in two’s complement.[get]
  *
  * @param  ctx      read / write interface definitions
  * @param  buff     buffer that stores data read
  *
  */
int32_t lsm6dsox_acceleration_raw_get(stmdev_ctx_t *ctx, uint8_t *buff)
{
 
  int32_t ret;
  ret = lsm6dsox_read_reg(ctx, LSM6DSOX_OUTX_L_A, buff, 6);
 
  return ret;
}

Sorry for such a big question...

Thanks.

Eleon BORLINI · ‎2021-10-07

Hi @Shivam Paliwal ,

1) Is my understanding correct for the conversion process and unit of X Y Z??

Right, the values look correct (along Z you see the 1g gravity acceleration) and

2) Do you think these values are correct even if Accelerometer PCB is just lying on the plastic table??

The conversion from mg into mm/s2 is correct. Consider that there can be a residual Zero g level (±20mg, see datasheet, p.10).

If you want to reduce this value, you can characterize it in a steady state and then write the value into the X_OFS_USR (73h), Y_OFS_USR (74h) and Z_OFS_USR (75h) registers, enabling the USR_OFF_ ON_ OUT bit of 1 CTRL7_G (16h) register.

The function you reported is ok.

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

Shivam Paliwal · ‎2021-10-08

Hi @Eleon BORLINI

Thanks for the data validation...

We will try residual Zero-g level settings and let you know the result...

Regards,

Shivam

Shivam Paliwal · ‎2021-12-23

Hi @Eleon BORLINI

as you know ,

We are using LSM6DSOXTR Sensor for getting the acceleration

Accelerator data coming from ST Sensors showing very high value of acceleration,

when compared to other Product such as XYZ brand.

We mounted ST Sensor on an Industrial equipment, we get Acceleration data in mm/sec2 as below.

(We converted from mg to mm2 by ((value in mg/1000)*9806.65) )

Y(in mm/sec2)	X(in mm/sec2)	Z(in mm/sec2)
8904.4382	4462.02575	5913.40995
9649.7436	5040.6181	3196.9679
10042.0096	2098.6231	696.27215
10865.7682	-961.0517	4177.6329
10669.6352	-6040.8964	3206.77455
10238.1426	-3991.30655	4001.1132
9306.51085	-1078.7315	1490.6108
9590.9037	2000.5566	98.0665
8227.77935	176.5197	-1990.74995
8727.9185	-2441.85585	3628.4605

When we mount Sensor from other brand XYZ, and measured vibration for same condition, we get below values.

x(in mm/sec2)	y(in mm/sec2)	z(in mm/sec2)
9.439	7.57	1.122
8.785	6.168	5.327
6.823	2.056	5.047
8.411	1.963	3.084
9.907	6.262	6.262
7.29	3.178	9.253
5.327	2.71	11.776
6.823	1.963	20.374
5.421	1.589	24.113
0.467	0.935	22.43

There is huge difference between these values coming from 2 sensors for exactly same conditions.

We then calculated VRMS from acceleration data from ST Sensor and XYZ sensor. With ST sensor it is coming abnormally high data.

Effectively we understand acceleration data coming from ST sensor is high value than it should be, but we are not sure, reason for this.

When we just keep ST sensor on stationary surface, we get acceleration data in mm/sec2 as below. (converted from mg)

X in mm/s2	Y in mm/s2	Z in mm/s2
9.80665	     166.71305	     -9747.8101
127.48645	166.71305	-9688.9702
176.5197	98.0665	       -9620.32365
147.09975	58.8399	       -9728.1968
78.4532	       78.4532	       -9581.09705
166.71305	88.25985	-10581.37535
-29.41995	313.8128	-9796.84335
68.64655	156.9064	-9433.9973
98.0665	      156.9064	         -9767.4234

This looks to be very large. Can you please throw some light??

Regards,

Shivam