LIS2DUX - Step Counter Undercounting and Stopping and Tap Detection not Registering

[voloved]

Hello,

I am working on adding a pedometer to the Sensorwatch project using this chip.

I added the logic found in this codebase to my repository and it's working fairly-well execpt for 2 issues:

• Tap detection isn't working
• The step counter is extremely insensitive and after about an hour, I stop seeing the step counter update at all.

Tap detection isn't working

The project currently has an LIS2DW chip, which allows for tap control. I'm trying to remake that logic with the LIS2DUX.

Here is the logic I used to set up tap control.
It's based off this section of the repo.

I was able to confirm that X,Y, and Z readings are updating correctly, and the interrupt does trigger on six_d events when I enable it, which leads me to believe that it must be the tap control parameters that I am setting up incorrectly.

Are there parameters that are recommended to prove that tap detection works?
Are there any other suggestions on why I don't see tap events?

The step counter is extremely insensitive and after about an hour, I stop seeing the step counter update at all.

The main reason I want the LIS2DUX is for the step counting feature. I ported the stm32duino code, and it works, but not well. It under-counts steps and I often see that I run for 100+ steps with nothing being read.
I often find that if I keep the pedometer running for a while, it just stops, and the only way to get it working again is to reset/cycle power to my board, as if the LIS2DUX just stops communicating after enough time passes.
I see in the datasheet that there is debounce and time delta settings that I can change, which may be able to help with the undercounting, but I don't know if it'll also address the chip just stopping communication over time. Since the base library doesn't mess with those settings, I'm hesitant on rabbit-holing too far without some guidance.

Are there parameters that are recommended to stop the LIS2DUX from stopping communication? Is that even what I'm seeing?
How do I make the step counter more sensative so it doesn't miss 100+ steps while running?
Are there any other suggestions on why I don't see tap events?

Enabling of the step counter in my code
The step Counter enable function itself
Based off this code from ST

[fpistm]

Hi @voloved
Probably @cparata could help on this.

[voloved]

Thank you.
I'm also not seeing lis2duxs12_stpcnt_period_set behave correctly.
Here's a snippet of my code and its output.

Snippet:

    static uint16_t period.
    uint16_t period_read;
    lis2duxs12_stpcnt_period_set(&ctx, period);
    period++;
    lis2duxs12_stpcnt_period_get(&ctx, &period_read);
    printf("period -  I sent:%x - And I got back: %x\r\n", period, period_read);

Output

period -  I sent:3 - And I got back: 202
period -  I sent:4 - And I got back: 303
period -  I sent:5 - And I got back: 404
period -  I sent:6 - And I got back: 505
period -  I sent:7 - And I got back: 606
period -  I sent:8 - And I got back: 707
period -  I sent:9 - And I got back: 808
period -  I sent:a - And I got back: 909
period -  I sent:b - And I got back: a0a
period -  I sent:c - And I got back: b0b
period -  I sent:d - And I got back: c0c
period -  I sent:e - And I got back: d0d

When I wrote the debounce step from 10 to 2, reading it back does give me 2, so I'm unsure how one works but not the other.

[cparata]

Hello @voloved ,
from the design of the board that you are using, it seems to me that the component on board is the LIS2DW12 and not the LIS2DUXS12. So, the correct library that you should use is this one. Unfortunately the tap feature is not implemented for this library, and the pedometer feature actually is not available for this part number. For sure you cannot use the ones available on LIS2DUXS12 library because the registers mapping on the two components is different. Regarding the tap feature you can give a look at the Application Note at the chapter 5.6. Any contribution to improve the library is welcome. So, if you want to add the APIs to support the tap feature, it would be great.
Best Regards,
Carlo

[voloved]

Hello @cparata ,

My board now has the LIS2DUX chip.
The original design used the LIS2DW, and I have replaced the part with an LIS2DUX.

I am getting correct WHO_IS, steps, accelerometer readings, etc with the LIS2DUX library, so I know it is installed correctly.

