MPU 6050(A) module problems - WHO_AM_I reports 0x98, not 0x68 as it should. Fake MPU 6050

I'm trying to use an MPU-6050 with the Arduino library and not having a lot of luck. I've read similar threads here but none have resolved my issue. I have it wired correctly with 5v to the GY512 board, letting the onboard 3.3v regulator supply the chip. I have the I2C outputs going through a bi-directional level shifter before connection to the Arduino UNO I2C pins. When I run the I2C scanner it comes up with:

I2C Scanner
I2C device found at address 0x68 !

So it appears the I2C is working as it should and it finds the MPU 6050 at the expected default address (0x68).

However, when do the "WHOAMI" test (6050 register 0x75), it comes back with 0x98, not 0x68. This seriously screws up most of the sample sketches which are looking for a 0x68 response and enter into a fault mode if they don't find it. It's possible the 6050 libraries also do this check, because most of the sketches using the 6050 library don't work either.

The 6050 does indeed appear to be at 0x68 since I can talk to it there and get some sort of reasonable looking data back. Sketches that assume it's at 0x68 and talk directly to it without using 6050 libraries seem to yield numbers that respond in the way you might predict when the 6050 is rotated.

0x68 (1101000) and 0x98(100011000) don't seen to have a simple relationship other than having the 4 LSB the same.

Is it possible I have a bad (clone) MPU 6050? I have no idea how it generates it's WHOAM! response. The datasheet isn't a lot of help...

This register is used to verify the identity of the device.
The contents of WHO_AM_I are the upper 6 bits of the MPU-60X0’s 7-bit I2C address.
The least significant bit of the MPU-60X0’s I2C address is determined by the value of the AD0 pin. The value of the AD0 pin is not reflected in this register.
The default value of the register is 0x68.
Bits 0 and 7 are reserved. (Hard coded to 0)

According to that (Bit 0 and Bit 7 hard coded to zero), you can't get a 0x98 response!

Has anyone heard a 6050 acting in this way?I can't really think of any other explanation for WHOAMI returning the wrong address.

I was getting very frustrated with nothing working right until I looked at the WHOAMI response.

Here's the WHOAMI code:

#include <Wire.h>

#define MPU6050_I2C_ADDRESS 0x68   // Default MPU-6050 address
#define MPU6050_WHO_AM_I 0x75      // R Who am I address

void setup()
  Wire.begin();        // Initiate wire library
  Serial.begin(9600);  // Initiate serial port 
  WhoAmI();            // Verifies identity of device
void loop()

