mma8453q - inconsistent transient interrupt

[r_sama]

Hello all,

I've created a 'drop test' apparatus which will drop the chip from a consistent height that I set.

I then drop the unit with the chip on it, and change the transient threshold by small decrements until it triggers.

However, I'm seeing a lot of inconsistency in whether the interrupt triggers or not - I don't think this has to do with the ODR, as I'm not seeing much change between 100hz and 800hz in respect of consistency.

Is there anything that I might be doing wrong in relation to this? I give the transient shock threshold as a mg value/64 (for number of steps).

Problem I'm seeing:

if I set it at around (for example) 7000mg , then work my way down until it triggers, I then repeatedly drop it at this height to ensure that it's being consistent... and it is. Let's say this value is 5000mg for simplicity's sake.

I then develop some other code, rebuild, and perform the drop test again.

Expected behaviour - it should trigger first time.

Actual behaviour - the trigger threshold has moved, and I need to find it again.

What could be causing this behaviour? Is it a calibration issue?

I know these aren't high precision sensors, but surely there should be some degree of consistency here?

Please help... really stumped and not sure if it's something I haven't done correctly, or the sensor... :smileysad:

[david_diaz]

Hello Rich,

I assume your problem is related with the Debounce counter.

The MMA845x contains an embedded transient function which analyzes the high-pass filtered data allowing the user to set a preset threshold with an added debounce counter to ensure the event happens for a set duration. Please review the figure below:

In this case, the EA bit from the FF_MT_SRC register, indicates a motion event after debouncing. Once the debounce counter reaches the threshold, the EA bit is set, and remains set until the FF_MT_SRC register is read. When the FF_MT_SRC register is read, all register bits are cleared and the debounce counter are cleared and a new event can only be generated after the delay specified by FF_MT_CNT.

Please note that the time step used for the debounce sample count depends on the ODR chosen.

I recommend setting a fixed ODR and then, set the debounce counter to eliminate false readings.

Example:

Set the debounce counter to eliminate false readings for 100 Hz sample rate with a requirement of 100 ms timer.

Note: 100 ms/10 ms (steps) = 10 counts

IIC_RegWrite(0x18, 0x0A);

I hope this information will be useful for you.

If I misunderstood your question, feel free to let me know.  I will be glad to help.

Have a great day.

David Diaz.

Note: If this post answers your question, please click the Mark Correct  button. Thank you!

[r_sama]

Hi David,

Thank you for your very detailed reply - I had begun to think the same thing... this definitely makes sense, and would certainly go some way to explaining the results I'm getting...

I've read up on debounce on Google, but am having a slightly difficult time understanding it in the context of this sensor (other resources talk about switches, for example...)

To my understanding, debounce counter means that an event (in this case, the movement/impact/shake that triggers the transient interrupt) must happen for a specified period of time (say 100ms) before the chip picks this up as a true event, rather than noise. Would I be correct in this assumption?

If I am, is there any information relating to this in terms of timings, and the physics behind them?

For example (the numbers are probably wrong), if I drop the device, it hits the ground, at which point:

at t = 0: has impacted on the floor, and vertical velocity becomes 0.

at t = 10ms, acceleration begins to be experienced upwards due to force exerted back from the ground.

at t = 50 ms, device accelerates up, and vertical velocity also.

So if this were the case, I'd set the debounce to e.g. 50ms - since I'm at 100hz, then that'd be 5 steps.

Is this correct?

Meanwhile, I'll play around with the debounce to see if I can't get any more accurate results.

Thanks!

[david_diaz]

Hello Rich,

Please accept my apologies for the delay.

Indeed, you assumption is correct.

Please note that the debounce counter acts like a filter to determine whether the condition exists for configurable set of time.

As I mentioned before, I recommend setting a fixed ODR and then, set the debounce counter to eliminate false readings.

I hope your application now is working properly.

Have a great day.

David

[r_sama]

Hi David,

No worries, thanks for the reply - I'll continue to test and I'm sure I'll get it correct through some trial and error!

Cheers!