Hi everyone, I recently picked up two ArduCAM modules — a B0310 and a B0482 — and I’m having trouble getting either of them to work. One thing that caught my eye: the boards I received are marked UC-B47, but the product page on the distributor’s site still shows UC-A65. I’ve attached some photos of what I received. Is the UC-B47 a different hardware revision? Could that be causing issues? They’re both dead when I try to use them with my Pi.
Good question. The UC-A65 → UC-B47 change is just a board revision update that happened back in June 2024 — both B0310 and B0482 share the same board design, and there’s no functional difference between the two revisions. The distributor’s product images are simply outdated, so the visual difference is nothing to worry about. Now, let’s dig into the actual problem. Can you share a few details: what Raspberry Pi model are you using, which OS version, and what exact errors or symptoms are you seeing when you try to use the cameras?
I’m on a Raspberry Pi 5 running the latest Raspberry Pi OS Bookworm (fully updated). I’ve enabled the camera interface through raspi-config already. When I run the usual libcamera commands I get ‘command not found’ across the board:
$ libcamera-hello
bash: libcamera-hello: command not found
$ libcamera-still -o test.jpg
bash: libcamera-still: command not found
$ libcamera-vid -t 5000 -o test.h264
bash: libcamera-vid: command not found
I’ve also attached a screenshot of what the board looks like. Starting to wonder if there’s some driver or overlay issue with these newer boards.
Thanks for the terminal output — that’s very helpful. I have a strong suspicion this isn’t a driver or overlay problem at all. The latest Bookworm OS made a significant change: the Raspberry Pi team has been migrating from the older libcamera-* command naming to rpicam-*. Can you try the following and report back?
rpicam-hello
rpicam-still -o test.jpg
If the hardware is fine, these should work. This will help narrow things down quickly.
Ok, interesting — rpicam-hello actually works! I get a live preview window and everything. So the camera sensor and the board seem fine. But here’s the problem: I’ve got a bunch of existing Python scripts and shell scripts that call libcamera-still and libcamera-vid, and I’m following some tutorials that reference those commands too. Is there any way to get the old libcamera-* commands back, or do I just need to rewrite everything?
That confirms exactly what I expected — your hardware is fine. Here’s what’s happening: the latest Bookworm update removed the symbolic links that used to map libcamera-* to rpicam-*. If you poke around in /usr/bin/, you’ll notice the old libcamera-hello, libcamera-still, etc. symlinks are simply gone. This is documented upstream by the Raspberry Pi folks over at the rpicam-apps repo on GitHub.
In terms of functionality, rpicam and libcamera are identical under the hood — it’s just a naming change. So the camera access itself is not broken, it’s just that software expecting the libcamera-* command names can no longer find them.
I see, that makes sense. So just to be clear — the UC-B47 board revision has nothing to do with this? I was pretty suspicious when the boards didn’t match the product images. Also, is there an official workaround or should I just update all my scripts to use rpicam-*?
Correct, the UC-B47 revision is not related to this issue at all. It’s functionally identical to UC-A65 — same pinout, same sensor interface, same everything. The board revision happened in mid-2024 and the distributor simply hasn’t updated their product photography yet. Your problem is 100% a software/OS compatibility issue introduced by Bookworm dropping the libcamera symlink.
As for workarounds, you’ve got a couple of options:
- Update your scripts and any software you use to call
rpicam-still,rpicam-vid,rpicam-hello, etc. instead of the oldlibcamera-*names. - Manually recreate the symlinks if you have legacy software that you can’t easily modify.
We’re currently in contact with other users who are testing these approaches to make sure everything behaves as expected across different setups. Could you give one of these workarounds a try on your end and let us know how it goes? Your results would be really helpful in confirming the full picture before we publish a final advisory on this.