Why CTUN.CRt does not follow the derivate of CTUN.alt?

Hello everyone, i am using Copter4.2.2 to fly to the althold mode on my 210 copter.but the effect of the althold is not good.Through checking the fly log, i found that CTUN.CRt does not follow the derivate of CTUN.Alt,or even the revese.Who knows that CTUN.CRt does not follow the derivate of CTUN.alt?thanks.

log file:
2023-02-01 10-01-07.bin

this is not uncommon and looks like in your case it is caused by poor GPS lock. The GPS vertical velocity is used in climb rate estimation
You have both a low quality IMU (an MPU6000) and a low quality GPS, getting discrepancies is not unusual in this case

@tridge Yes,i also suspect that it is caused by poor GPS lock,but i have put EK3_SR1_VELZ parameter is changed from 3 to 0,that vetical velocity source is not GPS,or unplug the GPS,they are still the same.
Is the fimware problem?

@tridge I found the problem!
This is really a firmware problem because when i change the INS_FAST_SAMPLE parameter from the default value of 1 to 0,the althold is normal.

At the same time, when INS_FAST_SAMPLE is 1,the FFT analysis log shows that the sampling rate of the acc is only 1k,not 4k,while the sampling rate of the fast sampling filter in the MPU6500 driver is configured as 4k, which results in abnormal date after the acc is filterd. the althold is abnormal.

The following link is my PR.
the accel fast-sampling rate of MPU6500 is 4k,not 1k