Sample timing variation on Cube Orange

Cross posting this issue from Slack Issues channel for sake of preserving history of any discussion.

I’m seeing two types of seemingly unnecessary sample timing variation:

  1. Toggling between 4 and 8mS
  2. Occasionally, sampling gaps of 10’s of milliseconds

The Cube Orange has two IMUs configured for interrupt-driven, FIFO operation. During normal operation, it looks like this configuration is contributing to some consistent timing patterns as the number of samples sometimes comes up short (not that “dt,” here, is computed from successive timestamp_sample values, not the dt field of the topic):

IMO, this type of variation is unnecessary, even if handled by PX4 pipeline. I’m looking into making changes to the IMU drivers to eliminate the phenomenon.

The second type of variation is more troubling because sampling just goes away for many cycles:

Again, the PX4 pipeline is robust to variation in sample timing, but this phenomenon seems unnecessary.

Do other boards have this sort of sample timing variation?

The large dts were log dropouts.

Master branch is different

nsh> ver all
FW git-hash: a4e9444ca4e6d0d95599fd3654c13398012a409d
FW version: 1.13.0 40 (17629248)
FW git-branch: master
OS: NuttX
OS version: Release 10.0.0 (167772415)
OS git-hash: 8660572a3c69e0e2ca24c3cabeaaaae3372a6960
Build datetime: Sep  5 2021 15:17:03
Build uri: localhost
Toolchain: GNU GCC, 9.3.1 20200408 (release)
PX4GUID: 000600000000383638393239510c00490048
MCU: STM32H7[4|5]xxx, rev. V

Log collected with: logger start -p sensor_gyro_fifo.