LIS2DTW12 accuracy & stability in an inclinometer application

[RMain.1]

I am using the LIS2DTW12 accelerometer in an inclinometer (tilt & roll) application. We have encountered some issues with accuracy and stability of the device in this application. All tests were performed with the device mounted statically, approximately horizontal (though the package is upside down) and at constant room temperature. The LIS2DTW12 is running at 3.3V. STMicro factory calibration of this device appears to be performed at 1.8V, but I expect any deviation due to VDD would result in different offset &/or gain (which would be static in a horizontal orientation with constant temperature). The LIS2DTW12 is configured for I2C comms, 2g full-scale, 12.5Hz, 12-bit (LP Mode 1), with BDU set (output not updated until MSB & LSB read). A soft reset is performed on power up. Initialization was tried both with & without the 'BOOT' bit set (forced reload of factory trimming).

Monitoring over hours (see graphs below), we see both 'dithering' (small, high frequency changes of +\- low single digit counts), and 'wandering' (more significant changes with a period of hours, with counts spanning 10s of digits). The 'dithering' is expected and well within specifications. The 'wandering' is higher than we'd like, but does not exceed specified typical (4.5mgs RMS) in LP Mode 1.

LIS2DTW stability test - hours

Most important though, we've logged significant discontinuities when the device is powered down, left for some period of time (hours/days) then powered back up (see graphs attached, the device was powered down midspan for more than 24hrs). THE DEVICE WAS NOT MOVED. If the device is powered down and then powered back up shortly afterward (an hour or two), there is no significant jump in readings. For this reason, I suspect this discontinuity may be related to the 'wandering' shown in the earlier graphs. I'm looking for any explanation of what might cause this significant change in readings, and what can be done to fix or at least mitigate it.

LIS2DTW power cycle discontinuity

A second issue is the (unexpected) tracking apparent between the Y & Z axes. The device is mounted parallel to the horizontal plane. I would expect the MEMs implementation of X & Y would be similar, and Z would be the odd axis (i.e., etched to the silicon in a mechanically different implementation). Since Y & Z both jump together at the 'power cycle discontinuity', it would appear they are somehow coupled, and this might provide a clue to the source of the jump.

Thanks & regards,
R. Main.

[niccolò]

Hi @RMain.1 ,

the 'dithering' you see is the normal noise from the sensor, while the 'wandering' can be due to different factors:
the offset and the output varies with the temperature, and I also expect the case to have thermal modifications that can affect that measurements. overall, what you show in the first graphs is expected for a test performed with uncontrolled environment.

regarding the second plot, a similar explanation is involved: maybe the temperature makes the offset shift, along with the fact that the case itself has some microvariations while the sensor is off.

finally, keep in mind the fact that the physical axis are not orthogonal, and Y and Z can interfere with each other for slight variations.

If this answers your question, please, mark this as "best answer", by clicking on the "accept as solution" to help the other users of the community

Niccolò

[RMain.1]

As I stated, the dithering was 'within spec', as was the wandering (though higher than I'd like to see).

The datasheet specifies TCO (offset) as +/- 0.2mg/deg C (typical), and TCS (sensitivity) as 0.01%/deg. C (typical). Neither of these can account for the significant jump I've shown. As I stated, all tests were performed at room temperature (say 21C +/-2C). If you're still suggesting thermal variation as a cause, I can re-run tests with temperature more tightly controlled, but unless the values quoted in the datasheet are bogus, I can't see thermal effects accounting for the change observed.

Please explain your statement: "finally, keep in mind the fact that the physical axis are not orthogonal, and Y and Z can interfere with each other for slight variations."

I expect that the x,y, & z axes are very close to orthogonal within the device. If you mean these axes are not precisely aligned with the X,Y & Z axes of the product the device is mounted within, and some cross-coupling of acceleration (for instance gravity) can be expected, that is understood. However that does not explain CHANGES in cross-coupling  when nothing has moved.

Thanks,

Robb.

[niccolò]

Hi @RMain.1 ,

I think that the temperature is responsible for the oscillations from the 8 hour and above (if you can repeat the test with that, we can be sure of it)
you are right in saying that the initial drift is above our test results, could it be that the setup is not completely still?
maybe you fix it with tape or something that adjusts in a few hours? if you could share a picture of the setup it could be helpful =)

 "finally, keep in mind the fact that the physical axis are not orthogonal, and Y and Z can interfere with each other for slight variations."
What I mean is that the physical axis of the MEMS, so the way the sensor senses the gravity, are not completely orthogonal, like in a normal XYZ space. anyway, I don't think that this is the reason for the fact that both those axis are up after the wakeup. I think that those axis are up because they sense this variation, maybe due to the setup.

Niccolò

[RMain.1]

Temperature has no correlation with the dithering. I ran tests inside our environment chamber at a constant temperature, and added the temperature read from the LIS2DTW accelerometer to the log. The test ran for 48 hours (see below). 

I turned the device off for 48hrs, then ran a second test for 18hrs, turned it off for 24hrs, and ran a third test for 20 hours. I then extracted the last hour of data from the first two tests, and plotted them immediately followed by the first hour of data from the subsequent test (to show any discontinuity). See results below.

In each case, the shutdown occurred at the 1hr mark in the graphs above. The reported temperature at startup is considerably & consistently off. When re-starting a test, I left the device un powered to soak at the set temperature for 2 hrs prior to turning it on, so it had definitely reached thermal equilibrium. I'd suggest that the internal temperature reported appears to reflect some heating internal to the device after powerup, which is independent of ambient temperature.

It is not clear why the deviation (only Y & Z) at the start of the second test is almost triple that seen at the start of the third test. duration of the previous test &/or duration of shutdown may be involved. It's unclear how shutdown duration could be involved, BUT we have see that little if any deviation is detected if the device is turned off for only a short period.

Temperature is not a factor in these errors.

 

 

[Federica Bossi]

Hi @RMain.1 ,

Can you try again the test without the soft reset performed on power up?

Let me know if something changes.