H3LIS100DL: prevent interrupting sample to be overwritten/overrun

PArve.1 · ‎2021-01-28

The H3LIS100DL has no fifo, and the ODR can be set to 400Hz. This would make it update the axes data each 2.5ms.

I have programmed it to interrupt a mcu when a threshold is reached. This wakes the micro controller from deep sleep. Unfortunately it takes the Mcu about 8ms before it has woken up and is ready to read back the samples (X,Y,Z) that caused the interrupt.

Is there a way to make the accelerometer to keep the data and not overwrite it?

I read something about BDU (Block Data Update for LIS3DH); something like that the output data would not be overwritten until all axes had been read out. Is there anything similar that would work for H3LIS100DL? Any other trick?

I know there will be lost samples, but I'm mainly interested in reading back the sample that caused the interrupt.

Eleon BORLINI · ‎2021-02-01

Hi @PArve.1 ,

as you noticed, unfortunately the H3LIS100DL device is not provided by a FIFO and -in general- an internal buffer for the storage.

>> Unfortunately it takes the MCU about 8ms before it has woken up and is ready to read back the samples (X,Y,Z) that caused the interrupt.

Before waking up, the H3LIS100DL is in low power state (cfr CTRL_REG5 (24h) register in the datasheet, p. 29), so that you have maximum ODR of 10Hz, and the interrupt event lasts at least 1/ODR, giving you the 8ms delay you are experiencing.

Having the low power set, data are available in the dataout registers, and if you are interested in characterizing the mechanica event that wake up the MCU you could acquire at least once this event in low power mode by the MCU (instead leaving MCU in sleep mode, so preventing it from acquiring data).

But if the MCU is in sleep mode and is activated only by the event, the only information about the interrupt you could retrospectively gain is the fact that 8ms before the MCU is waken up by a mechanical event that exceeded the threshold for 1/ODR (at least), or for the duration you can set in the register INT1_DURATION (33h). This is the predefined minimum event duration, and you can characterize it at the beginning of your experiments if the mechanical trigger is repeatable. I'm afraid is not possible to retrieve data of an event in the past if the MCU is sleeping and is the only processor acquiring H3LIS100DL data.

For completeness, the BDU bit is the block data update bit: if you enable it and you don't refresh the out registers by reading them (in I2C or SPI), the register content will remain the one it was at the beginning of the data production. So I believe it is not possible to use this bit to retrieve data near the event...

Please let me know if this answer can someway help you.

-Eleon

View solution in original post

Eleon BORLINI · ‎2021-02-01

Hi @PArve.1 ,

as you noticed, unfortunately the H3LIS100DL device is not provided by a FIFO and -in general- an internal buffer for the storage.

>> Unfortunately it takes the MCU about 8ms before it has woken up and is ready to read back the samples (X,Y,Z) that caused the interrupt.

Before waking up, the H3LIS100DL is in low power state (cfr CTRL_REG5 (24h) register in the datasheet, p. 29), so that you have maximum ODR of 10Hz, and the interrupt event lasts at least 1/ODR, giving you the 8ms delay you are experiencing.

Having the low power set, data are available in the dataout registers, and if you are interested in characterizing the mechanica event that wake up the MCU you could acquire at least once this event in low power mode by the MCU (instead leaving MCU in sleep mode, so preventing it from acquiring data).

But if the MCU is in sleep mode and is activated only by the event, the only information about the interrupt you could retrospectively gain is the fact that 8ms before the MCU is waken up by a mechanical event that exceeded the threshold for 1/ODR (at least), or for the duration you can set in the register INT1_DURATION (33h). This is the predefined minimum event duration, and you can characterize it at the beginning of your experiments if the mechanical trigger is repeatable. I'm afraid is not possible to retrieve data of an event in the past if the MCU is sleeping and is the only processor acquiring H3LIS100DL data.

For completeness, the BDU bit is the block data update bit: if you enable it and you don't refresh the out registers by reading them (in I2C or SPI), the register content will remain the one it was at the beginning of the data production. So I believe it is not possible to use this bit to retrieve data near the event...

Please let me know if this answer can someway help you.

-Eleon

PArve.1 · ‎2021-02-01

Hello Eleon

I forgot to clarify: the H3LIS100DL is, in this case, running in normal mode at 400Hz ODR.

The micro controller is sleeping though, but is woken up when a threshold interrupt is generated by the H3LIS100DL. It takes the mcu at least 8ms to reach a place in the code where it can read from the i2c bus (this is slow, I know, but the code overhead aside it still needs about 2.5ms to wake up from deep sleep as per the data sheet). Maybe I can squeeze the start-up time a bit but I'd still never come below the deep sleep wakeup time which is 2.5ms.

It just so happens that 1/400=2.5ms is the ODR period. So I if I understood it right I'll never be able to retrieve the sample in time; it will be overwritten after 2.5ms.

So could I change NT1_DURATION (33h) to prolong the interrupt event (blocking the H3LIS100DL from overwriting the samples)?

If I set NT1_DURATION=127 at ODR=400Hz, would it keep the data for 127/400 =0.3175s?

The BDU does not seem to be available on H3LIS100DL.

Eleon BORLINI · ‎2021-02-03

Hi @PArve.1 ,

>> So I if I understood it right I'll never be able to retrieve the sample in time; it will be overwritten after 2.5ms.

I'm afraid so... without a buffer or a FIFO storing the samples, the device cannot retain samples and so the data related to the interrupt event are not available... (and this would be a problem also in case the BDU would be available).

Also in case the MCU would be faster in its wake-up action, it would be not possible to retrieve previous samples from the device, unless MCU wake-up is faster that 2.5ms...

-Eleon