I’d like to preface that I am relatively new to Arduino, and am definitely new to forum-posting. But I’ve done some preliminary research on some how-tos on how to wire an MPU-6050 to an Arduino via I2C.
Anyways, for my particular project, I wanted to utilize 2 MPU-6050s to an Arduino Uno, in the hope of making the data more accurate. I’ve learned to keep note of the addresses according to the AD0 pin when wiring two of these. This is so that the Arduino knows which one it’s communicating to via I2C. When pulled to high, in my case feeding a parallel 3.3v signal to AD0, the address is 0x69; if pulled to ground, 0x68. But when I tried my hodgepodge coding, the 0x68 MPU outputs relatively normal values, if you think ~ 9.1 m/s^2 is good enough. But 0x69 MPU always seems to have more outlandish and more amplified values, going up as far as ~ 10 m/s^2. I’m not sure what is going on there. I thought going to the moon and back was alright /s.
I did some basic troubleshooting to find the fault in the source. It does not seem to be a burnt pin on the Arduino, though I’m not married to it. But when I swapped each of the SDA and SCL lines of the 2 MPUs (which shouldn’t change the address), it was the same 0x69 MPU that gave away crappy numbers. I resoldered my VCC and AD0 (both of which are connected in parallel) of both MPUs from 5v to 3.3v. I read in the Arduino documentation of the MPU6050 that AD0 needed 3.3v, but without evidence that 5v would be detrimental. This didn’t change anything. Here, I suspected that I burned my MPU seeing that I might’ve overloaded my AD0 pin with 5v, so I swapped the old 0x69 MPU with a new one, and the same effect happened but with arguably worse values, with +/- z going up to 20,000 (at its most sensitive, mind you; multiplying by (9.8 / 16384) gives me almost 12 m/s^2).
I suspect that I burned my MPUs, given that swapping still gave me broken data. And this problem might have to do with how I’ve wired my MPUs up, i.e. I did not solder a pull-down resistor to any of my pins, so it may just be a case of overcurrent when the pins couldn’t handle it. As another side note, I might do another test by temporarily disabling the normal-working 0x68 MPU and pull the 0x69 MPU AD0 pin to low, to effectively swap their addresses, to confirm that pulling AD0 to high was the problem. I don’t think I should, until I’ve heard from all of you.
As it stands, the connections are as follows:
- GND and AD0 are connected in parallel
VCC and AD0 are connected in parallel
the VCC and GND pins are also powered in parallel from the 3v3/GND of the Uno
I can also share the sketch I’ve made, just in case my code was bad. But I’ve also tried other sketches that effectively records the same data, but only changing the address in the Serial.beginTransmission() functions, and the same 0x69 MPU keeps acting up. Here, I left the recording sensitivity of the MPU at its most sensitive (+/- 8g). I could also change this to see if it does anything.
There are pictures below of the MPUs:
*1 S3162444 (2).jpg is the 0x68 MPU, so the other is the 0x69 MPU
Let me know if you guys need more information, but thanks for your attention.
- I’m almost ready to get more MPU9250s. I had 2 of those and 4 of the 6050 variant for the longest time and I wanted to use materials I already had.