Cannot read values from PU-6050 connected to Pi

[Björn Lundin]

Hi!
I got a GY-521 (or MPU-6050) for reading movement.
I connect it to pin 1,3,5,6 (vcc, SDA, SCL, Ground) as most tutorials
suggest.
I have enabled I2C
I find the device with

pi@raspberrypi:~ $ 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: -- -- -- -- -- -- -- --

I can read the device id
pi@raspberrypi:~ $ sudo i2cget -y 1 0x68 0x75
0x68

but I get 0x00 for the x/y/z and ax/ay/az values whatever I do
pi@raspberrypi:~ $ sudo i2cget -y 1 0x68 0x44
0x00
pi@raspberrypi:~ $ sudo i2cget -y 1 0x68 0x43
0x00
pi@raspberrypi:~ $ sudo i2cget -y 1 0x68 0x3b
0x00
pi@raspberrypi:~ $ sudo i2cget -y 1 0x68 0x3c
0x00


using
https://raw.githubusercontent.com/Tijndagamer/mpu6050/master/mpu6050/mpu6050.py
I get
pi@raspberrypi:~ $ sudo python mpu6050.py
36.53
Traceback (most recent call last):
File "gyro_test.py", line 247, in <module>
accel_data = mpu.get_accel_data()
File "gyro_test.py", line 139, in get_accel_data
x = self.read_i2c_word(self.ACCEL_XOUT0)
File "gyro_test.py", line 71, in read_i2c_word
high = self.bus.read_byte_data(self.address, register)
IOError: [Errno 121] Remote I/O error

So it reads temp, but get 0 back (get_temp adds 36.53)
and crashes on reading ACCEL_XOUT0 which is 0x3B.
Which was read to 0 by i2cget, unless that handles read error of course.



pi@raspberrypi:~ $ cat /etc/modules
# /etc/modules: kernel modules to load at boot time.
#
# This file contains the names of kernel modules that should be loaded
# at boot time, one per line. Lines beginning with "#" are ignored.

i2c-dev
i2c-bcm2708


