lies Madness. With such good results from reducing the dlpf filters and the samples per motion, there was once more step: set the gyro dlpf to 0; but that has implications. Setting the gyro dlpf to 0 sets the filter frequency to 250Hz – a good thing, and the delay to 0.97ms – an even better thing. But it also changes the sampling rate of the ADC to 8kHz from the standard 1kHz according to the spec – still fair enough – just a few extra lines of code required…
So what should have resulted was still data samples at 250Hz, but with a lag < 1ms – even higher precision forecasting of Euler angles based on gyro results.
But what I saw was the same 14s ‘flight’ according to the number of sensor reads at 250Hz actually took 19.95s according to time.time(). That’s just plain odd – it suggests the sampling rate was actually ≈175Hz. This corresponds to a sample rate divider of about 48 instead of the 32 it should be (8000/166.66 vs. 8000/250).
I tried to reverse engineer what the divider should be used to get 250Hz sampling, but regardless of the value (I tried 19, 31 and 47), I always got 20s elapsed time flights. Most odd – I think I’ll just shelve gyro dlpf 0 for now.