Would you be able to revisit my questions with knowing that the LIS2DUX is the part that I am using?

My apologies if I provided confusion on that.

[cparata]

Hi @voloved ,
sorry I misunderstood this point. I tried the tap example and the pedometer example provided with LIS2DUXS12 library and they seem working fine with my hardware setup (NUCLEO-F401RE + X-NUCLEO-IKS4A1). So, in my opinion, one possible reason why tap feature is not working combined with pedometer on your side is due to the different Output Data Rate required by the two algorithms (400 Hz for tap and 25 Hz for pedometer). Did you try to use only tap feature (without activating pedometer)? In order to use both features together, it is important to enable before the pedometer and then the tap, so the final Output Data Rate will be 400 Hz.
Regarding the behavior of the pedometer, I suggest to read the Appplication Note of the LIS2DUXS12 at chapter 6.1. Basically the pedometer algorithm starts to generate the step interrupt after 10 consecutive steps (to avoid false positive) and after an inactivity phase, it restarts to count the steps in the same way; so, basically, you lose 10 steps in any step counting cycle; you can avoid this drawback, setting the debounce to 0; unfortunately we did not implement this API in the current version of the library even if it should not be difficult to do; meantime, as workaround, you can try calling "lis2duxs12_stpcnt_debounce_set(&reg_ctx, 0);" in the "Enable_Pedometer" function implementation before the call to "lis2duxs12_stpcnt_mode_set".
Let me know if it improves the performance.
Best Regards,
Carlo

[voloved]

Thanks for the advice!

Tap Control

I did notice the ODR needed to by high-power 400 and disabled running the step counter during my original testing. I read back the ODR and confirmed it was set to 400.
Assuming that everything I did was correct aside from the thresholds, what are the most sensitive thresholds I can set? Even if it's false-triggers, I just want to see if I can get any response and tune from there. I read through the documentation on the parameters, but I am not experienced enough to know how to set them to their most-sensitive. Especially since it seems that some parameters are dependent on others or may lead to never triggering a tap being complete.

Here are my parameters:

        LIS2DUXS12Sensor_Enable_X(&ctx);
        LIS2DUXS12Sensor_Set_X_ODR_With_Mode(&ctx, 400, LIS2DUXS12_HIGH_PERFORMANCE);
        LIS2DUXS12Sensor_Set_X_FS(&ctx, 2);

        lis2duxs12_tap_config_t tap_cfg;
        lis2duxs12_tap_config_get(&ctx, &tap_cfg);

        // Parameters in Enable_Double_Tap_Detection in https://github.com/stm32duino/LIS2DUXS12
        tap_cfg.axis = LIS2DUXS12_TAP_ON_Z;
        tap_cfg.inverted_peak_time = 4;
        tap_cfg.pre_still_ths = 2;
        tap_cfg.post_still_time = 8;
        tap_cfg.shock_wait_time = 6;
        tap_cfg.post_still_ths = 8;
        tap_cfg.latency = 4;
        tap_cfg.wait_end_latency = 1;
        tap_cfg.peak_ths = 8;
        tap_cfg.single_tap_on = PROPERTY_ENABLE;
        tap_cfg.double_tap_on = PROPERTY_ENABLE;
        tap_cfg.pre_still_n = 10;

        lis2duxs12_tap_config_set(&ctx, tap_cfg);

        lis2duxs12_pin_int_route_t val;
        lis2duxs12_pin_int1_route_get(&ctx, &val);
        val.tap = PROPERTY_ENABLE;
        val.six_d = PROPERTY_ENABLE;
        lis2duxs12_pin_int1_route_set(&ctx, &val);

Step Counter

