What is the MotionFD input data frequency tolerance? (is it possible to use data from LSM6DSO FIFO)

[CBigg.1]

Hi,

We are currently evaluating the possibility of using the LSM6DSO and LPS22HH with the MotionFD library, to detect when our product has been dropped from height (up to 9 meters).

One of our requirements is that the product always monitors for fall events even when the main MCU is off/standby. Seeing as we do not need a real time indication of a fall event (just keeping a log of events), we want to try and utilise the FIFO buffer on the accelerometer to collect data that can retrospectively be passed to the MotionFD algorithm for analysis.

According the the MotionFD user guide (https://www.st.com/resource/en/user_manual/dm00427990-getting-started-with-motionfd-realtime-fall-detection-library-in-xcubemems1-expansion-for-stm32cube-stmicroelectronics.pdf), the library requires "accelerometer and pressure sensor data sampling frequency is 25 Hz".

Upon review of the LSM6DSO datasheet, it was found that the closest batching data rate that can be used for the FIFO is 26 Hz. Will this mismatch be a problem for the fall detection algorithm?

Many thanks

Calum

[Miroslav BATEK · Accepted solution]

Mismatch between 25 and 26Hz is not a problem.

I don't know what is your use case but please be aware the MotionFD library is designed mainly for human fall.

You might consider using embedded free-fall functions which can generate interrupt and wake-up the ma MCU when free fall is detected.

[CBigg.1]

Good to hear, thought that was the case but wanted to be sure.

Our product is attached to the end of a pole to test equipment mounted on ceilings, and sometimes the human operator loses control.

We are assuming that due the fact the product is attached to a pole, the fall will be similar enough to a human fall just on a larger scale. Hence we are investigating the use of the MotionFD library.

The free fall interrupt is also something we are looking into, in particular as a way to trigger data being recorded into the FIFO buffer. So that a fall event is recorded regardless of if the MCU is on or not.

I know this is kind of creeping into another question but do you see a problem with this approach?

From reading material on human fall algorithms, I get the feeling that the MotionFD algorithm will be like the implementation described here https://www.analog.com/en/analog-dialogue/articles/detecting-falls-3-axis-digital-accelerometer.html

 

As can be seen in the graph copied from the article, the algorithm relies on data from before free fall is reached to confirm a fall has been detected.

Which would mean that our approach, of only recording from the start of free fall would be flawed. Since we are not providing enough data to the MotionFD library.

Could you confirm if this is the case please

[Miroslav BATEK]

I'm afraid that the MotionFD is not suitable for your needs. To properly detect the fall it requires to pass several conditions (initial state - with vertical orientation, free fall, impact, change of height, motionless - with horizontal orientation). MotionFD uses also pressure sensor to detect change of height.

I guess in your case you can wake-up the MCU by the detected free fall and then monitor the acceleration and detect possible impact (high acceleration then certain threshold).