#include <Arduino.h>
#include <Wire.h>
#include "I2Cdev.h"
#include "MPU6050.h"
MPU6050 accelgyro;
int16_t gx, gy, gz;
void init_mpu() {
Wire.begin();
Serial.println("Initializing I2C devices...");
accelgyro.initialize();
Serial.println("Testing device connections...");
Serial.println(accelgyro.testConnection() ? "MPU6050 connection successful" : "MPU6050 connection failed");
}
void setup() {
Serial.begin(115200);
while (!Serial) {
; // wait for serial port to connect. Needed for native USB
}
Serial.setDebugOutput(true);
Serial.println("UART0");
init_mpu();
}
void loop() {
accelgyro.getRotation(&gx, &gy, &gz);
Serial.print(gz);
Serial.println();
}
Description
The loop() runs at about 1020Hz (get 490933 figures in 8 minutes), or a period of approximately 1ms.
Each byte at 115200 baud rate takes $\frac{10\text{-bit}}{115200\text{\ b/s}}\approx86.8\mu\text{s}$, so the Serial.print(gz); and Serial.println(); require 500~700us to send. The above result(1020Hz) seems to be reasonable for me.
But the QtSerialMonitor plots new data in the time domain at a minimum period of roughly 30ms~50ms, causing the phenomenon in the screenshots above.
I've tried to tinker with the process priority of QtSerialMonitor in Windows task manager. Unfortunately, it didn't work. And I don't have a Linux or Mac device to test on.
Data points overlap in the time domain at high frequency
Screenshots
zoom in:
Description
Environment
ESP32 WROOM DevKit v1 (ESP32-WROOM32 + CP210x(TTL2USB)) MPU6050
Windows 10, Home, 22H2, 19045.2486 QtSerialMonitor v1.53
Test code
library source: jrowberg/i2cdevlib: I2C device library collection for AVR/Arduino or other C++-based MCUs (github.com)
Description
The
loop()
runs at about 1020Hz (get 490933 figures in 8 minutes), or a period of approximately 1ms.Each byte at 115200 baud rate takes $\frac{10\text{-bit}}{115200\text{\ b/s}}\approx86.8\mu\text{s}$, so the
Serial.print(gz);
andSerial.println();
require 500~700us to send. The above result(1020Hz) seems to be reasonable for me.But the QtSerialMonitor plots new data in the time domain at a minimum period of roughly 30ms~50ms, causing the phenomenon in the screenshots above.
Speculation
Windows?
Acquiring high-resolution time stamps - Win32 apps | Microsoft Learn
I've tried to tinker with the process priority of QtSerialMonitor in Windows task manager. Unfortunately, it didn't work. And I don't have a Linux or Mac device to test on.
Qt
QDateTime and QTime accuracy issues
QtSerialMonitor?
software internal processing time?
software internal clog?
P.S.
by the way, is that possible to plot something like:
In this way the time domain accuracy is greatly improved. But it seems that Qt cannot achieve this?