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.
I am having trouble upgrading my OpenMV H7 Plus to the latest firmware. Even though the IDE reports success, the version doesnât change. Here are the details:
IDE Version: 4.8.1
OS: Windows 11
Action: I selected Tools -> Install Latest Development Release.
The Issue: 1. During the process, the progress gets stuck at âFlashing Firmware - DFU Utilityâ for about 30 minutes. 2. After the long wait, a message pops up saying: âDFU Firmware Update Complete!â. 3. However, after reconnecting the board, the firmware version is still v4.7.0, not v5.0.0.
BTW, I was able to successfully flash my OpenMV N6 using the same setup (same PC/cable/IDE).
Uh, thatâs not success, just an unhandled error as 30 minutes is a timeout.
What does the utility say? If itâs waiting for the camera, then itâs trying to connect to the camera bootloader. This is only possible right when the camera is plugged it. If for some reason, your PC doesnât enumerate the camera fast enough it may have started to run the firmware before DFU could connect.
Please do this, if the DFU util is saying, waiting for connection or something like that, unplug and replug the camera, it should work then. If not, then, could you send a screen shot of your devices in device manager? If you have a USB device in warning, then, USB enumeration is slow which causes issues with the programming bootloading handoff.