I changed the debounce to 1 step from 10 yesterday after rereading the datasheet's explanation of the debounce. I did not read see the application notes and I'll start reading through them.

    else if (movement_state.has_lis2dux) {
        LIS2DUXS12Sensor_Enable_X(&ctx);
        LIS2DUXS12Sensor_Enable_Pedometer(&ctx, LIS2DUXS12_INT1_PIN);
+        lis2duxs12_stpcnt_debounce_set(&ctx, 1);
        movement_state.counting_steps = true;
        return true;

It's set after lis2duxs12_stpcnt_mode_set, but I see it's set correctly when reading it back and I see it does trigger steps in under 10 steps.
It still under-reports. I walk 20 steps, and it reports back 3.
Do I have any other tuning knobs?

Also, would you happen to know if there are any known issues with setting lis2duxs12_stpcnt_period_set that I mentioned in my previous reply?

[cparata]

Hello @voloved ,
I tried on my side and I did not find any issue to combine pedometer and tap feature.
Could you try the following sketch:

#include <LIS2DUXS12Sensor.h>

#define INT1_pin A3

LIS2DUXS12Sensor LIS2DUXS12(&Wire);

//Interrupts.
volatile int mems_event = 0;
uint16_t step_count = 0;
uint32_t previous_tick;
char report[256];

void INT1Event_cb();


void setup() {

  // Initlialize serial.
  Serial.begin(115200);
  delay(1000);

  // Initlialize Led.
  pinMode(LED_BUILTIN, OUTPUT);

  // Initlialize i2c.
  Wire.begin();

  // Enable INT1 pin.
  attachInterrupt(INT1_pin, INT1Event_cb, RISING);
    
  // Initlialize components.
  LIS2DUXS12.begin();
  LIS2DUXS12.Enable_X();

  // Enable Pedometer.
  LIS2DUXS12.Enable_Pedometer(LIS2DUXS12_INT1_PIN);
  // Enable Single Tap Detection.
  LIS2DUXS12.Enable_Single_Tap_Detection(LIS2DUXS12_INT1_PIN);

  previous_tick = millis();
}

void loop() {
  if (mems_event)
  {
    mems_event = 0;
    LIS2DUXS12_Event_Status_t status;
    LIS2DUXS12.Get_X_Event_Status(&status);

    if (status.TapStatus)
    {

      // Led blinking.
      digitalWrite(LED_BUILTIN, HIGH);
      delay(100);
      digitalWrite(LED_BUILTIN, LOW);
      Serial.println("Single Tap Detected!");
    }

    if (status.StepStatus)
    {
      // Led blinking.
      digitalWrite(LED_BUILTIN, HIGH);
      delay(100);
      digitalWrite(LED_BUILTIN, LOW);

      LIS2DUXS12.Get_Step_Count(&step_count);
      snprintf(report, sizeof(report), "Step counter: %d", step_count);
      Serial.println(report);
    }
  }
  // Print the step counter in any case every 3000 ms
  uint32_t current_tick = millis();
  if((current_tick - previous_tick) >= 3000)
  {
    LIS2DUXS12.Get_Step_Count(&step_count);
    snprintf(report, sizeof(report), "Step counter: %d", step_count);
    Serial.println(report);
    previous_tick = millis();
  }

}

void INT1Event_cb()
{
  mems_event = 1;
}

Obviously, you need to adapt I2C instance and interrupt pin on your side, but in my case the sketch works as expected.
I also tried to restart the pedometer after an hour and I did not find any issue.
Best Regards,
Carlo

[voloved]

Thank you for the great support and detail.

I'll take some time tonight to give this a try. I see the difference in the code is that you're using Get_X_Event_Status while I'm using lis2duxs12_all_sources_get. They seem to do the same I2C requests; would you still recommend I try porting Get_X_Event_Status?

As for the counts not reading after an hour, I found that I had a background task that turns of the pedometer after a certain time. The issue was on my end 😅.

In the last hour, I tried these parameters after reading through the app notes:

        tap_cfg.axis = LIS2DUXS12_TAP_ON_Z;
        tap_cfg.inverted_peak_time = 0;
        tap_cfg.pre_still_ths = 0;
        tap_cfg.post_still_time = 0;
        tap_cfg.shock_wait_time = 2;
        tap_cfg.post_still_ths = 2;
        tap_cfg.latency = 0;
        tap_cfg.wait_end_latency = 1;
        tap_cfg.peak_ths = 3;
        tap_cfg.single_tap_on = PROPERTY_ENABLE;
        tap_cfg.double_tap_on = PROPERTY_ENABLE;
        tap_cfg.pre_still_n = 0;

Afterwards, I tapped the watch once a second. i got a few tap responses, but they were extremely sporadic and didn't match my taps. But at least it shows that I can read taps!

Here's the output of my console. I tap once a second, but only 2 of the seconds saw a tap:

Now: 8:09:03  9-30-2025  Steps: 0 
Now: 8:09:04  9-30-2025  Steps: 0 
Now: 8:09:05  9-30-2025  Steps: 0 
Now: 8:09:06  9-30-2025  Steps: 0 
cb_accelerometer_lis2dux_event
ODR:    400.000000
six_d:         1
six_d_zl:      1
cb_accelerometer_lis2dux_event
ODR:    400.000000
six_d:         1
six_d_zh:      1
cb_accelerometer_lis2dux_event
ODR:    400.000000
six_d:         1
six_d_zl:      1
cb_accelerometer_lis2dux_event
ODR:    400.000000
six_d:         1
six_d_zl:      1
cb_accelerometer_lis2dux_event
ODR:    400.000000
six_d:         1
six_d_zl:      1
cb_accelerometer_lis2dux_event
ODR:    400.000000
six_d:         1
six_d_zl:      1
cb_accelerometer_lis2dux_event
ODR:    400.000000
six_d:         1
six_d_zl:      1
Now: 8:09:07  9-30-2025  Steps: 0 
Now: 8:09:08  9-30-2025  Steps: 0 
Now: 8:09:09  9-30-2025  Steps: 0 
Now: 8:09:10  9-30-2025  Steps: 0 
Now: 8:09:11  9-30-2025  Steps: 0 
Now: 8:09:12  9-30-2025  Steps: 0 
cb_accelerometer_lis2dux_event
ODR:    400.000000
tap:           1
single_tap:    1
six_d_zl:      1
sleep_state:   1
Single tap!
Now: 8:09:13  9-30-2025  Steps: 0 
Now: 8:09:14  9-30-2025  Steps: 0 
Now: 8:09:15  9-30-2025  Steps: 0 
Now: 8:09:16  9-30-2025  Steps: 0 
Now: 8:09:17  9-30-2025  Steps: 0 
Now: 8:09:18  9-30-2025  Steps: 0 
Now: 8:09:19  9-30-2025  Steps: 0 
Now: 8:09:20  9-30-2025  Steps: 0 
Now: 8:09:21  9-30-2025  Steps: 0 
Now: 8:09:22  9-30-2025  Steps: 0 
cb_accelerometer_lis2dux_event
ODR:    400.000000
tap:           1
double_tap:    1
six_d_zl:      1
sleep_state:   1
Double tap!
Now: 8:09:23  9-30-2025  Steps: 0 
Now: 8:09:24  9-30-2025  Steps: 0 
Now: 8:09:25  9-30-2025  Steps: 0 
Now: 8:09:26  9-30-2025  Steps: 0 

Latched vs Pulsed

I saw that the chip allows for pulsed (90us on) or latched mode.
I thought that I may be missing pulsed triggers, so i tried latched mode.
I didn't see a change in reads, but I noticed what may be a bug.
On a latched trigger, I read the TAP_SRC` register, which should clear the latch per pg 35 of the app notes.
It normally does, but I've seen situations where the latch doesn't go low after reading and the ODR goes to zero.
Have you seen the latch not turn off after a read?
It may not be important for my application; I'll likely continue using pulsed, but I want to see if that may be expected.
The ODR being zero leads me to believe that it may be an issue on my end that turned the chip off somehow, but I've run out of time this morning to continue testing/root-causing.

My code:

void cb_accelerometer_lis2dux_event(void) {
        printf("pin level before read %d\r\n", HAL_GPIO_A3_read());
        lis2duxs12_all_sources_t int_src;
        lis2duxs12_all_sources_get(&ctx, &int_src);
        printf("pin level after read %d\r\n", HAL_GPIO_A3_read());
        float odr;
        LIS2DUXS12Sensor_Get_X_ODR(&ctx, &odr);
        printf("ODR:    %f\r\n", odr);
        if (int_src.tap)           printf("tap:           %d\r\n", int_src.tap);
        if (int_src.single_tap)    printf("single_tap:    %d\r\n", int_src.single_tap);
        if (int_src.double_tap)    printf("double_tap:    %d\r\n", int_src.double_tap);
        if (int_src.triple_tap)    printf("triple_tap:    %d\r\n", int_src.triple_tap);
        if (int_src.six_d)         printf("six_d:         %d\r\n", int_src.six_d);
        if (int_src.six_d_xl)      printf("six_d_xl:      %d\r\n", int_src.six_d_xl);
        if (int_src.six_d_xh)      printf("six_d_xh:      %d\r\n", int_src.six_d_xh);
        if (int_src.six_d_yl)      printf("six_d_yl:      %d\r\n", int_src.six_d_yl);
        if (int_src.six_d_yh)      printf("six_d_yh:      %d\r\n", int_src.six_d_yh);
        if (int_src.six_d_zl)      printf("six_d_zl:      %d\r\n", int_src.six_d_zl);
        if (int_src.six_d_zh)      printf("six_d_zh:      %d\r\n", int_src.six_d_zh);
        if (int_src.sleep_change)  printf("sleep_change:  %d\r\n", int_src.sleep_change);
        if (int_src.sleep_state)   printf("sleep_state:   %d\r\n", int_src.sleep_state);
        if (int_src.tilt)          printf("tilt:          %d\r\n", int_src.tilt);
        if (int_src.fifo_bdr)      printf("fifo_bdr:      %d\r\n", int_src.fifo_bdr);
        if (int_src.fifo_full)     printf("fifo_full:     %d\r\n", int_src.fifo_full);
        if (int_src.fifo_ovr)      printf("fifo_ovr:      %d\r\n", int_src.fifo_ovr);
        if (int_src.fifo_th)       printf("fifo_th:       %d\r\n", int_src.fifo_th);

Console Output:

still latched
pin level before read 1
pin after before read 1
ODR:    0.000000
tap:           1                                        
triple_tap:    1                                        
six_d:         1                                        
six_d_xh:      1                                        
six_d_yl:      1                                        
six_d_yh:      1
six_d_zh:      1

[cparata]

Hi @voloved ,
actually, the Arduino library is not thought to call directly the APIs of the lis2duxs12_reg.c/h files, but it's a C++ class that exports some high level APIs. If you prefer to use the low level APIs contained into the lis2duxs12_reg.c/h files, I suggest to use as reference directly the examples that you can find here.
In the C++ class that we implemented on the Arduino library, we only support the pulsed mode for the interrupt generation. So, no test has been done for latched mode.
The example that I provided before works perfectly if you use the APIs exported in the C++ class. If you start to mix the code (class APIs + reg files APIs), I cannot guarantee that the library works as expected.
Best Regards,
Carlo

[voloved]

Thanks for sharing that library. I have been rewriting C++ functions into C code as I needed them. I'll likely move over to it when I have the time since it allows for copying more functions over with no rewriting needed and has a more consistent style.

However, when I looked over that library in order to see if there were any differences in how the pedometer is set up (since pedometer accuracy is my first goal), I only saw that the C library did differently was that it reset the chip right after reading it. Which I wouldn't expect to affect sensitivity of the counter.

I have made a video of my step counter in action. It shows that it does count steps and that it's debounce is under 10. It's just not registering steps.

Should I expect the accuracy of my step counter that's seen in the video? I double checked to make sure my ODR and range are the same as both the Arduino and C code examples

https://youtu.be/8b5P_a8stHs?si=nMQ0quafXheJiI3k