LIS2DH12 value of temperature?

[Chupacabras]

I'm using sensor LIS2DH12, acceleration data I get looks OK. But I'm bit confused about temperature data.

CTRL_REG4.BDU is set to 1

CTRL_REG4.FS is set to 0 (= 2g scale)

CTRL_REG1.LPEN is set to 0

CTRL_REG4.HR is set to 0 (= 10bit normal mode)

CTRL_REG1.ODR is set 0x04 (50Hz)

TEMP_CFG_REG.TEMP_EN is set to 1 (enable temperature sensor)

I left measuring for 10 minutes, once every second, and I get these values (99% of time):

OUT_TEMP_H = 0b01111011 (7Bh = 123)

OUT_TEMP_L = 0

rarely I get value like 6Fh, 7Fh, 73h, 77h, 79h, 6Bh (I take those as some fluctuations).

Ambient temperature is around 23C.

How to interpret those values? They look too high to me.

UPDATE:

In normal mode (10bit) I get:

OUT_TEMP_H = 0b01111011 (7Bh = 123)

OUT_TEMP_L = 0

In low-power mode (8bit) I get:

OUT_TEMP_H = 0b01101111 (6Fh = 111)

OUT_TEMP_L = 0

This doesn't seem right.

[Ozone]

The datasheet only specifies a rate (1 digit per °C at 8 bit), but no fixed relation.

I understand this as the customer's responsibility to calibrate it.

Have you tried to vary the ambient temperature, and do the sensor values follow ?

[Chupacabras]

I'm not writing about calibration.

How to interpret those values? Because they seem to be too high.

OUT_TEMP_H contains two's complement value. So it can go from -128 to +127.

At room temperature I'm getting values like +123.

[Ozone]

> OUT_TEMP_H contains two's complement value. So it can go from -128 to +127.

You set it to 10 bit, didn't you ?

> CTRL_REG4.HR is set to 0 (= 10bit normal mode)

[Eleon BORLINI]

Hi @Chupacabras​ ,

on top of Ozone's suggestions, please consider the following formula for the LSB to physical units temperature conversion for LIS2DH12  (source Github lis2dh12:(

• Normal mode

float_t lis2dh12_from_lsb_nm_to_celsius(int16_t lsb)
{
  return ( ( (float_t)lsb / 64.0f ) / 4.0f ) + 25.0f;
}

• Low power mode:

float_t lis2dh12_from_lsb_lp_to_celsius(int16_t lsb)
{
  return ( ( (float_t)lsb / 256.0f ) * 1.0f ) + 25.0f;
}

Decoding your value, it looks like you have actually 123 (+25°C) degrees... since the temperature you want to measure is less than 25°C, you should have a negative value, i.e. a MSB value starting with "1" bit. Is the bit endianess of your temperature data correct?

-Eleon

[Chupacabras]

I assume endianess is correct, because readings of acceleration data is correct. Data from temperature sensor is handled the same way.

I actually use exactly that driver from github. And exactly that function you mentioned (lis2dh12_from_lsb_nm_to_celsius).

When

OUT_TEMP_H = 0b01111011 (7Bh = 123)

OUT_TEMP_L = 0

then

lsb value that goes to that function is  0b0111101100000000

so lis2dh12_from_lsb_nm_to_celsius returns 148.0

1. that looks very wrong
2. ambient temperature is 25C, and this value is already right on the upper edge. Imagine ambient temperature rises to 40C. The value would be off scale...

[Chupacabras]

OUT_TEMP_H contains higher bits

OUT_TEMP_L contains lower bits

so most important is value in OUT_TEMP_H no matter what resolution is used.

My point is that OUT_TEMP_H is very high at room temperature (25C), so I do not know how to interpret it.

Its value is +123.

Imagine ambient temperature rises to 40C, the value would be off scale already...

[Ozone]

> on top of Ozone's suggestions, please consider the following formula for the LSB to physical units temperature conversion for LIS2DH12 (source Github lis2dh12:(

I have seen no such relation (formula) described in the datasheet. Would probably be useful to update it, even if the temperature sensor is just a secondary function.

[Ozone]

> ambient temperature is 25C, and this value is already right on the upper edge. Imagine ambient temperature rises to 40C. The value would be off scale...

I would do that. I mean, measure at two other points. Say, 40°C and 0°C.

The presented output looks strange, so much is true.

I have always used the LIS2DH12 as accelerometer only.

[Chupacabras]

I agree, this should be described in datasheet. Absolutely yes.

To defend @Eleon BORLINI​ , he provided link to github sources, which seems to be maintained by ST.

I already contacted official ST support to ask about this problem. Waiting for response.