Raspberry Pi HQ Camera in Jetson Nano

Hi Erich,

Since NVIDIA is integrating the driver by default in Jetpack for Jetson Nano 2G we expect it will happen again with the 4GB board and work out of the box. We are not aware of problems with the driver in jetpack 4.4.1, however, one of our engineers will give it a try and report you back if it is a problem in the driver or a configuration issue.



Hi sagain,

I tried a fresh install of the JetPack 4.4.1 on B01 board with HQ camera (R8 removed).
After installing, I did an update & upgrade to be on the latest versions.

After installing the new driver with option A for nano, no boot is possible.
I have now an UART converter connected, here is the boot-log over UART in the attached txt file.

nano_boot_log_error_477_441.txt (27.8 KB)
After the last line in the logging there is a big delay, then automatic reboot.

Hi erich,

I am having the same exact issue…updated the software of the nano today, then the camera did not work any more, I reinstalled the kernels for the camera support and now it won’t boot again…

It seems like with the latest update the kernel won’t run.

Hopefully someone sees this and brings a new version of the kernel to bring back the support.

Thanks for all helping!


I have two Rasp Pi HQ cameras working on my Jetson Nano.
What I’m having trouble with is setting an exposure time.
Has this been tested?

I got the module from:

and installed JetPack:
Jetpack R32, REVISION: 3.1 via the SDK Manager.

I have tried all variations of nvarguscamerasrc but the exposuretimerange does not change the exposure, even when aelock=true is set.

I tried gst-inspect-1.0 nvarguscamerasrc to view more options but didn’t find anything useful.

Any ideas?

Changing the gain works! 100%

Thank you

Hi David,

are there any news from your side regarding HQ camera on 4.4.1 with latest updates?
My project here is complete standing without a working camera (a professional customer project!).


Hi Erich,

Sorry for the delay. One of engineers is now working on this, the end of year break delayed the update but this week we are back on this. In the next couple of weeks it should be ready.



Thank you so much for your effort.

I have little questions about using the drivers.
Could you let me know the Pixel Readout Rate of the drivers?
Where can I find the information?
Can we decrease the rate(reading less pixels per time)?

Thank you.


We have switched to the RidgeRun drivers and still can’t change the exposure time. Any advice?

Thank you


Exposure time GStreamer pipeline can be locked to the frame rate, or at least not greater than it (360 degree shutter).

If you think about it, it makes sense. In a video pipeline the shutter can’t be open for longer than a frame. You can try setting exposure after the pipeline starts on the Argus source but in my tests this breaks things.

For reference I’m working with the IMX 477 by Arducam and RidgeRun’s drivers using the patch method.

Thanks, I’ll give it a try.
I tried setting the frame rate very low and modulate the exposure, and still no luck. Autoexposure works, it somehow modulates the exposure time. Also changing the exposure time on the camera on the Pi works (but not using gstreamer).

Wondered if autoexposure somehow works with exposure time longer than the frame rate with some kind of sliding window buffering algorithm.

Hi All,

Thanks for the patience, the driver is already ported to JP 4.4.1 and tomorrow we will just do a review and then make it available.

@siderskiy, can you provide more details on how you are testing? We would like to give it a try, the driver has a exposure and the ISP makes use of that control.



IIRC, it does auto-gain by default unless you set both values of the ranges to the same, so there are at least these in play:

 $ gst-inspect-1.0 nvarguscamerasrc
  exposuretimerange   : Property to adjust exposure time range in nanoseconds                   Use string with values of Exposure Time Range (low, high)                        in that order, to set the property.                     eg: exposuretimerange="34000 358733000"
                        flags: readable, writable
                        String. Default: null
  gainrange           : Property to adjust gain range                   Use string with values of Gain Time Range (low, high)   in that order, to set the property.                      eg: gainrange="1 16"
                        flags: readable, writable
                        String. Default: null
  ispdigitalgainrange : Property to adjust digital gain range                   Use string with values of ISP Digital Gain Range (low, high)                     in that order, to set the property.                     eg: ispdigitalgainrange="1 8"
                        flags: readable, writable
                        String. Default: null
  exposurecompensation: property to adjust exposure compensation
                        flags: readable, writable
                        Float. Range:              -2 -               2 Default:               0 

For details of what exactly those do, you’ll have to dive into the source, which is in the public sources tarball, IIRC. To me at least, it’s not at all clear what these properties do.

Thank you @mdegans and @DavidSoto-RidgeRun,

TLDR; Real exposure time range for sensor mode 1: [34000,33333333]

With @aaronlozhkin:

We did an exhaustive test and here is the story.

  1. When using gst-launch-1.0 nvarguscamerasrc … it shows that both sensor modes have an exposure range of [13000,683709000]. However, both of those values output a warning ‘invalid time range’, and the camera defaults to some default exposure time.

gst-launch-1.0 nvarguscamerasrc exposuretimerange="13000 13000" wbmode=0 sensor_id=0 sensor-mode=1 ispdigitalgainrange="1 1" aelock=true gainrange="4 4" ! nvoverlaysink


GST_ARGUS: NvArgusCameraSrc: Setting Exposure Time Range : 13000 13000
GST_ARGUS: Invalid Exposure Time Range Input

  1. The values that don’t produce an error are [34000,358733008]. Suspiciously close to the gst-inspect-1.0 nvarguscamerasrc example.

  2. For sensor-mode=1: The exposure values from [34000,33333333] actually change the exposure time. However, the range [33333334,358733008] does not produce a warning message and defaults the exposure time to some arbitrary default value which seems to be relatively dim.

Here are some extra questions:
If sensor-mode=1 is 60 fps, how is it that we can set the exposure time to 33,333,333ns (i.e. 1/30s), instead of 16,666,666ns

How can I have an exposure time over 1/30s. My application is very low light.