Skip to main content
Visitor II
May 13, 2020
Solved

Hello, I'm currently testing the IIS3DWB accelerometer. The Datasheet says that the Timestamp tick resolution ist 25 us. All my measurements show, that the real resolution is 12.5 us. Is this correct?

  • May 13, 2020
  • 2 replies
  • 1366 views

This actually makes sense because the ODR is 26,667 kHz which means that between two samples are 37.5 us this would make three 12.5 us ticks. 25 us wouldn't make much sense.

    This topic has been closed for replies.
    Best answer by MNoll.2

    Hi Eleon,

    Thank you for your reply!

    I've read both datasheet and app note but I still think the value mentioned there is wrong. Here's how i come to this conclusion:

    Setup:

    IIS3DWB Eval Kit connected to 180 MHz Cortex M4 MCU via SPI (4 wires) @ 10 MHz, both Interrupts connected

    ODR 26,667 kHz, Timestamp active, DRDY Interrupt to INT1

    First test:

    Count the INT1 DRDY Pulses during 1 second - Result 26667 Pulses per Second +/- some ticks due to timing issues and maybe some clock errors (but very close to 26667 = no problem)

    Second test:

    Read the 32 bit timestamp value after each DRDY Pulse, Calculate the difference between the timestamp values after two consecutive DRDY Pulses - Result: The difference in timestamp values between two DRDY Pulses @ 26667 Hz ODR is 3 ticks

    This leads me to the conclusion that the timestamp tick resolution is 12.5 us because between two consecutive DRDY Pulses @ 26667 Hz there must be 37.5 us, so 37.5 us / 3 ticks = 12.5 us / tick

    25 us wouldn't make much sense simply because there would be 1.5 ticks between two samples and the tick value is an integer. So your IC designer would probably choose an integer value for the tick count between two samples.

    If your datasheet is correct I guess I have another chip revision...

    Best regards,

    Martin

    2 replies

    ST Employee
    May 13, 2020

    Hi @MNoll.2​ , I believe you are right, but let me please check internally.

    I can say that formula reported on the datasheet p. 38 can be used to calculate an estimation of the actual timestamp resolution:

    TS_Res = 1 / (40000 + (0.0015 * INTERNAL_FREQ_FINE * 40000))
    // INTERNAL_FREQ_FINE is the difference in percentage of the effective ODR (and timestamp rate) with respect to the typical. Step: 0.15%. Register INTERNAL_FREQ_FINE (63h)

    and the 25us value comes from INTERNAL_FREQ_FINE = 1 LSB. Regards

    MNoll.2AuthorAnswer
    Visitor II
    May 15, 2020

    Hi Eleon,

    Thank you for your reply!

    I've read both datasheet and app note but I still think the value mentioned there is wrong. Here's how i come to this conclusion:

    Setup:

    IIS3DWB Eval Kit connected to 180 MHz Cortex M4 MCU via SPI (4 wires) @ 10 MHz, both Interrupts connected

    ODR 26,667 kHz, Timestamp active, DRDY Interrupt to INT1

    First test:

    Count the INT1 DRDY Pulses during 1 second - Result 26667 Pulses per Second +/- some ticks due to timing issues and maybe some clock errors (but very close to 26667 = no problem)

    Second test:

    Read the 32 bit timestamp value after each DRDY Pulse, Calculate the difference between the timestamp values after two consecutive DRDY Pulses - Result: The difference in timestamp values between two DRDY Pulses @ 26667 Hz ODR is 3 ticks

    This leads me to the conclusion that the timestamp tick resolution is 12.5 us because between two consecutive DRDY Pulses @ 26667 Hz there must be 37.5 us, so 37.5 us / 3 ticks = 12.5 us / tick

    25 us wouldn't make much sense simply because there would be 1.5 ticks between two samples and the tick value is an integer. So your IC designer would probably choose an integer value for the tick count between two samples.

    If your datasheet is correct I guess I have another chip revision...

    Best regards,

    Martin

    ST Employee
    May 15, 2020

    Ciao Martin, your argument is valid, especially if supported from empirical measures... let me please check internally and come back to you. Regards

    ST Employee
    May 18, 2020

    Checked internally, there is the possibility we have to update IIS3DWB datasheet and app note on this topic. Thanks @MNoll.2​ for the issue reporting. Regards