Posting here because I’ve been banging my head against this for a while. I’m working with several Arducam modules — ov5647, imx296 (UC-717), imx477 small (UC-698 Rev D), and imx477 large (UC-517 Rev D3) — on both a Jetson Nano and an Orin Nano.
The ov5647 and imx296 both work fine on a Raspberry Pi, so the sensors themselves seem okay. On the Jetson Nano I can get some kind of picture from the imx477 through nvgstcapture, but it’s not right. The v4l2 interface gives me an RG10 single 16-bit frame instead of the promised 10 or 12 bit still color picture. If I try to grab a raw still with my own code or with v4l2-ctl, I just get something in an unknown/raw format.
The Orin Nano doesn’t seem to work with the cameras at all right now. It’s connected with a straight 22-pin parallel cable. I’ve tried a bunch of different drivers, packs, and CSI port setups without much luck. Has anyone gotten these imx477 boards working properly on these Jetson platforms?
For the Orin Nano, the problem is almost certainly the MIPI cable. You need the opposite 22-22 pin flex cable — the straight 22-pin parallel cable you have is not correct for that board. That would explain why the Orin Nano isn’t seeing the cameras at all.
On the format side, keep in mind that at the moment only Bayer RAW10 is supported on these. There aren’t other compatible formats available, so you won’t get 10/12-bit RGB directly out of v4l2. If you need a different format, customization is really the only viable route.
So first step: swap to the opposite 22-22 pin flex cable on the Orin Nano, and stick to Bayer RAW10 on the capture side.
Thanks — that cable was the issue for the Orin. After fixing the cable orientation (it was connected the wrong way), the Orin Nano now works with the UC-698. But I still have a few things that don’t add up.
The format: v4l2 reports RAW10 as RG10, but what the device actually outputs is a 16-bit word per pixel at 4032x3040 on the Orin (4056x3040 on the Nano). RG10 as I understand it is described as 8 bytes per pixel, so what I’m getting is effectively gray16. I really want RGB with 10 bits per channel.
Also, the external trigger connection isn’t clear. The UC-698 Rev D only has unmarked holes, while the UC-517 Rev D3 at least has board remarks showing where to connect. Which pins are actually used?
And can the imx296 (UC-717) work with the Orin Nano at all? Last question: for latency, which path is lower — Argus or going through v4l2?
Good to hear the Orin is up now. Let me go through these one by one.
The raw data from the sensor is Bayer RAW10. It only becomes 3-channel RGB after ISP processing, so what you’re seeing as a single 16-bit gray frame is expected until that processing happens. You need to run the RAW10 data through the ISP to get RGB with the channels you want.
For data acceptance, v4l2 is generally more stable and faster, so I’d prefer that over Argus. As for latency, the difference shouldn’t be too large, but it’s worth testing in your actual setup to see what you get.
On external trigger: neither the UC-698 nor the UC-517 supports external trigger mode, so those unmarked holes/board remarks won’t help for triggering.
Finally, the imx296 (UC-717) is not currently supported by Jetson. To use it you’d need to adapt the source code following the Jetson official documentation, or have Arducam do the customization for you.