Alright, it appears that I’m NOT colliding with reading the FIFO and new data coming in, as I thought earlier. Instead, in a previous loop, the resetting of the FIFO probably snaps off the “head” of some data packet being pushed in by the DMP at the same time. Makes a lot more sense, doesn’t it?
I duplicated the original problem with an Arduino UNO using basically jrowberg’s code out of the box, but by removing the Interrupt handler and replacing it by polling the FIFO_COUNT in the main program loop. After eventually reading the 42-byte data packet from the FIFO, I reset the FIFO. By adding a delay of 30 ms or so into the main loop (beyond the update rate of 10ms), I get the “jitter” effect on the little “teapot” airplane. It’s not severe, but it is detectable and annoying.
Then, I modified the program a little: By polling in a loop and letting the FIFO_COUNT go up to 400-something before reading the FIFO data and resetting it, I can see the FIFO_COUNT increase like this:
Multiples of 42 for reference: 42, 84, 126, 168, 210, 252, 294, 336, 378, 420, 462, 504, 546
... FIFO while waiting: 126 FIFO while waiting: 294 FIFO while waiting: 420 FIFO before reading: 546 Resetting FIFO FIFO while waiting: 154 FIFO while waiting: 294 FIFO while waiting: 420 FIFO before reading: 546 Resetting FIFO FIFO while waiting: 136 FIFO while waiting: 262 FIFO while waiting: 388 FIFO before reading: 514 --> Glitch: Read quaternion magn. not 1 Resetting FIFO FIFO while waiting: 126 FIFO while waiting: 252 FIFO while waiting: 378 FIFO before reading: 504 Resetting FIFO ...
This shows that the increasing FIFO_COUNT before the glitch keeps showing an offset of 10 bytes, but I can’t trust it to always be some constant value when polling.
I don’t really have a solution for this, as I want to read 20 totally unsynchronized sensors at the same time, but at least the problem got re-defined.