M-Series Board: What is the time delay and uncertainty between external trigger and sampling?

[creillyucla]

Hello,

I am using a 250kS/s M Series board to sample the peak of a waveform.  The amplitude of the waveform is ~0.5V and the waveform is within 5% of this value within ~100ns on either side of the peak.  Essentially, we would like to sample our peak with ~50ns accuracy.

We connect the waveform to AI0.  We are using PFI7 to as the external sampling clock.  Connected to the PFI line is the output of a Constant Fraction Discriminator (CFD).  When viewed on the scope, the falling edge of the CFD is perfectly ( < 1ns ) aligned with the peak of the waveform.  When we run the program to acquire the peak values, however, there appears to be a fixed delay ( on the order of hundreds of ns ), as well as some spread ( also on the order of nanoseconds ).

Does this M series card have the capability to sample with < 50ns accuracy?  What is the cause / value of the delay from our trigger to actual sampling of the waveform?

This solution also requires that our card be able to sample multiple channels simultaneously.  I understand that the S Series cards are capable of this.  Does the S Series suffer from the same timing issues as the M Series?

To summarize, my questions are:

Does this M/S series card have the capability to sample with < 50ns accuracy?

What is the cause / value of the delay from our trigger to actual sampling of the waveform?

Thank you,

Chris

[John_P1]

Hi Chris,

From what you've described, I am fairly sure that you are experiencing delay between the Sample Clock and Convert Clock edges (refer to the M Series User Manual for more information).  There are two major issues here that I think should be fixable with a bit of reconfiguration:

1.  Hundreds of ns of fixed delay:  By default, the delay between the sample clock edge and the convert clock is 3 ticks of the AI Convert Clock Timebase (see the above link).  This timebase should default to the internal 20 MHz timebase--three ticks would be 150 ns which sounds in line with what you are seeing.

One quick fix here is to manually configure the delay as follows (any point in your DAQmx task between the Create Channel and the Start functions).

You may find the above properties in the DAQmx Timing Property Node (More >> AI Convert >> Delay from Sample Clock)

2.  Spread on the order of nanoseconds:  I would imagine this is showing up since the convert clock is based off of the 20 MHz internal timebase which is not synchronized in any way with the external sample clock you are using.  Thus, there would be some periodic variance to when you are taking the measurement (up to 1 timebase tick off, or 50 ns).

The solution here is to either provide a common timebase to synchronize everything to, or to provide your own external convert clock that is phase-synchronous with your sample clock.  I'll leave it up to you which signal you wish

to provide--if providing the convert clock you wouldn't need to configure the delay mentioned above.  If you need any help with this part don't hesitate to post back.  One thing to point out is that you may actually use the same external signal as the sample and convert clock.

There is a third issue here that will not be fixable no matter how we configure the hardware:

3.  Sample multiple channels simultaneously:  Since the 622x is a multiplexed board, you cannot sample the channels at the same time.  The 50 ns you are looking for far exceeds the settling time specs of the 622x (as well as all other M series boards).

So, with your current hardware, we should be able to achieve your timing requirement on a single channel.  When extending to multiple channels, we have to account for the switching and settling time of the multiplexer which puts us well outside the 50 ns requirement.

The S series boards do not have this restriction since they have a dedicated ADC per channel and all channels are sampled on the same clock edge.  We will also be offering simultaneous sampling on some of our X Series boards, but currently there are only PXIe versions that have been announced with simultaneous sampling.

Thanks for posting, I hope this has been helpful,

-John

Message Edited by John P on 08-17-2009 05:08 PM

Message Edited by John P on 08-17-2009 05:15 PM

[creillyucla]

Thank you very much, your response was extremely helpful.

How would I configure the convert clock to come from the same source as the sample clock in ANSI C?  It's not immediately clear to me what functions I should use.

[John_P1]

Hi Chris,

I guess I should have asked which ADE you were using--I hope my previous post still made some sense (most of the DAQmx functions are direct mappings between LabVIEW and C).

You actually don't have to do anything special to use the same line as the convert/sample clock other than tell the driver that you want to do so.  To set the convert clock source in C you can use DAQmxSetAIConvSrc:

Regards,

John

[John_P1]

Hi Chris,

I actually just tried configuring the initial delay that I mentioned in my first post, it turns out that you can only specify a minimum of 2 timebase ticks (not 0 like I mentioned in my first post).  Sorry for the confusion, I should have tried out the configuration before posting.  One other thing to note is that our X series devices use a 100 MHz timebase for Analog Input tasks, so the minimum configurable delay would go from 100 ns (2 ticks of 20 MHz) to 20 ns (2 ticks of 100 MHz).

Nonetheless, I think using the external sample/convert clock should do what you need (on the first channel).  If you run into any issues with the configuration feel free to post back.  Thanks!

-John

[creillyucla]

Hello,

When I try to set the convert clock to the same source as the sample clock, I get this error:

DAQmx Error: Measurements: Specified property is not  supported by the device or is not applicable to the task.

Property: DAQmx_AIConv_ActiveEdge

Status Code: -200452

Also, why does one need a sample clock at all if one has specified a convert clock source?

Thanks again for the help,

Chris

[John_P1]

Hi Chris,

I can run the LabVIEW example code over here with no problems on my PCI 6251, as well as on a simulated PCI 6221.  If you could post your code I'd be more than happy to take a look at the C version.  This isn't the most standard configuration so maybe there's some nuance we are missing.

The sample clock is necessary to start the beginning of the scan list.  If we were sampling two channels of ai we might want to sample the two channels relatively close to one another but only take the next pair of samples after a slower signal has occurred.  The following diagram from the M Series User Manual helps illustrate why we still need to specify a sample rate even if we give an external convert clock:

In the above diagram, the convert clock could be a much faster signal than the sample clock, but extra ticks after the first two would be ignored until the next sample clock edge (assuming 2 channels in the scan list)

So, the sample clock starts the beginning of your scan.  Once the scan finishes, the device will wait for another sample clock edge before taking the next scan.

-John

[creillyucla]

Hello John,

I routed the sample clock and convert clock to be output to PFI lines.

When I looked at the signals on the scope, it appeared as though the SAMPLE clock is delayed by 100ns (2 timebase ticks).  In addition, the SAMPLE clock is also susceptible to the 50ns spread.  It appears as though there's no way to get better time resolution than the internal timebase rate from the M series card.

This troubleshooting adventure has, though, been pretty informative.

I'm still confused about why DAQmx does not seem to recognize certain functions in ANSI C.

So far, two examples that I've found include:

DAQmxSetExportedSampClkDelayOffset

and

DAQmxSetExportedAIConvClkOutputTerm

Perhaps I am doing something incorrectly.

Thanks,

Chris

[John_P1]

Hi Chris,

When you say the sample clock is delayed by 100ns, what is this delay relative to?  The convert clock should be delayed by the 2 timebase ticks relative to the sample clock, with jitter of up to 1 timebase tick if the convert clock and sample clock are not sharing a timebase.

Were you able to use your external clock signal as the convert clock?  Doing so should greatly reduce the delay you are seeing on a single channel.  I'm also not sure what might be going on with those functions, are you getting compile errors?  I'd like to take a look at the code you have so far if possible so I can better understand what might be going on.

-John