This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

LIS2DH INT1 Triggers on nRF9160

Has anyone had success getting triggers on motion to work with the LIS2DH? I only have INT1 wired so I modified the drivers to work on INT1 as the spec document says it should. I've added the appropriate registers: to list2dh.h:

#define LIS2DH_REG_INT1_SRC     0x31
#define LIS2DH_REG_INT1_THS     0x32
#define LIS2DH_REG_INT1_DUR     0x33
References in lis2dh_trigger_set() and lis2dh_acc_slope_config() were modified for INT1. Am I missing something?
Has anyone else been able to get this to work?
Parents Reply
  • NautDesigner said:
    It does trigger for SENSOR_TRIG_DATA_READY and that works fine. Trying to get it to trigger on movement.

     Have you configured INT1 to movement recognition? As LIS2DH datasheet, page 39, states:
    "AOI-6D = ‘01’ is movement recognition. An interrupt is generate when orientation move from unknown zone to known zone. The interrupt signal stay for a duration ODR."

    From sensor.h, SENSOR_TRIG_DATA_READY states:
    /** Trigger fires whenever new data is ready. */

    What happens when you read data from device?
Children
  • What I am finding is that if I just setup the trigger, nothing happens. However, if I call fetch_and_display(sensor) before going into a wait loop, the trigger does fire. But then it never stops firing.

     This is the output:

    Sampling at 10 Hz
    [00:00:00.024,780] [0m<inf> lis2dh: slope_config
    [00:00:00.030,334] [0m<inf> lis2dh: int1_ths=0x49 range_g=16 ums2=89999999
    [00:00:00.038,146] [0m<inf> lis2dh: slope_config
    [00:00:00.043,182] [0m<inf> lis2dh: int1_dur=0x4
    [00:00:00.048,614] [0m<inf> lis2dh: trigger_set
    [00:00:00.053,558] [0m<inf> lis2dh: trigger_anym_set
    [00:00:00.058,959] [0m<inf> lis2dh: setup_int1
    [00:00:00.064,697] [0m<inf> lis2dh: start_trigger_int1
    [00:00:00.070,281] [0m<inf> lis2dh: setup_int1
    Waiting for triggers
    #1 @ 78 ms: , x 3.22 , y 99.29 , z 64.36, g 108.6
    MOTION - #2 @ 117 ms: , x 0.00 , y 8.27 , z 5.06, g 0.1
    MOTION - #3 @ 215 ms: , x 0.00 , y 8.27 , z 5.06, g 0.1
    MOTION - #4 @ 312 ms: , x -0.46 , y 7.35 , z 5.52, g 0.6
    MOTION - #5 @ 409 ms: , x 0.00 , y 8.27 , z 5.06, g 0.1
    MOTION - #6 @ 507 ms: , x -0.46 , y 7.81 , z 5.06, g 0.5
    MOTION - #7 @ 604 ms: , x 0.46 , y 7.35 , z 5.52, g 0.6
    MOTION - #8 @ 701 ms: , x 0.00 , y 7.35 , z 5.52, g 0.6
    MOTION - #9 @ 799 ms: , x 0.00 , y 7.81 , z 4.60, g 0.7
    MOTION - #10 @ 896 ms: , x -0.46 , y 8.27 , z 5.52, g 0.2
    MOTION - #11 @ 993 ms: , x 0.00 , y 7.81 , z 5.52, g 0.2

    I do have the movement specified: 

    #define LIS2DH_ANYM_CFG (LIS2DH_INT_CFG_ZHIE_ZUPE | LIS2DH_INT_CFG_YHIE_YUPE |\
                 LIS2DH_INT_CFG_XHIE_XUPE | LIS2DH_AOI_CFG)
    Code is:
    struct sensor_value gScale;
    sensor_g_to_ms2(16, &gScale);
    rc = sensor_attr_set(sensor,SENSOR_CHAN_ACCEL_XYZ,
    SENSOR_ATTR_FULL_SCALE,
    &gScale);
    if (rc != 0) {
    printk("Failed to set g-scale: %d\n", rc);
    return;
    }
    struct sensor_value threshold = {
    .val1 = 90,
    .val2 = 0,
    };
    rc = sensor_attr_set(sensor,SENSOR_CHAN_ACCEL_XYZ,
    SENSOR_ATTR_SLOPE_TH,
    &threshold);
    if (rc != 0) {
    printk("Failed to set threshold: %d\n", rc);
    return;
    }
    struct sensor_value duration = {
    .val1 = 4,
    .val2 = 0,
    };
    rc = sensor_attr_set(sensor,SENSOR_CHAN_ACCEL_XYZ,
    SENSOR_ATTR_SLOPE_DUR,
    &duration);
    if (rc != 0) {
    printk("Failed to set duration: %d\n", rc);
    return;
    }
    trig.type = SENSOR_TRIG_DELTA;
    trig.chan = SENSOR_CHAN_ACCEL_XYZ;
    //trig.chan = SENSOR_CHAN_ALL;
    rc = sensor_trigger_set(sensor, &trig, trigger_handler);
    if (rc != 0) {
    printk("Failed to set trigger: %d\n", rc);
    return;
    }

    printk("Waiting for triggers\n");
    fetch_and_display(sensor);
    while (true) {
    k_sleep(K_MSEC(2000));
    }
  • Yes, I have. I'm modifying the drivers and using the sample. I'll ask over at Zephyr. Thanks.

  • FYI opened a bug about this: https://github.com/zephyrproject-rtos/zephyr/issues/34794

    I think previously if INT2 was not defined, it would fail gracefully. Something in the device tree API has changed which causes Zephyr to fault.

Related