I just purchased an PiicoDev MPU-6050, expansion board and cable to make an alarm for my eBike. Before doing that, I am testing the device to determine the data to invoke the alarm, without success.
I have tried using Thonny on two PCs and a RPI4 to test the device.
On the PCs , the results have been run for a few seconds and once only.
Even restarting Thonny it does not seem to be able to find the pico again.
On the RPI it runs for a few seconds then stops with the error -
‘line 124 in read accel_data
line 8 read_i2c word
OSError 5 EIO’
The program will restart but continues with the error.
I have downloaded the three programs and loaded them onto the pico
Thonny is running micro python v1.15.
I have updated and upgraded the Linux and apps on the RPi.
Would it be possible to get all of your code? It looks like that error seems to be caused by not allowing the device to either fully read or allow for initialization of the sensor.
Adding the line sleep(0.5) on line 7 and increasing the delay at the end of the file should get us pointed in the right direction.
Good News. Adding the delay, the program runs continually without error. Well at least until I move the sensor. This is the code I am using with the delays suggested -
from PiicoDev_MPU6050 import PiicoDev_MPU6050 # calls PiicoDev_Unified.py
from time import sleep
motion = PiicoDev_MPU6050()
sleep(0.5)
while True:
accel = motion.read_accel_data() # read the accelerometer [ms^-2]
aX = accel["x"]
aY = accel["y"]
aZ = accel["z"]
print("Accelerometer data - ")
print("x:" + str(aX) + " y:" + str(aY) + " z:" + str(aZ))
sleep(1.5)```
*The [ms^-2] does not appear in Thonny.*
*And this is the result when I shake the sensor* -
Accelerometer data -
x:-0.4381389 y:-0.02394202 z:9.636662
Accelerometer data - Good News.
x:1.422156 y:0.3280056 z:9.40203
Traceback (most recent call last):
File "<stdin>", line 11, in <module>
File "PiicoDev_MPU6050.py", line 128, in read_accel_data
File "PiicoDev_MPU6050.py", line 105, in get_accel_range
File "PiicoDev_Unified.py", line 104, in read16
File "PiicoDev_Unified.py", line 115, in UnifiedRead
OSError: [Errno 5] EIO
>>>
*I wonder if the accel or ax ay az vars are not holding the larger result?*
*The other consideration is that the purpose is to detect someone moving my eBike to steal it. Maybe I should be using the Gforce or gyroscope data. I will give them a try.*
Hi @Brian22570, I’m unable to replicate the error without interrupting the connection between my Pi and the IMU (unplugging the cable). Is there perhaps an intermittent connection in the PiicoDev cable? What happens if you (very gently) prod components on the motion sensor board with a nonconductive instrument like a toothpick, or piece of plastic? Don’t allow the sensor to move here - we want to isolate if the error is in the cable, or on the board.
Violently shaking my motion sensor. A 200mm PiicoDev cable connects the sensor to a Pi 4 w/ PiicoDev adapter which sits still on my desk.
We’ll work on making the PiicoDev modules more tolerant to connectivity issues. Meanwhile, here’s a modified version of the example so you can keep experimenting. This code will handle that particular OSError: If an OSError is raised, the reInit flag is set to True, which will trigger a reinitialisation of the MPU-6050.
A side effect - this means you can completely disconnect and reconnect your motion sensor without the program crashing.
# Example code for PiicoDev Motion Sensor MPU6050
from PiicoDev_MPU6050 import PiicoDev_MPU6050
from time import sleep
motion = PiicoDev_MPU6050()
reInit = False # If communications fails with the IMU, we'll need to reinitialise it
while True:
if reInit == True:
try:
motion = PiicoDev_MPU6050()
reInit = False
except:
pass # an error message is already printed by the motion sensor module
# Accelerometer data
try:
accel = motion.read_accel_data() # read the accelerometer [ms^-2]
aX = accel["x"]
aY = accel["y"]
aZ = accel["z"]
print("x:" + str(aX) + " y:" + str(aY) + " z:" + str(aZ))
except OSError: # an OSError occurred - re-initialise the IMU before attempting to read from it again.
reInit = True
sleep(0.1)
If we figure out that this is contributing, we’ll include a very short delay in the Motion Sensor initialisation function. Thanks for your help @Liam120347
Brilliant Liam.
It ran overnight.
I did get a “Device 0x68 not found” at some time.
But your code modifications recovered the program.
The highest readings I had were Z:10.4 and X:.26.
I have set it to alarm at Z:10.6 and X:.5.
A final thing, I am running on 18650 battery.
Is there a way to turn off the LED on board?
Wish you guys made in Australia all electronic devices.
The LED is a hardware power indication, so it’s not programmable. The best way to remove the LED is to desolder or mechanically lift itcut the trace on the reverse side of the PCB.
There was actually a mention about power LEDs in a recent #TheFactory episode, along with a great discussion from Oliver in the YouTube comments.
Also Brian, you’ve since discovered accidentally that motion is a weakness of the JST connector. As your project evolves and becomes more permenant/rigid, consider soldering to the breakout header (and on the MCU side as well).
That way, no amount of motion will unsettle the communication/power to the MPU-6050
I need to solder the I2C due to space anyway.
Your help is much appreciated.
Cheers,
Brian
P.S. Michael is very impressive with his designing. Keep up the great work.
I regret not checking the forums over the weekend! There is a less destructive way to disable the Power LED - Cut the jumper labelled PWR LED on the rear side of the board:
A hobby knife or razor works well. Be careful not to cut anywhere outside the pill-shaped outline. You can solder across this jumper to re-enable the power LED later.
I’ll update product listings to ensure this feature is more obvious.
Unfortunately a lot of the I2C modules don’t offer the functionality natively, I agree it would be amazing to be able to control everything in software although when producing a chip such as the MPU6050 a lot of thought would go into the features that are packed in and trying to optimise the cost-functionality usually has all of the QOL changes go.
I remember @Oliver33 mentioning that it is one of the best debugging tools somewhere on the forum. and it definitely is, making sure a module has power should be no 1 step of troubleshooting.
The guys over at Core might be able to share some insight into the design but the designs are open source, you can have a look at the schematic here: https://github.com/CoreElectronics/CE-PiicoDev-IMU-MPU6050/raw/main/Documents/schematic-piicodev-motion-sensor-mpu6050-v10.pdf
A solder bridge is pretty maker-renowned for being able to set those little QOL things; I2C addresses, default states and the list goes on.
Understood, and I agree with regards to debugging - the classic support call response “Is the power cord plugged in and turned on?” can be avoided quite simply with the LED.
Don’t get me wrong, these I2C modules are amazing and the the Core team has done a great job. Deep down I’m just a software person and I don’t even know where my soldering iron that I bought years ago is , cutting/bridging track makes sense for a simple module and cost effective.
Yeah right on the money. No doubt, so cheap and the open source nature/sharing insights on the Factory eps are great. An Idea that could work is a bit of Al foil and electrical tape (Kmart has a bunch of super cheap stuff that’s alright) and short it with that.
- programable power LED on/off, this would be cool and less destructive.
, cutting/bridging track makes sense for a simple module and cost effective.
