We are currently developing a high-FPS application on OpenMV N6 (FPS 250+) and OpenMV H7 Plus (FPS 100+). Our architecture utilizes UART3 (P4/P5) to communicate with an external MCU via TTL, transmitting small 8-byte packets per frame.
For testing, we use USB-C (VCP) to stream real-time images to a PC using the fb_dump protocol.
The Issue:
Stable Standalone Performance: UART communication is highly stable and real-time when the USB image streaming function is Inactive.
Delayed Performance Degradation: When the PC starts requesting frames via USB (using the pyopenmv.py FB Dump logic), the system works fine initially.
However, after approximately 5 minutes, the UART transmission frequency drops drastically (stalling for several seconds), causing the external MCU to trigger a timeout/disconnect. This also leads to severe lag in the USB VCP image stream.
IDE vs. Standalone Script Discrepancy:
When running main.py via the OpenMV IDE to view the framebuffer, the system remains stable for extended periods.
However, when running the same main.pyautonomously (standalone from Flash) and using a custom Python script (based on pyopenmv.py) to fetch images, the performance degradation is severe.
Questions:
During the fb_dump process in pyopenmv.py, does the USB VCP task block the hardware UART transmission? Is there a way to make this process truly non-blocking?
How does the OpenMV IDE fetch images without significantly impacting the MCU resources and main loop execution?
What is the official recommended implementation for scenarios requiring simultaneous high-frequency UART telemetry and real-time image debugging?
Hi, we have a new protocol in firmware v5.0.0. All the old stuff is deprecated. Let me know if you’d like support migrating to the new protocol and the latest firmware. The new protocol addresses a large number of issues with the old protocol and is much more reliable.
Otherwise, for the issue you are encountering, are you on windows? There are known issues with the kernel tossing USB packets which have to be worked around in the IDE. pyopenmv.py didn’t have support to handle all these unideal situations.
We have actually moved away from pyopenmv.py and implemented our own C++ host-side logic to handle the image packets. This was done to achieve better performance and integration for our specific application.
However, we are still facing intermittent stalls on Windows (likely due to the kernel packet tossing you mentioned). We are extremely interested in the v5.0.0 firmware and the new protocol.
Could you please share more information or documentation regarding the new protocol? Specifically, we’d like to understand how to adapt our C++ implementation to support the latest firmware and ensure the most reliable communication.
Thank you very much for providing the Qt Creator plugin source code! It’s extremely helpful for our C++ (Qt) implementation.
We are currently optimizing our host-side logic based on these references to handle the Windows kernel issues. Since we are planning our project milestone and mass deployment for the hardware, could you give us a rough estimate of the official release date for firmware v5.0.0?
We want to decide whether to stick with the current 4.8.0 protocol for the upcoming delivery or prepare for the migration to the new protocol in the very near future.
I found this repository on GitHub and flashed the firmware. However, in OpenMV IDE 4.8.1, the firmware version displayed in the bottom right corner is still only 4.8.1. I am unsure if it currently supports the v2 communication protocol.
