global_time_enabled not available on D555 over DDS/Ethernet

[iamanshulchauhan1]

Summary
When connecting the Intel RealSense D555 via USB, the global_time_enabled option is supported and enabled. However, when the same camera is accessed over DDS (Ethernet), this option is not exposed. This prevents proper multi-camera timestamp synchronization in Ethernet-only setups.

Environment

Camera: Intel RealSense D555

Firmware: 7.56.37618.4188

librealsense: 2.57.6

OS: Ubuntu 22.04 (Docker), ROS 2 Humble

Observed Behavior

USB connection: global_time_enabled → supported=True

DDS (Ethernet) connection: global_time_enabled → supported=False

Impact
Without global_time_enabled, hardware timestamps from multiple D555 cameras remain in separate clock domains (observed ~78s offset).

Question
Is this a DDS transport limitation, or is support for global_time_enabled over Ethernet planned? Is there an alternative way to synchronize timestamps across multiple D555 cameras over DDS?

[MartyG-RealSense]

Hi @iamanshulchauhan1 Thanks very much for your question. I will discuss it with my RealSense colleagues and update you as soon as I have information.

Update: my colleagues informed me that global timestamping for DDS was added recently to the development branch of librealsense and should be a part of librealsense release 2.57.7.

A further refinement to DDS global timestamping is currently being worked on at PR #14733

[iamanshulchauhan1]

@MartyG-RealSense

Thank you for the clarification regarding global_time_enabled coming in 2.57.7 (PR #14733).

However, I would like to clarify that my primary concern is capture synchronization, which global_time_enabled does not address.

I understand that hardware synchronization is supported via inter_cam_sync_mode using GPIO sync cables over USB. Unfortunately, my deployment is PoE-only, with no USB or GPIO connections available.

My Setup

4× Intel RealSense D555

Ethernet (PoE) only

Requirement: tightly synchronized multi-camera capture for multi-view processing

Questions

For Ethernet-only D555 deployments without GPIO sync cables:

Is PTP (IEEE 1588) support planned at the firmware level?
PTP is the standard industrial solution for deterministic multi-camera synchronization over Ethernet and would align well with the D555’s Ethernet-focused architecture.
(I am not fully sure whether this is even architecturally possible on the D555 hardware. I have seen PTP-based capture synchronization implemented on other industrial Ethernet cameras)

Is there any planned mechanism for capture-trigger synchronization over DDS, such as:

A software broadcast trigger?

I completely understand if roadmap details cannot be shared. However, even a high-level indication of whether Ethernet-based capture synchronization is technically feasible on this camera would greatly help us in making architectural decisions.

Thank you again for your support.

[MartyG-RealSense]

Hardware sync is only supported over USB on D555, unfortunately.

The principles of global time described at #3909 explain that in a multiple camera setup where all the cameras are attached to the same computer, global time should use the computer's system clock to calculate a common timestamp for all streams in order to sync multiple cameras.

I will discuss with my RealSense colleagues whether there are future intentions for PTP support and whether I can share the information if there are.

The link below has a guide from a person using a RealSense D415 who attempted to simulate PTP synchronization in software.

https://vcl3d.github.io/VolumetricCapture/docs/synchronization/

[MartyG-RealSense]

My colleagues validated that global time, being introduced in the upcoming 2.57.7 SDK, is the solution for D555 multicam sync over PoE.

[iamanshulchauhan1]

Thank you for the clarification.

I would like to confirm one important technical point regarding global_time_enabled.

From reviewing the librealsense implementation, global time appears to perform a conversion of hardware timestamps into the host system clock domain using a continuously updated mapping (linear regression between device time and system time). This ensures that all cameras attached to the same host report timestamps in a common time domain.

However, this mechanism does not physically synchronize exposure start between cameras. Each camera still runs free-running capture internally.

In that case:

The timestamps are aligned to a common clock.

But the actual exposure times may still differ by up to one frame period in the worst case.

At 5 FPS, this could theoretically approach 200 ms.

Even with nearest-frame matching, the effective mismatch could still be ~100 ms.

Could you confirm whether global_time_enabled introduces any form of frame phase alignment or exposure synchronization across D555 devices over PoE or if it strictly performs timestamp normalization?

[MartyG-RealSense]

Global time periodically compares the device time and the computer time to calculate a linear equation describing the connection between them. Then it applies the function to every frame in every stream..

It does not perform adjustments based on exposure.

[MartyG-RealSense]

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