Hi all. I’m stuck with a QUADCAM 64Mb CAMARRAY HAT (Arducam UC-512) on a Raspberry Pi 4, running Debian 12 Bookworm (June 2023). The first time I run this command:
all 4 cameras show up correctly. But after I stop it with CTRL+C and run the same command again, no camera is displayed and I get a timeout. Installation itself went fine and I’ve searched around but can’t find anything that matches.
Error log:
[0:03:53.919541596] [2032] WARN V4L2 v4l2_videodevice.cpp:2007 /dev/video0[14:cap]: Dequeue timer of 1000000.00us has expired!
[0:03:53.919651521] [2032] ERROR RPI pipeline_base.cpp:1422 Camera frontend has timed out!
[0:03:53.919690169] [2032] ERROR RPI pipeline_base.cpp:1423 Please check that your camera sensor connector is attached securely.
[0:03:53.919729336] [2032] ERROR RPI pipeline_base.cpp:1424 Alternatively, try another cable and/or sensor.
ERROR: Device timeout detected, attempting a restart!!!
Thanks for the detailed log. That dequeue timer warning means libcamera stopped getting frames from /dev/video0, then the pipeline frontend timed out and tried a restart. The ‘check the connector/cable’ part is generic advice from libcamera. Since your first run is always fine, let’s first rule out a stale state after the stream is torn down. Can you do a full reboot, then run the command once, stop it with CTRL+C, and run it a second time? Let me know if it still times out.
Tried that just now. After a reboot the first run shows all 4 cameras, but after CTRL+C the second run still times out with the same error. So a reboot doesn’t clear it. It only fails once libcamera has been stopped once.
Done. I ran the tool and PM’d you the arducam-bug-report.txt. It grabbed the config, dmesg, and libcamera info. Does anything in there point to the cause?
Thanks, I’ve got the report and I’m working through it. Based on the earlier log, the key sequence is the dequeue timer expiring on /dev/video0 and then ‘Camera frontend has timed out’. Because the first run works every time and it only breaks after CTRL+C, I don’t think this is a loose sensor/cable—it looks more like a pipeline/state issue after the stream is torn down. I’m still analyzing the report and I’ll post back when I have something concrete.
Quick update from my side: I ended up wiping Debian Bookworm (12) and installing Raspberry Pi OS Bullseye (11) on the Pi 4. That made the timeout go away—the QUADCAM now works and I can take several photos in a row without it crashing. New problem though: the capture saves all 4 cameras grouped into one image. I need to split that into one file per camera (camera 1, camera 2, camera 3, camera 4), and I’d also like to change the display order/layout.
Good to hear Bullseye is stable for you. For the grouped output, the composition layout (which camera appears where in the frame) is fixed, so the display order can’t be rearranged. The supported way to get separate files is to switch the board to single channel mode and capture each camera channel individually.
Use these to select the channel before each capture:
# Set to single channel 0
i2cset -y 10 0x24 0x24 0x02
# Set to single channel 1
i2cset -y 10 0x24 0x24 0x12
# Set to single channel 2
i2cset -y 10 0x24 0x24 0x22
# Set to single channel 3
i2cset -y 10 0x24 0x24 0x32
So: set channel 0, run your normal libcamera-still capture, then set channel 1 and capture again, and so on.
Just to make sure I’ve got this right: the grouped layout/order can’t be changed at all, and the only way to get separate files is to switch to each single channel with i2cset and capture one channel at a time? And I can keep using the same libcamera-still command after each i2cset?
Correct. The grouped composition/display order is fixed and can’t be reordered. Single channel mode is the supported workaround: set the channel with i2cset, then run your normal libcamera-still command for that channel, and repeat for channels 0 through 3. That gives you one file per camera.