Skip to main content
C
Collin Moore
Visitor II
December 6, 2019
Solved

LIS2DH false positives in detection of clicks

  • December 6, 2019
  • 2 replies
  • 1136 views

Hello all,

I am having an issue with single-click detection. I am getting false click detections at certain threshold values. I found this out yesterday when I had an MCU register lots of clicks repeatedly, but the device was not being shaken.

To test, I set up the LIS2DH as follows (using I2C):

  • Reset chip (write CTRL_REG5 with 0x80)
  • Read WHOAMI until it returns 0x33 to make sure it's up
  • Disable ODR and enable all 3 axes (write CTRL_REG1 with 0x07)
  • Write CTRL_REG2 with 0x00 (just to be sure)
  • Send Click to INT1 pin (write CTRL_REG3 with 0x80)
  • Set BDU so I can read values, +/-2g, normal mode (write CTRL_REG4 with 0x80)
  • Set up temperature (write TEMP_CFG_REG with 0xC0)
  • Run Self test (Sets ODR to max, sets SELF_TEST_0, sets back to normal, test passes)
  •  
  • Enable click interrupts on all 3 axes (write CLICK_CFG_REG with 0b010101)
  • write CTRL_REG5 to 0x0
  • Set ODR to 10Hz (write CTRL_REG1,4 accordingly)
  • Set click threshold to 80
  • Set click timeout to 127 (I leave it here always)

Now LIS2DH is set up at 10Hz ODR, with INT1 triggering on click and driving INT1 line high. Then I have a polling function that changes the CLICK_THS value every 5 seconds, and normal polling (more frequently) that watches for INT1 interrupts.

The 5-second poll increments CLICK_THS value up to 127, then sets it to 0 and sets ODR to disabled, then sets to 1 and ODR back to 10Hz, then increments CLICK_THS every 5 seconds from 1 to 127 again.

I have tested 4 devices so far (our manufactured devices with LIS2DH accel onboard. Each one detects false clicks at certain values of CLICK_THS:

  • one board at 3, 4,16,17, 59, 60
  • Second board at 2, 3, 10, 11, 65, 66
  • Third board at 1, 2, 11, 12, 65
  • Fourth board at 13, 33, 56

Has anyone seen anything like this before?

All these boards were tested sitting on my desk, with no actual bumping/clicking going on. Also, if there is an actual bump, they will detect it at all but the highest thresholds.

    This topic has been closed for replies.
    Best answer by Collin Moore

    Ok, I found the source of the clicks.

    It was not a problem in the accelerometer or code, it was just gravity!

    Between all the boards, the most common false-positive clicks happened between 61 and 69 (threshold counts).

    The accelerometer was set to +/-2g, and the threshold can go between 1 and 127. When set in the 60s, it is right around 1g (half-scale at +/-2g), and the sensor noise was triggering the click interrupt (it moves 2-3 counts when still, the way I have it set).

    I fixed the false positives by turning on HP filtering, which the LIS2DH supports, and my problem is solved!

    2 replies

    C
    Collin MooreAuthor
    Visitor II
    December 6, 2019

    My issue seems similar to this question:

    https://community.st.com/s/question/0D50X0000ArROIVSQ4/how-to-configure-iis2dh-for-use-of-click-detection-feature

    C
    Collin MooreAuthorAnswer
    Visitor II
    January 3, 2020

    Ok, I found the source of the clicks.

    It was not a problem in the accelerometer or code, it was just gravity!

    Between all the boards, the most common false-positive clicks happened between 61 and 69 (threshold counts).

    The accelerometer was set to +/-2g, and the threshold can go between 1 and 127. When set in the 60s, it is right around 1g (half-scale at +/-2g), and the sensor noise was triggering the click interrupt (it moves 2-3 counts when still, the way I have it set).

    I fixed the false positives by turning on HP filtering, which the LIS2DH supports, and my problem is solved!

    Terms & ConditionsAccessibility statement