Hey everyone, I’ve been fighting this for a while and could really use some help. I’m trying to get the Arducam Quad-Camera Kit B0388 (IMX519) working on a Jetson Orin Nano running Jetpack 6.0, following the camarray quick-start docs. When I launch the 1920x1080 nvarguscamerasrc pipeline at FRAMERATE=60 I just get a blank window and a pile of errors.
Relevant part of the log:
ST_ARGUS: Setup Complete, Starting captures for 0 seconds
GST_ARGUS: Starting repeat capture requests.
CONSUMER: Producer has connected; continuing.
nvbuf_utils: dmabuf_fd -1 mapped entry NOT found
Error generated. /dvs/git/dirty/git-master_linux/multimedia/nvgstreamer/gst-nvarguscamera/gstnvarguscamerasrc.cpp, threadExecute:732 NvBufSurfaceFromFd Failed.
Error generated. /dvs/git/dirty/git-master_linux/multimedia/nvgstreamer/gst-nvarguscamera/gstnvarguscamerasrc.cpp, threadFunction:243 (propagating)
Redistribute latency…
WARNING: from element /GstPipeline:pipeline0/GstEglGlesSink:eglglessink0: Pipeline construction is invalid, please add queues.
… Got EOS from element “pipeline0”.
Thanks for posting the full log. The NvBufSurfaceFromFd Failed error means the buffer that nvarguscamerasrc is trying to map has a bad fd (-1), so the frame never makes it downstream and the sink ends up with nothing to show. Before we dig deeper, can you try dropping FRAMERATE to 30 and re-running the exact same pipeline? The docs mention 1080p mode can go from 2 to 60, and 60 can be marginal depending on the setup.
Set FRAMERATE=30 and re-ran it - same blank screen and same NvBufSurfaceFromFd Failed error.
One thing that jumped out: the GST_ARGUS output still reports Frame Rate = 59.999999 even though I passed 30. Full run shows:
GST_ARGUS: Available Sensor modes :
4656 x 3496 FR = 9.000000 fps Duration = 111111112 …
3840 x 2160 FR = 17.000000 fps Duration = 58823528 …
1920 x 1080 FR = 59.999999 fps Duration = 16666667 …
1280 x 720 FR = 120.000005 fps Duration = 8333333 …
GST_ARGUS: Running with following settings:
Camera index = 0
Camera mode = 2
Output Stream W = 1920 H = 1080
Frame Rate = 59.999999
Then the same nvbuf_utils dmabuf_fd -1 mapped entry NOT found, NvBufSurfaceFromFd Failed, and threadFunction:243 (propagating) errors, then EOS.
Hardware note: both the cam array module and the Jetson use 0.5mm pitch 22-pin connectors. I’ve tested two different cables - a Type A cable that got really warm when the device powered on, and a Type B cable which is the one producing the errors above.
That Frame Rate = 59.999999 line is worth paying attention to. It looks like the driver is still selecting the 60fps sensor mode for 1080p regardless of what you pass, and your v4l2 output only lists a 60.000 fps interval for 1920x1080 - there’s no real 30fps mode exposed for that resolution. So changing FRAMERATE probably isn’t going to fix this.
Also, a cable getting warm on power-up is a big red flag. That usually means pins are misaligned or the cable has a wrong pinout, which can feed current somewhere it shouldn’t go. Which cable is connected right now, and can you double-check the ribbon orientation and that it’s fully seated on both ends?
I tried reinstalling the camera driver to rule out a bad install, and now it’s even worse - the camera isn’t detected at all. Now I get ‘No cameras available’ right after going to PLAYING:
Error generated. /dvs/git/dirty/git-master_linux/multimedia/nvgstreamer/gst-nvarguscamera/gstnvarguscamerasrc.cpp, execute:792 No cameras available
Followed by the same queue/latency warnings and EOS. So whatever buffer issue was happening before, now the sensor isn’t even showing up.
‘No cameras available’ means the driver can’t enumerate the sensor over I2C at all, so we’ve gone from a buffer-handoff problem to a detection problem. That points more at the physical layer than the GStreamer pipeline. Given the Type A cable heated up earlier, I’d treat that cable as suspect and not use it again. A few things to check:
Which cable is in use right now?
Is the ribbon fully inserted and locked in both connectors, with pin 1 aligned?
Any bent pins or scorch marks on either connector after the Type A cable got hot?
If you still have the cable that shipped with the kit, reseat both ends with that one and run v4l2-ctl --list-formats-ext again to see if the sensor enumerates.
At this point I want to rule out cabling completely. Can anyone recommend reliable 0.5mm pitch cables for connecting the cam array module to the Jetson Orin? The ones I’ve got are generic and I’m not confident in them anymore.
For this kit you need 22-pin 0.5mm pitch FFC/FPC cables with the contacts on the correct side for the connectors - same-side vs opposite-side contacts matters, and it’s easy to buy the wrong one. Generic CD/DVD-player ribbons may have the right pitch but the wrong contact orientation, which could explain both the heat and the bad buffer/visibility behavior. Best move is to use the cables Arducam supplies/recommends for the B0388 kit rather than generic ones. Whichever cable you use, verify the contact side and pin-1 orientation on both the module and the Jetson before powering up.
Thanks for the help. Honestly I’ve spent enough time on this - I’m going to switch to a Raspberry Pi 5 for this camera kit instead of continuing with the Jetson Orin Nano.
Fair enough. For anyone else who lands here: the summary of where this got to is that at 1080p the sensor only exposes a 60fps mode (setting FRAMERATE=30 still selects 59.999999 fps), the NvBufSurfaceFromFd Failed error at 60fps pointed at a buffer-handoff problem, and after a driver reinstall the sensor stopped enumerating entirely (‘No cameras available’). The Type A cable heating up made the cabling/connector the prime suspect. Since you’re moving to the RPi5, make sure to use the correct 22-pin 0.5mm cable and orientation for that board too. Good luck!