Far more comments have come in since last night, and far more then I have time to respond to at the moment!
@Thorsten I'm trying to understand your graph, but I'm not following what I'm being shown.
ArduPilot is already doing Lag compensation for you on the solution output by the EKF. Depending upon your flight speed 30cm is quite reasonable (even tiny) for the difference between EKF vs GPS distance) assuming that you are using a hot shoe to get feedback when the camera takes a photo. This can easily be 0.1 seconds (or worse) from the moment you command taking a photo (which always aligns with a new GPS update at the moment).
I'm afraid I can't recall off hand if the M8P came out different then the M8T. At the moment our level of detection is only telling us major versions (ublox 5/6/7/8). If you don't set the parameter value we will select the GPS_DELAY_MS parameter we will attempt to select the best value for a u-blox driver, while any other GPS will just use 0.2 seconds. So what I meant by hardware generation is that we use 0.12 seconds for a ublox 7 or 8, and any other ublox we use 0.22 seconds.
GPSTime is the iTOW, it's timestamps shouldn't be adjusted however you are seeing the timestamp when we actually log a GPS message which does give you a sense of when that actually is arriving.
@ultrafuge Biggest surprise is that 1) should have been as good (or better) then 3 in theory (at least without using an RTK GPS)...
@adam.g BRD_PWM_CNT must be a multiple of 2, 7 won't work, you should see an error print out on the debug console if you had a debug cable attatched.
ArduPilot handles 10Hz messages quite well, and I know that the SBP2 driver that just went in is setup/tested that way. @njoubert whats the requested update rate of the SBP driver?
The external event pin is exactly what you want to be using for this! Ideally you would either be working on an RTK data set, or PPK it first, then you can do exactly the interpolation as you were thinking. You will get better results if you know the internal lag, but this is the best path forward. You just need to manage the interpolation. (Hint: avoid floats for processing, doubles might be okay, but absolutely avoid using a float anywhere in the interpolation )
We should note that the numbers from @ultrafuge's test are the reconstruction errors, and don't actually reflect on the real world (absolute) accuracies, however reducing reconstruction error is always good (although sometimes this can actually just be an excacerbated toilet bowl effect, I don't think that's what you would see with the corrections that were done.
@jero If you are going to do an external solution use the PPS pin. Once we support that in ArduPilot that will be even better but, we aren't there yet. For the record the PPS timing will actually change depending upon hardware version/settings, so it's not the perfect solution, but it is much, much better and still the one we should be chasing.