Add support for CLKIN on modern gyros to improve flight performance.

[hydra]

Is your feature request related to a problem? Please describe

Gyros like the ICM-42688-P have a CLKIN signal which allows the FC to generate the clock signal.

TDK's datasheet for the ICM-42688-P says:

External clock input supports highly accurate clock input from 31kHz to 50kHz, resulting in improvement of the following:
a) ODR uncertainty due to process, temperature, operating mode (PLL vs. RCOSC), and design limitations. This uncertainty can be as high as ±8% in RCOSC mode and ±1% in PLL mode. The CLKIN, assuming a 50ppm or better 32.768kHz source, will improve the ODR accuracy from ±80,000ppm to ±50ppm in RCOSC mode, or from ±10,000ppm to ±50ppm in PLL mode.
b) System level sensitivity error. Any clock uncertainty directly impacts gyroscope sensitivity at the system level. Sophisticated systems can estimate ODR inaccuracy to some extent, but not to the extent improved by using CLKIN.
c) System-level clock/sensor synchronization. When using CLKIN, the accelerometer and gyroscope are on the same clock as the host. There is no need to continually re-synchronize the sensor data as the sensor sample points and period are known to be in exact alignment with the common system clock.
d) CLKIN helps EIS (Electronic Image Stabilization) performance by providing:

• Very accurate gyroscope sample points for use during integration to find true angular displacement.
• Automatic time alignment between the motion sensor and the host and potentially the camera system.
  e) Other applications that benefit from CLKIN include navigation, gaming, robotics.

https://invensense.tdk.com/download-pdf/icm-42688-p-datasheet/

Describe the solution you'd like

The CLKIN signal can be generated from a timer, STM's advanced control timers are better suited to this, e.g. TIM1/TIM8. TIM8 makes a great candidate on the H723/H730/H743/750.

Additionally, if the INT signal is also connected to another channel on the same advanced control timer, then it's possible to easily verify and monitor the gyro INT signal timing in relation to the clock signal.

For dual-gyro boards it's also possible to use all 4 channels of TIM8, 2 per gyro.

The SPRacingH7EF for example, is configured as follows:

MCU:

GYROS:

Describe alternatives you've considered

Not using CLKIN and having the system work from INT timings and guessing the gyro clock.

It's also possible to use a timer, + dma stream + gpio BSRR or ODR registers to generate a clock signal on an arbitrary GPIO pin, but this isn't as efficient as using a timer.

Other information

I have hardware available for testing if needed if anyone wants to work on this.

[ledvinap]

The CLKIN signal can be generated from a timer, STM's advanced control timers are better suited to this, e.g. TIM1/TIM8. TIM8 makes a great candidate on the H723/H730/H743/750.

Any timer with connection to output to pin should do. IMO it is better to rty to use least-useful timer (TIM12, TIM13, TIM14, TIM15, TIM16, TIM17) or even (currently unused?) LPTIMx

Another possibility is USART (smartcard mode clock), SPI (I2S MCK, but I did not check that 32k is possible).

Additionally, if the INT signal is also connected to another channel on the same advanced control timer, then it's possible to easily verify and monitor the gyro INT signal timing in relation to the clock signal.

Great for testing, but IMO almost useless otherwise. ODR is guarantied, you can synchronize data to clock, using status register if necessary.

For dual-gyro boards it's also possible to use all 4 channels of TIM8, 2 per gyro.

Good for testing. But sharing clock for both gyros (possibly with one clock inverted) should be enough.

Not using CLKIN and having the system work from INT timings and guessing the gyro clock.

Actually, it would be useful to implement general software PLL that can sync to peripheral without INT. But for gyro, direct sync is very reasonable.

It's also possible to use a timer, + dma stream + gpio BSRR or ODR registers to generate a clock signal on an arbitrary GPIO pin, but this isn't as efficient as using a timer.

Maybe as last resort, but there are so many better options.

I have hardware available for testing if needed if anyone wants to work on this.

Actually, I could use one ;-) But there are other, more interesting things possibly with H7

[hydra]

Any timer with connection to output to pin should do. IMO it is better to rty to use least-useful timer (TIM12, TIM13, TIM14, TIM15, TIM16, TIM17) or even (currently unused?) LPTIMx

My thought there was that the advanced control timers and gyro clock generation is new and more of an unknown at this point, so using a more capable timer is probably a good idea until more code is written, additionally the peripheral interconnect of TIM1 and TIM8 is better.

Additionally, if the INT signal is also connected to another channel on the same advanced control timer, then it's possible to easily verify and monitor the gyro INT signal timing in relation to the clock signal.

Great for testing, but IMO almost useless otherwise. ODR is guarantied, you can synchronize data to clock, using status register if necessary.

I was thinking of being able to stagger gyro readings from different gyros to effectively double the data throughput or to balance load.

[ledvinap]

@hydra : Part of my thinking is from Cleanflight F103 days - every timer was precious ;-)
IMO timer abstraction is generic enough to support simple frequency output.

SPRACING is probably only available hardware, so used pins are kind of fixed now. Eventually, less valuable pins may be supported .

Stagger is interesting idea. But readout is less than 16kHz, so even shared clock shall be ok. But changing clock phase may have influence on noise (IMO each gyro element will still resonate on it's mechanical frequency. External clock will probably influence digital part only)

[sriccardi-invn]

@hydra @ledvinap , I confirmed that using CLKIN will not change the gyro element resonate frequency (primary stage). Resonate frequency are different for all axis. CLKIN is used for Accel and Gyro sencondary stage only: ADC conversion, filtering, etc....
Use CLKIN will improve clock accuracy and this is a best way when you have several sensors to have synchonous data.
Gyro internal clock accuracy is worst than external crystal and drift more over temperature. Clock error = sensitivity error.........

[hydra]

Yes, as-per the datasheet list of improvements.

To me, inverting the /system/ dependency is the biggest win, i.e. the system/scheduler controls the gyro instead of reacting to it. Currently the gyro drivers and scheduler has code dealing with timing gyro EXTIs and handling scheduler skew which could be bypassed/removed/improved if the system generated the gyro clock.

[ledvinap]

@hydra : The code will stay in for other targets. And with RTOS, you can simply preempt on EXTI, no prediction of EXTI would be necessary.
But improved stability is definitely desirable.

[cvetaevvitaliy]

Hi @haslinghuis @ledvinap @hydra @sugaarK
I tested this implementation today, there is some improvement

Roll without EXT CLK

Roll with EXT CLK

Full blackbox log

btfl_001-without_clk.zip
btfl_002-with_clk.zip

[Quick-Flash]

The fft plots on the raw gyro look very similar. Its quite likely that differences could have been due to the flying. It'd be better if you just compared some hovers. @cvetaevvitaliy. However, it will likely give a decent improvement to attitude estimation as it'll essentially fix gyro drift.