D435 Genlock Trigger to Exposure Delay

[daziFR]

---

Required Info
Camera Model	D435
Firmware Version	5.12.7.100/5.12.13.50
Operating System & Version	any
Kernel Version (Linux Only)
Platform	PC
SDK Version	2.45.0
Language	viewer
Segment	others

Issue Description

Hi.

I'm testing the Genlock feature. From the https://dev.intelrealsense.com/docs/external-synchronization-of-intel-realsense-depth-cameras trigger input means the start of the exposure. (without any noticed delays)

For the start of the exposure test, camera is placed in a blackbox with the strobe controller controling the LEDs.

From the result i can state:

• there is a delay from the trigger input to the start of exposure in range of:
  • 790microseconds when using 848x480 and less
  • 880microseconds when using 1280x720

Can you confirm that there is an internal delay between the input trigger and the real start of the exposure (~800us)?

This is quite huge, and is there any way to decrease this?

Thank You.

[MartyG-RealSense]

Hi @daziFR The External Synchronization system is unvalidated by Intel and experimental. The validated and mature multiple camera system (Mode 1 and 2, master and slave) is the one in the original multiple-camera white paper document linked to below.

https://dev.intelrealsense.com/docs/multiple-depth-cameras-configuration

If you are using high-speed LED panels to validate hardware sync, that paper suggests setting exposure to less than 3 ms.

https://dev.intelrealsense.com/docs/multiple-depth-cameras-configuration#section-g-hw-sync-validation

If you need to use the External Synchronization system in your project: the white-paper for that system describes delay between trigger and exposure in its Principles of Operation section (linked to below).

https://dev.intelrealsense.com/docs/external-synchronization-of-intel-realsense-depth-cameras#section-2-principles-of-operation

---

"Once the trigger arrives, exposure will start ... this detail is important to note when temporally synching with events from other cameras or devices, as there is up to 1 frame delay between trigger and readout. Since the stereo camera exposure is global shutter, the camera sensor will accumulate charge during the exposure time, and when done, it will read it out".

[daziFR]

Thanks @MartyG-RealSense. I've read all those documents, and I'm aware that genlock is not a mature feature. The case is:

• using infra streams for exposure/led sync validation
• fixed exposure set to 150us
• LED pulse is set to 10us
• same trigger for LEDs and camera

When I set delay for the LEDs in order of 3,4 us, infrared images are black. When I increase delay for the LEDS to 790us then the exposure and LEDs are synced, and I have a bright image.

More info on image below.

[MartyG-RealSense]

Apologies for the delay in responding further, as I was researching your question carefully.

When the original multiple-camera white paper recommends setting exposure at less than 3 ms, it may be 3 milliseconds and not microseconds. 3 milliseconds would be 3000 microseconds (us), which may account for why a high value like 790 us (0.79 ms) achieves LED panel sync successfully.

[MartyG-RealSense]

Hi @daziFR Do you require further assistance with this case, please? Thanks!

[daziFR]

Can guys from the firmware side comment on this also? Thanks!

[MartyG-RealSense]

What advice would you wish a firmware developer to contribute, please? The system seems to be performing as described in the sync white-papers. A trigger is initiated (shown as '1' in the diagram below. The trigger signal rises, plateaus and falls after a certain period of time.

After the trigger is initiated, there is a delay period, as expected according to the Principles of Operation section of the External Synchronization white-paper. During this period the camera sensor is accumulating charge, and when completed the exposure read-out starts.

My understanding is that you are concerned about missing information, because the trigger pulse (the green line) ends sooner than the start of the read-out period after the delay.

It may be easier to visualize if the trigger pulse and the exposure time are treated as separate entities - once the trigger is initiated then the delay period before start of read-out begins, but the job of the trigger pulse is now completed and it falls back to zero whilst the exposure-time process carries on. It would be like putting a box on wheels at the top of a hill. The box requires an initial push to get moving, but then it rolls down the hill on its own without further interaction from the hand that pushed it.

[daziFR]

Thanks, @MartyG-RealSense. I understand the principles of operation. In my case, I don't really need information about readout, I'm only interested in the start of the exposure.

The problem is that the rising edge of a trigger (green signal) doesn't start the exposure immediately, but 800 us later (some will expect a few us delay).

This makes synchronization with other cameras and strobe controllers hard to implement.

[MartyG-RealSense]

The External Synchronization paper suggests at the bottom of Section 3: "Alternatively, one can also create a signal generator that can control the individually multiple output sync signals, with control over the frequency as well as the phase (time delay) between each trigger".

Might using this method help with your timing concern?

https://dev.intelrealsense.com/docs/external-synchronization-of-intel-realsense-depth-cameras#section-3-camera-connections

[agrunnet]

@daziFR You are absolutely right in your observation. Here is the sensor delay of the "external trigger snapshot mode" on the Omnivision sensors we use: tExp_Dly = 61396 tXVCLK + n tRow where tXVCLK is 80Mhz and n=1. The other numbers are in the table below.

[daziFR]

Thanks @agrunnet for the confirmation. So this is a sensor limitation, and there is no way to reduce this?

@MartyG-RealSense topic can be closed now.

[MartyG-RealSense]

Thanks very much for your advice @agrunnet

@daziFR - as suggested, I will close the topic if you are satisifed with the outcome.