Arducam camera detected but no image or live stream on Jetson Nano

Nvidia Jetson Cameras
1

Hey everyone, I’m having trouble getting my Arducam Vision Automatic Switching All-Day camera working on a Jetson Nano. The system seems to detect the camera — it shows up under /dev/video0 — but I can’t actually capture any images, stream video, or view the camera feed at all. Every app I try just shows a black screen or times out.

I bought this camera specifically for the all-day switching feature, but I’m stuck at square one. Does anyone have working drivers or setup instructions for this camera on the Nano? Not sure if I’m missing a driver or if there’s a specific pipeline I need to use.

2

Welcome to the forum! This sounds like a driver/pipeline configuration issue — fairly common with third-party MIPI cameras on Jetson platforms.

Before we dive into troubleshooting, can you share some details about your environment? Specifically:

  • JetPack / L4T version
  • Kernel version
  • Ubuntu release
  • Python version (if you’re using Python for capture)

You can grab most of this with:

cat /etc/nv_tegra_release
uname -r
lsb_release -a
python3 --version

That’ll help narrow down what we’re working with.

3

Sure, here’s what I’m running:

  • Board: Jetson Nano (t210ref)
  • JetPack: 4.6.1
  • L4T: 32.6.1
  • Kernel: 4.9.253-tegra
  • Ubuntu: 20.04
  • Python: 3.8.10

And yeah, I already checked — /dev/video0 is definitely there:

$ ls /dev/video*
/dev/video0

So the hardware side seems fine, but still nothing works when I try to actually use it.

4

Good, so the camera is enumerating on the CSI bus correctly. Let’s dig a little deeper — can you run v4l2-ctl to list the supported formats and resolutions? This will tell us exactly what the V4L2 driver is exposing:

v4l2-ctl --device=/dev/video0 --list-formats-ext

Paste the output here. It’ll help confirm whether the sensor driver is loaded properly and what pixel format is being advertised.

5

Here you go:

$ v4l2-ctl --device=/dev/video0 --list-formats-ext
Type: Video Capture

[0]: 'RG10' (10-bit Bayer RGRG/GBGB)
    Size: Discrete 4032x3040
        Interval: Discrete 0.033s (30.000 fps)
    Size: Discrete 3840x2160
        Interval: Discrete 0.033s (30.000 fps)
    Size: Discrete 1920x1080
        Interval: Discrete 0.017s (60.000 fps)

So it’s clearly talking to the sensor — RG10 Bayer at up to 4032x3040 @ 30fps. But despite this, every attempt to capture a frame or stream still fails. I’ve tried basic GStreamer pipelines with v4l2src, nvgstcapture, and a few Python OpenCV snippets — all either hang or return empty frames. Pretty frustrating since everything looks like it should work.

6

Alright, so here’s my analysis of what’s going on:

The camera is physically present on the I2C/CSI bus and the V4L2 driver is loaded — /dev/video0 is there and v4l2-ctl correctly enumerates RG10 Bayer formats at the expected resolutions and framerates for the IMX477 sensor. That’s the good news.

The bad news: detection and format enumeration are only half the battle. The capture pipeline is where things are breaking down. On JetPack 4.6.1, this usually comes down to one of a few things:

  1. Missing or incorrect device tree overlay — the IMX477 needs a proper DT overlay loaded so the CSI/ISP pipeline knows how to handle the sensor’s data stream.
  2. Driver-level configuration gap — the sensor may be registered in V4L2 but the ISP (Image Signal Processor) path through Argus isn’t wired up correctly for a non-NVIDIA camera.
  3. Incompatible GStreamer/Argus pipeline — nvgstcapture and Argus-based pipelines expect specific camera plugin configurations; a third-party sensor may not have those registered out of the box.

The RG10 Bayer output means the sensor is sending raw Bayer data, and something needs to debayer it — either the ISP hardware or software. If the pipeline doesn’t know how to route RG10 through the ISP, you’ll get exactly what you’re seeing: detection works, capture fails silently.

Let’s try a more targeted test. I’ve put together a quick-start script specifically for troubleshooting Jetson camera pipelines:

GitHub - Dion4cen/jetson_quick_start_script · GitHub

Clone that repo and follow the instructions in there. The script will attempt to:

  • Verify the sensor device tree status
  • Test raw V4L2 capture
  • Try a basic Argus/nvgstcapture pipeline if supported

Run through it and let me know what output you get — especially any error messages during the capture attempts. That should give us a clearer picture of where exactly the pipeline is failing.