Hey all, I’ve been fighting with an Arducam Camarray HAT (ArduCam UC-512 QUADCAM 64Mb) on a Raspberry Pi 4. On Raspberry Pi OS Bookworm (Debian 12) the camera would constantly time out and crash. Logs looked like this:
[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!!!
I eventually got past that by wiping Bookworm and reinstalling Bullseye (Debian 11). Now that it’s stable on Bullseye, what I actually want is to capture 4 photos as one separate file per camera instead of a single grouped image, and I need to figure out which physical camera maps to channels ‘1’, ‘2’, ‘3’, ‘4’. Any pointers?
Good to hear the Bullseye rollback fixed the timeouts. That frontend timeout usually means the sensor is dropping frames, and Bookworm’s libcamera stack didn’t get along with these HATs. For the one-file-per-camera goal, the usual approach is to switch the HAT to a single channel over I2C and capture each channel one at a time. First, can you run i2cdetect -l and i2cdetect -y 10 and share what you get? That’ll confirm the HAT’s I2C address is showing up where we expect.
I ran both commands and attached a screenshot of the output (i2C_000.png). While digging around I also found these single-channel switch commands from another thread:
i2cset -y 10 0x24 0x24 0x02 # single channel 0
i2cset -y 10 0x24 0x24 0x12 # single channel 1
i2cset -y 10 0x24 0x24 0x22 # single channel 2
i2cset -y 10 0x24 0x24 0x32 # single channel 3
But I’m still not sure which channel number matches which physical camera.
Right, on that HAT the last byte in those i2cset commands is the channel selector: 0x02 selects channel 0, 0x12 selects channel 1, 0x22 selects channel 2, and 0x32 selects channel 3. Note the channel numbering in the commands is 0-based even though they’re often labeled 1-4 in the docs. Easiest way to map them is to switch to one channel, point it at something obvious (or cover the other sensors), and capture. Then repeat for each channel. You’ll quickly see which physical sensor is which.
Made some progress! Single-channel capture for channel 2 does work now and I’m getting one file per camera. But the capture still prints an error message even though the image saves fine. I ran:
i2cset -y 10 0x24 0x24 0x22
libcamera-still -t 0
The error shows up after the capture starts (screenshot attached as i2c_cam3_000.png).
That error is the embedded data parsing failure that happens during libcamera capture on these cameras. The image still gets written because the error is in parsing the embedded metadata, not the capture itself. The easiest fix is to tell libcamera to skip parsing that embedded data. Run this in the same shell before your capture:
export LIBCAMERA_NOTPARSE_EMBEDDED_DATA=1
Then run libcamera-still again. This avoids the error without any hardware changes.
Thanks, that did it. After setting export LIBCAMERA_NOTPARSE_EMBEDDED_DATA=1 the previous error lines disappeared. But now I’m trying to add --autofocus and it fails. I’m running:
Autofocus on these Arducam modules needs the correct libcamera usage/config, and just adding --autofocus isn’t enough on its own. The supported setup is documented in the Arducam libcamera user guide, specifically the continuous autofocus section:
That section covers how autofocus is supposed to be configured with libcamera, so check it against the options you’re passing. To summarize where we are: single-channel capture is working one file per camera, the embedded data error is handled with the LIBCAMERA_NOTPARSE_EMBEDDED_DATA=1 export, and the remaining autofocus error comes down to following the continuous autofocus configuration in that guide.