orientation and movement values in LIS2DW12 accelerometer

[Msaga.1]

Hello We are working with accelerometer LIS2DW12.

we did tests on the different movements of the accelerometer and the graphs we see (the graphs were made with the x_physical y_physical z_physical values). However we see graphs that are not as we expected;

when we look at a 'free fall' movement we expect to see all axis intersect in value 0, however it is not the case.

For example:

1. in this image we see free fall when the orientation bit raised on zh (meaning the fall was on zl), but I do not see intersection of all axis ( Z is not even close) and I do not see intersection on 0 - x&y intersect on ~300 . Please explain this.
2. here we do see intersection , however it is around value ~360 and not 0. Please explain why we see it.

More images :

here we see that the intersection is ~200

here we see that the intersection is ~250 (at 31)

here we don't see intersection and the values are not as expected from free fall.

Please help me understand our results.

[Eleon BORLINI]

Hi @Msaga.1​ ,

it could be that the accelerometer has a residual offset, and I'm referring to the plots where you are seeing the intersection among the axes.

I suggest you to first check this residual in a steady condition, i.e. with the device is flat on the ground, with z axis pointing to the sky. In particular, you can tune the X_OFS_USR (3Ch), Y_OFS_USR and (3Dh), Z_OFS_USR (3Eh) registers (see datasheet p. 55) to minimize the offset value.

By the way, is the device in free fall condition during all the plotted acquisition, of just in a small timeframe? Which is the time scale along x axis (if seconds, it's difficult to capture a (fast) free fall in rms value)?

I suggest you in any case alto to check the C example for the free fall app on Github --> lis2dw12_free_fall.c, especially for a double check of the device initialization:

 /* Configure power mode */
 lis2dw12_power_mode_set(&dev_ctx, LIS2DW12_HIGH_PERFORMANCE_LOW_NOISE);
 /* Set Output Data Rate */
 lis2dw12_data_rate_set(&dev_ctx, LIS2DW12_XL_ODR_200Hz);
 /* Set full scale to 2 g */
 lis2dw12_full_scale_set(&dev_ctx, LIS2DW12_2g);
 /* Configure Free Fall duration and samples count */
 lis2dw12_ff_dur_set(&dev_ctx, 0x06);
 lis2dw12_ff_threshold_set(&dev_ctx, LIS2DW12_FF_TSH_10LSb_FS2g);
 /* Enable free fall interrupt */
 lis2dw12_pin_int1_route_get(&dev_ctx, &int_route.ctrl4_int1_pad_ctrl);
 int_route.ctrl4_int1_pad_ctrl.int1_ff = PROPERTY_ENABLE;
 lis2dw12_pin_int1_route_set(&dev_ctx, &int_route.ctrl4_int1_pad_ctrl);
 /* Set latched interrupt */
 lis2dw12_int_notification_set(&dev_ctx, LIS2DW12_INT_LATCHED);

-Eleon

[Msaga.1]

Hi @Eleon BORLINI​ ,

>>you can tune the X_OFS_USR (3Ch), Y_OFS_USR and (3Dh), Z_OFS_USR (3Eh) registers (see datasheet p. 55) to minimize the offset value

I have written to the registers however nothing has changed, can you explain it to me?

Thank you

[Msaga.1]

Hi @Eleon BORLINI​ , thank you for your answer,

About checking  this residual in a steady condition I am attaching the graphs for the steady condition:

this is an example on one orientation bit, on all orientation we get the same graph +-g on the appropriate axis. (dont pay any attention to the right graph)

The device in free fall condition during a small timeframe, we want to see the movement graph if we 'drop it'.

What is the example you said will do? what do I expect to see?

thank you

[Eleon BORLINI]

Hi @Msaga.1​ ,

since the free fall event is very fast, in order to see the movement graph you have to acquire -for example- at 200Hz as shown in the C example above.

Which data rate speed are you using so far?

By the way, in the stationary graph I see there is a residual offset especially on Y axis, that you can compensate writing the average value in the Y_OFS_USR and (3Dh) register.

The example above shows you how to configure the embedded free fall detection feature in the device, showing you especially how to characterize the free fall event in terms of duration (06h value = 6 * 1/ODR) and threshold (3h = 10LSB), in the FREE_FALL (36h) register.

Are you exploiting this feature?

-Eleon

[Msaga.1]

Hi @Eleon BORLINI​ ,

The free fall even takes less than 1 sec. so how can I get the values from the fall to be more accurate?

(I am not *yet* exploring the feature you suggested, but will it work if the fall is less then 1 sec?)

Regarding the tuning the registers -

If I will tune them on one surface , will it be accurate on other surface as well? (on the same position)

[Msaga.1]

@Eleon BORLINI​ 

another question - if I tune the registers while it is on zh orientation ( so the values should show 0,0,1g)

what will happen if I will put the device on xl orientation , will I see -1g,0,0 ?

The question is will tuning on one orientation , effect the values we get the different orientation?

[Eleon BORLINI]

HI @Msaga.1​ ,

>> so how can I get the values from the fall to be more accurate?

You can set the duration in the FREE_FALL (36h) register (plus FF_DUR5 bit in WAKE_UP_DUR (35h) register) so that it is below 1s and, to increase the accuracy, you should increase ODR.

>> If I will tune them on one surface , will it be accurate on other surface as well?

You have first to be sure that your reference surface is flat, so that it is orthogonal to the Earth center. In this way, you will have an absolute reference in your device.

>> what will happen if I will put the device on xl orientation , will I see -1g,0,0?

if you also tuned the x and y axis towards 0g when you were in z position, yes, you will see -1g, 0g, 0g.

-Eleon

[Msaga.1]

Hi @Eleon BORLINI​ ,

>>if you also tuned the x and y axis towards 0g when you were in z position, yes, you will see -1g, 0g, 0g.

so just to double check - if I am on zh orientation, and I tune the values towards x=0g y=0g z=1g, I wil still be able to get 0g on z-axis if I were to be on xl orientation?

[Eleon BORLINI]

HI @Msaga.1​ ,

yes, you will,

-Eleon

[Msaga.1]

Thank you @Eleon BORLINI​ ,

A few more questions:

1) Regarding the free fall initialization , I read page 6 , and the init for LIS2DW12 said " write_reg(0x36, 0x1B); /* FREE_FALL(36h): Set Free-fall duration and threshold */"

