Sparse LIS331 Datasheet(s)

[Jan Belohoubek]

Posted on July 12, 2018 at 08:16

Dear all - especially STM developers,

I recently integrated an LIS331HH sensor. It seams to be very nice sensor! But anyway while reading LIS331 Datasheet, I found that information required for proper MCU driver implementation (especially interrupt-related information) missing.

Even though some information become clear during repeated reading of Datasheet, something remains unclear. Even though I was able to find proper settings experimentally, it took some time...

Some points:

• The two's complement output (OUT_X_L, OUT_X_H, ...) range is not explicitely given (it is clear after repeated Datasheet reading, but implicitly hidden) - is it full range (16bit two's complement used? or there are limits? e.g. -4096 to 4096?) - I found, that full range is used for LIS331HH, but other family members are be different (I have no experience, but I saw code here:

  https://github.com/szotsaki/LIS331/blob/master/src/LIS331.cpp

   ) - missing explicite range declaration in Datasheet causes confusion
• meaning of threshold and other interrupt-related settings is foggy:
  • it is unclear how to set-up threshold value (INT1_THS/INT2_THS) - depends on range ...
  • for XLIE interrupt: 'value lower than preset threshold' is ambiguous (same for other interrupts): means 'abs(INT1_THS) > abs(accel)' or '- INT1_THS > accel', thus signaling 'crossing threshold back to defined range' or 'crossing threshold out of range'
• self-test function is described poorly (missing use-case?)

Please, could you clarify here or extend the datasheet?

Thank you!

Jan

[Miroslav BATEK]

The two's complement output (OUT_X_L, OUT_X_H, ...) - not all 16 bit is used, the LIS331HH has 12-bit output left-adjusted in 16-bit output register. The 4 right bits always 0.

[Jan Belohoubek]

Thank you for clarification!

That means: the range is -4095 to +4096; the result is stored as two's complement in 16-bit register as int16 -> right 4 bits are 0 for positive values and 1 for negative. Right?

This will be very helpful for correct implementation, but it lso supports my statement about lack of detail in LIS331 DS.