Testing accelerometer settings in controlled environment (LIS2DW12)

[CF3nXftw]

Hi,

 

do you have any suggestion of a mechanical test bench setup to verify (/evaluate) the chosen accelerometer parameters?

 

I'm working with an LIS2DW12, but I expect my question applies to all accelerometers:

1. I have configured the accelerometer to send me an interrupt as a certain threshold condition is fulfilled (INT1_WU enabled).
2. I use my device in a situation in which, in my opinion, the threshold condition is fulfilled. Nonetheless, the accelerometer does not wake up. Note, the accelerometer can wake up, but only in the event of a stronger acceleration. In other words there is no electrical/mechanical problem with the device itself.
3. Therefore, I see several possible culprits
   
   1. either the acceleration in the real world situation is below my threshold (in which case I would have to lower the threshold(*)); and/or
   2. the above-threshold value happens too shortly, so that the accelerometer didn't have time to react (a higher ODR might work(*)?); and/or
   3. the housing(s) in which I've tested the module dampen(s) the acceleration; and/or
   4. I'm generally using the wrong settings due to a misunderstanding of the documentation somewhere.

 

(*) both sensitivity and ODR are already at the maximum value (at least maximum acceptable from system aspects).

==> Now I'm looking for a way to figure out where the problem is. How do other people find their settings? I'm thinking of setting up a mechanical bench which allows me to test the dynamical behavior. Is there an application note which suggests such a setup?

 

Thank you to everyone reading and commenting, best regards,

 

[Andrew Neil]

---

@CF3nXftw wrote:

I use my device in a situation in which, in my opinion, the threshold condition is fulfilled. Nonetheless, the accelerometer does not wake up.

---

So forget about the wakeup stuff - just capture what readings your accelerometer is actually giving in that situation.

See if that corresponds to your expectations ...

[CF3nXftw]

Hi Andrew,

 

that's a valid point. Unfortunately, due to space and other accessibility constraints I cannot attach a full-fledged data logger.

 

Let me phrase my question in another way: how do other people find the right balance between "false positives" and "false negatives"?

 

I intend to use the accelerometer for condition monitoring. It's supposed to give me a signal when a certain condition is met. In the real world application, said condition is not present all the time, but over a certain amount of time it certainly should have occurred.

If I log all the measurements, I only learn that the accelerometer didn't see the condition. This can be due to

1. the condition was not present and the accelerometer rightfully didn't trigger. ==> If I were to increase the sensitivity, then I would run into wrong positives.
2. the condition was present but the accelerometer didn't sense it (e.g. because of a mismatch in sensitivity, or because the event was too short, etc) ==> false negative

 

What I'm interested in, is building a mock-up which allows me to control the acceleration (including change in acceleration). Does anyone have an idea on how to realize such a mock-up?

[Andrew Neil]

---

@CF3nXftw wrote:

I cannot attach a full-fledged data logger.

---

You don't need a "full-fledged" data logger: just a single UART Tx line (plus ground) should be sufficient - then just capture the data in a terminal.

Added:

Or do you have a wireless link available?

Or could you log to RAM, and extract later?

 

---

@CF3nXftw wrote:

If I log all the measurements, I only learn that the accelerometer didn't see the condition. 

---

That's not true.

If you log the raw data, you can see exactly what the accelerometer saw - then you use that to determine your thresholds, etc.

Condition Monitoring really depends on having a good body of data - at least representative of "good" conditions; preferably also examples of known "bad" conditions.

For a mock-up, you'd need to understand the nature of the kinds of fault conditions that could occur in your system, and then think of ways to simulate those.

EDIT

Simple example here: https://www.youtube.com/watch?v=SZEz8AbcnZc

1. They train it on a fan running "normally"
2. They simulate a blockage
3. They obstruct the blades

You could do other things; eg, attach a weight to a vane to give out-of-balance ...