The symptoms of the I2C problems I’m seeing are python exceptions from the smbus library; when caught, as well as incrementing the ‘misses’ count, I have code that re-reads the sensors. The trouble is, the I2C exceptions I’m catching are actually symptomatic of a bigger problem: duff data from reads which don’t trigger exceptions. Just one set of duff data results in long lasting errors in angles, acceleration, gravity measurement etc etc etc. Put simply, you can forget any chance of stability in a flight.
I’d solved the problem with Phoebe using the hardware interrupt to trigger the I2C read. And it worked like a dream, and Chloë and Zoë inherited that solution.
But the problem came back with the birth of HoG (using the latest Raspbian distribution) and the swap to the MPU-9250. So I’ve been trying things today to work out what’s gone wrong.
First step was to solder together a couple of pads on the MPU-9250 breakout to connect the pull-up resistor – this should be unnecessary as the Raspberry Pi I2C bus already has a pull-up and adding another could be detrimental. Anyway, there was no change in behaviour – still I2C missing.
Next step was to track down whether it’s the sensor, the code, the A+ or the kernel causing the problem. Zoë still lives in a half-alive state so I could swap SD cards around as see what happened:
- HoG’s SD card @ kernel 3.18.7+ sees I2C read misses with MPU-9250 (HoG’s hardware)
- Zoë’s SD card @ kernel 3.12.28+ sees I2C read misses with MPU-9250 (HoG’s hardware)
- HoG’s @ kernel 3.18.7+ sees zero I2C read misses with MPU-6050 (Zoë’s hardware)
- Zoë’s SD card @ kernel 3.12.28+ sees zero I2C read misses with MPU-6050 (Zoë’s hardware)
That rules out the kernel version, the A+ hardware, and my software. It suggests a problem with the MPU-9250 breakout board, the PCB it’s connected to, the wiring or a long term I2C driver problem that only shows it’s ugly face with the MPU-9250.
My best guess is the I2C barometer on the same breakout; it uses the same bus, but as yet, I’ve not configured it in any way. Perhaps as a result, it’s being noisy as a result, annoying all the other passengers on the bus as a result?
Update: on a whim, I reduced the data rate from 1kHz to 500Hz to allow more time for the sensor data to be read. What I saw was the data rate go up from just under 700Hz to over 700Hz. That suggests the data ready interrupt isn’t working; data is only being made ready at 500Hz, so where are those other pulses coming from?
I had a looking at my custom GPIO code, and a slightly contraversial change I made; I backed this out and tried again. This time, no edge were detected at all!
Something in that area is very dodgy. More tomorrow, no doubt.