LIS3DH scale factor? 1g = 16600. Not 1mg/digit!

[sima2]

Posted on September 29, 2014 at 09:33

I'm testing a LIS3DH and set the FS bit to 00 (+/-2g measurement range).

I get about 16600 at 1g. The datasheet says 1mg/digit. Then I found in another application note (AN3182) that the sensor uses 12 bits left justified values. This could explain why I get this result.Could anybody explain this?What value should I get if I activate the self test? The datasheet says 276 for Ax. So this should be 276x16 = 4416?I think the datasheet should need some rework to make things more clear.

[Richard Hartman]

Posted on April 18, 2017 at 08:07

I know this is an old thread, but just in case someone else searches on it... I recently had to figure this out as well.

'Left justified' is the answer. For some reason, the 12 bit data is left justified in the (resulting) 16 bit field. This causes all values to appear multiplied by 16, as you observed. You can confirm this by capturing and examining lots of samples of output data... their four LSB's will all be zero.

The solution is to right shift the assembled 16 bit words by 4 bits. Then you will have data that matches the sensitivity specified in the spec sheet.

Hope this helps someone....

[BALAGANESH ARASIAH]

Posted on April 22, 2017 at 13:19

Hope this is help others...

First off all u have to check the o/p acceleration data size

It may be 10-bit, 12-bit or even 16-bit

Then u have to check for the accelerometer sensitivity

It may be given as 16384g/LSB or 15.6mg/digit and so on

Once we are ready with this data, we can readily proceed with the scaling and measurement

For example : 

Assume 10-bits of o/p data

Sensitity : 16mg/digit

So 10-bits has 1024 (2^10) scalable values in it

So it is 16 x 1024 = 16384

So u have to divide the o/p data by 16384 to get the actual 'g' acting on it

g = (o/p data on respective axis / 16384)

If u place the accelerometer at a flat surface, with top position pacing upward, u can see the z-axis alone will experience 1g acceleration in it. so u will get nearly 16384 on z-axis data. Rotating and placing corresponding axes towards the ground will make that particular axis measure 1g acceleraton

[Richard Hartman]

Posted on April 24, 2017 at 18:11

The problem that the original poster was experiencing was due to the left-justified nature of the LIS3DH output data. Strictly speaking It's not because the accelerometer is 'multiplying' the data by an extra 16... it's because the (in this case 12 bit) data is left justified in a 16 bit field. Bit shifting solves this with minimum CPU cycles. (It would have been nicer if ST had simply right justified the data, but we're stuck with their decision.)

[BALAGANESH ARASIAH]

Posted on April 25, 2017 at 12:07

@ Ritchard Hartman :

Anyhow the signed data is 12-bit. So it can attain a maximum value of (+/-)2^11.

But the actual static acceleration cant go to that limit.

It will be restricted to +/- 16g

Hence the sensitivity has to be considered as far I know

Your valuable comment is expected.....

[Richard Hartman]

Posted on April 25, 2017 at 17:55

There are several variables in play here. Sensitivity (as you correctly noted), but also justification, and bit width (i.e. resolution mode), ALL must be considered to interpret the data correctly.

The left justification is very confusing and misleading.When you are sitting still on the table, presumably under 1G acceleration on the Z axis, and you're getting a reading of ~16,000... what's happening? Are you in the wrong mode? Is your resolution incorrect? Is your sensitivity wrong? It's easy to see how this can be confusing for folks just getting started with the part.

There's only one reason that I can think of for using left justification, and that's if you want to put the device in a higher resolution mode but then only use the 8 MSB's to artificially reduce your dynamic range to 48dB. *EVERY* other usage case makes left justification a PITA to handle, requiring special coding and wasting extra CPU cycles to manipulate each reading to a useful format (right justified) that can then be used mathematically. And then you get to do that three times, once for each axis.

Reformatting left justified data to normal, rational right justification requires at least two shift operations and at least one bitwise operation. Times three for X, Y, and Z. That's a lot of wasted CPU time, when instead the chip could have just emitted the data right justified. And it's confusing to folks not familiar with the part, as this thread illustrates.

Hopefully others new to the part will search and find this thread, and save themselves a lot of confusion and time.

[BALAGANESH ARASIAH]

Posted on April 25, 2017 at 18:09

Yeah................... :)

Moreover, I personally suggest the datasheets (specially for accelerometers) needs improvisation.

It took 3-4 days for me to start guessing things and reach a state of confirmation

The datasheets are more of hints rather than precise explanation.

Let us expect STM to release a revised version

[Anusuya Nallathambi]

Posted on May 11, 2017 at 03:26

Thank you very much for the answer. However I would like to confirm something. According to the app note the ouptut is 10 bits left alighned and the sensitivity So is 4mg/bit at +/-2g scale. Going by that the above calculation will yeild a scale factor of 4096(4x1024) which should be the 1g value. Am I right in this assumption ? I am confused because the LIS3DH sensor I have is outputing around 16500 when the axis is pointed towards ground i.e 1g force. I have set the mode as Normal mode (10 bit output) and 1.344kHz data rate. I expected the sensor to output 4000 at 1g. Please help.

[Miroslav BATEK]

Posted on May 23, 2018 at 21:22

As the value is left adjusted in the 16 bit register you have to divide the value by 16 (in case of 10 bit resolution) and then multiply by the sensitivity.