Hello,
After configuring the test set as shown in the image below
I am testing the exposure value using v4l2-ctl.
However, the imx327 NANO camera is overexposed.
I am using the same sensor device driver for the imx327 NANO and imx327 Xavier NX cameras.
Can you give me some advice on why this is happening?
| camera name | exposure |
|---|---|
| imx327 Xavier NX | 178 |
| imx327 NANO | 2433 |
| imx219 NANO | 307 |
Thank you.
hello mszeta,
AE is not running by v4l standard controls.
are you sending ET setting via v4l2-ctl command-line?
you may also examine your default mode settings,
thanks
Hello, @JerryChang
If you look at the document below nvcamerasrc auto-exposure=1 aeLock=true
It says that auto-exposure can be disabled by specifying this
If you check with gst-inspect-1.0 nvarguscamerasrc , you cannot check the setting called auto-exposure. Did the settings change?
I want to know how to disable auto exposure when using nvarguscamerasrc.
Thank you.
hello mszeta,
what’s your capture pipeline, don’t you use v4l2-ctl in you 1st post?
you may execute $ gst-inspect-1.0 nvarguscamerasrc for checking element properties. it’s aelock=1 to set the auto exposure lock.
Hello,
The capture pipeline is shown below.
./test-launch “nvarguscamerasrc ! video/x-raw(memory:NVMM),width=3820, height=2464, framerate=21/1, format=NV12 ! nvvidconv flip-method=0 ! nvv4l2h264enc ! h264parse ! rtph264pay name=pay0 pt=96”
Thank you.
hello mszeta,
I cannot confirm what’s your test-launch calling, but this looks like gst-pipeline.
you may try nvarguscamerasrc with options to adjust exposure time range
for example, exposuretimerange="34000 358733000" the unit is in nanoseconds.
hello mszeta,
you may examine your device tree settings, it might be something wrong in your min/max exposure time configurations.
Hello, @JerryChang
The exposure min max of the imx327 sensor is as follows.
Xavier NX camera does not cause overexposure even if exposuretimerange is not included with the nvarguscamerasrc option.
Nano camera is overexposed if you don’t set exposuretimerange with nvarguscamerasrc option.
Could this be a problem with the min and max settings of the exposure value in the device driver?
manager@manager-desktop:~$ v4l2-ctl -L
Camera Controls
group_hold 0x009a2003 (bool) : default=0 value=0 flags=execute-on-write
sensor_mode 0x009a2008 (int64) : min=0 max=2 step=1 default=0 value=0 flags=slider
gain 0x009a2009 (int64) : min=0 max=714 step=3 default=0 value=9 flags=slider
exposure 0x009a200a (int64) : min=30 max=660000 step=1 default=33334 value=778 flags=slider
frame_rate 0x009a200b (int64) : min=2000000 max=33000000 step=1 default=30000000 value=21000000 flags=slider
bypass_mode 0x009a2064 (intmenu): min=0 max=1 default=0 value=1
0: 0 (0x0)
1: 1 (0x1)
override_enable 0x009a2065 (intmenu): min=0 max=1 default=0 value=1
0: 0 (0x0)
1: 1 (0x1)
height_align 0x009a2066 (int) : min=1 max=16 step=1 default=1 value=1
size_align 0x009a2067 (intmenu): min=0 max=2 default=0 value=0
0: 1 (0x1)
1: 65536 (0x10000)
2: 131072 (0x20000)
write_isp_format 0x009a2068 (bool) : default=0 value=0
sensor_signal_properties 0x009a2069 (u32) : min=0 max=4294967295 step=1 default=0 [30][18] flags=read-only, has-payload
sensor_image_properties 0x009a206a (u32) : min=0 max=4294967295 step=1 default=0 [30][16] flags=read-only, has-payload
sensor_control_properties 0x009a206b (u32) : min=0 max=4294967295 step=1 default=0 [30][36] flags=read-only, has-payload
sensor_dv_timings 0x009a206c (u32) : min=0 max=4294967295 step=1 default=0 [30][16] flags=read-only, has-payload
low_latency_mode 0x009a206d (bool) : default=0 value=0
preferred_stride 0x009a206e (int) : min=0 max=65535 step=1 default=0 value=0
sensor_modes 0x009a2082 (int) : min=0 max=30 step=1 default=30 value=2 flags=read-only
Thank you.
hello mszeta,
may I also know what’s the JetPack release version between those Nano and Xavier platforms?
Hello, @JerryChang
NANO : 4.6
cat /etc/nv_tegra_release
NX : 4.6.1
cat /etc/nv_tegra_release
Thank you.
Hello, @JerryChang
Can it work differently depending on the jetpack version?
Were there any issues related to auto exposure of nvargus in jetpack 4.6?
Thank you.
hello mszeta,
since Xavier NX is using later release and it works normally.
for checking this issue, are you able moving Nano series to latest release for confirmation.
or, please add exposuretimerange into pipeline for your camera solutions.
thanks
Hello, @JerryChang
Upgraded from R32.6.1 to R32.7.2.
From the Jetson Linux Driver Package Software Features document
I followed Updating a Jetson Device
deb https://repo.download.nvidia.com/jetson/common r32.7 main
deb https://repo.download.nvidia.com/jetson/t210 r32.7 main
After editing the source list with
I did sudo apt dist-upgrade.
No reboot was done.
manager@manager-desktop:~$ cat /etc/nv_tegra_release
R32 (release), REVISION: 7.2, GCID: 30192233, BOARD: t210ref, EABI: aarch64, DATE: Wed Apr 20 21:34:48 UTC 2022
If I don’t set the exposurerange option, you’ll still be overexposed.
Can you please tell me how can i solve this problem?
Thank you.
Hello, @JerryChang
I see /dev/video0
When the test-launch program is executed, the following error message appears.
How should I approach to solve this problem?
dmesg is also attached.
manager@manager-desktop:~$ ls /dev/video0
/dev/video0
manager@manager-desktop:~$ ./test-launch "nvarguscamerasrc ! video/x-raw(memory:NVMM),width=3820, height=2464, framerate=21/1, format=NV12 ! nvvidconv flip-method=0 ! nvv4l2h264enc ! h264parse ! rtph264pay name=pay0 pt=96"
stream ready at rtsp://127.0.0.1:8554/test
nvbuf_utils: Could not get EGL display connection
nvbuf_utils: ERROR getting proc addr of eglCreateImageKHR
nvbuf_utils: ERROR getting proc addr of eglDestroyImageKHR
Opening in BLOCKING MODE
Error generated. /dvs/git/dirty/git-master_linux/multimedia/nvgstreamer/gst-nvarguscamera/gstnvarguscamerasrc.cpp, execute:740 No cameras available
NvMMLiteOpen : Block : BlockType = 4
===== NVMEDIA: NVENC =====
NvMMLiteBlockCreate : Block : BlockType = 4
Opening in BLOCKING MODE
Error generated. /dvs/git/dirty/git-master_linux/multimedia/nvgstreamer/gst-nvarguscamera/gstnvarguscamerasrc.cpp, execute:740 No cameras available
NvMMLiteOpen : Block : BlockType = 4
===== NVMEDIA: NVENC =====
NvMMLiteBlockCreate : Block : BlockType = 4
Opening in BLOCKING MODE
Error generated. /dvs/git/dirty/git-master_linux/multimedia/nvgstreamer/gst-nvarguscamera/gstnvarguscamerasrc.cpp, execute:740 No cameras available
NvMMLiteOpen : Block : BlockType = 4
===== NVMEDIA: NVENC =====
NvMMLiteBlockCreate : Block : BlockType = 4
Opening in BLOCKING MODE
Error generated. /dvs/git/dirty/git-master_linux/multimedia/nvgstreamer/gst-nvarguscamera/gstnvarguscamerasrc.cpp, execute:740 No cameras available
NvMMLiteOpen : Block : BlockType = 4
===== NVMEDIA: NVENC =====
NvMMLiteBlockCreate : Block : BlockType = 4
manager@manager-desktop:~$ ls /dev/video0
/dev/video0
manager@manager-desktop:~$ dmesg | grep imx327
[ 0.207903] DTS File Name: /home/test/imx327release_srcl4t3261/Linux_for_Tegra/source/public/kernel/kernel-4.9/arch/arm64/boot/dts/../../../../../../hardware/nvidia/platform/t210/porg/kernel-dts/tegra210-p3448-0002-p3449-0000-b00.dts
[ 0.412164] DTS File Name: /home/test/imx327release_srcl4t3261/Linux_for_Tegra/source/public/kernel/kernel-4.9/arch/arm64/boot/dts/../../../../../../hardware/nvidia/platform/t210/porg/kernel-dts/tegra210-p3448-0002-p3449-0000-b00.dts
[ 1.833634] imx327 6-001a: probing v4l2 sensor at addr 0x1a
[ 1.833643] imx327 6-001a: imx327_probe: allocated memory for sensor-priv data and tegracam device
[ 1.833806] imx327 6-001a: avdd, iovdd and/or dvdd reglrs. not present, assume sensor powered independently
[ 1.833812] imx327 6-001a: Clock found, executing get
[ 1.834069] imx327 6-001a: tegracam sensor driver:imx327_v2.0.6
[ 1.834074] imx327 6-001a: imx327_probe: tegra camera driver registration succesfull
[ 1.834080] imx327 6-001a: imx327_probe: setting up board
[ 1.834085] imx327 6-001a: imx327_power_on: power on
[ 1.834094] imx327 6-001a: imx327_power_on: pwdn set to 0
[ 2.034423] imx327 6-001a: imx327_power_on: turned on mclk
[ 2.034454] imx327 6-001a: imx327_power_on: pwdn set to 1
[ 2.034458] imx327 6-001a: imx327_power_on: powered on
[ 2.034789] imx327 6-001a: IMX327 sensor found
[ 2.337814] imx327 6-001a: imx327_probe: board has been setup succesfully
[ 2.337870] imx327_set_gain 271 val ; 0
[ 2.338093] imx327_set_exposure 463 val ; 0
[ 2.338716] imx327_set_frame_rate 362 val ; 0 frame : 0
[ 2.339335] imx327_set_group_hold 136 val ; 0
[ 2.339559] imx327_set_exposure 463 val ; 30
[ 2.340180] imx327_set_frame_rate 362 val ; 2000000 frame : 16875
[ 2.340799] imx327 6-001a: detected imx327 sensor
[ 2.505209] vi 54080000.vi: subdev imx327 6-001a bound
[ 4.467572] imx327 6-001a: imx327_open:
[ 4.485965] imx327 6-001a: Camera Already ON
[ 4.760031] imx327 6-001a: Camera Already ON
Thank you.
hello mszeta,
you should reboot Jetson device when the upgrade is finished.
I assume this failure happened after you reboot system, right?
it shows failure to access stream via nvarguscamerasrc plugin, is this IMX327 implemented by yourself?
can you please try Applications Using V4L2 IOCTL Directly to test the stream by V4L2 IOCTL to verify basic functionality.
Hello, @JerryChang
It is not a jetpack upgrade using apt.
After pushing emmc and installing jetpack, the release number is as follows.
cat /etc/nv_tegra_release
R32 (release), REVISION: 7.2, GCID: 30192233, BOARD: t210ref, EABI: aarch64, DATE: Wed Apr 20 21:34:48 UTC 2022
If I don’t apply the exposurerange option to nvarguscamerasrc, I can see overexposure just like in the previous version of jetpack4.6.1.
Thank you.
hello mszeta,
it’s exposuretimerange option to modify the max/min exposure settings.
that’s should be an issue of device tree configuration since you’re able to workaround by command options.
please examine your sensor device tree settings. please check they’re within the range of your settings.
for example,
$ cat /proc/device-tree/cam_i2cmux/i2c@0/rbpcv2_imx219_a@10/mode0/default_exp_time
$ cat /proc/device-tree/cam_i2cmux/i2c@0/rbpcv2_imx219_a@10/mode0/max_exp_time
$ cat /proc/device-tree/cam_i2cmux/i2c@0/rbpcv2_imx219_a@10/mode0/min_exp_time
Hello, @JerryChang
manager@manager-desktop:/proc/device-tree$ cat /proc/device-tree/host1x/i2c@546c0000/imx327_a@1a/mode0/default_exp_time
33334
manager@manager-desktop:/proc/device-tree$ cat /proc/device-tree/host1x/i2c@546c0000/imx327_a@1a/mode0/max_exp_time
660000
manager@manager-desktop:/proc/device-tree$ cat /proc/device-tree/host1x/i2c@546c0000/imx327_a@1a/mode0/min_exp_time
30
manager@manager-desktop:/proc/device-tree$
I set the same as the IMX327 Xavier NX, but why is only the NANO overexposed?
Thank you.
hello mszeta,
it’s camera side to determine the lux, if the scene is dark, it’ll send request to increase exposure time.
are you having exactly same driver between Xavier and Nano?
could you please dump the settings of each frame to compare the difference; we need to understand why Nano converge at such large exposure values.
BTW,
according to your 1st post for the environment setup. it looks Xavier NX only had camera module, but Nano also had infrared sensors. could you please remove that for testing?