Skip to main content
TANGQ1
Associate
June 10, 2026
Solved

GNSS time synchronization support for IIS3DWBG1/IIS3DWBG1TR and AIS25BA/AIS25BATR

  • June 10, 2026
  • 2 replies
  • 80 views

Hello,

I am evaluating IIS3DWBG1/IIS3DWBG1TR and AIS25BA/AIS25BATR for a data acquisition system where sensor data timestamps need to be aligned with GNSS time.

I would like to ask whether these devices support any GNSS-related time synchronization interface or equivalent mechanism, such as GNSS/GPS 1PPS or PPS input, UTC/NMEA time reference input, PTP/IEEE1588 synchronization, external sync input, external reference clock input, FSYNC/CLKIN/EXTCLK, or any pin/register mechanism that can reset, latch, align, or discipline the internal timestamp counter using an external timing signal.

Based on my review of the publicly available ST documentation and product pages, IIS3DWBG1/IIS3DWBG1TR appear to provide an internal timestamp counter and FIFO timestamp function, but I have not found any clearly documented pin, register, or configuration mechanism to align this timestamp to GNSS 1PPS/PPS or UTC time.

For AIS25BA/AIS25BATR, the publicly available documentation shows TDM interface signals such as TDM_MCLK, TDM_BCLK, TDM_WCLK and TDM_SDOUT. My current understanding is that TDM_WCLK is a TDM word/frame synchronization signal, not an absolute GNSS/PPS time synchronization input.

If GNSS-aligned timestamps are required, my current understanding is that timestamp alignment may need to be implemented externally in the host MCU, processor, or data acquisition system, for example by timestamping DRDY/FIFO readout using a GNSS/UTC/1PPS reference.

Could anyone from the community or ST moderators help check whether this understanding is correct?

Also, if there are any application notes, reference designs, or recommended implementation methods for GNSS-synchronized timestamping with these devices, I would appreciate the guidance.

Thank you.

Best answer by Federica Bossi

Hi ​@TANGQ1 ,

Neither IIS3DWBG1/IIS3DWBG1TR nor AIS25BA/AIS25BATR provides a native GNSS timestamp directly inside the sensor.

 

Regarding the TDM interface of AIS25BA/AIS25BATR, your interpretation is correct: TDM_WCLK is derived from the clocking scheme provided by the host microcontroller to the sensor, and it defines the effective ODR at which the host receives new data from the sensor.

 

Both sensors provide an internal timestamp capability, typically used together with data acquisition and FIFO storage. This means that sensor data can be stored in the FIFO and, depending on the configuration, timestamp information can also be captured with a defined cadence or after a given number of samples. However, this timestamp is not synchronized to GNSS time; it is generated from the sensor’s internal clock domain. As a result, its resolution is on the order of the internal clock LSB, approximately 10 µs, and it should be considered as the sensor’s local time reference rather than an absolute GNSS-aligned timebase.

 

Therefore, if GNSS-aligned timestamps are required, the conversion to GNSS time must be performed on the host side, i.e. in the microcontroller, processor, or data acquisition system.

 

For GNSS-based time correlation, we can suggest two possible approaches:

 

Use AIS25BA/AIS25BATR in TDM mode, where you provide the reference clock to the sensor. In this configuration, you know the acquisition cadence from the supplied clock, but you still need to implement the timestamp logic in software, since the TDM peripheral itself does not provide an absolute GNSS timestamp.

 

Alternatively, if you need a sensor solution with support for an external clock reference, we can suggest LIS2DUX12. This device supports the possibility of applying an external clock to the sensor, so the timestamp can be synchronized to the clock provided to the sensor rather than relying solely on the internal clock domain. We recommend referring to AN5909, section 3.5.

2 replies

Federica Bossi
Federica BossiBest answer
ST Technical Moderator
June 15, 2026

Hi ​@TANGQ1 ,

Neither IIS3DWBG1/IIS3DWBG1TR nor AIS25BA/AIS25BATR provides a native GNSS timestamp directly inside the sensor.

 

Regarding the TDM interface of AIS25BA/AIS25BATR, your interpretation is correct: TDM_WCLK is derived from the clocking scheme provided by the host microcontroller to the sensor, and it defines the effective ODR at which the host receives new data from the sensor.

 

Both sensors provide an internal timestamp capability, typically used together with data acquisition and FIFO storage. This means that sensor data can be stored in the FIFO and, depending on the configuration, timestamp information can also be captured with a defined cadence or after a given number of samples. However, this timestamp is not synchronized to GNSS time; it is generated from the sensor’s internal clock domain. As a result, its resolution is on the order of the internal clock LSB, approximately 10 µs, and it should be considered as the sensor’s local time reference rather than an absolute GNSS-aligned timebase.

 

Therefore, if GNSS-aligned timestamps are required, the conversion to GNSS time must be performed on the host side, i.e. in the microcontroller, processor, or data acquisition system.

 

For GNSS-based time correlation, we can suggest two possible approaches:

 

Use AIS25BA/AIS25BATR in TDM mode, where you provide the reference clock to the sensor. In this configuration, you know the acquisition cadence from the supplied clock, but you still need to implement the timestamp logic in software, since the TDM peripheral itself does not provide an absolute GNSS timestamp.

 

Alternatively, if you need a sensor solution with support for an external clock reference, we can suggest LIS2DUX12. This device supports the possibility of applying an external clock to the sensor, so the timestamp can be synchronized to the clock provided to the sensor rather than relying solely on the internal clock domain. We recommend referring to AN5909, section 3.5.

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.
    TANGQ1Author
    Associate
    June 15, 2026

    Hi Federica,

    Thank you very much for the clear and detailed explanation.

    Your answer confirms my understanding: IIS3DWBG1/IIS3DWBG1TR and AIS25BA/AIS25BATR do not provide a native GNSS-aligned timestamp inside the sensor, and their internal timestamp should be treated as a local sensor time reference rather than an absolute GNSS timebase.

    It is also helpful to know that AIS25BA/AIS25BATR in TDM mode can provide a known acquisition cadence from the host-supplied clock, but the absolute GNSS timestamping still needs to be implemented on the host MCU/processor/data acquisition system side.

    Thank you also for suggesting LIS2DUX12 and AN5909 section 3.5 as a possible reference for external clock support. I will review those materials.

    Best regards,
    TANGQ1

    Terms & ConditionsAccessibility statement