Hi all, hoping someone has seen this before. We’ve got three Arducam B0485 cameras (the 13MP USB3 models) and we’re running them on an Nvidia Jetson — specifically a reComputer J4012. When a camera is plugged into the Jetson, it’s only ever detected as USB 2.0, and we’re limited to 720p @ 10fps. The same camera plugged into an Ubuntu server gets correctly identified as USB 3.0 with all resolutions available, so the camera itself seems fine.
Things I’ve already tried:
Different USB cables
Every USB port on the board
Removed all other USB devices
Tested on multiple reComputer units
Various plug/unplug patterns, including rebooting with and without the camera connected
I’m wondering if it’s power-related (maybe a powered hub would help) or if the camera is advertising a max bitrate that’s too high for the bus. I also came across these while digging around:
Welcome! Let’s rule out the host side first before we go down the kernel or bitrate path. Two quick checks:
Can you confirm the Jetson board you’re plugging into actually has a USB 3.0 interface? I know the reComputer J4012 advertises 4x USB 3.2 ports, but just double-check which physical port you’re on.
With only one UVC 3.0 device connected (no other USB devices), is it still recognized as USB 2.0, or does it come up as USB 3.0?
That’ll tell us whether this is a host capability problem or something specific to how the camera is connecting.
Thanks for the reply. Yes, the reComputer J4012 has 4x USB 3.2 ports (see https://www.seeedstudio.com/reComputer-J4012-p-5586.html). And even with only one camera connected, it’s not recognized at USB 3.0 — still comes up as USB 2.0.
Understood. Can you run lsusb -t with the camera connected on the Jetson and paste the output? That shows the USB topology and what speed each device actually negotiated, which should confirm exactly where the downgrade is happening.
Here’s what I found from a bunch of connector tests, plus the dmesg logs from a manual unplug/replug:
[ 597.131696] usb 2-1.3: new SuperSpeed Gen 1 USB device number 4 using tegra-xusb
[ 597.153536] usb 2-1.3: LPM exit latency is zeroed, disabling LPM.
[ 597.155588] usb 2-1.3: New USB device found, idVendor=04b4, idProduct=0485, bcdDevice= 0.00
[ 597.155591] usb 2-1.3: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[ 597.155593] usb 2-1.3: Product: Arducam B0485 (USB3 13MP)
[ 597.155594] usb 2-1.3: Manufacturer: Arducam
[ 597.155595] usb 2-1.3: SerialNumber: Arducam_20240708_0001
[ 597.193747] uvcvideo: Found UVC 1.10 device Arducam B0485 (USB3 13MP) (04b4:0485)
[ 597.200385] input: Arducam B0485 (USB3 13MP) as /devices/platform/3610000.xhci/usb2/2-1/2-1.3/2-1.3:1.0/input/input5
[ 597.200464] usbcore: registered new interface driver uvcvideo
[ 597.200465] USB Video Class driver (1.1.1)
I noticed something interesting about how the connector is seated:
USB-A stays in the Jetson, and I add/remove the camera via its USB-C connector → always connects as USB 3.0 (tested 10 times, worked every time).
USB-C stays in the camera, and I add/remove the USB-A end from the computer → sometimes demoted to USB 2.0 (tested 10 times, demoted 5 times).
Fast insertion generally gives USB 3.0. If I insert it partially (most of the way in, but the last few mm) and then slowly ‘click’ it into place, it comes up as USB 2.0. Maybe the slow connection doesn’t give enough time for the SuperSpeed handshake?
Second problem: the camera doesn’t show up on boot at all. Unbinding/binding the host doesn’t help, and neither does resetting power. Nothing appears in dmesg until I manually unplug and replug.
Environment notes: the Jetson takes a while to boot and seems to power cycle a few times. Other devices (like a Zed camera) show up fine on boot. USB auto-suspend is disabled.
Thanks for the detailed write-up. I tried to reproduce this on my Jetson Orin NX, and I do get the camera info in dmesg when it boots, so I’m not too worried about that part yet. Question for you: after boot, can you actually access the camera (open the video device) without unplugging/replugging it? Or is it completely absent until you reseat the cable?
On our setup it’s completely absent until I reseat the cable. I restarted the machine with the camera plugged in and it was not detected. No dmesg logs until a manual unplug/replug. Unbinding/binding the host doesn’t work, and neither does resetting power. That’s a real problem for us because this is going into a production device where unplugging/replugging isn’t possible.
To restate the connector behavior:
USB-A in the Jetson, add/remove via USB-C → USB 3.0 every time (10/10).
USB-C in the camera, add/remove USB-A from the computer → demoted to USB 2.0 half the time (5/10).
Fast insertion → USB 3.0; slow partial insertion then click → USB 2.0.
The Zed camera enumerates fine on boot, so this looks specific to the Arducam firmware. USB auto-suspend is already disabled.
Thanks, that’s clear. Since the boot enumeration is the main blocker and it’s hard to diagnose from logs alone, I’d like to look at the device directly. I’ve sent you the remote support details in a private message — please check your messages, install the tool, and send the access details back privately so we can schedule a session.
Done. I’ve restarted the machine with the camera plugged in (still not detected, as expected) and I’ve sent you the remote access details in a private message.
Thanks for the session today. After that, the camera kept working through more restarts and testing, so I think we’ve figured it out. One question I forgot to ask: is that button on the back of the camera a reset button?
Happy to hear it’s still holding up. To summarize what we found during the session: removing the metal shell of the camera module made it keep working. The shell was the culprit — once it was removed, the camera stayed stable across additional restarts and testing. If you can reassemble the shell, go ahead; if you’re not sure how, I’ll send you the assembly manual. And to answer your question: no, the button on the back isn’t a reset button — it’s there for Arducam to debug the firmware. Reach out again if the problem comes back.