[Question] Intermittent Frame Timestamp Jitter (26ms-35ms) on D455 in Genlock Mode with Non-Integer External Trigger (30.303030Hz)

[keaiduo12138]

Camera Model (if applicable)

D455

Topic

Other (specify in description)

Your Question

 We are using a RealSense D455 camera in Genlock mode (Mode 4), driven by an external hardware trigger from a custom sensor. Our trigger frequency is precisely 30.303030Hz. This results in an ideal frame interval of 33.00ms.
The Issue:While the majority of frames arrive at the expected 33.00ms interval, we observe intermittent jitter where the delta time dt between consecutive depth frames fluctuates between     26 ms and 34 ms  within a one-minute window.

We have verified via oscilloscope and internal logging that our master trigger signal is extremely stable, with a jitter of less than 10 microseconds. Therefore, the irregularity appears to originate from the RealSense firmware or SDK processing.We need to understand if this jitter is an inherent limitation of the D455 when handling non-integer frequencies and how to achieve a perfectly stable 33.00ms capture.

Context / What You've Tried

1. Hardware & Sync Configuration:
   Camera: RealSense D455.
   Sync Mode: Both Stereo Module and RGB Camera are set to RS2_OPTION_INTER_CAM_SYNC_MODE = 4.
   Nominal FPS: Configured to 60 FPS in the SDK to ensure the trigger frequency 30.3Hz is within the internal sensor's support range.
   Exposure: We have tested both Auto-Exposure and Manual Exposure (set to 10ms )to ensure the exposure window does not overlap with the next trigger pulse.

2. Software & Data Collection:
   Timestamping: RS2_OPTION_GLOBAL_TIME_ENABLED is set to 0 to ensure we are reading raw hardware timestamps.
   Measurement: We use poll_for_frames() to fetch framesets and compute dt =current_ts - previous_ts using depth.get_timestamp().
   Timestamp Domain: We confirmed the domain is RS2_TIMESTAMP_DOMAIN_HARDWARE_CLOCK.

3. Observed Jitter Pattern:
   Expected dt: 33.00 ms.
   Occasional dt: 29 ms, 31 ms , 34 ms. Fluctuate between these numbers.
   This behavior occurs intermittently even when the camera is static and the environment lighting is constant.

LibRealSense SDK Version (if applicable)

LibRealSense SDK: v2.56.5-0~realsense.6681 Package: librealsense2 (arm64)

Operating System (if applicable)

Ubuntu 20.04

Additional Context

[keaiduo12138]

Non-Integer Frequency Support: Does the D455 firmware have specific constraints or internal PLL (Phase-Locked Loop) alignment issues when the external trigger is a non-integer value like 30.3030 Hz?

Internal Sampling: Is there an internal high-frequency clock that causes quantization jitter when the trigger doesn't align with the internal 60Hz nominal cycle?

Recommendations: Would you recommend a different Burst Count or any specific Inter-Cam Sync parameter to stabilize the capture for this specific frequency?

Testing: Has Intel validated Genlock stability with non-integer external frequencies on the D400 series?

[MartyG-RealSense]

Hi @keaiduo12138 It sounds as though you are configuring Mode 4 as though it were Mode 2. Mode 4 works differently from mode 2 and has a different approach to hardware sync.

In Mode 4, you do not need to set the trigger to a precise decimal value such as 30.3030 Hz as it is more flexible and forgiving than Mode 2. However, a key difference is that the trigger Hz in Mode 4 needs to be set to half of the camera's FPS. So if the camera is set to 30 FPS, the trigger frequency should be set to 15 FPS. The capture speed of the synced camera will still be 30 FPS though despite the halved trigger frequency.

If you need to have the trigger set to 33 Hz then you will need to set the camera to 60 FPS instead of 30. This can be done with 848x480 resolution or lower but not with 1280x720 resolution, which has a maximum speed of 30 FPS.

Mode 4 is considered 'unvalidated' by RealSense, a proof of concept experiment that is no longer officially supported by RealSense but is still usable in the SDK.

If there is jitter occurring in Mode 4 then it may be arising if the trigger frequency is not being set to around half of the camera's FPS speed.

Burst mode would likely not help with jitter. The purpose of burst mode is to generate additional frames on each trigger pulse received instead of just one frame per trigger.

[MartyG-RealSense]

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