Arducam 64mp PiCamera2 Not working

Hi, I tried the upgrade and ended up with unusable camera

[email protected]:~ $ dmesg | grep arducam
[ 9.106790] arducam_64mp 10-001a: Device found Arducam 64MP.
[ 9.194903] arducam_64mp 10-001a: Consider updating driver arducam_64mp to match on endpoints
[email protected]:~ $ ls /dev/video0
ls: cannot access ‘/dev/video0’: No such file or directory
[email protected]:~ $ libcamera-still -t 0
Made X/EGL preview window
[0:02:09.773167982] [1327] INFO Camera camera_manager.cpp:293 libcamera v0.0.0+3897-c3c878a9
[0:02:09.776487882] [1329] ERROR RPI raspberrypi.cpp:1190 Failed to register camera arducam_64mp 10-001a: -2
ERROR: *** no cameras available ***
[email protected]:~ $


Maybe something doesn’t match, you can contact my email ([email protected]), I wrote a diagnostic program to help you judge.

I’m getting an identical error message on a freshly installed RPi 4B.
raspberrypi.cpp:1190 Failed to register camera arducam_64mp 10-001a: -2

I have also been having issues with using the AF trigger in Python on fresh installs in the last week or thereabouts (although libcamera-still worked fine). I am using several devices in parallel - the SD cards installed about 2 weeks ago still work perfectly. Perhaps a regression got introduced in the most recent versions.

Should I email you to get the diagnostic tool you mentioned?

This might be relevant (or not) – My 64mp camera has worked like a champ…until today…after I ran a standard “apt upgrade” on my Raspberry Pi. Now, I’m getting similar messages and the camera is not detected. For example:

l# dmesg|grep arducam
[    7.883489] arducam_64mp 10-001a: Link frequency not supported: 493500000
[    7.883537] arducam_64mp: probe of 10-001a failed with error -22
# ls /dev/video0
ls: cannot access '/dev/video0': No such file or directory

Okay, I think I found the problem –
The newest driver named their overlay file (in /boot/overlays) as “arducam-64mp.dtbo”.
But the previous version had an UNDERSCORE (_) instead of the dash in the name.
So, your /boot/config.txt either needs to be changed to: dtoverlay=arducam-64mp
or you need to rename that overlay file. I changed the config.txt, and now my camera works.
However, I’m not sure if that old name is referenced elsewhere, so it might be safer to just rename the file supplied by Arducam.

I’m getting ready to test my camera – yep, it works again!

1 Like

Well, I may have spoken too soon. The camera does work again, but I no longer have the focus control that I previously had using the “v4l2-ctl -d /dev/v4l-subdev1” device. That device no longer exists.
I can see all the controls in v4l-subdev0, but not in the v4l-subdev1 device.
I’m still troubleshooting, but if Edward or someone at Arducam has some advice, it will be appreciated.

1 Like

Can confirm both these points. Camera working, autofocus not. Great detective work ldwellman!

Thanks, but I’m not a good enough detective to get this fixed yet. :slight_smile:
I may have messed this up. I had a perfectly good working camera system, used for frequent live-streaming, and after I did a standard-procedure RPI update today, the camera went haywire. I think the update might have clobbered some of the “libcamera” software, and I have a feeling that Arducam’s pivariety drivers don’t work well with the very latest libcamera. So, I’m considering removing libcamera and pivariety components and then trying to start fresh…if that is even possible…

The issue with the Arducam dtoverlay does exist (having a dash instead of an underscore), but there seems to be much more wrong than just that. Once I got the camera partially working, I tried a video recording, using the exact same scripts I have used hundreds of times before. The scripts simply focus the camera, then start a “libcamera-vid” process. I call it with several standard parameters like contrast, gain, exposure, brightness, rotation, and ROI (region-of-interest, choosing just a portion of the sensor instead of the whole area).
But now, the video produced is upside-down, out-of-focus, darker than it should be, and doesn’t come close to the ROI that I previously used. So, it appears that the newest pivariety driver is mishandling or ignoring some of those standard libcamera parameters!

I sent this info to “[email protected]” (I think Edward monitors that). So, I’m hoping he or someone will respond soon. If you come across a solution, by all means, please share it, as well. I will do the same. I’ll probably work on it a lot tomorrow and Friday. We have an event coming up next week that I need to stream again. I hate to have to revert to another system. This Pi 4 with 64mp camera has been working very well for us thus far.

1 Like

Same, camera rolling no focusing on a previously functional python script.

the kernel changed as well as something else with bullseye

@ldwellman That’s the problem innit with being on the bleeding edge, eh? Sometimes it really bleeds! I noticed the vflip too, it’s easily corrected in Python (which is my primary realm) but I’m not sure about v4l2. If you need a disk image of an earlier version that works fine for me let me know.

Thanks, Alan. But I worked on it further late last night, and I finally got it fixed (so far, at least). I just ran a 60-second test with my scripts, and the picture looks great, just as it should. Focus is working again, gain/ev adjustments are working, picture is rotated properly, and ROI portion of screen is correct again. All of these options were failing just last evening.

I’m not certain of the EXACT fix step, but here’s what I ended up doing last night:

  1. I noticed that the public key for some github repositories were expired and failing when I tried to do my normal “apt update” commands. I ignored these earlier, but now with the camera issues, I decided to investigate those further. I was getting messages similar to this below.
    These are NOT my actual messages, but some other users posted similar – I didn’t keep a copy of my actual error messages, but they were very similar, with phrases like “NO_PUBKEY” and “repository is not updated.” I should have been more astute, but I wasn’t:
Err stable InRelease
  The following signatures couldn't be verified because the public key is not available: NO_PUBKEY 23F3D4EA75716059
