C# NatNet precision and frame skip issues.

NatNet, VRPN, TrackD, and Plugins
Post Reply
bteitler
Posts: 18
Joined: Thu Jun 12, 2014 12:57 am

C# NatNet precision and frame skip issues.

Post by bteitler » Thu Jun 12, 2014 1:23 am

I'm using the latest versions of Motive and NetNetSDK. I'm running Motive and the samples on the same machine. The C# examples seem to have only tenth of a second precision floats from the FrameOfMocapData object for both "fLatency" and "fTimestamp". Is this expected? The C examples are all reporting millisecond precision values correctly. I'd really like to use C# but I need millisecond precision. I'm pretty sure they aren't being truncated by accident anywhere in client code - I'm getting them straight from the FrameOfMocapData on each FrameReadyEventHandler event.

I'm also having a really strange issue where many of the frames seem to be missing / skipped, but only when I'm not recording in motive. As my project requires live data, I don't really care about recording the data in Motive. However, if I don't record in Motive, I get large bursts of missing frames (m_FrameOfData.iFrame not always consecutive). I know Motive has the data because I can see in the rendering in motive that the tracking is flawless, but the missing frames cause problems in my end application. Is Motive doing something different with respect to streaming data when recording is on or off?

bteitler
Posts: 18
Joined: Thu Jun 12, 2014 12:57 am

Re: C# NatNet precision and frame skip issues.

Post by bteitler » Thu Jun 12, 2014 2:17 pm

My first issue with precision seems to be a floating point accuracy problem. I had Motive open for a few days so the timestamps were large numbers, causing problems with the decimal part. However, I still don't know why the C examples have no problem and output millisecond precision (they seem to be using single precision float as well). However, in the short term I can simply restart Motive to fix this.

My second issue with recording vs. non recording is still a problem however.

bteitler
Posts: 18
Joined: Thu Jun 12, 2014 12:57 am

Re: C# NatNet precision and frame skip issues.

Post by bteitler » Sun Oct 05, 2014 11:42 pm

I'm also having a really strange issue where many of the frames seem to be missing / skipped, but only when I'm not recording in motive. As my project requires live data, I don't really care about recording the data in Motive. However, if I don't record in Motive, I get large bursts of missing frames (m_FrameOfData.iFrame not always consecutive). I know Motive has the data because I can see in the rendering in motive that the tracking is flawless, but the missing frames cause problems in my end application. Is Motive doing something different with respect to streaming data when recording is on or off?
I still have this issue with all versions of Motive I've tried. Can someone please help? It is really undesirable to have to record a massive take in order to stream consistent data.

NaturalPoint-Dustin
Posts: 609
Joined: Tue Mar 19, 2013 5:03 pm

Re: C# NatNet precision and frame skip issues.

Post by NaturalPoint-Dustin » Mon Oct 06, 2014 9:45 am

Hello, I will look into this today and have a response for you shortly.
Dustin
Technical Support Engineer
OptiTrack | TrackIR | SmartNav

morgan
NaturalPoint Employee
NaturalPoint Employee
Posts: 199
Joined: Tue Jun 24, 2008 2:01 pm
Location: Corvallis, OR, USA
Contact:

Re: C# NatNet precision and frame skip issues.

Post by morgan » Mon Oct 06, 2014 10:42 am

Motive 1.6b2 and earlier has an inconsistency in the NatNet streaming frameID parameter in Live when not recording.

This has been resolved for the pending 1.7 release. Until then can you try using the NatNet fTimestmap value, and converting that to a frameID if necessary?

Morgan

bteitler
Posts: 18
Joined: Thu Jun 12, 2014 12:57 am

Re: C# NatNet precision and frame skip issues.

Post by bteitler » Mon Oct 06, 2014 7:46 pm

I don't explicitly need the frameID at this time so I will try without it. I mostly was using it to try to detect network problems and discard duplicate packets. Thanks for the response.

Post Reply