Hi everyone. I’m having trouble with an Arducam 64MP Autofocus Camera for Raspberry Pi on a Raspberry Pi 4B with 8GB RAM. It was working fine, but then it started taking only black pictures, and now it doesn’t create a picture at all. The autofocus motors still make a clicking sound when the Pi powers on and when I run libcamera-still, so the module seems to be getting power. Running libcamera-still -t 1000 -n just times out. I’m on a bullseye-based Raspberry Pi OS image, and I also can’t get it to show up in OctoPrint anymore.
Welcome to the forum. Could you run that command again and paste the full terminal output here? The timeout message at the end matters a lot for diagnosis. Also, can you run the Arducam bug report tool and send the resulting file over private message?
wget -O arducam-camera-bug-report https://github.com/ketai-dhr/arducam-camera-bug-report/releases/download/tools/arducam-camera-bug-report
chmod +x ./arducam-camera-bug-report
./arducam-camera-bug-report
It will drop an arducam-bug-report.txt in your current directory.
Here’s the full output from libcamera-still -t 1000 -n:
[0:13:42.406375212] [1002] INFO Camera camera_manager.cpp:293 libcamera v0.0.0+3897-c3c878a9
[0:13:42.412308259] [1004] WARN CameraSensorProperties camera_sensor_properties.cpp:174 No static properties available for 'arducam_64mp'
[0:13:42.412352887] [1004] WARN CameraSensorProperties camera_sensor_properties.cpp:176 Please consider updating the camera sensor properties database
Open i2c bus error: No such file or directory
[0:13:42.425304481] [1004] WARN RPI raspberrypi.cpp:1280 Mismatch between Unicam and CamHelper for embedded data usage!
[0:13:42.426193526] [1004] ERROR DelayedControls delayed_controls.cpp:87 Delay request for control id 0x009a090a but control is not exposed by device /dev/v4l-subdev0
[0:13:42.426357354] [1004] INFO RPI raspberrypi.cpp:1404 Registered camera /base/soc/i2c0mux/i2c@1/arducam_64mp@1a to Unicam device /dev/media1 and ISP device /dev/media3
[0:13:42.427520112] [1002] INFO Camera camera.cpp:1035 configuring streams: (0) 4624x3472-YUV420
[0:13:42.427915636] [1004] INFO RPI raspberrypi.cpp:765 Sensor: /base/soc/i2c0mux/i2c@1/arducam_64mp@1a - Selected sensor format: 4624x3472-SBGGR10_1X10 - Selected unicam format: 4624x3472-pBAA
[0:21:38.130189841] [1004] WARN V4L2 v4l2_videodevice.cpp:1990 /dev/video0[14:cap]: Dequeue timer of 475252000.00us has expired!
[0:21:38.130352054] [1004] ERROR RPI raspberrypi.cpp:1901 Unicam has timed out!
[0:21:38.130425780] [1004] ERROR RPI raspberrypi.cpp:1902 Please check that your camera sensor connector is attached securely.
[0:21:38.130496358] [1004] ERROR RPI raspberrypi.cpp:1903 Alternatively, try another cable and/or sensor.
Note the timestamps — it sits there for about 8 minutes before the Unicam timeout. I’ve also already tried a bunch of things:
- Same camera on another Pi 4B 8GB, a Pi 1B, and a Zero W (using 16MP commands on the older boards) — all end in libcamera timeouts after 5-10 minutes.
- Other cameras work fine on those Pis.
- Fresh lite images, 32-bit and 64-bit, several release dates, all bullseye.
- Swapped flex cables — no change.
Looking at that log, the camera is actually detected and the sensor format gets selected (4624x3472-SBGGR10_1X10), so the driver is loading fine. The failure is the Unicam timeout at the end — normally that points to the ribbon cable or the connector. There’s also that Open i2c bus error line, but the camera still registers afterwards. Since you’ve already ruled out images and other Pis, let’s try a different camera cable next and run the libcamera command again.
I swapped to a new cable but it’s the same result. The camera still powers on (you can hear the autofocus clicking), but every command ends in a timeout. I re-ran the bug report tool and sent the new arducam-bug-report.txt over private message.
Thanks, I got the report. One thing that will help me narrow this down: are you running the Pi headless (SSH/remote) or with a monitor attached when you run these tests? Just want to understand the exact setup.
All my previous tests were done over SSH via PuTTY with no display attached. But here’s something interesting — I just tried running the reporter tool with a monitor connected and it actually produced an output without any timeout. I’ve sent the bug report and a picture over private message.
That’s an interesting change. Since it behaves differently with a monitor attached, can you run libcamera -t 0 with the monitor connected and watch the preview? I want to know if the preview shows the same corrupted/artifacted video as the picture you sent.
The preview window shows artifacts but no actual picture. It’s hard to tell whether there are fewer artifacts or the preview window is just cut off at the top. I’ve sent a screenshot of the preview on the screen, plus an older picture of the camera from when it was working.
Thanks. I’m a little confused by those two images though — the first one looks cut off, and the second shows the camera working in OctoPrint. Can you clarify whether the camera is working right now, or is that second image from before? Also, could you try a different monitor to rule out a display or resolution issue?
Sorry for the confusion. In OctoPrint the camera showed a white line at the top and then later just a black screen — no picture from it at all. OctoPrint doesn’t support this camera natively, and the setup takes much longer than a vanilla image anyway. That second picture is from December when the camera was working correctly. I’ll test with another monitor and check the resolution settings, but I won’t have access to the hardware for the next couple of days.
No problem, take your time. Whenever you’re back at the hardware, give the other monitor a try and let me know what you see.
Quick update: with the monitor attached, most of the picture is still black and the artifacts are right at the top of the screen — same as the image the camera captured earlier. I’m away from the hardware for the next few days (working offsite), so I’ll continue once I’m back.
Thanks for the update. When you get a chance, could you also try changing the display resolution and see whether the preview window shows up at all?
I tried another display resolution and the preview window didn’t show up at all. 1080p is the maximum resolution I have access to. I’ve tested both Raspberry Pi OS lite and desktop. Sent the output images over.
Thanks for all the testing. At this point we’ve ruled out the cables, OS images (32-bit and 64-bit), different Pis, and different monitors/resolutions. The camera is still being detected and configured, but the stream is either black or full of artifacts at the top. That points toward a fault in the sensor module itself rather than the setup. I’ve sent you remote support details over private message — if you can set up a session, I’ll connect to the Pi directly and confirm what’s going on. Please check your messages.