Strange problem, I setup the hardware and make the config work with the webinterface. Turned the debug + ubx on and everything works ok.

When I make a total reboot (ESP + 2x F9P) the configuration is not coming back functional and debug is off in the serial monitor.

First I was thinking of power problems, but I found out, when I simple hit the button 'Apply and Save' on the webinterface within the GPIO section (without change anything) the setup is working again.

Hope this can fixed.

On stopping, the heading sticks at the last random value due to VTG. One advantage of dual antenna is to get correct heading on stop. I think the heading output should revert solely to RelPosNED values at dead slow to stop speeds and ignore VTG. Also maybe if antenna distance is extremely good say within 1-2cm maybe heading should not rely on VTG as much if at all. VTG is basically a derivative and can introduce unnecessary noise to the system. I am guessing VTG is just used to take out yaw due to crabbing?
Roll is very severely filtered. One advantage of using roll is to correct instantaneous antenna sway due to roll when driving over ruts and bumps. This looks like noise, but it can be taken out by correcting to virtual antenna position rather than filtering, provided the roll is not first filtered.
Again maybe if antenna distance is extremely good say within 1-2 cm ( should be so for dual f9p) use unfiltered roll and heading to get instantaneous virtual antenna position, then filter that position if absolutely necessary.
I could play with the code a bit and test. Ideally a rapid roll ( due to bump) should give no lateral movement to the virtual antenna position. and heading should be true at stop.
Another related question is if the IMU, if used, should it be integrated into the dual antenna system.
If it was, and was fitted at the antenna this could help take out apparent noise due to lateral motion of the antenna during bumps.
Just my thoughts.

In the U-Center I have a 3D / DGNSS-Fix (no DGPS) with a 3D quality of approximately 0.5 m. This is without NTRIP or RTCM from the BASE, but AOG indicates that there is an RTK-FIX . RTK-FIX is cm accurate in my experience, so something is not going well in the translation from MTZ to AG.

Hello. Are you sure about this if stm? Shouldn't it be
if (abs(cosHeadVTG) > 0.98)

In doing some F9P stress/consistency testing, I discovered the RelPosNED F9P is sending a message that is too long when starting up and it doesn't have a stable position yet. I am checking for bad checksum and wrong length on both NavPVT and RelPosNED.

A sample of the code I added to Line 141

if (UBXDigit2 > (108)) {
  UBXDigit2 = 0;
  UBXLength2 = 100;
  diagnostics.wrongLengthRelPosNEDCount += 1;
  saveDiagnostics();
}

The RelPosNED wrong length is the only one making problems, for about 100 messages. Since the count is being saved - to load on power up, it would be nice to ignore or fix the bootup wrong length messages. Any ideas?