[RSDK-13174] Fixing spammy color and depth timestamps differ logs by SebastianMunozP · Pull Request #62 · viam-modules/orbbec

SebastianMunozP · 2026-01-15T01:16:18Z

After some debugging and experimentation, this is the list of improvements as part of this work

Enable OB_MULTI_DEVICE_SYNC_MODE_STANDALONE: If color and depth frames uses the same FPS, this option sync's them, in my testing, this reduced the average time difference from 4.5us to 1.9us, more info here.
Use GlobalTimestamps: If supported (which both our cameras do), this allows us to get the frame timestamps at the source (i.e. the device) but on the host time domain, more info here.
Only considering time differences between color/depth > 2ms as troublesome
Throttle the logs: Log all troublesome difference at the debug level, but only once per minute at the warn level.

With these improvements, we are getting frames more in sync and I'm not seeing any more logs.

hexbabe · 2026-01-15T15:00:04Z

src/module/orbbec.cpp

+    if (ts > 0) {
+        return ts;
+    }
+    return frame->getSystemTimeStampUs();


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?

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?

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.

I researched this further, even with GlobalTimestamps we are still seeing differences between the frames. I know this is a known issue at Orbbec, I just sent them an email to ask about it. In the meantime, I'm going to use GlobalTimestamps, throttle this log to once per minute, and log always on debug level.

Also, I prefer to keep support for System Timestamps for know, to be future proof for cameras we may support in the future that doesn't support GlobalTimestamps.

Could we log once per five minutes and keep it at the info level?

would that be considered "spammy" still?..

With the latest improvements, on this PR, we should not see any more timestamp differ logs, I'll set this to 5 minutes but raise this to warn instead of info.

hexbabe · 2026-01-15T15:02:19Z

the Astra2 device does support this feature

what about in the models we unofficially support?

oliviamiller · 2026-01-15T16:03:06Z

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 · 2026-01-15T16:09:19Z

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 · 2026-01-15T21:48:42Z

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 · 2026-01-15T21:56:22Z

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 · 2026-01-20T19:56:47Z

@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?

src/module/orbbec.cpp

oliviamiller · 2026-01-20T20:08:19Z

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 · 2026-01-20T20:10:43Z

@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 · 2026-01-20T20:18:05Z

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

SebastianMunozP · 2026-02-05T18:48:08Z

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

Hello, I just tested this OB_MULTI_DEVICE_SYNC_MODE_STANDALONE feature and I'm seeing a big improvement in our color/depth frame syncronization:

With it being set:

  Average:             1938 µs (1.94 ms)
  Std Dev:             522 µs (0.52 ms)
  Min:                 1871 µs (1.87 ms)
  Max:                 9222 µs (9.22 ms)

Without it (using default OB_MULTI_DEVICE_SYNC_MODE_FREE_RUN mode)

  Average:             4551 µs (4.55 ms)
  Std Dev:             4354 µs (4.35 ms)
  Min:                 97 µs (0.10 ms)
  Max:                 17037 µs (17.04 ms)

… 2ms

hexbabe

great findings with the sync mode!

SebastianMunozP added 2 commits January 14, 2026 20:15

Fixing spammy color and depth timsteamps differ logs

d6a909b

Removing unneeded MAX_TIME_DIFFERENCE

39ec6f6

SebastianMunozP requested review from hexbabe and oliviamiller January 15, 2026 01:27

SebastianMunozP changed the title ~~Fixing spammy color and depth timsteamps differ logs~~ [RSDK-13174] Fixing spammy color and depth timsteamps differ logs Jan 15, 2026

SebastianMunozP requested a review from seanavery January 15, 2026 01:51

hexbabe reviewed Jan 15, 2026

View reviewed changes

SebastianMunozP force-pushed the fix-color-depth-timestamp-smappy-log branch from 327f21c to 39ec6f6 Compare January 16, 2026 20:01

seanavery reviewed Jan 20, 2026

View reviewed changes

src/module/orbbec.cpp Show resolved Hide resolved

src/module/orbbec.cpp Show resolved Hide resolved

SebastianMunozP changed the title ~~[RSDK-13174] Fixing spammy color and depth timsteamps differ logs~~ [RSDK-13174] Fixing spammy color and depth timestamps differ logs Feb 3, 2026

SebastianMunozP added 2 commits February 4, 2026 10:26

Improving color vs. depth timestamp log message

3139d42

Fixing build

2b53c3a

SebastianMunozP requested review from hexbabe and seanavery February 5, 2026 14:33

seanavery approved these changes Feb 5, 2026

View reviewed changes

Adding OB_MULTI_DEVICE_SYNC_MODE_STANDALONE syncMode

f993489

SebastianMunozP added 2 commits February 5, 2026 14:07

Only logging color/depth differences if the difference is bigger than…

6d0f251

… 2ms

Raising the time to log timestamps to 5 minutes

4952672

hexbabe approved these changes Feb 5, 2026

View reviewed changes

oliviamiller approved these changes Feb 5, 2026

View reviewed changes

SebastianMunozP merged commit f105429 into viam-modules:main Feb 6, 2026
5 checks passed

Comments

Conversation

SebastianMunozP commented Jan 15, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

hexbabe Jan 15, 2026

Choose a reason for hiding this comment

Uh oh!

hexbabe Jan 15, 2026

Choose a reason for hiding this comment

Uh oh!

SebastianMunozP Jan 15, 2026

Choose a reason for hiding this comment

Uh oh!

SebastianMunozP Feb 4, 2026

Choose a reason for hiding this comment

Uh oh!

SebastianMunozP Feb 4, 2026

Choose a reason for hiding this comment

Uh oh!

hexbabe Feb 5, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

SebastianMunozP Feb 5, 2026

Choose a reason for hiding this comment

Uh oh!

hexbabe commented Jan 15, 2026

Uh oh!

oliviamiller commented Jan 15, 2026

Uh oh!

oliviamiller commented Jan 15, 2026

Uh oh!

SebastianMunozP commented Jan 15, 2026

Uh oh!

SebastianMunozP commented Jan 15, 2026

Uh oh!

seanavery commented Jan 20, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Uh oh!

Uh oh!

oliviamiller commented Jan 20, 2026

Uh oh!

seanavery commented Jan 20, 2026

Uh oh!

oliviamiller commented Jan 20, 2026

Uh oh!

SebastianMunozP commented Feb 5, 2026

Uh oh!

hexbabe left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

4 participants

SebastianMunozP commented Jan 15, 2026 •

edited

Loading

hexbabe Feb 5, 2026 •

edited

Loading

seanavery commented Jan 20, 2026 •

edited

Loading