NI PCIe-6351 Count Edges Channel error on fast TTL - Multiple Sample Clock pulses were detected

[mhbakalar]

Hello,

I am trying to use a PCIe-6351 to record the arrival times of a fast TTL pulse stream (generated by an Excilitas/Elmer Perkin APD). The TTL pulses are 2.5 volt amplitude, 20 ns duration, with a gauranteed dead time of 50 ns between pulses. I am trying to use the the Count Edges function, with the  100MhzTimebase as the input terminal and the input to counter 0 (PFI8) as the sample clock. After a few seconds of acquiring data at 100 Mhz, the application throws the following error (-201314):

"Multiple Sample Clock pulses were detected within one period of the input signal"

I had thought that because there is 50 ns dead time between pulses, multiple pulses would never arrive within a single clock cycle of the 100 Mhz timebase. Is there any way this might not be the case? Alternatively, is it possible that the counter is triggering on some jitter around the edges of the pulses? If so, is there any way to filter such high frequencies without losing the 20 ns pulses?

I have read through the forums for similar problems with photon detectors, but have not been able to resolve this issue. Thank you for the help.

Matthew Bakalar

[cade]

Hello Mathew,

I want to make sure I understand your parameters.

First, can you say exactly which function the 100MHz timbase is the input for as well as which specific input it is?

Which are you specifing as the counter source for the Count Edges function?

Also, am I correct in saying that you are using the TTL signal as the sample clock for the DAQmx timing function and as the signal which you are trying to count?

If for some reason you are using the 100MHz timbase as a sample clock input and trying to count edges of the TTL signal, this would cause the error that you mentioned because the timebase signal is faster than the edges which you are trying to count.

[mhbakalar]

Hello Cameron,

The TTL signal is connected to PFI8. The task I created is a "CountEdgesChannel" task with counter 0 as the input. PFI8 is configured as the sample clock (in NIDaqmx .net, task.Timing.ConfiguSampleClock). The 100 Mhz timebase is configured as the "CountEdges Terminal" (in Nidaqmx .net, channel.CountEdgesTerminal).

So, the 100 Mhz timebase should increment the counter on every clock cycle. The TTL pulse should latch the value of the counter into the data buffer. In this way, the arrival time of each TTL pulse is recorded in the data buffer.

Best,

Matt

[cade]

Yes, that is strange.  It seems that you have the correct parameters set.

Have you tried implementing a slower sample clock or tried to allow for more time in between the TTL pulses to see if you get the same error message?

Also, when do you normally receive the error message? Does it always occur around the same time during your aquisition?

Have you received any counted edges in the buffer before the error occurs?

[John_P1]

It sounds like the input signal is being detected as multiple edges.

The PFI filtering feature on the X Series card likely isn't going to be suitable for you.  The minimum setting is actually exactly 20 ns, which should in theory guarantee a 20 ns pulse passing through.  However, if the signal is high for anything less than that there wouldn't be a guarantee (depending on the phase of the timebase relative to the rising edge of the signal)--considering rise times and that there is evidently a glitch in the signal itself, it probably isn't actually a continuous 20 ns high time by the time the DAQ card sees it.

What you should do instead:

1. Configure a second counter as a retriggerable counter output (single pulse).
   
   
2. Use your external signal as the start trigger for this counter output task.
   
   
3. Set the initial delay, high time, and low time for the counter output task all to 20 ns (the minimum).
   
   
4. Use the internal output of the counter output task as the sample clock source for the original edge count task.
   

The counter output will be triggered when it sees the external signal, wait 10-20 ns, then generate a 20 ns pulse.  If there is a glitch on the trigger line during this 30-40 ns that the output is generating, it will be ignored.  The counter output will be re-armed in time for the next pulse given the minimum dead time of 50 ns between pulses.

Best Regards,