pi@raspberrypi:~ $ grep blacklist /etc/modprobe.d/*
/etc/modprobe.d/blacklist-rtl8192cu.conf:blacklist rtl8192cu
/etc/modprobe.d/blacklist-rtl8xxxu.conf:blacklist rtl8xxxu
/etc/modprobe.d/fbdev-blacklist.conf:# This file blacklists most
old-style PCI framebuffer drivers.
/etc/modprobe.d/fbdev-blacklist.conf:blacklist arkfb
/etc/modprobe.d/fbdev-blacklist.conf:blacklist aty128fb
/etc/modprobe.d/fbdev-blacklist.conf:blacklist atyfb
/etc/modprobe.d/fbdev-blacklist.conf:blacklist radeonfb
/etc/modprobe.d/fbdev-blacklist.conf:blacklist cirrusfb
/etc/modprobe.d/fbdev-blacklist.conf:blacklist cyber2000fb
/etc/modprobe.d/fbdev-blacklist.conf:blacklist kyrofb
/etc/modprobe.d/fbdev-blacklist.conf:blacklist matroxfb_base
/etc/modprobe.d/fbdev-blacklist.conf:blacklist mb862xxfb
/etc/modprobe.d/fbdev-blacklist.conf:blacklist neofb
/etc/modprobe.d/fbdev-blacklist.conf:blacklist pm2fb
/etc/modprobe.d/fbdev-blacklist.conf:blacklist pm3fb
/etc/modprobe.d/fbdev-blacklist.conf:blacklist s3fb
/etc/modprobe.d/fbdev-blacklist.conf:blacklist savagefb
/etc/modprobe.d/fbdev-blacklist.conf:blacklist sisfb
/etc/modprobe.d/fbdev-blacklist.conf:blacklist tdfxfb
/etc/modprobe.d/fbdev-blacklist.conf:blacklist tridentfbonme
/etc/modprobe.d/fbdev-blacklist.conf:blacklist vt8623fb



pi@raspberrypi:~ $ grep i2 /boot/config.txt
dtparam=i2c_arm=on
dtparam=i2s=on
dtparam=i2c1=on



pi@raspberrypi:~ $ uname -a
Linux raspberrypi 4.9.35+ #1014 Fri Jun 30 14:34:49 BST 2017 armv6l
GNU/Linux



The above is from a pi Zero, I get the same result with a Pi 1b+
Anyone have any suggetions


--
--
Björn

[jack...@gmail.com]

so you can communicate wiith the device, but the device seems not working correctly.
Either is broken or you need the read the datasheet of the device in order to learn how to set it up so it starts takeing measurements.

Bye Jack

[Björn Lundin]

On 2017-11-06 08:57, jack...@gmail.com wrote:

> so you can communicate wiith the device, but the device seems not working correctly.
> Either is broken or you need the read the datasheet of the device in order to learn how to set it up so it starts takeing measurements.

Hmm, I guess it is broken then.
I'll ask the vendor for a replacement
Thanks

--
--
Björn

[Gordon Henderson]

In article <otl47d$mid$1...@dont-email.me>,

Björn Lundin <b.f.l...@gmail.com> wrote:
>pi@raspberrypi:~ $ sudo i2cget -y 1 0x68 0x75
>0x68
>
>but I get 0x00 for the x/y/z and ax/ay/az values whatever I do
>pi@raspberrypi:~ $ sudo i2cget -y 1 0x68 0x44
>0x00
>pi@raspberrypi:~ $ sudo i2cget -y 1 0x68 0x43
>0x00
>pi@raspberrypi:~ $ sudo i2cget -y 1 0x68 0x3b
>0x00
>pi@raspberrypi:~ $ sudo i2cget -y 1 0x68 0x3c
>0x00

I've not used this device, but in emails with others what I gather is that
you need to make sure it's not in self-test mode and that the registers
(scaling, etc.) are set correcty, and that it's not in sleep mode, then
trigger it to take a sample. Until then, the default values are all zeros.

Or put it into continuous sample mode.

So go and read the fine manual before writing it off!

-Gordon

[Tony van der Hoff]

On 06/11/17 10:32, Gordon Henderson wrote:
> In article <otl47d$mid$1...@dont-email.me>,

You have to send it a wake-up signal. Write a 0 to register 0x6b.

See
http://blog.bitify.co.uk/2013/11/reading-data-from-mpu-6050-on-raspberry.html
for a python program

Cheers, Tony

[jack...@gmail.com]

My guess is that you don't setup the device for correct operation (and from what you posted, even the python script) you don't.

Read the manual.

Bye Jack

[Björn Lundin]

Den 2017-11-06 kl. 12:14, skrev Tony van der Hoff:

>>
>> I've not used this device, but in emails with others what I gather is that
>> you need to make sure it's not in self-test mode and that the registers
>> (scaling, etc.) are set correcty, and that it's not in sleep mode, then
>> trigger it to take a sample. Until then, the default values are all zeros.
>>
>> Or put it into continuous sample mode.
>>
>> So go and read the fine manual before writing it off!
>>
>> -Gordon
>>
>
> You have to send it a wake-up signal. Write a 0 to register 0x6b.
>
> See
> http://blog.bitify.co.uk/2013/11/reading-data-from-mpu-6050-on-raspberry.html
> for a python program
>

Thanks for the hints.
I downloaded the code and adjusted for bus 1
pi@raspberrypi:~ $ sudo python gt.py
gyro data
---------

Traceback (most recent call last):

File "gt.py", line 46, in <module>
gyro_xout = read_word_2c(0x43)
File "gt.py", line 20, in read_word_2c
val = read_word(adr)
File "gt.py", line 15, in read_word
low = bus.read_byte_data(address, adr+1)

IOError: [Errno 121] Remote I/O error

this is using 0x6 as the data sheet and other web-pages suggests.
Changing to use 0x6c as wake-up (as the code suggests)
I get no crash but just zeros

pi@raspberrypi:~ $ sudo python gt.py
gyro data
---------
gyro_xout: 0 scaled: 0
gyro_yout: 0 scaled: 0
gyro_zout: 0 scaled: 0

accelerometer data
------------------
accel_xout: 0 scaled: 0.0
accel_yout: 0 scaled: 0.0
accel_zout: 0 scaled: 0.0
x rotation: 0.0
y rotation: -0.0



I think I'll try it in an arduino uno before I return it.



--
--
Björn

[jack...@gmail.com]

Il giorno mercoledì 8 novembre 2017 19:50:17 UTC+1, Björn Lundin ha scritto:
> Den 2017-11-06 kl. 12:14, skrev Tony van der Hoff:
>
> >>
> >> I've not used this device, but in emails with others what I gather is that
> >> you need to make sure it's not in self-test mode and that the registers
> >> (scaling, etc.) are set correcty, and that it's not in sleep mode, then
> >> trigger it to take a sample. Until then, the default values are all zeros.
> >>
> >> Or put it into continuous sample mode.
> >>
> >> So go and read the fine manual before writing it off!
> >>
> >> -Gordon
> >>
> >
> > You have to send it a wake-up signal. Write a 0 to register 0x6b.
> >
> > See
> > http://blog.bitify.co.uk/2013/11/reading-data-from-mpu-6050-on-raspberry.html
> > for a python program
> >

the program in the page doesn't initialize the device.
It's normal that it returns zeros.

Check here, the initialize function:
https://github.com/jrowberg/i2cdevlib/blob/master/Arduino/MPU6050/MPU6050.cpp

Bye Jack

[Björn Lundin]

On 2017-11-09 08:56, jack...@gmail.com wrote:
>>>
>>> You have to send it a wake-up signal. Write a 0 to register 0x6b.
>>>
>>> See
>>> http://blog.bitify.co.uk/2013/11/reading-data-from-mpu-6050-on-raspberry.html
>>> for a python program
>>>
>
> the program in the page doesn't initialize the device.
> It's normal that it returns zeros.
>
> Check here, the initialize function:
> https://github.com/jrowberg/i2cdevlib/blob/master/Arduino/MPU6050/MPU6050.cpp
>
> Bye Jack
>

Ok, so I tried numerous python and c++ code (but for the one above -
needs arduino)
I also read that they MUST have 3.3v - but then again, someone wrote
that they can not work properly at 3.3 v - needs 5 v and voltage
regulator fixes it. Tried that too - luck

The chip is cheap so I ordered two more.
And I'll try to get my arduino nano work with it.

Thanks so far for all suggestions
--
--
Björn

[Björn Lundin]

On 2017-11-10 09:13, Björn Lundin wrote:
> I also read that they MUST have 3.3v - but then again, someone wrote
> that they can not work properly at 3.3 v - needs 5 v and voltage
> regulator fixes it. Tried that too - luck

That was supposed to be NO luck :-(


--
--
Björn

[Martin Gregorie]

On Fri, 10 Nov 2017 09:13:47 +0100, Björn Lundin wrote:

> On 2017-11-09 08:56, jack...@gmail.com wrote:
>>>>
>>>> You have to send it a wake-up signal. Write a 0 to register 0x6b.
>>>>
>>>> See
>>>> http://blog.bitify.co.uk/2013/11/reading-data-from-mpu-6050-on-
raspberry.html
>>>> for a python program
>>>>
>>>>
>> the program in the page doesn't initialize the device.
>> It's normal that it returns zeros.
>>
>> Check here, the initialize function:
>> https://github.com/jrowberg/i2cdevlib/blob/master/Arduino/MPU6050/
MPU6050.cpp
>>
>> Bye Jack
>>
>>
>
> Ok, so I tried numerous python and c++ code (but for the one above -
> needs arduino)
> I also read that they MUST have 3.3v - but then again, someone wrote
> that they can not work properly at 3.3 v - needs 5 v and voltage
> regulator fixes it. Tried that too - luck
>

You "also read that" they must have that voltage?

Have you got a data sheet for the MPU-6050 and if not, why not? It is not
exactly hard to find: the 3rd item on the first page of search results
for "MPU-6050" is:

https://www.invensense.com/wp-content/uploads/2015/02/MPU-6000-
Datasheet1.pdf

Get it, read it, and you'll KNOW whether the supply voltage from an RPi's
expansion bus is in the required range as well as a lot more detail about
how to configure and use it correctly.



--
martin@ | Martin Gregorie
gregorie. | Essex, UK
org |

[Björn Lundin]

On 2017-11-13 11:20, Martin Gregorie wrote:
>
> Have you got a data sheet for the MPU-6050 and if not, why not? It is not
> exactly hard to find: the 3rd item on the first page of search results
> for "MPU-6050" is:
>
> https://www.invensense.com/wp-content/uploads/2015/02/MPU-6000-
> Datasheet1.pdf
>
> Get it, read it, and you'll KNOW whether the supply voltage from an RPi's
> expansion bus is in the required range as well as a lot more detail about
> how to configure and use it correctly.
>

Thanks for the link.
Did I mention that I have near zero experience with
small devices like this?

Read the datasheet, but no luck yet.
But one day- I'll get it working

--
--
Björn

[Martin Gregorie]

On Wed, 15 Nov 2017 09:23:48 +0100, Björn Lundin wrote:

> On 2017-11-13 11:20, Martin Gregorie wrote:
>>
>> Have you got a data sheet for the MPU-6050 and if not, why not? It is
>> not exactly hard to find: the 3rd item on the first page of search
>> results for "MPU-6050" is:
>>
>> https://www.invensense.com/wp-content/uploads/2015/02/MPU-6000-
>> Datasheet1.pdf
>>
>> Get it, read it, and you'll KNOW whether the supply voltage from an
>> RPi's expansion bus is in the required range as well as a lot more
>> detail about how to configure and use it correctly.
>>
>>
> Thanks for the link.
> Did I mention that I have near zero experience with small devices like
> this?
>

No, you didn't, but since understanding device datasheets is always key
to doing the sort of thing you are trying to do, this is a good start.
They can be hard to understand as they tend to be written for electronics
engineers rather than programmers, but they are the only definitive guide
that can tell you exactly what a program or driver module must do the
access the device.

General point: unless you have teeny weeny eyes, a decent magnifier and
very steady hands for soldering, you may want to avoid surface mount
devices (SMDs) if at all possible and (unless they come already mounted
on a PCB with easily solderable connections or a pre-installed RPi
expansion board connector) and stick to more traditional dual inline
packed devices with 0.1 inch (2.54mm) pin spacing.