The FIFO solution which should address all the problems of corrupted and lost data, along with accurate timings has failed. There are multiple factors:
The MPU-6050 FIFO isn’t a real FIFO as I know it – the amount of data in the FIFO doesn’t decrement as you read from the FIFO. That means the FIFO needs to be emptied and then reset. And that means the data read needs to be stored in another FIFO in my code. Also the enforced FIFO reset means potential loss of data if new data arrived in the small gap between emptying the FIFO and resetting it – and in testing, I’ve seen this happen. And this is a real problem; each batch of sensor data is 12 bytes long (3 axes * 2 bytes * (accelerometer + gyro)). Lose a byte or two of accelerometer data in the FIFO read / reset gap, and all of a sudden, data read from the FIFO as accelerometer readings now contains gyro readings. In addition, the FIFO is read byte by byte. That means 12 1 byte reads for a full batch of data compared to 1 14 byte read directly from the data registers. The latter is a lot more efficient – in fact the 12 x 1 byte reads are so slow that the FIFO is filling up faster than the data can be read, and starts overflowing; yes I can reduce the sampling rate (and I did to 500Hz) and that improved matter but, to cap it all, there are still I2C bus errors which means FIFO data can still get lost, again shifting the data so the gyro data slips into what ought to accelerometer data readings. Put together, the FIFO doesn’t stand a feline in the fire’s chance of working.
Which means I need to drop back to plan A – PyPy. I think the problem here is the PyPy I2C code which is out of date in the Raspberry Pi Raspian distribution. I’m hoping someone reading this blog can encourage the RPF to update the distribution to include the latest copy of PyPy and it’s I2C / smbus library – please 🙂
Until / unless that happens, I’m stuck again with Phoebe and Chloe all dressed up and nowhere to go.