Holybro H7 problems with keeping altitude (Baro and RTK GPS)

Hello,
We are using a Holybro H7 flight controller with Holybro F9P RTK GPS (with base) on a small Cinewhoop, unfortunately even after tuning we still have problems with keeping the altitude on longer flights (the drone generally fluctuates a bit and on longer flights it eventually sinks to the ground).
Attached is a log with a Auto flight where the drone should only fly straight ahead, but after some time the drone sinks to the ground.
We are not sure why this error occurs, because it seems that the drone (EKF) gives this command.

Does anyone have a tip for us what it could be because we are really wondering why it happens?
Or could the baro of the flight controller be broken?

https://drive.google.com/file/d/1l4CQgHckG0rYbCYtqmr5aV3BzXgxHg2k/view?usp=sharing

We would be grateful for any help

This copter is running 4.2.1 so I’ve moved this to the 4.2 category so that we don’t mix it up with 4.3 beta testing.

It looks to me like it is an uncommanded dip in altitude. It’s like it is something in the frame or power system that is causing the vehicle to lose altitude. I don’t think it is being commanded to descend by the autopilot navigation software. Below is a graph of the desired altitude (in red) and the actual altitude (in green) and we see the actual altitude is falling and pulling the desired with it (we do this so that the target never gets too far from the actual). One slightly odd thing though is that I don’t see the altitude controllers fighting back very much. Maybe @Leonardthall has an opinion on what is happening.

I see that you’ve set-up the 2nd bank of EKF sensor sources (e.g. EK3_SRC2_POSZ, etc) but I assume you’re not changing between sources.

I also notice you’ve set ARMING_CHECK=0. This is generally a bad idea because a lot of configuration and other checks are being disabled. Instead it is better to get to the bottom of the problem or worst case just disable the single check that you’re sure is not a real problem.

By the way, it’s probably unrelated but these parameter values seem extremely high. If it is a very small copter it might be OK but if it is a standard 10inch propeller vehicle (or larger) these seem too large. Perhaps this is a result of a failed autotune.

ATC_ACCEL_P_MAX,504233.8
ATC_ACCEL_R_MAX,286430.2
ATC_ACCEL_Y_MAX,121107.2

Here’s another interesting graph showing that the vehicle is climbing at 0.5m/s (red is desired climb rate, green is actual climb rate) but at the same time the altitude is actually falling (blue is desired altitude, orange is actual altitude). This contradiction in the estimate altitude vs climb rate is normally caused by high vibration but other sensors could also be to blame.

We also did another test when the drone is on the desk (motor off) and he determines the position without GPS.
What was clearly visible was that the altitude drifts very strongly. After about 15 minutes, there was an altitude difference of 2 meters. We suspect that one of the internal sensors of the board is not in order and it behaves so strangely. Could this be the reason?
Because we have never had such a drift with a flight controller.

According to the logs, the autotune should have worked. We had tuned all axles individually and these were the values he found.