Hi all, hoping someone has seen this before. I have an Arducam Multi-Camera Adapter Board 4-Channel (model B012001) on a Raspberry Pi 3B+, Raspbian bullseye, kernel 5.15.84-v7+. Four Raspberry Pi High Quality Camera Modules (M12 mount, imx477) are connected to it.
When I run init_camera.sh, video0 is detected and it moves on to AdapterTestDemo.py, but then it just stalls when it calls libcamera-still. This is what I get:
Start testing the camera A
Preview window unavailable
[0:53:33.459536828] [1812] INFO Camera camera_manager.cpp:299 libcamera v0.0.4+22-923f5d70
[0:53:33.505752824] [1813] INFO RPI raspberrypi.cpp:1476 Registered camera /base/soc/i2c0mux/i2c@1/imx477@1a to Unicam device /dev/media3 and ISP device /dev/media0
[0:53:33.506757252] [1812] INFO Camera camera.cpp:1028 configuring streams: (0) 2028x1520-YUV420
[0:53:33.507315742] [1813] INFO RPI raspberrypi.cpp:851 Sensor: /base/soc/i2c0mux/i2c@1/imx477@1a - Selected sensor format: 2028x1520-SBGGR12_1X12 - Selected unicam format: 2028x1520-pBCC
I waited over 5 minutes and nothing else prints. If I press Ctrl-C, the script moves to the next camera and hangs the same way again.
Thanks for the full log, that’s helpful. The sensor is clearly being registered (imx477@1a) and the stream gets configured as 2028x1520-YUV420, so detection isn’t the problem — the capture itself is stalling after the config completes.
First, make sure you’ve worked through the Quick Start Guide for the Multi-Adapter Board:
I tried that already. Calling libcamera-still directly hangs at the same place, even with a shorter timeout. Once it actually captured an image from camera A and then hung on camera B. I also swapped the libcamera-still calls for Picamera2 and called picam.capture_array(), and that hangs too. Feels like it’s not specific to the test script.
Okay, so it’s not the script. Next thing I’d check is your /boot/config.txt camera overlay. What dtoverlay line do you have for the mux, and how many cameras does it enable? If the overlay doesn’t match your sensors, libcamera can still enumerate the sensor but fail at the capture stage.
A couple of things there. First, that’s a typo — it’s dmesg, not dmseg. But more importantly, since you’re using imx477 sensors, you shouldn’t expect any output from grep arducam at all. Use this instead:
dmesg | grep imx477
That will show you the imx477 detection entries.
For the hang itself, could you generate a bug report and send over some photos of the hardware connections? I’ve sent you the bug report tool and the exact steps by private message. The log plus the photos will let us check the overlay, the connections, and what libcamera sees at capture time.
I rebooted and ran the bug report tool — I’ve sent the generated log over. One thing I noticed is the tool itself sometimes can’t finish after a reboot because it times out.
The behavior is also intermittent: on some reboots all 4 cameras capture an image, on others it fails, with the hardware completely untouched between reboots. And when it does work, capturing one image from each of the 4 cameras takes over 4 seconds in total. A single camera used to run around 100 FPS with the same config.
My custom script is based on the previewOpenCV.py example. I found that when multiplexing, the Picamera2 object has to be closed and recreated each time — otherwise the picture still comes from the same camera even after switching the mux via i2c/gpio. My goal is a real-time pipeline that captures and processes images from all 4 cameras in under 1 second.
I’ve gone through the bug report and the photos. The good news: the adapter itself is working — the report shows the camera being detected and a still image being captured successfully.
The problems I can see:
You’re using imx477 cameras, so dmesg | grep arducam (or dmseg) will never return anything. That earlier command returning nothing was expected, not a sign of failure. Use dmesg | grep imx477.
From the photos, the camera connectors don’t look seated stably. The HQ camera ribbon connectors on the mux board are finicky, and a marginal connection explains the intermittent behavior across reboots.
Your config only enables two cameras (cam0 and cam1) even though four are connected, and the dtoverlay line is commented out. That mismatch will cause exactly this kind of flaky behavior.
So: enable the dtoverlay line, make sure it enables all four cameras (cam0 through cam3), reseat the connectors firmly, and verify with dmesg | grep imx477 after boot.
I’d noticed that commenting out the dtoverlay camera-mux line didn’t seem to change the mux behavior either way. I’d originally tested with only 2 cameras, then tried all 4 to see if it helped the mux work properly.
A few questions:
Is the dtoverlay camera-mux line actually needed, and what does it do?
The black clips are really hard to seat snugly on the mux board, unlike on the Pi itself. Should I force them shut, or is there a risk of breaking the connector?
Is the low FPS normal, or is that a software-side issue?
The dtoverlay line is definitely needed — it’s what enables the multi-camera adapter on the Pi, so it should not be commented out. If you leave it out, the adapter’s camera channels won’t be properly registered, which matches the intermittent results.
On the clips: they should close fully so the ribbon is held flat and straight. If it’s not seating, double-check the cable isn’t slightly angled or pushed in too far. You may need a bit more even pressure, but if it feels like it’s going to snap, stop and recheck the alignment first.
For the FPS question — can you clarify what you’re measuring? What resolution/frame count are you seeing per camera when it does work?
To clarify the FPS issue: my script captures one image from each of the 4 cameras, and that whole loop takes over 4 seconds. A single camera previously ran at about 100 FPS with the same configuration. I have to close and recreate the Picamera2 object every time I switch the mux, otherwise I get the same camera’s image repeatedly despite the i2c/gpio switch. I’ll update the config so the dtoverlay line is enabled with all four cameras.
My question: what’s the fastest way to properly interface with the multiplexer in Python using Picamera2? Is my current approach (recreate the object per switch) the best I can do, or is there a better pattern?
I’ve looked at your script and the approach you’re describing. Here’s the honest answer: the multiplexer board isn’t designed for real-time capture across cameras. You’re switching one camera channel at a time over a single CSI/ISP path, and the overhead of tearing down and recreating the Picamera2/libcamera pipeline per switch is what’s killing you. Modifying the Python code won’t get you to 4 cameras in under 1 second.
For a real-time, synchronized multi-camera pipeline you need a multi-camera HAT, not a mux. Since you’re using four imx477 sensors, take a look at the CamArray HAT options here:
The Arducam 12MP 4x IMX477 Quadrascopic Camera Bundle Kit is the matching hardware for that use case:
To summarize the original issue: the adapter is functional, but the hang came from a combination of the dtoverlay line being commented out (and only 2 cameras enabled), unstable connector seating, and using the wrong diagnostic command (dmesg | grep arducam instead of dmesg | grep imx477). For the real-time goal, the mux is simply the wrong tool.