Making sense of times

[tobi]

Hi,

I'm developing an application which merges Optitrack tracking data in real time with other data sources. One important consideration for this purpose is clock synchronization, in particular understanding of latencies. I cannot use the hardware SMPTE sync. The only thing I think I'm missing is the processing delay, i.e. the time from when the frame was taken to when it is put on the network.

I'm having a hard time making sense of the information provided by the NatNet library. We have:

Code: Select all

typedef struct
{
    int iFrame;                                     // host defined frame number
    ...
    float fLatency;                                 // host defined time delta between capture and send
    unsigned int Timecode;                          // SMPTE timecode (if available)
    unsigned int TimecodeSubframe;                  // timecode sub-frame data
    double fTimestamp;                              // FrameGroup timestamp
    ...
} sFrameOfMocapData;

fLatency and fTimestamp both seem to count the time since starting Motive, the former as float, the latter as double, but there is slight variation between the two. I would expect fLatency to be what I need, but it clearly isn't. Its purpose eludes me. Is there a setting somewhere that I'm missing that gives fLatency another meaning? Is there another way to find out when the packet was emitted relative to the time the camera frame was taken? Is the difference between fLatency and fTimestamp meaningful (either can be greater, though I'd think not, independent of the resolution issues with evergrowing floats).

Motive prints a "latency" value in its status bar. I'm not sure about the meaning of that. It sure seems to be what I want, but I didn't find a comparable entry in the NatNet data types.

[joe.lee]

Hello tobi,

Which version of NatNet/Motive are you using?

In NatNet 2.10, the fLatency value in the frame of data reports the estimated software processing latency, which is the time between when Motive receives the frame data and when they are all processed and ready to be streamed out. (Before NatNet 2.10, this value was used to report computer's hardware timestamp due to compatibility reasons with older software). In your case, you would want to use Motive 1.10, and the fLatency value included in NatNet version 2.10.

However, note that this does not represent the latency of the entire system (hardware & software). It only covers the software processing portion of the pipeline. Unfortunately, there is no way to obtain the precise hardware latency values (Camera exposure to Motive receiving the frame). You can estimate this very roughly by taking the inverse of the camera frame rate and adding them to the equation: e.g. (1/(max camera frame rate) * 1000) + software latency + .3 (estimated transmission time). We are improving latency reports in the upcoming release so that the client can obtain latency measurements at different points of the system pipeline. If latency measurements are critical to your application, this update will be very useful.

The latency value on the status bar in Motive 1.10 is the fLatency value. There could be a slight difference between two values because the refresh rate on the status bar is slower than the refresh rate of the NatNet stream; in which case the value is averaged from multiple frames per each refresh.

Hope this answers some of your questions.

Thank you,
Joe


Joseph Lee
OptiTrack | Customer Support Engineer

[tobi]

Thank you for your detailed reply that also took a few possible follow-up questions into account.

My conclusion: I'll look forward to updating from Motive 1.9.0