[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.