Hi everyone. I’m working with an Arducam B0195 (UC625) board, which I believe is the ‘Stereo Camera HAT’, connected to two OV5647 cameras on a Raspberry Pi. I’m on Buster OS since I can’t use the libcamera stack with this board. I followed the quick-start guide at Quick Start Guide for Arducam CamArray HAT Kit - Arducam Wiki and I’m capturing with Picamera and OpenCV in Python, plus raspistill.
The problem: unlike the Camarray HAT examples I’ve seen (which show a UC-512 board and a compressed half frame), my UC-625 gives me a cropped-half frame. If I think of the two camera feeds as (AB) and (CD), I expected to get (ABCD) or at least (AB) then (CD). Instead I’m getting (AC), and the information from B and D is just lost.
Is there actually a difference between the ‘Stereo Camera HAT’ and the ‘Camarray HAT’ in whether it crops frames, or is something else going on?
Thanks for the details. Just to set expectations up front: the B0195 / UC625 board has been discontinued and support for it has ended, so I can only really point you to the quick-start document. Also, this module only works on Buster OS with the legacy camera stack - the libcamera/Picamera2 stack won’t work with it.
That said, can you tell me exactly how you’re capturing? For example, which dtoverlay lines you have in /boot/config.txt, and what resolution you’re requesting in the PiCamera class versus the resize/resolution passed to start_recording? The (AC) behavior you’re describing sounds like the mux is interleaving half-frames, but the details matter.
Editing /boot/config.txt - I’ve toggled camera_auto_detect=0 and =1, and tried dtoverlay=ov5647 as well as dtoverlay=camera-mux-2port,cam0-ov5647,cam1-ov5647.
Setting various resolutions in the picamera.PiCamera class, and also checking the resizing resolution when calling start_recording. Tried the same with raspistill and OpenCV.
I even forced the maximum camera resolution to 5184x1944 (it was originally 2592x1944) by editing the picamera library directly.
I installed arducamstill manually and tried to run it, but the script fails to run, and the GitHub repo says this board is not on the supported device list.
None of it changes the output - I still get the cropped combined frame.
Right, that matches what I’d expect. Raspberry Pi is deprecating the legacy camera stack (Buster) and Arducam has moved development over to Bullseye. This discontinued UC625 module depends entirely on that legacy stack, so a lot of the newer tooling simply won’t cooperate with it. arducamstill failing is also consistent with this board not being on its supported device list.
So the recommendation stays: use Buster OS with the legacy stack, not libcamera. Can you describe what output you’re actually trying to achieve? Knowing the target resolution/format will help me tell you whether this board can even produce it.
Ultimately I want either a 3840x1080 frame (two FHD feeds side by side), or two separate 1920x1080 frames that I can grab in rotation. Stretching two 1920x1080 frames into 3840x1080 would also be fine.
But before I keep hacking at it, I need to understand what the UC625 (B0195) actually sends over the bus - is it each frame from one camera, or is it already a cropped-and-combined frame? That determines everything on my end. I’ve been using the Camarray quick-start doc as my reference.
One thing I’d like to rule out: we suspect you might be using a third-party carrier board, which would explain some of the odd behavior. This camera driver should also be compatible with the Jetson Nano, and we’ve tested an Ethernet extender solution on the Jetson platform that requires installing the recommended driver.
Could you share a picture of your board/setup so I can check the carrier board situation? Also, make sure you’ve installed the camera driver I mentioned earlier.
Hold on, I’m a bit lost - my setup is a Raspberry Pi, not a Jetson Nano. I’m not sure where the Jetson Nano / Ethernet extender part comes in. Did I miss something? Could you clarify which driver you mean by ‘earlier’? I don’t see a driver link from you anywhere in this thread.
Sorry about that - please disregard my last post, I mixed this up with another case. Give me until tomorrow and I’ll come back with a proper answer for the UC625.
Okay, here’s the situation as clearly as I can put it. The UC-625 and UC-512 modules actually use a similar approach: they compress the individual camera feeds so they can be shown inside a single window. So the combined/cropped output you’re seeing is by design, not a misconfiguration on your side. That also means per-camera full frames are not what comes out of this board.
Unfortunately the UC-625 has been discontinued and we can’t provide further support for it. If you need a working multi-camera setup, I’d suggest looking at the currently available Camarray HAT modules listed here: Multi-Camera Solution - Arducam Wiki - they may offer an alternative that meets your 3840x1080 requirement.