grpc-device and timestamps

[david.yamagata]

I'm currently looking into NI's grpc-device (https://github.com/ni/grpc-device) and in the process learned that in NI's text based APIs the timestamp has to be estimated as it is not returned with the data like it is when working in LabVIEW (specifically working with daqmx for now).  Below are some links related to timestamps in text based APIs: 

• https://knowledge.ni.com/KnowledgeArticleDetails?id=kA00Z0000019UrMSAU&l=en-US
• https://knowledge.ni.com/KnowledgeArticleDetails?id=kA00Z000000kJy2SAE&l=en-US

Does grpc-device also have this limitation?  (I'm hoping that I overlooked something)

[santo_13]

Are you referring to the ability of the DAQmx driver to return the t0 value in a waveform acquisition?

FYI - even in LV, it is estimated, just that the driver does that for you.

[david.yamagata]

Yes, I was referring to the equivalent of the t0 value in the waveform.  Do you happen to know if grpc-device has a feature that would return this information along with the data?  There was concern from my team that the additional layer of the grpc implementation adds some amount of delay/jitter.

And thanks for pointing out that its an estimate on the LV side as well.  I re-discovered this link explaining just that 😀

• https://knowledge.ni.com/KnowledgeArticleDetails?id=kA00Z000000P9Q9SAK&l=en-US 

[santo_13]

What kind of application do you use DAQmx in? why is the t0 timestamp so critical?

[david.yamagata]

Sorry for the delayed response, and thanks for the continued support on this.

This is for a HITL platform and we want to be able to accurately align data from a cRIO's acquisition with telemetry data from a separate embedded device.  I don't have the exact values but from the testing the team performed they were getting "inconsistent delay with the gRPC calls".