Exposure time longer than 750 ms

Autonomous Machines Jetson & Embedded Systems Jetson TX2
#1

Hello!

I have made Sony sensor driver for the TX2 and I can’t seem to get exposure time longer than about 750 ms. I have noticed on all other cameras, which are supported by default, that the exposure time in Argus can’t be set more than about 1 second.

I need to get at least 5 second exposure times on image capture. Judging by the fact that the exposure settings work on my driver correctly and it just freezes when I set it to more than about 750 ms in Argus camera, for example - it probably has to do something with the Jetson. Is it something to do with ISP? I really need to get this to work.

Thanks!

#3

When the exposure too much cause the frame rate to low would cause capture failed due to timeout.
Have a try below command before start camera APP.

sudo service nvargus-daemon stop
sudo enableCamInfiniteTimeout=1 nvargus-daemon
1 Like
#4

Wow, thank you very much for this! This was the last thing on my project and now I can capture long exposure images. :)

By the way, there’s sometimes the frames twitch for couple of frames at random. Is this something about when the framerate is not completely in sync with the exposure time?

#5

Maybe, you can confirm if raw data from v4l2-ctl

#6

What do you mean by ‘if raw data’?

#7

Below command can capture raw data from sensor without ISP process. But you need to configure the exposure first.

v4l2-ctl -d /dev/video0 --set-fmt-video=width=1920,height=1080,pixelformat=RG10 --set-ctrl bypass_mode=0 --stream-mmap --stream-count=20 --stream-to=test.raw
#9

Do you happen to know the reason why:

sudo service nvargus-daemon stop
sudo enableCamInfiniteTimeout=1 nvargus-daemon

Doesn’t work on the Nano? Thanks!

#10

TX1/Nano doesn’t support infinite timeout debug feature.

#11

Is that something that could be added in the driver/kernel, or is it a hardware limitation?

Also, do you know if the TX2 NX module supports the infinite timeout debug feature (when installed in the Nano development carrier board)? Thanks again.

#12

The key was the chip so yes TX2 support infinite timeout feature.

#13

Ok. Would you be able to share any specifics as to why it couldn’t be supported on the TX1/Nano? We may soon begin working on our own IMX477 driver modifications and using v4l2 directly for raw bayer access (bypassing nvargus-daemon), and would probably need to understand the reason why an infinite timeout doesn’t work on those particular chips. Any help you can provide would be much appreciated. Thanks!

Update - And since the source for nvargus-daemon isn’t available, it’s not currently possible to see how that enableCamInfiniteTimeout debug feature was implemented.

#14

It’s driver implementation don’t support it during TX1/Nano phase.
And add that feature after TX2 and after chip. But if you choice v4l2 path you can ignore this.

#15

Is it theoretically possible to port this feature back to Nano/TX1? Would it be done in the camera sensor kernel driver or in the nvargus-daemon source?

#16

Sorry no plan for this feature on Nano/TX1, it’s user space camera driver and nvargus-daemon implement by it API.

#17

Ok. It would be awesome to have on the Nano/TX1. Please keep it in mind for the future. I’m sure people working on photography usecases would appreciate it.

But just to confirm, if I were to use v4l2 on the Nano/TX1, is it possible to use long exposures up to the sensor maximum?

V4l2-ctl not respecting frame_rate control, unlike Gstreamer on IMX477 + Nano 2GB
#18

Yes, but need VI driver modification.

#19

Ok thanks. If you could, any help / pointers to where and what those modifications are would be much appreciated. Thanks!

#20

Have a reference to below topic.

1 Like
#21

Thanks. I’ll give that a try and report back.

#22