LIS3DH Acceleration Data Interpretation

[Aaron Derbyshire]

Posted on October 26, 2017 at 14:01

I have been looking over the datasheet and AN3308 for the LIS3DH Accelerometer in the hope that I can find a clear and concise explanation of how to interpret and scale the data.

So far I have seen (VALUE)*(FS/2^BIT_RESOLUTION) which intuitively makes sense but doesn't correspond to the sensitivity scalers mentioned in the datasheet:

Low Power Mode:      { 2g = 16mg/digit, 4g = 32mg/digit, 8g = 64mg/digit, 16g = 192mg/digit }

Normal Power Mode: { 2g = 4mg/digit,   4g = 8mg/digit,   8g = 16mg/digit, 16g = 148mg/digit }

High Power Mode:     { 2g = 1mg/digit,   4g = 2mg/digit,   8g = 4mg/digit,   16g = 12mg/digit }

Additionally to this I have seen some people state that the FIFO buffer is only capable of 10 bit resolution, which again contradicts the contents of the datasheets.

In an attempt to better understand the process I have been working with AN3308 Table  8 Example of Acceleration Data. I worked on the +350mg and -350mg examples and they worked as expected:

-350mg = 0xEA2h -> invert -> 0x15Dh -> +1 -> 0x15Eh = {256 + 64 + 16 + 8 + 4 + 2} x -1 = -350 x 1mg = -350mg

350mg = 350 x 1mg = 350mg

However this approach falls apart when working with the +1g and -1g examples. Given the data is held left aligned in two's complement I would have thought the values should have been:

-1g = (-1) / 1mg = -1000 =  0xC18h     BUT it is given as 0xC00h which is -1024.

+1g =   1  / 1mg =  1000 = 0x4E8h      BUT it is given as 0x040h  which is 64.

To top it all off I have seen comments which suggest all that is needed is a shift of the register to correlate with the bit resolution and then simply multiply by the scaler, but surely in two's complement format this will result in all values becoming positive because the MSB has now lost its place?

Has anyone got any clear instructions on the process?

#lis3dh #data-scaling #lis3dh-data-format #data-intepretation

[Alexandre T]

Posted on October 26, 2017 at 14:52

The x value is given by this formula :

int16_t X;

X = OUT_X_H << 8 | OUT_X_L;

If you put a 2g scale, 2g will be 32767;

So if you want the value in g you do :

2*X/32767;

if your scale is 16g : 

16*X/32767;

[Miroslav BATEK]

Posted on October 26, 2017 at 14:57

1. The value which describes relation between raw data and acceleration in g is sensitivity. You can find the values in Table 4 for all full scales and modes.

The output value is left justified in the output 16 bit register, so you have to first shift the value right according to selected mode (8, 10, 12 bit).

2. The FIFO stores only 10 bits values see chapter 3.6 in datasheet

3. The conversion in the table 8 in AN3308 is correct, maybe the rounding 1.024 to 1g can be misleading. You made one mistake in the following line '

+1g =   1  / 1mg =  1000 = 0x4E8h      BUT it is given as 0x040h  which is 64.'

The value in the table is 0x4000. The output is 12 bit (high-resolution) so you can shift it by 4 bits (or divide by 16) and you will get 0x400 which is 1024.

4. The conversion can be done very simply in C using for example following code:

int16_t result_lsb;

result_lsb = ((int16_t)high_byte<<8)+(uint16_t)low_byte;

result_lsb = result>>4; // in case of high resolution mode = 12bit output

result_mg = result_lsb * sensitivity; // LSB to mg, see sensitivity in datasheet

[Aaron Derbyshire]

Posted on October 26, 2017 at 15:40

Thank you for your reply Miroslav.

1. Good this aligns with what my understanding of what the process was!

2. Okay I was unaware of this, it didn't seem to correlate when I looked into the sections mentioned by previous posts.

3. If that is the case then I am not sure I understand. When we interpret the values for the ±350mg the values are given as:

+350mg: 0x15E0h and for the 12 bit resolution we can drop the read 0x0h to obtain 0x15Eh.

-350mg:  0xEA20h and again we can mitigate the LSB to give 0xEA2h

So why does 0x0400h become 0x4000h?

Thank you for clarifying that the data has also been rounded to obtain ±1g, this may be worth noting in the documentation.

Thank you for your time and comments.

[Miroslav BATEK]

Posted on October 26, 2017 at 15:51

Oh, I see, it seems you have old version of the application note with the error.

Please download the latest version of

http://www.st.com/content/ccc/resource/technical/document/application_note/77/ed/e7/e1/28/5a/45/d6/CD00290365.pdf/files/CD00290365.pdf/jcr:content/translations/en.CD00290365.pdf

where the table has been fixed.

[Aaron Derbyshire]

Posted on October 26, 2017 at 15:54

That about wraps it up then!

Thank you very much for your help!