I wonder why? the device should recognize any movement regardless of threshold.

I made a graph were I caught free fall movement without this threshold.

aside from the offset, that can be fixed, why the file above specifies to write to FREE_FALL?

2) >>You can set the duration in the FREE_FALL (36h) register (plus FF_DUR5 bit in WAKE_UP_DUR (35h) register) so that it is below 1s and, to increase the accuracy, you should increase ODR.

I want to keep the ODR = 12.5 Hz and get the same graph for 0.5 m fall (according to my calculations I should see at least 3 points of (0,0,0),

However I do not see it.

So I am activating the low noise filter (LIS2DW12_CTRL6, 0x00) on 100 HZ , should it be the same value on 12.5 Hz? or perhaps 0x04?

(on ODR = 12.4 Hz I am using (LIS2DW12_CTRL6, 0x04) for activate low noise filtet I am wondering if it is correct or should it be 0x00)

3) Why do I see an offset in the first place? I understand that nothing is perfect but as you can see from the image, offset of 150-200 is large (in my opinion).

[Eleon BORLINI]

Hi @Msaga.1​ ,

1) The threshold is needed for the internal state machine (the free fall block) to recognize how much close to the 0g level the free fall event shall be. In the graph you are showing, all the axis are close to 0g and the device should correctly detect the free fall with a proper setting of the threshold. This could be tuned trying multiple drops and checking the best threshold for your application.

2) Do you have problems to detect the free fall (axis below defined threshold) also with higher ODRs? 3 points should be enough but aren't too many...

By the way, enabling the low noise filter should also affect the noise performances in LP, according to the Table 11 in the datasheet, p.15.

3) + I have written to the registers however nothing has changed, can you explain it to me?

A spurious offset due to soldering, or the specific application setup could affect the correctness of the acceleration zero level. But are you writing values in the registers without seeing any variation of the data, at least in the steady state?

-Eleon

[Msaga.1]

1) thank you

2) no , but I want to keep my ODR low (12.5 Hz)

3) I am writing values in the registers without seeing any variation of the data, at least in the steady state

[Eleon BORLINI]

Hi @Msaga.1​ ,

so probably it is an issue coming from the combination of the small drop and the low ODR...

Couldn't you just double the ODR?

-Eleon

[Msaga.1]

No I cant double the ODR, then how do i solve the problem? i still dont see those 3 point and i SHOULD.

[Eleon BORLINI]

Hi @Msaga.1​ ,

understood... what if you slightly increase the free fall threshold, so that you'll probably have more point in a "free-fall condition"?

3 points are a bit few, in practice...

-Eleon

[Msaga.1]

@Eleon BORLINI​  tank you, but why should it work? in theory even without threshold , if I look at a graph made by the x,y,z values I got. I should see points.

The threshold is only if I want the accelerometer to tell me that the movement was free fall.

[Eleon BORLINI]

Hi @Msaga.1​ ,

but isn't your target the reading of the accelerometer interrupt, when the free fall is happening?

The increase of the threshold would increase the probability (number of points) to make this interrupt rising, detecting the correct free-fall movement.

Another question: in order to avoid spurious effects coming from a single device, did you have the possibility to test another LIS2DW12?

-Eleon

[Msaga.1]

Hi @Eleon BORLINI​ ,

What I want is to look at the graphs I make from the x,y,z values and 'see' the free fall (x number of points with the value 0,0,0 - x depending on the hight of the free fall)

so i dont care much for the interrupts.

>>in order to avoid spurious effects coming from a single device, did you have the possibility to test another LIS2DW12?

I tested this on multiple devices but unfortunately the same result.

[Eleon BORLINI]

Hi @Msaga.1​ ,

please note that the recommended threshold for recognizing a free fall event with the internal interrupt is FF_THS = 0b011 corresponding to ~ 10 x 31.25 mg = 312 mg (see the document), and not strictly zero, since spurious acceleration during the free fall might occur (for example rotations that ends up in linear acceleration, or torsional effect).

For this reason, I suggest you to use a similar threshold.

-Eleon

[Mostafa1]

---

@Eleon BORLINI wrote:

Hi @Msaga.1​ ,

 

please note that the recommended threshold for recognizing a free fall event with the internal interrupt is FF_THS = 0b011 corresponding to ~ 10 x 31.25 mg = 312 mg (see the document), and not strictly zero, since spurious acceleration during the free fall might occur (for example rotations that ends up in linear acceleration, or torsional effect).

For this reason, I suggest you to use a similar threshold.

 

-Eleon

---

Hi, any idea where this 31.25mg came from?