Timing latency

[mhtx]

We're trying to get accurate (ms level) measurements from one pre-processed analog signal, one (python) program performing some processing, and a post-processed analog signal. Currently we have the two analog signals fed into a NI USB-6212 box. Additional processing is performed by other systems before the signal reaches our program and after it as well. What we'd like is a measurement of what part of the total lag is the analog signal getting to the python program and what part is after.

Since the NI DAQ box can get highly accurate time measurements from a recorded start time using LabView, we figured that having our python script also record the system time would suffice. However, based on our readings, we're not completely confident that the clocks are matching up - our code seems to get the signal before the NI DAQ box records the signal, which should be impossible.

We're considering trying to get our program to output a signal to the NI box so all measurements are performed on the same clock - in which case, getting the lowest latency signal possible is important.

The other approach is to move the NI DAQ code inside our code (using pydaqmx) - but my understanding of how data is collected in this way in batches sounds like it doesn't guarantee more accurate timing. 

Any thoughts or advice would be appreciated. This is my first time working with a NI DAQ system.

[Esteban.R]

Hi mhtx

If I have understood your application you are using the daqms driver with python and in LabVIEW, when you run the application in LabVIEW the delay is bigger than the application that runs in python.

Is that what you are doing?

If you are programming the application in python, when do you request the system time as a reference? Here is a link with information about how accurate is the timestamp of the waveform returned by the NI DAQmx device.

Regards

Esteban R.

[mhtx]

I am not using the daqms driver with python. I have some code running continuously within Python that checks the current value of a variable and the current system time. It is queried about once every millisecond.

The link you sent seemed helpful - no strong guarantees, but very likely that the timestamp is no more than ~1ms off.

-Matt

[Esteban.R]

Hi mhtx

If you are not using the DAQmx driver, how are you communicating with the device and acquiring the data?

Regards

Esteban R.

[mhtx]

The Python code is not communicating with the device - its datastream is part of a closed black box we're trying to understand. So the challenge is getting a time clock in Python (based on the system clock) synced with the DAQ data. Currently LabView handles the DAQ.

More details: We're trying to get the latency of a motion capture system as part of a virtual reality setup. We have a zero-latency signal to the DAQ that reports an object's actual position - our ground truth of when motion occurs. Our motion capture system then tells our Python process where the object is located. The python process then alters the screen based on that position. We have a photodiode on the screen to detect those changes, which feeds into the DAQ. So the DAQ (LabView) has access to the beginning and end points of the processing, and the Python process to the midpoint. We'd like to know how much of the total latency is before the position info gets to the Python process (motion capture and network latency) and how much is after (rendering and display). 

We COULD try and move what we're having LabView do inside the Python process... but it didn't sound like that would necessarily make the syncronization more reliable, since the DAQ data would still use an initial timestamp based on the system clock. But I'm a novice when it comes to NI DAQ, which is why I'm turning to the forum.

Thanks!

-Matt

[Esteban.R]

Hi mhtx

Maybe this might help you Call Perl and Python Scripts from LabVIEW. I think that the problem might be that you are trying to synchronize both systems but when you say synchronize what exactly you mean. From my point of view the process is a sequence and there is not any task in parallel but of course as I do not know your application I might be mistaken. Why not move all the application to LabVIEW?

Regards

Esteban R.

[mhtx]

Sadly, no. The Python process and LabView must be running in parallel as both are receiving continuous streams of data. The challenge we're facing is measuring the latency between streams.

The motion capture system (PhaseSpace) does not natively support LabView. Nor is LabView capable of rendering largescale 3D scenes.

So, either:

(1) We acquire confidence that the DAQ clock and the system clock are in sync (which intuitively they should be, or at least close, since the DAQ gets its start time from the system clock). If this is something others have experience with, tips would be appreciated.

(2) We move the Labview functionality into Python. Since it seems the DAQ outputs batches of data and still relies on t0 and delta_t, I don't see why this would help - but I could be wrong

(3) We somehow get a low latency output from the Python program to LabView. We considered using the soundcard and sending a signal to the DAQ, but that introduces too much latency. If there's a simple way to have the two processes communicate, it would be appreciated.

Thanks again,

Matt

[Esteban.R]

Hi mhtx

I see the problem, unfortunately I do not know if it might be possible internally even if you are able to use the same internal clock of the computer you will need like some sort of trigger in order to properly synchronize them.

If you are actually thinking of using the sound card for synchronization, why not use the serial ports it might be faster and more stable, but it might require a little more code in order to program some sort of synchronization routine between both tasks. But to do this you will need two serial ports, the first one should be the one of the computer and second one could be a usb to 232 converter from NI (or some other usb to serial converter that might be compatible with LabVIEW )

So you could control one port with python and the other one with LabVIEW. (I assume that you can control a serial port using python but keep in mind that I am not familiar with python).

Regards

Esteban R.