W: An error occurred during the signature verification. The repository is not updated and the previous index files will be used. GPG error: stable InRelease: The following signatures couldn't be verified because the public key is not available: NO_PUBKEY 23F3D4EA75716059
W: Failed to fetch The following signatures couldn't be verified because the public key is not available: NO_PUBKEY 23F3D4EA75716059
W: Some index files failed to download. They have been ignored, or old ones used instead.

Upon researching, I learned that I need to reinstall new github certificates. So, I performed that step. Here’s a quick link to the exact steps I took for that:
debian - “The following signatures couldn't be verified because the public key is not available: NO_PUBKEY 23F3D4EA75716059” - Super User

  1. After that, I re-ran my normal “apt update” and “apt full-upgrade” commands.

  2. Next, I reinstalled the Arducam 64mp driver, per this instruction from Arducam’s site:
    How To Use Arducam 64MP Camera On Rapberry Pi - Arducam
    Specifically, this is the driver install:
    ./ -p 64mp_pi_hawk_eye_kernel_driver

I checked the content of /boot/overlays after this step, and oddly enough, the “arducam_64mp.dtbo” file it added was identical to my OLD driver (I had saved a copy). It had reverted to an “October 31” dated file. Yesterday, during my attempts to fix this, I had somehow installed a newer dtbo file, the one named “arducam-64mp.dtbo”. But now, that file is gone…and good riddance!

  1. After that, I re-installed the Arducam versions of libcamera-dev and libcamera-apps:
./ -p libcamera_dev
./ -p libcamera_apps
  1. I then rebooted, and everything seemed to come up properly, including the creation of /dev/v4l-subdev1 (which controls the focus motor).

I was working on this remotely, and the room was too dark to test my video last night, so I finally ran test videos this morning, and they look good again. I’ll keep a close eye on it, but so far, it seems to be back to normal.

1 Like

Regarding the “bleeding edge” aspect, you are correct! I was hoping for more from this 64mp camera, but until the drivers catch up, it’s only minimally better than the V2 for video. Arducam’s website states that “due to Raspberry Pi limitations” it can only do 1080p/30fps video. I was hoping for 4K video. :frowning:

It’s also been a tad frustrating switching from the legacy V4l2 drivers to the newer Pivariety/libcamera setup. Libcamera may be the future, but so far, it doesn’t have nearly as much control over the camera as I did with V4l2. But this may just be Arducam’s version of libcamera – it appears to me that they are still loading their own limited versions of libcamera components. For example, with my old V4l2 setup (using the legacy RPI camera driver), I could change camera parameters on-the-fly while video was rolling. I could change exposure settings, contrast, rotation/flip, etc. during recordings. This allowed me to adjust the picture quality based on environmental conditions. But with libcamera-vid, it appears that you can only set those parameters when it STARTS recording. I haven’t yet found a way to adjust anything (other than focus) while video is running. I’m streaming some of this to YouTube, so it’s really inconvenient to stop libcamera-vid, change parameters, then restart it. That hiccup can potentially stop my stream.

Additionally, with the legacy RPI camera driver, it was directly accessible by “ffmpeg”, but the new Arducam Pivariety driver doesn’t seem to be recognized by ffmpeg…at least, I haven’t yet been able to access it directly. For example, with the legacy driver, I didn’t even need “raspivid” – I could just directly load the video like this:
ffmpeg -i /dev/video0 . . . {parameters}
Now, I have to pipe it like this:
libcamera-vid {parameters} | ffmpeg -i - . . .{parameters}
That’s not a showstopper, but it does add a small extra load to the CPU.

I hope it’s just my own lack of understanding, and I’m open to any advice from others. I have a working system, and I can schedule streams and get decent video now, but the transition from legacy to Pivariety/libcamera took me a few weeks to iron out. Certainly a good learning process – I’m glad this is just a hobby for me! (I’m a retired IT manager, so I have time tinker with all this)

1 Like

Thanks for this, I didn’t do the public key fix part as I haven’t got such errors, but I have reinstalled the drivers and can confirm the camera is working again.

libcamera_dev reinstallation returned one error:
W: Repository is broken: libcamera-dev:armhf (= 0.0.10) has no Size information

I tried autofocus python example from here:

and got:
Traceback (most recent call last):
File “/home/pi/Desktop/”, line 3, in
from picamera2 import Picamera2, Preview
File “/usr/local/lib/python3.9/dist-packages/picamera2/”, line 5, in
from .picamera2 import Picamera2, Preview
File “/usr/local/lib/python3.9/dist-packages/picamera2/”, line 22, in
from picamera2.encoders import Encoder, Quality, H264Encoder, MJPEGEncoder
File “/usr/local/lib/python3.9/dist-packages/picamera2/encoders/”, line 1, in
from .encoder import Encoder, Quality
File “/usr/local/lib/python3.9/dist-packages/picamera2/encoders/”, line 4, in
from v4l2 import *
ModuleNotFoundError: No module named 'v4l2

So, what I think is that they just reverted the drivers to the old ones and we are back where we were before.

1 Like

Hi Edward, I emailed you but haven’t got any response yet?


I haven’t had a chance to test this yet, but if the drivers have indeed been reverted, you should be able to autofocus using libcamera-hello --autofocus, for what it’s worth - and the resulting focus state should stay put when you run your Python code.

Definitely hoping for some word from Arducam HQ soon!

Great stuff! I’ve been preoccupied with other things (since I still have several units working just fine thankyouverymuch) so haven’t tried this out - might wait a little longer to see if/what we hear back from Edward et al. I’m hopeful they’ll get it back to It Just Works status in the next few days…!