How to get the acceleration sample corresponds to the exact time when the interrupt is triggered？

[Kefei Yao]

Posted on March 09, 2018 at 11:44

The LIS3DH is configured to use INT1 to interrupt the MCU when the acceleration value on any of the 3 axis exceed the threshold that is set by the MCU. Firstly, as my understanding, the LID3DH does not stop sampling acceleration data even if the interrupt is triggered (even in stream-to-fifo mode, it does not stop sampling until the fifo gets full). Is this correct? If it's correct, is there a good way to get the acceleration data corresponds to the exact time when the interrupt is triggered? Thanks.

[Miroslav BATEK · Accepted solution]

Posted on March 12, 2018 at 15:12

You understanding is correct and the stream-to-fifo mode is exactly the right mode for the purpose. 

FIFO content will be composed of #30 samples collected before the trigger event, the sample that has generated the interrupt event and one sample after the trigger.

Please check chapter 9.3.4 in the application note

http://www.st.com/content/ccc/resource/technical/document/application_note/77/ed/e7/e1/28/5a/45/d6/CD00290365.pdf/files/CD00290365.pdf/jcr:content/translations/en.CD00290365.pdf

.

[Kefei Yao]

Posted on March 13, 2018 at 08:40

Thanks for the reply. My understanding is a bit different. In AN3308, it describes following about the stream-to-fifo mode:

So as my understanding, if the case 2 happens, we are still not able to know where in the fifo the trigger data is. Right? 

So do I have to read back all the 32 data sample in the fifo and compare to the Threshold I set? The first sample in the fifo that exceed the threshold is the trigger data. 

[Miroslav BATEK]

Posted on March 15, 2018 at 16:43

You are right, in case 2 you want be sure which sample corresponds to the interrupt and you have to compare each sample with threshold. But this case can happen only when you start your measurement, after 32 samples the FIFO will be full and case 1 will happen.

[Kefei Yao]

Posted on March 16, 2018 at 07:59

Thanks for the reply. So case 2 just happens once in the initial state. Most cases it's case 1.

As AN3308 describes, when the fifo is full, it stop collecting data at first sample after the trigger, so the data that trigger the interrupt should be at F[30]. But when I read out the 32 data from lis3de when the MCU is interrupted (the fifo should be full at this time because I wait for enough time) and compare the data with the threshold, it turns out the trigger data is always at F[26]. Why? I'm using lis3de as the sensor.

[Miroslav BATEK]

Posted on March 16, 2018 at 10:30

What is your DURATION settings for the interrupt?

This could explain why the trigger was reached already at FIFO sample 26, but the interrupt was triggered after DURATION number of samples exceed the threshold.

[Kefei Yao]

Posted on March 16, 2018 at 11:42

My duration is 5. Now I completely understand. Thank you very much.

[Kefei Yao]

Posted on March 20, 2018 at 04:08

One more question: What if the duration setting is larger than 31? My assumption is the fifo will contain the last 31 samples of the trigger data and 1 samples of the sample after the trigger. Am I right?

[Miroslav BATEK]

Posted on March 20, 2018 at 09:53

Yes, you are right.

[Kefei Yao]

Posted on March 20, 2018 at 11:37

More question pops up. A typical use case for Stream-to-Fifo mode is to flush the fifo by setting it to bypass mode and set it back to Stream-to-Fifo mode. If we do not do this, the fifo will be kept full and can no longer store data. This operation will happen frequently during the measurements. If the trigger comes quick enough after the fifo is flushed, case 2 will happen. So case 2 is not that rare and we should not treat case 2 as a special case. Am I right?