Hey everyone, I’ve got an Arducam B0315 hooked up to a Raspberry Pi Pico and I’m using the Arduino IDE with the Processing sketch to view the stream. At the default resolution everything works perfectly — I can see the feed in Processing with no issues at all.
Now I’m trying to switch the camera to QQVGA (160×120). I modified the Arduino sketch and the Processing example to use 160×120, but when I run it, the stream in Processing looks really weird — it’s like I’m seeing multiple copies of the image side-by-side, almost like the frame is being tiled or replicated across the window. My guess is the image buffer sizes aren’t matching the new resolution somehow, but I can’t figure out where the mismatch is.
Thanks for the detailed description. That “replicated stream” effect you’re seeing is almost certainly a buffer size mismatch — the camera is outputting data at one size and the host side is interpreting it as a different size. Can you share exactly what changes you made? Did you modify anything beyond the Arduino sketch and the Processing code, like any of the register configuration files?
Yeah, I dug into it a bit and tried tweaking the register values in hm01b0_init.h to enable 1/4 binning mode. I figured since QQVGA is 1/4 of QVGA, setting up binning would be the right approach. But honestly I’m not 100% sure I’ve got the registers right — I was sort of going by the datasheet and guessing a bit. The replicated frames still show up regardless of what I change.
I see — so let me dig into this a bit. When you say you’re modifying hm01b0_init.h, what specific registers are you changing? And are you also adjusting the buffer allocation on the Pico side to account for the smaller frame size? The Pico has limited RAM and the library’s buffer sizes are set up for the default resolution, so if the camera is outputting fewer bytes than expected, the host will just keep reading past the valid data and reinterpret the next frame’s pixels as part of the current one — which would look exactly like what you’re describing.
Good point on the buffer side. I did update the Processing sketch to expect 160×120 but maybe the Pico firmware side isn’t allocating the right buffer size. To be honest I’ve been focused more on the register side — I changed a few binning-related registers in hm01b0_init.h but I can post the exact changes later today when I’m at my setup. But here’s the thing: QQVGA is literally listed as a supported resolution on the B0315 product page and in the HM01B0 sensor datasheet. So it should work, right? This isn’t some random custom resolution I made up.
I understand the confusion, and you’re right that the HM01B0 sensor itself does support QQVGA at the hardware level. However, the driver stack we provide for the RPi Pico platform has only been validated and tested at the default resolution. The library, buffer handling, and timing are all tuned for that specific configuration. When you modify the register headers in hm01b0_init.h for modes like QQVGA — even ones the sensor technically supports — it introduces buffer size mismatches between what the camera outputs and what the host firmware expects, which is exactly what’s causing those replicated frames you’re seeing.
That’s a bit frustrating, not gonna lie. The product page lists QQVGA as a feature so I bought it partly for that. Is there really no workaround? Has anyone else gotten a lower resolution working on the Pico? Even if it’s not officially supported, maybe there’s a way to patch the buffer sizes in the library to match?
I understand the frustration, and I’ve flagged this internally regarding the product page listing. Unfortunately, at this point, custom resolution configurations on the Pico platform are not something we can provide technical support for — the driver stability has only been verified at the default resolution, and introducing non-default modes requires changes across multiple layers (register init, buffer allocation, DMA configuration, and the host-side parser) that go well beyond just editing hm01b0_init.h. Any register header modifications for modes like QQVGA will introduce the kind of buffer mismatch you’re experiencing, and we don’t have a validated configuration to share.
The recommended path forward is to revert your modifications to hm01b0_init.h back to the original defaults and use the default resolution setting from the library. That’s the configuration where we can guarantee stable operation. If you really need QQVGA for your project, you might consider doing the downscaling on the host side after capturing at the default resolution — it’s not ideal from a bandwidth perspective, but it’s a reliable approach on the Pico platform given the current driver limitations.
Alright, fair enough. I’ll revert the register changes and stick with the default resolution for now. Post-processing downscale on the host side might actually work for my use case — I’ll give that a shot. Still hoping you guys add proper QQVGA support to the Pico driver down the line though. Thanks for explaining what’s actually going on under the hood, the buffer mismatch explanation makes total sense now that I think about how the frames were being tiled. Appreciate it.