Yes, you’re right that the GPA.Delta does have little jumps and they are very evenly spaced which is quite suspicioius. The board’s PM message doesn’t report any significant CPU issue.
Anyway, this is a bit out of my depth so I think Andy, Tridge and others will probably investigate but we’re tracking it now at least.
yes, I noticed that too. As if something at a certain time slows down the receipt of data from the gps. And the most interesting thing is that this does not happen after 10hz - which suggests that the data from the gps comes as usual at 5Hz, but the AP processes them out of time
Some update - i’m test latest b7 on 57600 and with stock buffers - gps warning messages present! Increasing buffers - fix this at 57600 speed but not > 57600
This mean that not only speed but buffers help to fix this spikes!
Maybe try changing gps_save_cfg to 1 (Save config)? I see in the log you have it set to 2(Save only when needed). Maybe NMEA on by default flooding the link? Are ubx msgs even sent? Or maybe they are not necessary, I am not knowledgeable on this
Output protocol NMEA-0183 or UBX, default NMEA-0183 protocol
edit oops read the site wrong does have 4mb flash
Please change INS_GYRO_RATE to 0. In my experience F4’s are not powerful enough to deal with higher gyro rates.
Also please change INS_HNTCH_OPTS to 0. Flying double notch at loop rate update again is too much for an F4 - you are basically killing the CPU.
No this not related to my changes to notch or gyro speed - this logs from last my changes for 7 inch copter - problems started from 450 copter with default gyro speed and after i’m start using crsf protocol.
From my last logs i’m see that cpu load about 35% in flight - this is bad values? dont think.
I’m test all variants with def gyro, with notch_opt 0 - all same. And gps spikes present in 57600 baud rate too. And after flight, at idle i’m see again gps warnings.
I do not think that f4 is weak for such simple tasks - the reason here is most likely in the incorrect operation of either the cross protocol or the task manager as a whole. Moreover, I do not like it when they say - perhaps the processor is not so fast for such settings - for this there are programmers - to solve tasks and optimize the code.
Honestly, it’s not hard for me to find the reason - but I need a lot of time to study the part of the code that is responsible for all this - but I don’t have time - and I think that someone who participated in this should do this and knows where problems can arise … Moreover, the processing of data from the receiver and the gps is one of the main tasks that must work very stably and without failures - otherwise the whole system will fall apart very quickly without careful optimization.
I apologize for the many words and this is my personal opinion. Thanks.
We’ll have to go back to 4.0.7 and not twitch.
The load value only tells you what is going on in the scheduler - it doesn’t tell you about the other threads (e.g. the IMU thread which runs the notch filters). Honestly, if you are just going to make wrong assumptions about the code and are not willing to help track this down then I can’t really help you.
I am always ready to help test anything. But at the moment I see that the situation requires a thorough review, testing and identification of problems associated with the operation of com ports - and whether this is an excessive load on the processor or not - this requires tests, logs, data is needed - I asked before how and where identify the reason - but so far I have not seen a single piece of advice that would have practical meaning. If you have any thoughts what it might be - please suggest - i’m test.
And 4.0.7 have this spikes in gpa delta too 
–enable-stats has been fixed in master - I suggest you use that to see where the CPU time is going. I also suggest you take a look at the DMA contention statistics.
Ok. DMA contention i’m send you - you say all good.
ThreadsV2
ISR PRI=255 sp=0x20000000 STACK=1192/1536 LOAD= 2.6%
ArduCopter PRI=182 sp=0x20000600 STACK=5368/7168 LOAD=27.6%
idle PRI= 1 sp=0x20011878 STACK= 144/ 352 LOAD=22.7%
UART_RX PRI= 60 sp=0x2001D970 STACK=1024/1360 LOAD= 0.6%
OTG1 PRI= 60 sp=0x2001CDB8 STACK= 456/ 848 LOAD= 0.5%
monitor PRI=183 sp=0x2000F050 STACK= 472/ 848 LOAD= 0.7%
timer PRI=181 sp=0x200102D0 STACK=1488/1872 LOAD= 2.3%
rcout PRI=181 sp=0x2000F990 STACK= 488/ 848 LOAD= 7.5%
rcin PRI=177 sp=0x2000F3F0 STACK= 744/1360 LOAD=11.0%*
io PRI= 58 sp=0x2000E6B0 STACK=1408/2384 LOAD= 1.5%*
storage PRI= 59 sp=0x2000FD30 STACK= 864/1360 LOAD= 0.7%
UART3 PRI= 60 sp=0x2001C220 STACK= 496/ 848 LOAD= 1.0%
UART6 PRI= 60 sp=0x2001B770 STACK= 472/ 848 LOAD= 0.5%
I2C0 PRI=176 sp=0x2001A0E8 STACK= 888/1360 LOAD= 1.4%
FrSky PRI=178 sp=0x20018930 STACK= 832/1360 LOAD= 1.7%
UART1 PRI= 60 sp=0x20017F78 STACK= 456/ 848 LOAD= 1.1%
OSD PRI= 59 sp=0x20013F70 STACK= 928/1616 LOAD= 0.9%*
log_io PRI= 59 sp=0x200149E0 STACK=1320/1656 LOAD= 0.7%
SPI1 PRI=181 sp=0x20012DE0 STACK= 576/1360 LOAD=13.8%
FTP PRI= 58 sp=0x100082B8 STACK=1432/2896 LOAD= 0.6%
This is bad ?
Some update - i’m revert R9M to stock FW and now i’m can say that gps warnings showing again - this only mean that problem related to rcin but not crsf!
Make test more - with DMA on 57600 i’m have this warnings too - what cause this? maybe 4.0.7 have this problem too but without any message to MP ?
11% CPU on RC in is pretty high. The * means that the worst time was longer than 5000us which is bad. Interesting that you have a lot of idle - I get about 6% CPU on RCIN on an F7 again with the long worst time, but I have no idle.
This logs with frsky sbus and sport telemetry connected to serial1 and notch_opt - 0. i’m now not using crsf or elrs. F7 have 216mhz f4 have 168mhz - this differnces in rc loading. 5ms - for sbus i’m think normal or?
Idle - dont know why this… But i’m only see that DMA breaks GPS stability…
Why rcin loading cpu ? maybe more priority?
The big difference between F4 and F7 is not the clock speed but rather M4 vs M7 architecture
well, not the point.
Might just turn off these warnings 
Please say where in code writing to log about GPA delta - I want to trace the full path - and try to figure out the reason in instability GPA delta.
And I can say that lately, when using crossfire, I began to receive a failsafe without causation - perhaps this is somehow related and saw such entries on the forum…
I am investigating the CRSF failsafe as I have a reproducer here. The GPA delta is because of the GPS jitter correction code - no idea where the code is.
Ok - i’m find where.
Jitter maybe present in rcin - and some time we have failsafe.
I’m test GPS_DRV_OPTIONS - and this not working - baud always == 234000
I’m partial fix this when change gps_rate_ms to 100ms
Now spikes from 100 to 170ms from logs, but jitter detector using 215ms as max value - now AP silent but spikes present!
I’m think this need attention from devs…
@Evgen_Stenkin can you try my branch to see if that helps:
this doesn’t fix the jitter issues but does fix DMA contention on F4s and issues with CRSF frame timeouts.
@Derek The log shows that the crystal on this board sets a new record for poor calibration. The system clock is off by 6631 parts per million. That is why we’re getting those delta corrections.
It would be good to know if this affects all MambaF405v2 boards or if you just got a bad one.