HW sync drift in time

[aling96]

• Before opening a new issue, we wanted to provide you with some useful suggestions (Click "Preview" above for a better view):

  • Consider checking out SDK examples.
  • Have you looked in our documentations?
  • Is you question a frequently asked one?
  • Try searching our GitHub Issues (open and closed) for a similar issue.

• All users are welcomed to report bugs, ask questions, suggest or request enhancements and generally feel free to open new issue, even if they haven't followed any of the suggestions above :)

---

Required Info
Camera Model	{D400 }
Firmware Version	(Open RealSense Viewer --> Click info)
Operating System & Version	{Linux (Ubuntu 18.04)
Kernel Version (Linux Only)	(4.15)
Platform	PC
SDK Version	{ legacy / 2.. }
Language	{python }
Segment	{Robot/Smartphone/VR/AR/others }

Issue Description

<Describe your issue / question / feature request / etc..>

I have a camera set up of 3 D435 cameras, 1 master 2 slave. I have wiring set up between them and have set the inter cam sync mode in code.

I have read the white paper documentation and many other forums extensively about this issue, but I am still confused about what the "drift in time" really means. My current thought is that you would look at (master time - slave time) for 10s of minutes and then see if the difference in time changes. I recorded master frame time and slave frame time for 10 minutes and then subtract the two values from each other. I observe that the difference does change. However, for one slave camera, the difference in time is constant for 4 minutes, and then jumps to a different time, and then remains constant. For the other slave camera, there is a gradual change in time over the course of 10 mins. Is one of these behaviors correctly showing time syncing?

I also compared my HW sync set up vs. a no HW sync set up, then I see the same "drift in time" behavior from both of them.

Am I taking the correct calculations to figure out if HW sync is working?

[MartyG-RealSense]

In the Inter Cam Sync setting, do you have the Master set to a value of '1' and both slave cameras set to a value of '2' please?

The approach of looking for drift over a period of 10s of minutes that the multi-camera white paper describes is the correct one.

If hardware sync is not active then the timestamp values of the cameras should remain the same. Drift over time is the evidence that hardware sync is active.

When testing a no-sync setup, I believe that you should make sure that Inter Cam Sync is set to a value of '0' for all the cameras.

If you have all the camera streams and their timestamp information on the screen at the same time then you could capture an image of the screen and look at the static snapshot of that moment in time. The drift is so slow that the timestamps should accurately reflect the amount of drift at the time that the snapshot was taken.

[aling96]

I do have master set as 1, and the other two set as 2. As for the non-HW sync I have all set to 0.
Since the cameras start at different times, would you recommend subtracting the offset from the slave cameras to align with the master's first to see if the timestamp values are the same or if they drift?

[MartyG-RealSense]

A RealSense user at #2637 came up with a way of calculating drift using code, though they were not sure it was correct.

To quote their script, which is in the opening comment of the above link, they used this method for calculating timestamp drift:

std::cout << "Drift: " << depth_frame.get_timestamp() - last_time << ", ";
last_time = depth_frame.get_timestamp();

[MartyG-RealSense]

Closed due to no further comments.