Arduino with MPU 6050 freezes after a while

Hello All,

I ham working with MPU 6050 and Arduino UNO on my vibration project. The problem is after running the motor the UNO freezes (the TX light turns off) indicating i2c isn't working anymore. I read in the forums that I will have to use a pullup resistor probably, but don't know-how. Can anyone provide the connection schematic?

I don't think there is any problem with my code as well. I am reading the serial monitor Data in Labview.

  1. How can I calculate the sample rate for MPU 6050 if the baud rate is 115200 and requesting 20 bytes of data as a string for LabVIEW?

Please help.

Only you will know if there is a problem in your code since you didn't share it. Motors are usually quite noisy and that can interfere with i2c communication. Since you also did not provide a schematic (even a hand drawn one is fine) it is difficult to say.

Issues could be everywhere in your code or wiring...

To your general question: I2C pull-up are resistor you put in parallel on your SCL and SDA lines to Vcc They are documented all over the web including recommendations on how to choose the resistor value.. let me google an example for you.

I’m not sure this is the issue though. There has been a long heated discussion here (where I found @batata004 being totally off limits) but if you read the very last post from Jeff you’ll see in that summary that there are deficiencies that are hard to overcome and likely point at hardware and software issues in the Arduino Wire library.

If you don’t need DMP then things seems to work fine but if you need DMP then you are at risk of the wire library being locked in an infinite loop.

From personal experience it seems (just observation, I have not explored in deep details) that chances for this to happen increase when there are other interrupts going on and you can’t keep up with the fifo buffer. It means chances for this To happen increase when printing on serial at a fast pace, saturating output buffer and locking code in the print function. I’ve had some success by implementing mitigation techniques to throttle access to outputting data and discard erroneous buffers and not printing stuff out (using the info in a PID process)

How can I calculate the sample rate for MPU 6050 if the baud rate is 115200 and requesting 20 bytes of data as a string for LabVIEW?

At 115200 bauds you send roughly 11 520 bytes per second if there is nothing limiting the data being available for Tx. So 20 bytes would take 20/11520= 1.74ms so you could run say at 500Hz if there are no maths slowing down the code. I2C will also add its own limit (clock speed of 400 KHz) depending how much data you read off your sensor. (From theoretical 8kHz only for the gyrometer and 1kHz for the accelerometer).

But as said above I would expect issues at that frequency so implement a way to Throttle The Tx and optimize the packets’ size (use binary and not ascii or don’t slow down the arduino doing floats computation, just send raw data and do the maths on the other side if possible for example)

I apologise, here is the code attached

#include <Wire.h>
#include <MPU6050.h>

MPU6050 mpu;

void setup()
{
  Serial.begin(115200);

  //  Serial.println("Initialize MPU6050");
  //
  while(!mpu.begin(MPU6050_SCALE_2000DPS, MPU6050_RANGE_2G))
  {
  //    Serial.println("Could not find a valid MPU6050 sensor, check wiring!");
 delay(500);
 }

  // If you want, you can set accelerometer offsets
  mpu.setAccelOffsetX(-18);
  mpu.setAccelOffsetY(-2354);
  mpu.setAccelOffsetZ(1022);

  checkSettings();
}

void checkSettings()
{
  //  Serial.println();
  //
  //  Serial.print(" * Sleep Mode:            ");
  //  Serial.println(mpu.getSleepEnabled() ? "Enabled" : "Disabled");
  //
  //  Serial.print(" * Clock Source:          ");
  switch (mpu.getClockSource())
  {
    case MPU6050_CLOCK_KEEP_RESET:     /*Serial.println("Stops the clock and keeps the timing generator in reset");*/ break;
    case MPU6050_CLOCK_EXTERNAL_19MHZ: /*Serial.println("PLL with external 19.2MHz reference");*/ break;
    case MPU6050_CLOCK_EXTERNAL_32KHZ: /*Serial.println("PLL with external 32.768kHz reference");*/ break;
    case MPU6050_CLOCK_PLL_ZGYRO:      /*Serial.println("PLL with Z axis gyroscope reference");*/ break;
    case MPU6050_CLOCK_PLL_YGYRO:      /*Serial.println("PLL with Y axis gyroscope reference");*/ break;
    case MPU6050_CLOCK_PLL_XGYRO:      /*Serial.println("PLL with X axis gyroscope reference");*/ break;
    case MPU6050_CLOCK_INTERNAL_8MHZ:  /*Serial.println("Internal 8MHz oscillator");*/ break;
  }

  //  Serial.print(" * Accelerometer:         ");
  switch (mpu.getRange())
  {
    case MPU6050_RANGE_16G:             /*Serial.println("+/- 16 g");*/ break;
    case MPU6050_RANGE_8G:             /* Serial.println("+/- 8 g");*/ break;
    case MPU6050_RANGE_4G:              /*Serial.println("+/- 4 g");*/ break;
    case MPU6050_RANGE_2G:              /*Serial.println("+/- 2 g"); */break;
  }


}

void loop()
{
  Vector rawAccel = mpu.readRawAccel();
  Vector normAccel = mpu.readNormalizeAccel();
  float temp = mpu.readTemperature();



  Serial.println(String(normAccel.XAxis) +"\t"+ String(normAccel.YAxis) +"\t"+ String(normAccel.ZAxis) +"\t"+ String(temp));
 
}

Here is the wiring schematic attached

Thank you @J-M-L,

I read the discussion as you stated and turns out it is inconclusive.

They did point point out that, the board freezes because of the serial print function.

Is there a way to work around it? because I have to read the data in Lab view.

Also Is there a schematic I can get about how to connect resistors.

I'm sorry if I am asking for too much, but I need help.

-naik2408

naik2408:
Also Is there a schematic I can get about how to connect resistors.

Did you read the link I posted → page 2.

you don’t have multiplexers / repeaters etc but the idea is the same: your MPU is where they have the first multiplexer basically.

They did point point out that, the board freezes because of the serial print function.
Is there a way to work around it? because I have to read the data in Lab view.

Not exactly: they point out the board freezes because the wire library gets in an infinite while loop due to stuff happening to the I2C line - which might be caused by timing challenges or state machines issues (did not read the buffer fast enough ?) within the MPU.

it would seem that ensuring you have time to read the FIFO buffer in the right way helps, so minimizing what gets send over Serial. how fast really do you need the data in LabView? is 1Hz / 10Hz / 100 Hz acceptable?

working around this issues as you read is complex, you might be better off with another more recent MPU.

PUR.png