Trouble with transferring images over UART

Hello, all,

I’m having trouble with “image_transfer_jpg_as_the_controller_device.ino”. I’m running this code on my Adafruit Feather 32u4 with an onboard SD card and I’m running “image_transfer_jpg_as_the_remote_device_for_your_computer.py” on my OpenMV H7 plus. The boards are connected via UART. My end goal is to run this code with a Raspberry Pico 2040 by establishing LittleFS for file storage, but I’m using the Feather to prove that the code can work. I’ve gotten the “popular features” code working between these devices just fine.

The code runs fine, but I’m running into terrible reliability when it comes to initiating the snapshot and file save sequence. 99% of the time while the code is running, my Arduino IDE shows me “Taking a pic…Failed!” VERY occasionally it’ll move on to “Creating jpg file…Reading bytes” and then usually errors out. A couple times, the file saved completely, and I could view it from the SD card. Is there a way I can improve the reliability of this code?

I can successfully save an image once after pressing the “Play” button in the OpenMV IDE. After that completes, the Arduino gets stuck in the “Taking a pic…Failed!” cycle. I can capture another image by pressing the OpenMV “Play” button again.

Hi, that was a toy example. I don’t recommend actually using it.

Of, if you plan to use it made the chunk size larger. If you look into what’s going on it’s a very slow way of sending image data.

Thanks for your reply. I did notice that saving the image took a while, so I increased the buffer size; Is that what you mean by chunk size? Increasing that did help a little.

I wasn’t super worried about that since I know I’ll eventually move this code to the Pico. The 2040 has much more flash than the Feather. On the Pico, I also plan to use SPI rather than UART.

Yeah, it’s really about the buffer size. You should aim to use like a 8KB transfer chunk size versus 256 bytes.

If you do this from one OpenMV Cam to another it’s fine. But, at 256 bytes at time you’re going to be waiting a while.