Sample Clock Delay for PCI-6132

[fmd1977]

Hello,

I am using a PCI-6132 in a continuous analog measurement with a digital external sample clock.

The measurement is sensitive to delay between the sample clock and the measurement and so I'm trying to characterise this on my device.  To do this I use a function generator to create a synchronised sinusoid for the measurement channel and squarewave for the sample clock and examine the value the DAQ measures.

By varying the delay between the two signals I find the delay value that gives a value closest to 0V on the DAQ and take that as the sample clock delay.

I have found that the delay is low for high sample clock frequencies (2 MS/s) but for frequencies of 1MS/s the delay is >200 ns.

I guess my first quesiton would be if there is any information on what the delay should be for the PCI-6132 device.

But also if this seems like a valid method for measuring the sample clock delay.

I have seen this article: http://digital.ni.com/public.nsf/allkb/4F5347018DBA372B862575210051EF1D but it seems that the "Delay from Sample Clock" property doesn't work with S-Series devices or maybe with external sample clocks. More information on this would be appreciated.

The idea is to measure this delay and then compensate for it externally by delaying the measurement signal.

Thanks,

Frank

[LVbum42]

Frank,

I believe the difference in delay times you are experiencing is due to an attenuated signal.  If you open the 6132 specifications manual I linked to and scroll down to the typical performance graphs, the input attenuates at 1MS/s.  It's not that it's a shorter delay, but that with your setup you are detecting lower voltages faster. In order for a more accurate reading conduct the experiment from the 1-100kS/s.  Also, what function generator are you using? Are you sure of its synchronization?  In addition would you be able to post a snippet of your LabVIEW code so I can see how you are acquiring your data?.

NI 6132/6133 Specifications:  http://digital.ni.com/manuals.nsf/websearch/357F80807E3C11EF862571A90050120C

Regards,

Isaac S.