Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Data points overlap in the time domain at high frequency #8

Open
RarityBrown opened this issue Jan 17, 2023 · 0 comments
Open

Data points overlap in the time domain at high frequency #8

RarityBrown opened this issue Jan 17, 2023 · 0 comments

Comments

@RarityBrown
Copy link

Data points overlap in the time domain at high frequency

Screenshots

image

zoom in:

image

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)

#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.

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:

image

In this way the time domain accuracy is greatly improved. But it seems that Qt cannot achieve this?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant