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.
-David
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.
BR
Erich
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!
David
Hello,
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
Valentin
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!).
BR
Erich
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.
-David
Hi.
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.
Hello,
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.
-David
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.
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
Out:
GST_ARGUS: NvArgusCameraSrc: Setting Exposure Time Range : 13000 13000
GST_ARGUS: Invalid Exposure Time Range Input
The values that donāt produce an error are [34000,358733008]. Suspiciously close to the gst-inspect-1.0 nvarguscamerasrc example.
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.
