ARGUS: missing sensor startup delay properties

Dear all,

We have two coupled image sensors (IMX290) connected via FPD-III to CSI, where one sensor acts as a Master and provides synchronized clocking (HSYNC, VSYNC) to the slave sensor. Reason is to have a good-quality stereo capture where both sensors are recording images at exactly the same time.

However, we find that we are having difficulties starting both captures simultaneously because LIBARGUS hits a timeout on the slave sensor. The slave is likely to require some more time to synchronize to the external XVS than the master sensor which just runs when started.

The same setup has worked nicely with R28.1/2 but is no longer working with R32.1. We have seen that there is a new “set_mode_delay_ms” property in the DTB but no similar “start_delay_ms” or a more general “max_frame_delay_ms” property to configure such requirements. This would be vital in our application!

The error recovery capabilities of the NVidia camera software stack have not improved at all between releases: when ever a single frame gets missing somehow, the whole software stack just hangs and must forcedly be killed. If the application links against libargus (which is said to be preferred to using the gstreamer plugin), the application must kill and restart itself. Sometimes one must wait a few minutes in between to allow hardware timeouts to trigger so that a new capture can start cleanly. Sometimes even a reboot seems to be required to get the ISP running again. Please improve on that, this is not production-quality software!

  1. The purpose of set_mode_delay_ms is let argus have more time to wait sensor initial that could be the same with start_delay_ms" or "max_frame_delay_ms.

  2. Have a try “Infinite Timeout Support”
    This use case is different from typical camera use cases, where the camera sensor streams frames continuously and finite timeouts for the camera driver and associated hardware waiting for camera frames.
    In this use case a camera sensor is triggered to generate a specified number of frames, after which it stops streaming indefinitely. Whenever it resumes streaming, the camera driver must resume capturing without timeout issues. The camera driver and hardware must always be ready to capture frames coming from the CSI sensor. Since the camera driver does not know when streaming will start again, it must wait indefinitely for incoming frames.
    To support this use case, the camera sensor hardware module must support suspending and resuming streaming.
    To enable this feature, run the camera server (i.e. the nvargus-daemon service) by setting an environment variable:
    sudo service nvargus-daemon stop
    sudo enableCamInfiniteTimeout=1 nvargus-daemon

Dear ShaneCCC,

I have tried set_mode_delay_ms, but that seems to have effect only after argus-daemon has set-up the semsor mode and before it tries to set additional initial camera parameters (gain, exposure, …). We need the delay between start streaming and the first frame.

In fact, looking at the IMX290 manual, it says exactly:

The serial communication block operates even in standby mode, so standby mode can be canceled by setting the STANDBY register to “0”. Some time is required for sensor internal circuit stabilization after standby mode is canceled. After standby mode is canceled, a normal image is output from the 9 frames after internal regulator stabilization (20 ms or more).

What this statement means is that the first frame is generated 20ms after releasing STANDBY (e.g. when nvargus-daemon calls START_STREAM and the driver performs the I2C register write), and the first valid, stable frames are generated after 9 frame times (20ms + 8 * 33.3ms, ca 300ms). Currently, nvargus-daemon and everything based on libargus is not able to handle such sensors!

I would have supposed to be able to delay capture by putting sleeps into the start_stream() method [more exactly into the regtable that gets written using regmap_util_write_table_8()], but apparently libargus doesn’t wait for the driver method have completed before it schedules capture timeouts, which seems broken by design.

Will the “enableCamInfiniteTimeout” parameter also enable libargus to skip over errorneous frames, like ones with CRC errors which may occur from time to time via FPD-III?

You can try add the set_mode_delay_ms and have those two sensor sync and start stream togher.

Dear ShaneCCC,

as I have already mentioned, the set_mode_delay_ms did not have any effect. For now we stick with the enableCamInfiniteTimeout method, but that cannot be a permanent solution.

Please inform the developer team to consider a stream_start_delay_ms for sensors that need some time to generate stable images after enabling them, this is a vital property for some sensors (especially for sensors connected via serial links where the I2C communication also has a higher latency).

I can help to bring this request back . However it’s could take long long time for the specific request. It could delay your production time.
My suggest is to handle them from sensor kernel driver, that’s the full source you can handle.