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.
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.
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.
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!).
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.
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)?
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.
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.
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.
In:
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.
we are using the RidgeRun drivers on Jetson Nano DK (JP4.4/L4T 32.4.3), but having a little issue (the video starts to blink yellow) when accidentally looking at the sun (which is very common in our use case).
This was recorded from our system using gstreamer:
We were able to reproduce it on lab tests using a flashlight:
I donāt know if itās really a driver issue or just the expected behaviour when these conditions are met. Anyways, as we are not experts on the field of digital video, some advice would be nice.
As context, we are using nvarguscamerasrc with default parameters, maybe thereās some tuning we can try there?
Iām happy to announce that the IMX477 driver porting for Jetpack 4.4.1 is ready for you all to give it a try. You can check it out in our Github repo:
Thanks for the new version, its working here on an full updated nano 4GB!
I marked the 2 files with apt-mark hold so that they are not update.
Just in time, we have an telco today with an potential customer - so wen can report that we can start with the demonstrator application programming.
I want to start the jetson_io.py tool, but it is not starting correctly.
The window shortly is visible for a fraction of a second and then it dissapers.
No error message.
I tried the init.py hack and the dtb file is from your hack in the /boot/dtb directory.
Could there be a problem with your hack and the jetson_io tool?
Auto exposure still works even though I disabled auto exposure and set the exposure timerange.
When I see the laser beam, It flashes like @jbarria and stops.