Hi all, I’m trying to set up an Arducam IMX462 (B0333) on a Raspberry Pi running Debian Bullseye 64-bit and I’m stuck. In v4l2 mode the camera barely exposes anything, and gstreamer is basically unusable — the pipeline just won’t complete.
v4l2-ctl --list-formats-ext only shows two 10-bit Bayer formats, pRAA and RG10, and gstreamer doesn’t support either of them.
My overlay in /boot/config.txt is set up like this:
One thing I tried: switching to the libcamerasrc source in gstreamer with just dtoverlay=arducam-pivariety, and that exposed way more camera capabilities. My use case is capturing night sky objects on video, so I need the full resolution and format control. Any pointers?
Thanks for the details. Could you paste the exact gstreamer pipeline you’re trying and the logs you get when it fails? That will help narrow down where it’s breaking.
To set expectations: Arducam doesn’t really develop or explore Gstreamer on Raspberry Pi. libcamera is much more compatible on the Pi, which is why the libcamerasrc path behaves better. I don’t have any Gstreamer-specific docs for the Pi to share — the recommended stack is libcamera.
Looking at your log, the camera is actually being configured correctly (1920x1080-SRGGB10_1X10 selected, registered to /dev/media4), so the pipeline is mostly working as far as libcamera is concerned. I’d stick with libcamera-based pipelines rather than fighting the raw v4l2 Bayer formats.
That matches what I found. One thing that’s really unclear in the docs though: they don’t state that after setting dtoverlay=arducam-pivariety the system should be ready for normal usage in libcamera/gstreamer-based apps. The docs gave me the impression that a lot of software stacks still needed the overlay configured as dtoverlay=arducam-pivariety,media_controller=0.
Support told me Arducam doesn’t explore Gstreamer on Raspberry Pi because libcamera is more compatible — but the doc ambiguity sent me in circles for a while.
I’ll pass that feedback along. To clarify for this thread: for libcamera-based usage you want just dtoverlay=arducam-pivariety. The media_controller=0 variant is the legacy v4l2 media-controller path, which is exactly what limits you to the raw 10-bit Bayer formats (pRAA/RG10) that gstreamer can’t consume. With the plain overlay, libcamera drives the sensor and ISP properly, which is why you saw many more capabilities.
Switching topics a bit — I’ve also got some IMX477 cameras on a Jetson Orin Nano Developer Kit. I understood the IMX477 should be compatible out of the box, but the cameras I received need a special kernel and I/O setup to function. I need PWM signals on the dev kit’s GPIOs, but I can’t get PWM and the cameras working at the same time. With the special kernel/I/O setup the cameras work, but then PWM doesn’t.
Can you test with the NVIDIA native IMX477 camera driver and see whether the same problem reproduces? That would tell us if the conflict is specific to the special kernel/I/O setup. Here’s the application note for enabling the native driver through Jetson-IO:
Thanks, I’ll try the native driver. While I’m at it — I’m also seeing black vertical lines in the picture from one camera of a B0266 Arducam 1MP 2 stereoscopic camera bundle kit (two OV9281 global shutter monochrome modules + Camarray stereo camera HAT). One camera’s image has these disturbances.
Could you tell me the exact command you used to capture that raw picture showing the black vertical lines? The capture method matters for figuring out whether it’s a software/capture issue or the camera itself.
Just so you know, ROS support has been discontinued, so I can’t offer much ROS-specific help. To determine whether the vertical stripes are a hardware issue or a driver/software issue, please run the official arducam_displayer.py script and check whether the stripes still appear.
Thanks for confirming. Next, let’s isolate the hardware. Swap the two cameras on the HAT board and see whether the problem follows a specific camera or stays with the same HAT port. That will tell us if it’s a camera module or the HAT board.
OK, here’s what I found. At first I thought it might be the Camarray HAT, so I replaced it with another Camarray HAT I had — same vertical line issue. Then I swapped the two camera modules on the HAT board, and the vertical line follows one specific camera (camera A), not the port.
That strongly suggests camera A itself is faulty. To confirm, take a known-good camera from the other Camarray HAT module and put it in place of camera A on the original HAT. If the preview is clean, then camera A is the culprit.
Confirmed. I replaced camera A with a known-good camera from the other HAT, and the picture now looks perfect. So it was definitely that one camera module.
Great, glad that sorted it. To summarize the vertical line issue: the black vertical lines were caused by a faulty camera module (camera A), not the HAT board and not the ROS/driver software. Replacing that module resolved it.
As for the earlier items: on the Pi, stick with libcamera and the plain dtoverlay=arducam-pivariety overlay (avoid the media_controller=0 v4l2 path for gstreamer), and on the Jetson Orin Nano, compare the special kernel/I/O setup against the NVIDIA native IMX477 driver to narrow down the PWM conflict.