Jump to content

MikeT

Members
  • Posts

    3
  • Joined

  • Last visited

Posts posted by MikeT

  1. 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

  2. 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

  3. 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

×
×
  • Create New...