Some DMP troubles – part 2

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.


6 thoughts on “Some DMP troubles – part 2

  1. What solved the same problem for me (and I search some days:o):
    Sometime hangs, sometimes byte shift.
    Byte shift seems to happen, if my rate is to high (I have an additional LCD with long cables on the i2c)

    Somethings seems to get messed up with the interrupts so lets disable them and pull.

    mpu.setRate(9); //100 Hz
    mpu.setIntEnabled(false); //disable Interrupts

    void checkMPU()

    fifoCount = mpu.getFIFOCount();

    // there are sometimes left over data (fifoCount not multiple of packetSize)(see global byte shift problem), if we got this reset fifo
    if (fifoCount % packetSize != 0)

    //Fifo ran full, try mpu.setRate(int) // 1khz / (1+ rate)
    if (fifoCount >= 1024)
    fifoCount = 0;

    // while we have more than 42 bytes, lets get ALL packets
    while (fifoCount >= packetSize)
    // read a packet from FIFO
    mpu.getFIFOBytes(fifoBuffer, packetSize);

    //fifoCount -= packetSize; Thats may not be true, because data are coming and coming
    fifoCount = mpu.getFIFOCount();
    proccessVals(); // do your axis magic

    May this can help someone too,
    Cya Rene

  2. Hey!
    Have you found out what is causing this corrupted data?
    I’ve been dealing with the same issues using 2 MPUs, every now and then a corrupted “quaternion” appears. I’ve been having good results adding small delays after resetting the FIFO in each read, but it’s not 100% fault free.

  3. Hello, I have the same problem with 9250 fifo.
    I am using row data under SPI protocol (linux banana pi)
    And sometimes I get glitches….
    Do you have any new findings ?

    • Hi. Unfortunately I don’t. This project has been on the back burner for way too long. Also, I haven’t tried using the MPU under linux yet.. There seem to be a couple of libraries for linux / the Raspberry Pi out there. Are you using one of those? My guess is, that linux isn’t always able to respond to timing critical events fast enough (like reading some data immediately after the MPU pulses the interrupt pin) if something like that should be required.

  4. Have you tried ti connect the AD0 pin directly to ground or vcc? Most shields use a pull down or pullup weak enough so that an inductive spike messes up with the mpu i2c address!

    • Oh, man.. Not yet, because the shield/breakout board works fine with the jrowberg’s example code. Only when I tried to use my own bit-banging I2C/TWI implementation, I got into trouble. This is most likely because I couldn’t respond to the interrupt signal immediately and was still communicating (as in issuing a FIFO reset) with the MPU as it already made the next quaternion sample available… The demo code from jrowberg managed to do it’s thing just about within the 10 ms time frame of the continuous stream of the MPU’s interrupt signals.

      However, thank you very much for the suggestion, as this is something I really wouldn’t have thought of and I’ll certainly pay attention to this in the future! This tip could save days in troubleshooting any I2C chip 🙂

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s