Corrupt Timestamps after calling EnableDeviceClockSync with Femto Bolts

[David-Conrad]

After I call context.EnableDeviceClockSync(timeinterval); over the c# api I get corrupt Timestamps via depthFrame.GetTimeStamp(), depthFrame.GetTimeStampUs() still works...

SDK version 2.1.1
Windows 11
2x Orbbec Femto Bolt

[zhonghong322]

You are using the C# wrapper. Future C# issues can be reported in this repository.
You are calling the depthFrame.GetTimeStamp() interface. Is the issue that the timestamp unit is incorrect, or is the timestamp completely wrong? I will forward this to the C# engineers.

[zhonghong322]

SDK version 2.1.1 #define ob_frame_time_stamp(frame, err) (ob_frame_get_timestamp_us(frame, err))
There is an issue with the implementation of this interface. The unit is supposed to be milliseconds (ms), but the interface returns microseconds (us). It needs to be divided by 1000. The corrected interface should look like this:
#define ob_frame_time_stamp(frame, err) (ob_frame_get_timestamp_us(frame, err) /1000)

[David-Conrad]

I get an overflow. The Timestamp (in milliseconds) is supposed to be within the bounds of datatype ulong. but when i try to convert it to TimeSpan.FromMilliseconds() I get the overflow error, that the timestamp is too large:

ulong timestamp = depthFrame.GetTimeStampUs();
TimeSpan timeSpan = TimeSpan.FromMicroseconds(timestamp)
works just fine, but

ulong timestamp = depthFrame.GetTimeStamp();
TimeSpan timeSpan = TimeSpan.FromMilliseconds(timestamp)
produces the overflow

Edit: I just tested both Timestamp-Functions: And you are right, the MS-Timestamp is the same as the US-Timestamp, in my case
  | timestamp | 1738743844204217 | ulong

which is a quite large timestamp by the way. Anyway, the error occurred when trying to convert it to the TimeSpan-Datatype, which was possible before I used the context.EnableDeviceClockSync(timeinterval); ...