Skip to main content
chobits
Visitor II
June 17, 2026
Solved

LSM6DSM, timestamp in FIFO occasionally incorrect

  • June 17, 2026
  • 1 reply
  • 51 views

acc + gyro + timestamp, ODR 208 hz, FIFO continous mode, timestamp resolution 25us, following is my register setting

imu.__write_reg(CTRL3_C, 0x44)

imu.__write_reg(WAKE_UP_DUR, 0x10)

imu.__write_reg(CTRL10_C, 0x34)

imu.__write_reg(CTRL1_XL, 0x5c)

imu.__write_reg(CTRL2_G, 0x5c)

imu.__write_reg(FIFO_CTRL2, 0x80)

imu.__write_reg(FIFO_CTRL1, 45)

imu.__write_reg(INT1_CTRL, 0x08)

imu.__write_reg(FIFO_CTRL3, 0x09)

imu.__write_reg(FIFO_CTRL4, 0x08)

imu.__write_reg(FIFO_CTRL5, 0x2E)

Occasionally, I get incorrect timestamp value in FIFO (acc and gyro value is ok), following are some example

530929, 531123, 531316, 531510, 531704, 531898, 532092, 532286, 532224, 532673 (timestamp go backward)

165672, 165866, 166060, 166254, 166448, 166641, 167087, 167223, 167417, 167611, 167804 (timestamp jump)

 

Thank you very much for helping

Best answer by Federica Bossi

Hi ​@chobits ,

The issue is likely related to the FIFO timestamp setup rather than the accelerometer/gyroscope data themselves.

In the LSM6DSM, timestamp and step-counter information are stored in the FIFO as the 4th data set. According to AN4987, TIMER_PEDO_FIFO_EN = 1 is required, but DEC_DS4_FIFO[2:0] in FIFO_CTRL4 must also be different from 000b in order to actually store the timestamp data in FIFO.

In your current configuration, FIFO_CTRL4 = 0x08, which means DEC_DS4_FIFO = 000b, so the 4th data set is not enabled in FIFO. This can lead to misalignment when parsing the FIFO stream and may explain the occasional backward/jump in the timestamp values.

Please also note that the timestamp FIFO format is not a standard contiguous 24-bit layout:

  • Byte1 = TIMESTAMP[15:8]
  • Byte2 = TIMESTAMP[23:16]
  • Byte3 = unused
  • Byte4 = TIMESTAMP[7:0]
  • Byte5/Byte6 = step counter

Therefore, the FIFO pattern and byte ordering must be handled carefully when decoding the stream.

Finally, if the timestamp resolution was changed from low-resolution to high-resolution, the timestamp counter should be reset by writing 0xAA to TIMESTAMP_REG2.

I would suggest updating FIFO_CTRL4 so that DEC_DS4_FIFO is enabled, then re-checking the FIFO parsing logic and the FIFO pattern.

1 reply

Federica Bossi
Federica BossiBest answer
ST Technical Moderator
July 6, 2026

Hi ​@chobits ,

The issue is likely related to the FIFO timestamp setup rather than the accelerometer/gyroscope data themselves.

In the LSM6DSM, timestamp and step-counter information are stored in the FIFO as the 4th data set. According to AN4987, TIMER_PEDO_FIFO_EN = 1 is required, but DEC_DS4_FIFO[2:0] in FIFO_CTRL4 must also be different from 000b in order to actually store the timestamp data in FIFO.

In your current configuration, FIFO_CTRL4 = 0x08, which means DEC_DS4_FIFO = 000b, so the 4th data set is not enabled in FIFO. This can lead to misalignment when parsing the FIFO stream and may explain the occasional backward/jump in the timestamp values.

Please also note that the timestamp FIFO format is not a standard contiguous 24-bit layout:

  • Byte1 = TIMESTAMP[15:8]
  • Byte2 = TIMESTAMP[23:16]
  • Byte3 = unused
  • Byte4 = TIMESTAMP[7:0]
  • Byte5/Byte6 = step counter

Therefore, the FIFO pattern and byte ordering must be handled carefully when decoding the stream.

Finally, if the timestamp resolution was changed from low-resolution to high-resolution, the timestamp counter should be reset by writing 0xAA to TIMESTAMP_REG2.

I would suggest updating FIFO_CTRL4 so that DEC_DS4_FIFO is enabled, then re-checking the FIFO parsing logic and the FIFO pattern.

In order to give better visibility on the answered topics, please click on 'Best answer' on the reply which solved your issue or answered your question.
Terms & ConditionsAccessibility statement