How can I determine time of day for a sample (USB-1608G/Universal Library)?

[MikeT]

Hello,

I'm hoping that I can get some information or guidance to help me determine the best scheme to use to synchronize data from an MCC device (plan is to use USB-1608G with Universal Library) with data from non-MCC sources.  I work for a company that produces some devices using radio telemetry, and we would like to synchronize signals from those devices with analog signals from the USB-1608G.  The goal is long-term synchronization within +/- 10 milliseconds.

Obviously, the ideal solution would be to use external pacing and triggering into the USB-1608G.  We do that with some of our current products, but that may not be possible in a new product under development.

From my review of the Universal Library, and searches here, I can't find any functions that provide the time of day for any given sample.  The minimum I would need is the time of day for the very first sample, and then I would need to devise a method to detect and correct for long-term drift.

Does anyone have and suggestions?

Thanks in advance for any help.

-Mike

[Jeffrey]

Hello @MikeT

The USB-1608G series does not include a real time clock feature. so there is no way for it to time stamp the data.

You can accomplish this  depending on your sampling method:

1.  If taking individual samples using the UL library call AIn() or VIn():  Use an IDE built in time of day function call just before or after you call AIn or VIn.

2.  if streaming analog data in using AInScan(), Again, use the IDE's built in time of day function call just before the scan begins.  Since the AInScan() is hardware clocked, you know how much to offset each collected sample after the scan starts.

Note that all supported programing IDEs such as C/C++, Python, VB.NET and C#.NET have built in functions to read the current time, regardless of Windows or  Linux.

[MikeT]

Hello Jeffrey,

Thank you for your response.  I was assuming a method like you suggested would be my fallback plan, but was hoping there might be some method within the Universal Library that would assist in this.  I suppose the best I can do is to get the system time prior to and following the first sample, which will allow me to give a worst-case estimate of error for the time of the first sample due to system latencies.

So, if I use the USB-1608G in continuous mode, am I correct that the first data transfer will not occur until the board's FIFO is at least half full?  Based upon the data sheet, that would appear to be 4 ks / 2 = 2ks.  If sampling 4 channels @ 1 kHz, that would mean my first data transfer would happen after 500 milliseconds, correct?

Best regards,

Mike

[Jeffrey]

The FIFO transfer is irrelevant. You have no access to that. That would be akin to figuring out your automobiles' speed by looking at engine RPM.   

It is the buffer transfer that is important.  Prior to calling AInScan() you would have created a buffer using WinBufAllocEx() or ScaledWinBufAllocEx()

You/ your app makes this happen when you call the UL library function WinBufToArray().

Using another UL function, GetStatus(), you find out where your scan is writing data to the local buffer.  When it is above the mid point you copy the lower half of the buffer to local array and when it is below the mid point you copy the upper half of the buffer to the local array.

Just for the sake of this example, let's say you are acquiring data from 1 channel, at 1 kHz.  In your app you create a buffer using WinBufAlloc() for 1000 samples. You set your app to take a time of day (TimeOfDay) reading just before you start your app.

Immediately following  the scan start, you start a timer/or sleep to periodically call GetStatus().  FYI, I recommend you call it every 250 mS. Among other parameters, GetStatus() returns CurrentIndex.  This lets you know where the the driver is in writing to the buffer.  When CurrentIndex is above the mid point, (in this example, 500) you can copy the lower half of the buffer to local array().  Array(0) is your initial sample.  That sample was taken as close as the collective system can to your TimeOfDay reading so that is the time stamp for Array(0).  Since this example is set to acquire data at 1 kHz or a new sample every 1 mS, Array(1) is TimeOfDay +1 mS  and so on.

You might ask, "What do you mean, 'That sample was taken as close as the collective system...' ?"  

There is an operating system delay in setting up scan.  it can be between 20 mS to 80 mS.  To be clear, there is little you can do remove or minimize that time delay.  Windows is a non-deterministic system and at time Windows needs to service a higher priority than your app such as memory refresh, Screen refresh, Mouse movement, etc.

The only way I have found to negate or reduce the scan setup time is to use the External Trigger option of AInScan().  In this way, your scan sets up and waits for the external trigger. You can use a digital bit set to output tied to the digital trigger, take your TimeOfDay reading and toggle the digital bit On then Off (rising edge).  All subsequent samples would follow the same time stamp rule as above.

[MikeT]

Thank you again Jeffrey for your response.  I am aware that Windows isn't a true real-time operating system, and have encountered issues such as these in the past.  I think the most valuable information you have shared is that the latency from a request to sample can be 20 - 80 ms.  This level of latency will likely preclude me from coming up with a solution to attain a true +/- 10 ms synchronization with another data source with a software-only approach. I'll share this information with my team, and advocate for requiring a hardware connection for triggering the samples on this project.

 

Best regards,

Mike