FOXS8700CQ - pulse detection latency does not behave as expected

[JRB]

Hi all!

I am working on a single tap detection and am noticing that the latency time seems to be not kept by the sensor algorithm.

The sensor is set to detect single pulse using:

// PULSE_CFG => Enable X, Y and Z Single Pulse, latch enable
ACC_Write_Register( FXOS8700CQ_REG_PULSE_CFG, 0x55 );
// PULSE_TMLT
// Maximum time of a pulse. If the pulse width is greater than 
// the time specified by this variable, pulse will be ignored.
// 1LSB =
// @12.5Hz low power/low noise => 20 ms *
// @12.5Hz low power => 40 ms
// @12.5Hz normal mode => 5 ms
// @12.5Hz high resolution => 0.625 ms
ACC_Write_Register( FXOS8700CQ_REG_PULSE_TMLT, 0x0F );
// PULSE_LTCY Latency Time
// During this time interval, all pulses after last pulse are ignored 
// 1LSB = see above
ACC_Write_Register( FXOS8700CQ_REG_PULSE_LTCY, 0x30 );
// HPF filter setting
ACC_Write_Register( FXOS8700CQ_REG_HP_FILTER_CUTOFF, 0x03 );
 // CTRL_REG2 - set low power/low noise OSR=4 => 0x09 (low power => 0x1B)
ACC_Write_Register( FXOS8700CQ_REG_CTRL_REG2, 0x09 );
// CTRL_REG1
// Setup device for acc only mode
// ODR = 12.5Hz, normal noise, go to ACTIVE mode
ACC_Write_Register( FXOS8700CQ_REG_CTRL_REG1, 0x29 ); // 12.5Hz

The detection works quite well for our application.

However I am seeing tap interrupts occurring much earlier than 960ms after each other.

This indicates to me that the latency time is shorter than expected.

Does the HPF setting influence the latency timing (or even other timing, like max pulse width)?

What else can lead to detected pulses within the latency time?

Can 2 pulses be detected if they fit within the max pulse width?

Thanks a lot for input!

JR

[TomasVaverka]

Hi Jean,

Please try to set the pls_ele bit to 0.

If this bit in the PULSE_CFG (Reg 0x21) register is "0", the interrupt is kept high for the duration of the Latency window PULSE_LTCY (Reg 0x27).

If the pls_ele bit is "1", the source register values will remain static until the PULSE_SRC (Reg 0x22) register is read. Then the pulse interrupt is deasserted.

Best regards,

Tomas

[JRB]

Hi Tomas!

Thx for your input!

So you are basically saying that when clearing the interrupt by means of reading the interrupt source practically immediately (by MCU reading the PULSE_SRC register) the sensor is ready for the next interrupt and therefore indirectly disregards the latency time?

Ok, if I set the pls_ele bit = "0", I will still get other interrupts as usual out of the INT_SOURCE register or will I keep seeing the src_pulse bit for the time of the lattency?

For example I have a typical case that I get a pulse event, which is shortly followed (<1s) by a vector event. When I handle this interrupt, will I see only the src_a_vecm bit = "1" in INT_SOURCE  or will I also see src_pulse bit still as "1"?

Thanks!

JR

[JRB]

Hi Tomas!

I just tried changing the pls_ele bit to "0".

Now I have a totally different problem:

The sensor interrupt line seems to change multiple times faster its state than the MCU can react to it.

What happens:

- init sensor

- cause any interrupt e.g. tap => ok

- ...

- double tap or shake sensor to give reason for tap within latency time - to check latency behavior

=> mcu sees interrupt, handles it

==> meanwhile new interrupt appears and stays unhandled since MCU disables interrupt for a short moment to handle current interrupt of same level

Why does this behavior appear?

From the interrupt being raised for the time of the latency I would have expected the interrupt pin to signal for longer and then fall.

Thx!

JR