I could not see a specific reason for such high CPU load.
There are some things I would point out though, and some I would change.
It’s a Cube Black, so there is NOT a lot of processing power to play with and I think a lot of improvements to attitude control (and related code) over the last couple of years has probably increased CPU load noticeably. I’ve got similar, or even better, flight controllers I’m putting aside or delegating to mundane jobs so I can continue to use the modern-day improvements and features (like scripting). I dont want this to sound like “ERROR - not enough money spent” when an old flight controller could still work fine.
It might be a case of working out which Arducopter version still allows reliable use with the most fixes and improvements. I’m guessing around version 4.2.3 or slightly earlier.
The tuning and attitude control needs some attention, it could be quite a bit better, even without enabling more features such as the Harmonic Notch Filter.
Some GPS settings are unrealistic and only one of the GPS units can keep up with the update rate you set. These would be better set back to 200ms
GPS_RATE_MS
GPS_RATE_MS2
and try these at 5 or 65 , whichever gives you the lowest reliable HDOP
GPS_GNSS_MODE
GPS_GNSS_MODE2
This will help to stabilise the update rate too.
You appear to relying heavily on GPS altitude, although your barometers appear quite well behaved and closely match GPS altitude. I would set:
BARO_FLTR_RNG,10 //to reduce the baro noise, but EKF does a good job anyway
EK3_ALT_M_NSE //reduce to closer to default
EK3_SRCx_POSZ //set at least 1 of these 3 parameters to Baro instead of GPS
Keep in mind the barometer can give variations in altitude with changing conditions, but GPS can give sudden step-changes for no apparent reason (although is generally reliable)
To help reduce CPU load I would start by disabling SRTL and setting these associated failsafe actions:
SRTL_POINTS,0
BATT_FS_CRT_ACT,1
BATT_FS_LOW_ACT,2
and try disabling these too:
SURFTRAK_MODE,0
TERRAIN_ENABLE,0
Do you use the SBUS Out ? Maybe for a gimbal - If not set this
BRD_SBUS_OUT,0
SR1 parameters have some relatively high values, you might want to scale them back to be more like SR0, after all you’ve only got a 56k telemetry link and sending all that data 20 time per second will be flooding it and needlessly using CPU cycles. In fact you usually dont even need to set these as the groundstation will be requesting the data, they are more important if you’ve got some older device that passively waits for the data and doesnt request anything.
Unrelated to CPU usage, but quite important, set these battery voltage parameters
Lipo
BATT_ARM_VOLT,44.30
BATT_CRT_VOLT,42.00
BATT_LOW_VOLT,43.20
MOT_BAT_VOLT_MAX,50.40
MOT_BAT_VOLT_MIN,39.60
Li Ion
BATT_ARM_VOLT,38.30
BATT_CRT_VOLT,36.00
BATT_LOW_VOLT,37.20
MOT_BAT_VOLT_MAX,49.20
MOT_BAT_VOLT_MIN,33.60
Those MOT_BAT parameters will really aid tuning and attitude control.
Lastly I would reassess the attitude control - that might help with flight time and more.
