PCI express alternative to PCI 6602?

[thomas03]

Kevin,

I found what you proposed just minutes ago.

My problem all week has been that Switzerland is not in your time zone.

Could have saved me much time.

Thanks a lot for your help!!!

Thomas

[John_P1]

Hi Thomas,

You set the filter for the trigger in a very similar manner, but you have to use DAQmxSetDigEdgeArmStartTrigDigFltrEnable and DAQmxSetDigEdgeArmStartTrigDigFltrMinPulseWidth.

As far as waiting for the sample to be available, you have a couple of options that Kevin mentioned:

1.  Wait for data to be available before calling DAQmx Read.  You can do this by polling the available samples with DAQmxGetReadAvailSampPerChan, or you can register an event to occur every N samples with DAQmxRegisterEveryNSamplesEvent.

2.  Read from each of your counters in parallel threads.

3.  Set the timeout to a lower value and handle the error when it comes up

I like the first option personally--if the counter read has the potential to block for a long time then you can avoid calling into it in the first place.

Best Regards,

[thomas03]

Hi John,

Everything works! Almost.

About once a week I receive the error -201314: Multiple sample clock pulses. It occurs only at about one in one billion pulses.

Playing with digital filter parameters did not help.

We have used an oscilloscope to look at the 5V, 35ns pulses from our detectors and also a frequency generator we use for testing. When plugged into the NI connector block (50Ohm BNC cable) we observe severe glitches/reflections for both devices that are absent when not plugged into the connector block. For the detectors the reflected pulse with a delay of about 10 ns after is nearly 2V high and therefore probably the source of the occasional error.

1. Do you have a suggestion how to improve the signal conditioning?

2. Is there a way to ignore this error and force the card to proceed? 

Thank you,

Thomas

[thomas03]

Hello,

The problem i have discribed in the message above persists.

I do not get a reliable reading for our perkin elmer avalanche detectors.

At high count rates above 1 Mhz the "multiple sample clock pulses" error occurrs within seconds.

In the testpanel of the measurement explorer this problem does not seem to occur and detector signal is counted properly.

What can I do?

[Kevin_Price]

No solid answers here, but in lieu of total silence, here are some thoughts off-the-cuff.

- It sounds like your root cause is likely to be false "sample clock" edges caused by noise, or maybe transition ringing (possibly due to impedance mismatch), or whatever.

- This seems like the kind of thing that digital filtering should be able to suppress, though it may take some trial and error to determine where to set the pulse width threshold for the filter. 

- In MAX, the APD signals are probably just being treated as edges to count rather than as a sample clock that requres a value to be buffered & transferred.  That would explain the absence of errors.  However, any extra glitches would still register as extra (false) counts.

- In attempting to support up to 3 MHz APD pulse rates, perhaps buffered period measurement isn't really your best choice?  I don't know exactly what you're studying, but I know other APD-related threads discuss

"binning" operations for high photon rates. 

   With binning, you would let the APD signals be source signals that simply increment the count registers, much like what you observe in MAX.  Then you would produce a fixed timebase to use as a sample clock at a rate that makes sense for the phenomenon under study.  If the dynamics of the physical process only have a bandwidth in the 100's of Hz for example, then you could do "binning" at 5 or 10 kHz and produce plenty of quality info.

-Kevin P

[thomas03]

Thank you Kevin for your answer. You are making solid points.

There really is a significant impedance mismatch between the output of APDs (we tested 7 from Perkin Elmer) and counter input of the 6320.

Unfortunately binning is no option for us:

We need buffered measurement for autocorrelating the signal with a resolution down to 50 ns (fluorescence correlation spectroscopy, FCS).

Thereby the average count rate lies typically below 100 kHz. The intensity can, however, exceed 1000 counts per millisecond depending of the number of molecules in the detection volume.

Having in mind what you said about MAX/binning I wonder how binning the APD signal can be a reliable solution. Glitches producing false counts is not a good prerequisite

to study a physical process...

Are there any other (APD) users that came across this issue and maybe solved it?

Thanks,

Thomas

[Kevin_Price]

Agreed that the binning might still produce occasional 1-count errors within a bin where such a glitch occurs.  I just took a guess that such occasional 1-count errors might fall within the realm of acceptable measurement tolerances.  Especially compared to the current behavior, where they produce data acq errors which prevent you from getting any results at all.

Again, just guessing, but I figured there'd be lots of trials, lots of reps, and eventually some sort of smoothing curve-fitting operation over a large population of data.  Didn't you say you were getting about a 1 per billion glitch rate?  I figured that'd be invisible in a sea of data.

Just to poke and prod a bit more, you mention a 100kHz typical count rate with higher rates that can average

1 MHz for a msec or more (probably with shorter-term peaks that exceed 1 MHz).   You also talk about autocorrelation at 50 nanosec (20 MHz).  I don't know anything about FCS and don't know what kind of autocorrelation you mean, but it strikes me that the very vast majority of 50 nanosec intervals will contain exactly

0 counts, and probably all the rest have 1 count.   That severe of a discretization effect strikes me as a bigger problem to deal with than an off-by-1-per-billion count problem.   Again, I'm ignorant of FCS, just trying to apply general mathematical horse sense to a bunch of numbers out of context.

-Kevin P

[thomas03]

Yes, when correlating low lag times in FCS the content of the 50 ns intervals is almost always zero but the few exceptions make the difference an FCS can be used even at smaller lag times, e.g. to measure fluorophore triplet dynamics.

The glitch rate depends on the individual APD and also seems to depend on the count rate. With increasing intensity the glitch rate appears to grow overproportionally.

The output of the APDs are not identical (e.g. Pulse Voltage varies between 4 to 5.5 V). When connected to the counter the voltage is pulled down to (typically) 3V, thus fairly close to the trigger level.

The 1 billion glitch rate was the best case, several 100 kHz the worst case.

You are right, that such error rates are okay for most applications. We could also live with it.

Our real problem is that the counter stops the bufffered measurement at every glitch.

Thanks for your thoughts!

[Kevin_Price]

Soooo....

Maybe you're already on this, but could you in fact live with the following?

1. Feed your 4 APD signals to your counters as "Source" signals that will increment the count registers once per edge.  This way glitches just become count errors that won't make the task error out.

2. Create a dummy DI task at up to 1 MHz sample rate (the max rate supported on the 6320), and use its sample clock for the counters.  This internal routing should guarantee a clean glitchless signal that won't error out.

3. Mathematically rework your binned counts into the format you need.

-Kevin P