PFI channel crosstalk, Error Code: -201314

[fgoe]

Hi everyone,

I would like to perform multiple externally synced edge counting tasks on an NI PCIe-6353.

The problem is that I get crosstalk of the pulses between the PFI channels, leading to misinterpreted sample clock pulses and eventually to the error -201314:

'Multiple Sample Clock pulses were detected within one period of the input signal. Use a Sample Clock rate that is slower than the input signal. If you are using an external Sample Clock, ensure that clock signal is within the jitter and voltage level specifications and without glitches.'

I am counting pulses from APDs, they have a height of 5V, width of 20ns and a  rate of approximately 1MHz. My sync Signal has a repetition rate of 10kHz, the pulses are 5V high and 50µs long. When I start the measurement, it takes only a couple of seconds until the mentioned error appears. I can also validate it with the NI-MAX, by 'counting' pulses in my sample clock input channel even if there is nothing attached to it (only the APD to the counter channel).

I have tried the following combinations:

sample clock connected to: PFI 0, PFI 5, PFI 1

counter connected to: PFI0, PFI 5, PFI 8, PFI 3

they all fail except when I use the PFI8 as only counter source.

Also, damping the pulse edges with a lowpass or adding a 50 Ohms resistor to the connecor does not work.

The connection cable to the breakout box is 0.5m long. I have tried the SCB-68A and BNC 2110 Breakout box without much change in the behaviour.

Is there a way to better isolate the PFI channels, or are there channels that are isolated better from each other?

Thanks for the help

Fabian

[dennis.waschik]

Hello Fabian,

maybe this Knowledge Base Page will help with your problem: Why Do I Receive Error -201314 in Counter Sample Clock Buffered Pulse Measurement

http://digital.ni.com/public.nsf/allkb/18E8B27384BBCC7B86257A6800618056?OpenDocument

If not you could send your VI in this Forum Post.

Kind Regards.

[John_P1 · Accepted solution]

You can configure a digital filter on the sample clock PFI line to prevent the noise from registering as a legitimate sample clock pulse (set Min Pulse Width to something less than the sample clock width but greater than the width of the noise pulses--5.12 us uses one of the built-in dividers and would probably be suitable).

If you want to troubleshoot the source of the noise itself, I'd start by scoping the sample clock line (the scope needs to be fast enough to pick up ~20 ns pulses if this is indeed the source of the noise).  I'd suspect that the issue is more likely with how the signals are connected/grounded.  Keep in mind that the PFI lines on the DAQ card share a common digital ground.

Best Regards,

[fgoe]

Hi John, the digital filter solved the problem. I wasn't aware of it's existence, thanks!

I'm using the c-api instead of labview, here's the calls to the device: 

DAQmxGetSysNIDAQMajorVersion (9)
DAQmxGetSysNIDAQMinorVersion (8)
DAQmxCreateTask ("", 0x6DEEC030)
DAQmxGetTaskName (0x6DEEC030, "_unnamedTask<0>", 3000)
DAQmxCreateCICountEdgesChan (0x6DEEC030, "/Dev1/ctr1", "", DAQmx_Val_Rising, 0, DAQmx_Val_CountUp)
DAQmxCfgSampClkTiming (0x6DEEC030, "/Dev1/PFI1", 20000, DAQmx_Val_Rising, DAQmx_Val_ContSamps, 1000)
DAQmxSetSampClkDigFltrEnable (0x6DEEC030, True)
DAQmxSetSampClkDigFltrMinPulseWidth (0x6DEEC030, 2E-005)
DAQmxStartTask (0x6DEEC030)
DAQmxReadCounterU32 (0x6DEEC030, 256, -1, 0x075DB6E8, 256, 0x07874BE8, NULL)

Without line 7,8 the program crashes with the mentioned error.