Set_mode_delay_ms property in R35 device-tree

Autonomous Machines Jetson & Embedded Systems Jetson AGX Xavier
1

Hello,

I am wondering if the property “set_mode_delay_ms” is actually parsed and implemented anywhere in Jetson Linx R35.3.1 (or newer). This is a sensor mode property documented here: Sensor Software Driver Programming — Jetson Linux Developer Guide documentation.

I am interested in this property because it would help me resolve this camera sensor issue: ERROR: NULL VI channel received on AGX Xavier.

Similar to what others have reported, changing “set_mode_delay_ms” does not have any impact for me: Infinite timeout support - #9 by MarkusHess

Unlike all the other camera mode properties, I do not see it being parsed within sensor_common.c, in the linux-nvidia repo, even as of R35.5.0.

So I am wondering, is this property usable? If not, is there any alternative other than enableCamInfiniteTimeout?

My goal is to increase the timeout time between sending a capture request and receiving the start-of-frame., but I would prefer not enableCamInfiniteTimeout because that seems to be more for debugging.

Hope you can let me know.

Thanks for your time.

3

hello alok.deshpande,

please apply the pre-built update here… Topic 284939. there’s bug fix of paring set_mode_delay_ms via device tree.
after that,
you should be able to configure set_mode_delay_ms in the device tree.

4

Hello @JerryChang,

Thanks for getting back to me and letting me know. I will try it and let you know if it works.

One more question: when set_mode_delay_ms is configured in the device tree, does that mean enableCamInfiniteTimeout is not needed? For example, if I set set_mode_delay_ms = 5000 in the device tree, do I still need to run the following?

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

Based on your response here, I am unclear about that.

Please let me know. Thank you.

5

hello alok.deshpande,

you cannot use them together.
enableCamInfiniteTimeout will ignore set_mode_delay_ms to keep waiting for sensor frames forever.

6

Unfortunately setting set_mode_delay_ms to a large value does not achieve the same result as setting enableCamInfiniteTimeout=1.

What additional timeouts are disabled by enableCamInfiniteTimeout which are not disabled by set_mode_delay_ms? Can any of them be disabled/increased by patching open-source code?

It would be appreciated if you can share the patch file for the pre-built in Infinite Timeout Support #2 - #3 by JerryChang so it is clear what is changed.

Is the pre-built only compatible with R35.5.0, or can it be used with older versions such as R35.3.1?

7

hello alok.deshpande,

may I know what’s the real use-case? you cannot configure too large as it might cause internal pipeline timeouts.

yes, there’s L4T version dependency, please based-on r35.5.0 to apply such update.

8

I just selected an arbitrarily large value for testing (3000ms), and experienced the timeout anyways. That I why I just want to understand what is the difference between enableCamInfiniteTimeout and set_mode_delay_ms ?

My use-case: I am experiencing this problem, and enableCamInfiniteTimeout=1 solves it but set_mode_delay_ms does not (yet). I am still waiting for my camera partner (e-con) to provide a more reasonable value - i.e. less than 3s - based on the details of their camera. If I receive this from them, I will try it again and then mention the result here.

In the meantime, I will make sure to update to Jetson R35.5.0 on all my other modules.

9

hello alok.deshpande,

let me have clarification…

VI engine it expects frame packet arrived (it’s looking for SOF) as soon as stream-on.
in some scenario, such as huge amount of register programming during sensor init. it’ll take longer time than VI’s expectation to cause timeout failure. that’s configuration, set_mode_delay_ms to add some delay after capture starts.
however, internal timeout mechanism still there for waiting frame packet has arrived.
note, internal timeout it’s 2500ms by default, it has configure to a larger amount (i.e. 4500ms) in the r35.5.0 release version.
when you configure enableCamInfiniteTimeout, it’ll toggle timeout values as Infinite, which means waits forever.

10

@JerryChang sorry for the late reply. I was waiting on my camera vendor (e-con systems) to get back to me on this. I have only just managed to get a hold of them now.

Thanks very much for letting me know about that internal timeout of 2500ms. If I am understanding correctly, that is hard-coded in some closed-source libraries, so it cannot be changed to 4500ms without upgrading to R35.5.0.

I noticed that there are also hard-coded timeouts within gst-nvarguscamerasrc.

ACQUIRE_FRAME_TIMEOUT: Set the waiting time for the acquireFrame before timeout. Default 3000ms
WAIT_FOR_EVENT_TIMEOUT: Set the waiting time for the event before timeout. Default 5000ms

  1. What is the meaning of “event” and “acquireFrame”? Are they related to the total timeout like this?

Total_timeout = set_mode_delay_ms + ACQUIRE_FRAME_TIMEOUT + WAIT_FOR_EVENT_TIMEOUT + 4500ms

  1. Am I understanding this correctly?

Request stream-on -----> Event ---> AcquireFrame ----> Start-of-Frame

You can feel free to refer me to documentation about this because I was not able to find any.

11

it’s event to retrieve concurrent frame event type.
and, acquireFrame to retrieve the frames from queue.

here’s developer guide for reference, Argus::EventType::EventType.
you may dig into gstnvarguscamerasrc.cpp for have more details.

13

This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.