I am trying to read raw sensor data from MPU6050 over Raspberry pi Pico. Everything was working fine for me but I started to read the data on serial connection. And then everything shuts down. A simple example code in Thonny too giving me error. Here it is:
unable to connect to com3: could not open port ‘com3’: permissionerror(13, ‘access is denied.’, none, 5) if you have serial connection to the device from another program, then disconnect it there first. process ended with exit code 1.
I have uninstalled every other program but still getting the error. Any help will be helpful. The pico is connected to my laptop over a usb cable.
Can you let us know what MPU6050 module you were using? Do you have a part number or a link to it?
What library were you using on the Pico to handle the serial connection?
Thanks a lot for replying and sorry for late reply. I wanted to plot the raw sensor data like accelerometer gyroscope and temperature data of MPU6050. For me MPU6050 is soldered with Pico and Pico is connected to my laptop via USB connection. The earlier problem got solved for me as I found out that somehow my micro python firmware got corrupted and I reinstalled everything so the error got fixed for me.
Now, my problem is the frequency is quite low like 101sample/second. I am using serial library of python for this. And on Pico side I have used UART. I should get at least 1khz frequency as per the MPU6050 datasheet. But, I am seriously doing something wrong here.
I have used serial.readline() to read the data and I believe I have to make use of inbuilt fifo buffer and I should read from buffer. But I am quite new and don’t know how to do it. Any help on this will be really helpful for me. Thanks in advance.
What baudrate are you using for serial? There are sometimes overheads in USB-serial adapters that cause problems, but most throughput problems are solved just with higher baudrates.
Can you send us your code to see if anything might be slowing it down?
Thanks for your reply. I am using baudrate 115200. I did some trial and error and find out that there is no problem between Pico and Python with Pyserial. It’s like Pico is not able to read data from MPU6050 that fast because I am getting lot of empty bytes with the use of serial.in_waiting(). I am uploading my code here. Just a bit overview, my main.py uses two external module imu.py and vector3d.py to read data. I am getting only 100sample/second but It is a lot less. According to MPU6050 datasheet I should get atleast 1khz frequency.
from imu import MPU6050
from machine import Pin, I2C, UART
i2c = I2C(0, sda=Pin(4), scl=Pin(5), freq=400000)
imu = MPU6050(i2c)
uart = UART(0, baudrate=115200)
print("UART Info : ", uart)
ax = round(imu.accel.x, 2)
ay = round(imu.accel.y, 2)
az = round(imu.accel.z, 2)
gx = round(imu.gyro.x)
gy = round(imu.gyro.y)
gz = round(imu.gyro.z)
tem = round(imu.temperature, 2)
print(ax, ay, az, gx, gy, gz, tem)
#Python side code
import numpy as np
import matplotlib.pyplot as plt
import pandas as pd
ser = serial.Serial('COM4', 115200)
file = open("serial_sample.csv", "w")
start_time = time.time()
curr_time = time.time()
output_list = 
header_string = "X_accel" + "," + "Y_accel" + "," + "Z_accel" + "," + "X_Pos" + "," + "Y_Pos" + "," + "Z_Pos" \
+ "," + "Temperature" + "\n"
while curr_time - start_time < 10:
data = ser.readline()
data = str(data).split("\\").split(" ")
output = data.split("'") + "," + data + "," + data + "," + data + "," + data + ","
+\ data + "," + data + "\n"
curr_time = time.time()
I’m no expert in what you are trying to achieve. But I’ve been debugging code for a long time. Try and cut your problem in half. Is the problem in the reading part or the serial / sending part. Comment out the serial part and just write the data to a file for a second or two. See how fast that can go.
I was mucking around with sounds the other day and logging the number of loops to a file. I was astounded it logged around 900,000 entries in around a second of me pressing a button.
This might narrow the field a bit for you.
Hope this helps
I agree with David on this one, definitely break this problem out into smaller bits. Test each interface individually, each building on the last
- Read the sensor to a file, or just discard the data and pulse a pin every time you’re able to get something back. A logic analyser, oscilloscope or another microcontroller helps here to count the pulses.
- Next I’d start sending serial from the Pico, and watch that on a scope or LA if you have one.
- If that doesn’t reveal anything you can look at your Python code.
An important detail you haven’t included is which MPU6050 library you’re using. Looking through the code and docs for that may reveal to you and us whether you need to enable certain settings to get a higher speed (some sensors have built in averaging by default that you need to disable to get the highest speed).
Give the above a look to the best of your ability, and let us know how you go!
Hi David and James,
Thanks a lot for your reply and thanks for your valuable input. I tried out without serial connection but I am only getting 15.1 sample/second and that is a lot less. With serial connection I am getting 100 sample/second. so data read over serial connection increase the sample rate.
Additionally, I use imu.py and vector3d.py as external module and I did not change anything in those external modules. The link I followed is :
And, I read few blogs and they say that, using FIFO buffer increase the frequency. But I do not know how to do it and where to change in those external module. Do you guys o anyone has any idea about it?
Where did you spot the 1kHz polling rate on the data sheet?
While the MEMS devices inside of the IC might be rated to update that quickly the I2C interface won’t allow the full amount. I’ve seen libraries work with a polling rate of 200SPS.
What application do you have that requires such a high poll rate?
Thanks a lot for replying. I have taken reference from the following source:
It says that, gyroscope has a sample rate of 8kHz while accelerometer has a sample rate of 1kHz. But the first link clearly says that it will be difficult to achieve if I read every data. But 100Hz SPS is too low. I have tried to use FIFO buffer too but seems no use.
My application is vibration data analysis. The goal is to read data from MPU6050 through PICO and analysis the vibration data.
Can you please help me with your knowledge to achieve at least a bit more SPS? Thanks in Advance.
The site you are using as your guide has some sort of protection enabled and cannot be accessed. Can you provide the reference to the library that you are using. That you are seeing close to 100sps suggests that something in that library has set the sampling rate. For instance, the Adafruit library has a property cycle_rate. There might be a similar setting you can adjust.
Otherwise, you can try re-arranging the flow of the program so that the Pico simply stores the raw data as received - no processing of any sort other than to stuff it into an array. At the end of the sampling period you can dump that data to the PC, convert it into a form suitable for matlab and process it.
Jeff has hit the nail on the head regarding data limits in the library.
From what I could see in the guide you are referencing uses an STM32 which offers very rich HAL documentation and a custom-written driver.
Breaking the problem down even further, do you know what frequency the vibration is?
Nyquist theorem says that your vibration frequency should be half of the sensors read frequency, though to fully characterise a wave it should be at least a quarter.
It sounds like you’ll have to write a custom driver for high-speed reading of the MPU6050 on the Pico (micropython or a variation of C). To do this you’ll have to study and understand the register map or the STM32 code on the guide.
Hi Susmita and All
I have been reading this post with some interest. Not so much regarding exactly what you are trying to do but more of if you are asking too much from the devices you are using.
I recently tried to do exactly that but realised early that the devices I was trying to use were unlikely to be suitable. This led to some experimenting and of measurement of the particular limitations.
These devices are Arduino UNO R3 and Arduino NanoEvery and while I appreciate you are working with RPi I feel that the general idea would still apply. The practise of using a device within its particular limitations would apply to most everything I think.
I posted my experiments and results here
if you would like to read through. Although my results are for Arduino and you are using RPi the general idea is the same and may be some help.