void WhoAmI(){
  uint8_t waiByte;                                    // Data will go here
  MPU6050_Read(MPU6050_WHO_AM_I, &waiByte);           // Get data
  Serial.print(F("Device WhoAmI reports as: 0x"));    // 
  Serial.println(waiByte,HEX);                        // Report WhoAmI data

void MPU6050_Read(int address,uint8_t *data){            // Read from MPU6050. Needs register address, data array
  int size = sizeof(*data);                              //
  Wire.beginTransmission(MPU6050_I2C_ADDRESS);           // Begin talking to MPU6050
  Wire.write(address);                                   // Set register address
  Wire.endTransmission(false);                           // Hold the I2C-bus
  Wire.requestFrom(MPU6050_I2C_ADDRESS, size, true);     // Request bytes, release I2C-bus after data read
  int i = 0;                                             //
  while(Wire.available()){                               //
    data[i++];                               // Add data to array

and here's what I get back

Device WhoAmI reports as: 0x98

Can you please post the code that you use with the Library.
I don't think you need a level changer with the MPU5060.
Have you tried 4K7 pullup resistors in the two I2C lines.

Have you looked here.

Thanks.. Tom.. :grinning: :+1: :coffee: :australia:

If you bought a cheap Chinese module on Amazon, Alibaba, etc., the chances are extremely high that you have a counterfeit or reject chip.

68 is the I2C address the other number is one of several that can be returned by reading the registers on the MPU6050. Some libraries account for the various WHOAMI register return values and others do not. You can look in the libraries cpp file and add an or to the address being returned to the WHOAMI checking routine.

Most likely you'll get about 100 hours of continuous operation from the module before it wears out. About enough time for you to decide that the MPU6050 is not so good. In the end though, digging through the library is a great learning experience.

I'm not sure how the WHOAMI request can return anything but 0x68 . The register map documentation ( specifically states that it contains the upper 6 bits of the 7 bit I2C address and that the 0 and 7 bits are reserved and hard codes to zero. If the IC2 address is 0x68 (which it is and where the I2C finder finds it), then the response from the WHOAMI request has to be 0x68 as if I'[m reading the do0cumentation correctly. If there is some way in which it can be different and some way in which the bit 7 can be a 1 (which it is when the response is 0x98), then I'd like to know how that can happen - if the device is not faulty.

Though you don't absolutely need level shifters, they are a good idea. Otherwise you are depending on the fact that you may be pulling up the level of the 6050 I2C output to 3.3v, which is only 300 mV over the minimum required by the Arduino for a "high" (assuming a 5.0v supply) to the Arduino. You can get away with it if connections are short and noise free, but in general it's not a great idea. Without the level shifter I still see the same anomalous response to the WHOAMI request.

The code in the tutorial example does work, but that's because it doesn't do a WHOAMI check and it doesn't use any MPU6050 library.

When I run the WHOAMI code on a Nano and then on a UNO, both with no I2C connection

Both return.

Device WhoAmI reports as: 0x3F

Tom... :grinning: :+1: :coffee: :australia:

Hi, @KA1GT
Can you please post a picture of your project?

Have you tried 4K7 pull-up resistors on on the two I2C lines?

Tom... :grinning: :+1: :coffee: :australia:


So what iswrong with adapting the example code"

Tom... :grinning: :+1: :coffee: :australia:

The WHO_AM_I is 0x68 of course, unless you have an other chip. Sometimes a similar chip is put on a module, an other genuine chip or a counterfeit or something else.

Could you try again with minimal code ?

Code not tested.

// WHO_AM_I is 0x68

#include <Wire.h>

void setup()
  Serial.println( "The sketch has started");

void loop()
  Wire.beginTransmission( 0x68);
  Wire.write( 0x75);
  int n = Wire.requestFrom( 0x68, 1);
  if( n == 1)
    int data =;

    Serial.print( "0x");
    Serial.println( data, HEX);
    Serial.println( "Sensor not found");

  delay( 1000);

[UPDATE] I have tested this code

void some_function( uint8_t *data)
  int size = sizeof(*data);
  Serial.println( size);

and it does indeed return 1. However, everyone else uses a integer for the number of bytes to read.

Your sketch runs and generates:

The sketch has started

The chip is marked as an InvenSense MPU 6050A, but of course that means nothing. It's just what's written on the chip and there are lots of Chinese chip "clones" out there.


I'm not sure what the significance of the "A" is, but I've seem "A", "C" and I think "M" designations on the 6050. I assume it's some sort of packaging code? I don't know that I've ever seen a close up picture of a genuine Invensense MPU-6050 to compare it with. I suspect many of the GY-521 boards use "fake" chips, but I've never heard of one that reported an incorrect (and impossible) address.

The problem with adapting code to compensate for the bad reported address is (a) it could be anywhere in the libraries and of course an adapted library wouldn't be of much use with any 100% working chips. I'd rather junk this one and try again, if it's bad, and (b), if this is wrong, who knows what else is wrong!

Did you try the 4k7 pullup resistors?

Tom.... :grinning: :coffee: :coffee: :coffee: :coffee: :australia:

Thank you for running my test.
Someone at reddit has the same problem, but without solution.

I grabbed a photo from Adafruit and enhanced it. This is a real MPU-6050:
I don't see a big difference with your photo.

My guess is that it is either a counterfeit or Invensense made a special version for a customer.
The MPU-6050 is outdated and noisy. I suggest to buy a better sensor.

No longer even manufactured, since about two years. There are much better sensors available now.

I now have a report from Germany from a friend of mine, who is also experiencing EXACTLY the same problem and seeing. A WHOAMI response of 0x98 and exactly the same set of program failures that I am. Seems like these chips are now loose in the wild and will be causing countless headaches for those unfortunate enough to receive them. Some of the available code will work, some won't. I'm not yet sure that there are not other subtle differences, since even after modifying sketches for the 0x98 reply, they don't seem to give quite the expected behavior. Some sketches seem to work OK. It;s going to be tough to figure out who is selling what if sources in both the US and Germany have them. Any Chinese made board (95% of what's out there) is even more of a gamble than it always was.

@KA1GT, could you change the topic title ? Something with "MPU-6050", "WHOAMI" or "who_am_i" and 0x98 ? Then others with the same problems will find this topic easier.

Invensense made a ICM-20689 sensor:
It is a improved version of the MPU-6050 and it seems to be backward compatible with the MPU-6050.
The WHOAMI of the ICM-20689 is also in register 0x75 and is 0x98 :exclamation:

So far so good.
The problem is that the ICM-20689 sensor or a counterfeit is labeled "MPU-6050A" and is sold as a MPU-6050.

Stop buying MPU-6050 modules.

They are worthless trash, and the trash is where you should be putting yours, right away.


I wouldn't say it's worthless trash (though it can be an incredible waste of time!). I just doesn't work with many sketches written for the 6050, especially any using the Arduino MPU6050 libraries which do a check that the WHO_AM_I request returns a 0x68 and then generate an error when it returns a 0x98.

It looks pretty likely that it's an ICM-20689. The WHO_AM_I is in the same place with a 0x98 value as Koepel correctly pointed out (thanks). It also has it's offset registers in a different location, which might explain why all the calibration programs seem to fail!

Presumably it would be fine if there was a library for the ICM-20689, or of you program it via direct register access for the 20689

Do you have a suggestion for a similar 3-axis accelerometer module with 16-bit IC2 output that contains a genuine chip and for which there are functional Arduino libraries?

This accelerometer/gyro module is considerably improved over the long obsolete and discontinued MPU-6050.

Unlike the MPU-6050, it runs on any voltage between 2.5V and 5.5V, so you don't have an interface problem with 5V Arduinos.