Yeah today after work I’m going to hook the mpu sensor up to an Arduino and make a test sketch and see if the Arduino will find the sensor or not so i can try to rule something out
Did you find a solution. I have a very similar or the same problem.
I have a MPU-6050 Accelerometer. and i am struggling since days to get it to work with klipper. I get “invalid MPU id (got 72)” in klipper. i tried different cable and length.
what realy bugs me is that the Raspi (4B) sees the sensor and i can also read it with some simple python code that i found on GitHub.
why is it that the pi can see and read the sensor but klipper can not?
An I2C device announces itself on the bus with a certain device ID (WHO_AM_I).
For the MPUxxxx series, Klipper supports the following device IDs:
| MPU ID | MPU-xxxx |
|---|---|
| 0x74 | MPU-9515 |
| 0x73 | MPU-9255 |
| 0x71 | MPU-9250 |
| 0x70 | MPU-6500 |
| 0x68 | MPU-6050 |
Any other IDs are unusual and potentially point to a defect or even counterfeit chip.
There are just enough reports out there on such chips with unusual IDs, e.g. Counterfeit MPU6050 chips from China - Page 1
Personally, I would not rely on such a chip even if you get some values from it.
Thanks for the reply.
Yeah I read about the China Chips. I bought mine at Berrybase so I thought it should be ok.
It has not obvious Branding like I found on some pictures online. But on the other side, who knows if that pics where from legit items.
Mine Registers as 0x68 so everything is working.
Just that klipper does not want to work
This is weird since the Klipper error message identifies it as 0x72 and not 0x68. On the Klipper machine, what is the output of i2cdetect -y 0 (or 1 depending on the bus you are using)
Maybe also check i2cdump -y 0 0x68 (or 1 depending on the bus you are using) respectively i2cdump -y 0 0x72
Please post formatted as code
thanks agian for your reply!
Just to clarify this agian.
I connected it like in this picture from the Klipper Docu for MPU_6050:
And this is the accelerometer i am using:
i have already ordered some new cables and Sensors
ADXL345 3-Achsen GY-291 . Sry can not post more links as new user.
This is the output for sudo i2cdetect -y 1
david@octopi:~ $ sudo i2cdetect -y 1
0 1 2 3 4 5 6 7 8 9 a b c d e f
00: -- -- -- -- -- -- -- --
10: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
20: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
30: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
40: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
50: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
60: -- -- -- -- -- -- -- -- 68 -- -- -- -- -- -- --
70: -- -- -- -- -- -- -- --
From the output for Bus “0” i guess i am using Bus “1” (i dont know exactly how to confirm this otherwise)
david@octopi:~ $ sudo i2cget -y 0 0x68
Error: Could not open file `/dev/i2c-0' or `/dev/i2c/0': No such file or directory
For your Suggestions i get:
david@octopi:~ $ sudo i2cdump 1 0x68
No size specified (using byte-data access)
WARNING! This program can confuse your I2C bus, cause data loss and worse!
I will probe file /dev/i2c-1, address 0x68, mode byte
Continue? [Y/n] y
0 1 2 3 4 5 6 7 8 9 a b c d e f 0123456789abcdef
00: 81 04 81 8c 8c 8a e4 12 f0 8a 23 a3 00 65 5f 78 ??????????#?.e_x
10: c1 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ?...............
20: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
30: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
40: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
50: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
60: 00 00 00 00 00 00 00 00 00 00 00 40 00 00 00 00 ...........@....
70: 00 00 00 00 00 72 00 00 00 00 00 00 00 00 00 00 .....r..........
80: 81 04 81 8c 8c 8a e4 12 f0 8a 23 a3 00 65 5f 78 ??????????#?.e_x
90: c1 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ?...............
a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
e0: 00 00 00 00 00 00 00 00 00 00 00 40 00 00 00 00 ...........@....
f0: 00 00 00 00 00 72 00 00 00 00 00 00 00 00 00 00 .....r..........
david@octopi:~ $ sudo i2cdump -y 1 0x72
No size specified (using byte-data access)
0 1 2 3 4 5 6 7 8 9 a b c d e f 0123456789abcdef
00: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XXXXXXXXXXXXXXXX
10: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XXXXXXXXXXXXXXXX
20: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XXXXXXXXXXXXXXXX
30: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XXXXXXXXXXXXXXXX
40: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XXXXXXXXXXXXXXXX
50: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XXXXXXXXXXXXXXXX
60: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XXXXXXXXXXXXXXXX
70: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XXXXXXXXXXXXXXXX
80: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XXXXXXXXXXXXXXXX
90: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XXXXXXXXXXXXXXXX
a0: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XXXXXXXXXXXXXXXX
b0: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XXXXXXXXXXXXXXXX
c0: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XXXXXXXXXXXXXXXX
d0: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XXXXXXXXXXXXXXXX
e0: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XXXXXXXXXXXXXXXX
f0: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XXXXXXXXXXXXXXXX
Thanks again for any help!
P.S.
This is my Klippy.log.
klippy (3).log (398.7 KB)
and the link to the new Sensor:
https://www.amazon.de/gp/product/B0987T1GS8/ref=ppx_yo_dt_b_asin_title_o02_s00?ie=UTF8&psc=1
i will try the new sensor on Wednesday. maybe this fixes my problem.
but its still not understandable for me why this is not working right now
P.P.S:
I read out the values via the python script and looked at it a bit closer. i realized that the Z Gyro values are very irregular, although the sensor is laying still on the table. all other values are very close to each other. could this be the problem.
Your chip is showing a WHO_AM_I of 0x72 at the relevant register 0x75 and expected are the values as shown above in the table.
I have found one reference here: drivers/iio/imu/inv_mpu6515/inv_mpu_iio.h - kernel/msm - Git at Google
Allegedly this is a MPU-9350, but the TDK web page does not list this chip.
What you could try just for fun:
Modify klipper/klippy/extras/mpu9250.py to include
0x72: "mpu-9350",
then restart Klipper with systemctl restart klipper
1 Like
thanks so much for your help again!
i tried this and its now working!
i will try the resonance test with it working now.
just for the future: will this work after an update to klipper?
should there be put into klipper?
im pretty new to all this so would not know how to do it. but maybe it would help others.
i know its probably not the right place to ask, but as i am curious:
why is the sensor 0x72 when it shows 0x68 in the icedetect command?
No, after an update it will be gone.
I’m not sure, if this is a valid change actually as the WHO_AM_I seems fishy at best due to the lack of information
While I’m not an expert for the I2C, my understanding is:
- 0x68 is the address on the bus and depending on the device type certain address ranges are reserved / allocated
- 0x72 is the device ID (WHO_AM_I register) that is programmed into the device as kind of type identification
1 Like