forums.naturalpoint.com

Discussion and Support for the OptiTrack, SmartNav and TrackIR brands by NaturalPoint

Timestamps in SDK 3.0

NatNet, VRPN, TrackD, and Plugins

by dario.turchi » Tue Jan 23, 2018 5:06 am

Hello,
from the documentation, it is a little unclear which is the "reference" (time 0) for the timestamp values introduced with the last version of the streaming engine (NatNet 3.0), more specifically
* CameraMidExposureTimestamp
* CameraDataReceivedTimestamp
* TransmitTimestamp

While for the field "fTimestamp" it is clearly stated that "Reports the time since software start", for the others it is just indicated that are "Given in host's high resolution ticks" (so resolution but no origin).
I was expecting then for the timestamps to make reference to the standard Windows epoch, which is 1 January 1601, but actual values are not consistent with this assumption, rather suggesting that the reference is the system start-up.
Would it be possible to have further information about this? Which time-range do the timestamps make reference to ? I am currently streaming from a take file: is there any difference respect to live streaming (apart from the CameraMidExposureTimestamp field, which is clearly 0) ?
dario.turchi
 
Posts: 8
Joined: Tue Aug 08, 2017 10:28 am

by steven.andrews » Tue Jan 23, 2018 1:07 pm

Hello dario.turchi,

The timestamp variables report what are called "clock ticks". "Clock ticks" are the unit of measurement used by computers to keep track of time. These are used since they are able to provide us the necessary resolution to make these sorts of timing measurements. Using our timing variables in NatNet, you should be able to calculate things like how long it took for Motive to calculate all of the data ("Software Latency") for each frame of NatNet data. Because the goal is to calculate things like "Software Latency" on a per frame basis, it does not really matter when the timer (clock ticks) started, only the difference between the values.

The "fTimestamp" is an older metric. It simply reports the amount of time, in seconds, that Motive has been open.


You can find more information on the latency measurements in our online documentation.
We also recommend that you reference the "SampleClient.cpp" sample in NatNet (~line 540) for a reference on how to use these new timing variables.


There will be a slight difference between streaming recorded and live data. When streaming from a recording, some of the time values will not be available, since there is no actual connection to the cameras. For example, if you look at the Status Panel in the bottom-right corner of Motive, the "System" latency will probably be blank while the software latency will continue to report how long it took the software to perform its calculations.This is explained in more detail in the Latency Measurement documentation.

Best,
Steven
--
Steven Andrews
OptiTrack | Senior Customer Support Engineer
help.naturalpoint.com
support@optitrack.com
steven.andrews
NaturalPoint Employee
NaturalPoint Employee
 
Posts: 405
Joined: Mon Jan 19, 2015 11:52 am

by dario.turchi » Wed Jan 24, 2018 1:55 am

Because the goal is to calculate things like "Software Latency" on a per frame basis, it does not really matter when the timer (clock ticks) started, only the difference between the values.

I don't fully agree on this. For example, how can I calculate what you define as "Client Latency" if the number of ticks associated to the "MidExposureTimestamp" is not making reference to a fixed time instant known also to the client ?
Basically, I would need to develop something similar to the NatNetClient::SecondsSinceHostTimestamp API function, which I can not use since I am developing with Python in a Linux environment.
If the number of ticks associated to the timestamps would constitute "absolute time references" (e.g., ticks since a well-known date) that would be easy, but this seems not the case.
Any suggestion about how to calculate the "Client Latency" on a python/linux client ?
dario.turchi
 
Posts: 8
Joined: Tue Aug 08, 2017 10:28 am

by steven.andrews » Wed Jan 24, 2018 12:01 pm

Thanks dario.turchi,

The high resolution timestamps are available through direct depacketization, which is the process any Linux application would need to follow in order to receive the tracking data.

The PacketClient and PythonClient both demonstrate the depacketization process. Specifically, you can find information on accessing the timestamps in line 933 of the PacketClient and line 301 of the PythonClient.

Unfortunately, I have to note the PythonClient provided in NatNet 3.0.1 is currently broken and will not run as is. We will be fixing this, but for the time being the PacketClient will be a better resource for determining the correct process for depacketizing the data.

Best,
Steven
--
Steven Andrews
OptiTrack | Senior Customer Support Engineer
help.naturalpoint.com
support@optitrack.com
steven.andrews
NaturalPoint Employee
NaturalPoint Employee
 
Posts: 405
Joined: Mon Jan 19, 2015 11:52 am

by dario.turchi » Thu Jan 25, 2018 1:52 am

The high resolution timestamps are available through direct depacketization, which is the process any Linux application would need to follow in order to receive the tracking data.

The PacketClient and PythonClient both demonstrate the depacketization process. Specifically, you can find information on accessing the timestamps in line 933 of the PacketClient and line 301 of the PythonClient.

Unfortunately, I have to note the PythonClient provided in NatNet 3.0.1 is currently broken and will not run as is. We will be fixing this, but for the time being the PacketClient will be a better resource for determining the correct process for depacketizing the data.


Thank you for your reply, but I probably didn't make myself clear about the issue.
I have fixed the PythonClient application and I am able to access timestamp by depacketization.

The point is that, on a linux client, those timestamps cannot be used to have an absolute time reference of, e.g., when the frame has been acquired by the camera (the "CameraMidExposure" as you call it). It seems to me that, from a client-side point of view, the use of "differential-valued" timestamps instead of "absolute" ones makes not possible to calculate the "ClientLatency" but only the "SystemLatency" ... Is this right ? When I receive a packet on the client how could I possibly relate the local clock to the "arbitrary" number of ticks that you provide (where "arbitrary" means from a not-known time instant)? I am just asking for confirmation here ...
I think that the use of timestamps indicating the number of tickes since a well-known epoch (windows systems use 1st January 1601) would make synchronization easier for Linux users that cannot use the C++ API
dario.turchi
 
Posts: 8
Joined: Tue Aug 08, 2017 10:28 am

by steven.andrews » Fri Jan 26, 2018 10:01 am

Hi dario.turchi,

I am afraid this is going beyond our normal Support, since we do not officially support the Linux environment. This is why direct depacketization becomes the only option when working outside of Windows.

I was able to find this last bit of information regarding your questions, which may or may not be useful in your efforts.

  • A message from the client of type NAT_ECHOREQUEST can contain an arbitrary payload.
  • The server responds with NAT_ECHORESPONSE with a payload equal to the incoming NAT_ECHOREQUEST, plus an appended 8 bytes containing its current timestamp as an int64.

Perhaps some other users will be able to post regarding their experiences syncing in Linux as well.

Best,
Steven
--
Steven Andrews
OptiTrack | Senior Customer Support Engineer
help.naturalpoint.com
support@optitrack.com
steven.andrews
NaturalPoint Employee
NaturalPoint Employee
 
Posts: 405
Joined: Mon Jan 19, 2015 11:52 am


Return to OptiTrack Data Streaming