[RSDK-13174] Fixing spammy color and depth timsteamps differ logs

[SebastianMunozP]

Fixing color and depth timestamps differ, defaulting to older of the twocolor timestamp was 1768433375958437 depth timestamp was 1768433375967415 spammy logs.

This is caused by the fact that the timestamp used is the system time of when the frame arrives to the host, not the timestamp of when the frame was captured at the device. We want to make sure that the frames were captured at the same time, so using System Time is not accurate

Instead, we are switching to using Global Timestamp, which is explained here from the documentation itself:

    /**
     * @brief Get the global timestamp of the frame in microseconds.
     * @brief The global timestamp is the time point when the frame was captured by the device, and has been converted to the host clock domain. The
     * conversion process base on the device timestamp and can eliminate the timer drift of the device
     *
     * @attention The global timestamp disable by default. If global timestamp is not enabled, the function will return 0. To enable the global timestamp,
     * please call @ref Device::enableGlobalTimestamp() function.
     * @attention Only some devices support getting the global timestamp. Check the device support status by @ref Device::isGlobalTimestampSupported() function.
     *
     * @return uint64_t The global timestamp of the frame in microseconds.
     */
    uint64_t getGlobalTimeStampUs() const {
    ...
    }

In my testing, the Astra2 device does support this feature, so the spammy logs are no longer seen.

Gemini 335LE cameras also supports this feature:

1/15/2026, 6:47:45 PM info Viam C++ SDK     [module/orbbec.cpp:720] [configureDevice] Global timestamp enabled for device CPER7530001R   log_ts 2026-01-15T16:47:45.384Z

[hexbabe]

according to your description, it sounds like we shouldn't use system timestamp bc it's unreliable

why are we still using it as a fallback when somehow getGlobalTimeStampUs is LEQ 0?

also, how can getGlobalTimeStampUs be LEQ 0? have you observed this happening

could it happen when global timestamp is not enabled on the system?

[hexbabe]

should we log a single, not noisy warning that color-depth timestamp comparisons are not supported when global timestamp isn't available? Instead of falling back to the unreliable system timestamp?

[SebastianMunozP]

hmmm, another option would be to support system timestamp and put a threshold of perhaps 400ms between frames. My thinking is that it may be better to have that rough measurement than nothing, but totally open to discuss it.

[hexbabe]

the Astra2 device does support this feature

what about in the models we unofficially support?

[oliviamiller]

In my testing, the Astra2 device does support this feature, so the spammy logs are no longer seen.

When you say this do you mean Astra2 doesn't support using the Global timestamp?

[oliviamiller]

This old thread may be relevant: orbbec/OrbbecSDK_v2#92 We haven't tested their suggested fix yet if you want to try it, but if this works thats fine too

[SebastianMunozP]

In my testing, the Astra2 device does support this feature, so the spammy logs are no longer seen.

When you say this do you mean Astra2 doesn't support using the Global timestamp?

I'm sorry I wasn't clear enough, I mean that Astra2 does support using the Global timestamp.

[SebastianMunozP]

the Astra2 device does support this feature

what about in the models we unofficially support?

Good call, the only other model we currently support is the Gemini35Le, and we officially support it (documentation here).

I tested with it and it also supports global timestamps, so at this moment both our cameras support it.

[seanavery]

@oliviamiller Is there any documentation on what the OB_MULTI_DEVICE_SYNC_MODE_STANDALONE flag does? The timestamps on color/depth are differing on a single camera module right?

[seanavery]

Given that GlobalTimstamps are supported on the orbecc module we care about, can we remove the system backup?

[seanavery]

Suggested change

	uint64_t getBestTimestampUs(std::shared_ptr<ob::Frame> frame) {
	uint64_t getBestTimestampUs(const std::shared_ptr<ob::Frame>& frame) {

[maybe nit] Should we pass in as const ref here so we do not increment/decrement the shared_pt every time the helper is called?

[oliviamiller]

yes, docs here. "The Color and Depth should be set to same frame rates, the Color and Depth will be synchronized."

@oliviamiller Is there any documentation on what the OB_MULTI_DEVICE_SYNC_MODE_STANDALONE flag does? The timestamps on color/depth are differing on a single camera module right?

[seanavery]

@oliviamiller Ty for the docs. But still confused on why this was suggested... I believe this is referring to syncing multiple orbec modules with hardware pwm input over VSYNC_IN pins, right? But the problem here is color/depth are not synced on a single orbecc camera.

[oliviamiller]

@oliviamiller Ty for the docs. But still confused on why this was suggested... I believe this is referring to syncing multiple orbec modules with hardware pwm input over VSYNC_IN pins, right? But the problem here is color/depth are not synced on a single orbecc camera.

yes that is what the ob_multi_device_sync_mode enum does, but the OB_MULTI_DEVICE_SYNC_MODE_STANDALONE option indicates that the device isn't syncing with any other cameras. Im assuming the default is OB_MULTI_DEVICE_SYNC_MODE_FREE_RUN which indicates

The device does not synchronize with other devices 
The Color and Depth can be set to different frame rates.