LIS3DH | Switching interrupt type during readout leads to unlikely values

[SSpuh.1]

Hello

I am using the LIS3DH to detect an impact on a vehicle. Our layout does contain only one interrupt pin, so I have to switch during the event.

Init:

• Clear all registers
• CTRL_REG1 (400Hz, XYZ enabled)= CTRL_REG1_ODR2 | CTRL_REG1_ODR1 | CTRL_REG1_ODR0 | CTRL_REG1_XEN | CTRL_REG1_XEN | CTRL_REG1_XEN
• CTRL_REG2 (HP filter for interrupt and output buffer = CTRL_REG2_FDS | CTRL_REG2_HP_IA1
• CTRL_REG3 (interrupt IA1) = CTRL_REG3_I1_IA1
• CTRL_REG4 (+-8G) = CTRL_REG4_FS1
• INT1_THS (504mg) = 0x08
• INT1_CFG (enable xyz interrupts) = INT1_CFG_YHIE | INT1_CFG_XHIE | INT1_CFG_ZHIE
• CTRL_REG5 (enable FIFO) = CTRL_REG5_FIFO_EN
• FIFO_CTRL_REG (watermark 16, stream-to-fifo )= 16 | FIFO_CTRL_REG_FM1 | FIFO_CTRL_REG_FM0
• read REFERENCE_ADDRESS

I build a pendulum to have a predictable signal. This seems to work well as I do get an interrupt:

1. Interrupt received, read last 32 Samples in FIFO
2. Change interrupt to watermark
3. read 14 times 16 samples when watermark interrupt occurs
4. Change interrupt to threshold

This seems to work quite good, as I get the amount of data I am looking for.

But the data I do receive is not looking as I expect, there is nothing that looks like a pendulum and it does have spikes in it.

Can somebody tell my where I do have an error in my procedure?

Kind regards

[Eleon BORLINI]

Hi @SSpuh.1​ ,

during the procedure of the two switching interrupts, are you resetting and setting alternatively each of the two interrupts?

Did you try to read data in polling/continuous mode (without going through the FIFO), to check if they are consistent in this operating mode? I'm wondering if you are maybe concatenating non-consecutive samples from different consecutive FIFO readings

-Eleon

[SSpuh.1]

Dear Eleon

I am very sorry for my late answer. Was quite a busy time.

No I am not setting them manually. I thought (as they are not lached) they will reset each other themselves.

Yes, I did test without the fifo and it seems to be right then.

Would it be an option to let the device run in stream mode instead of stream-to-fifo, wait for an interrupt when an axis exceeds the threshold and switch then the interrupt to watermark (or overflow)? When I read faster as the positions are sampled I should be able to read correct values without switching to fifo mode.

[Eleon BORLINI]

Hi @SSpuh.1​ ,

>> Would it be an option to let the device run in stream mode instead of stream-to-fifo, wait for an interrupt when an axis exceeds the threshold and switch then the interrupt to watermark (or overflow)? When I read faster as the positions are sampled I should be able to read correct values without switching to fifo mode.

Yes, it could be a valid option. Did you have the time to test it?

-Eleon