Buffered Edge Counting Error: "Multiple Sample Clock pulses"

[jpedrego]

Dear all,

Some time ago, I asked regarding "Basic Buffered Edge Counting". Kevin_Price put me in the right path.

To put it in context: I need to time tag the arrival of photons from an ion in an RF trap.

However, I have now some issues...

First, I am using the Python NI-DAQmx library rather than LabVIEW (it should not change anything). A simplified version of my code is:

import nidaqmx
from nidaqmx.constants import AcquisitionType, Level, Edge

fs = 100e6
nb_channels = 128

task_ci_ctr3 = nidaqmx.Task()
task_ci_ctr3.ci_channels.add_ci_count_edges_chan("Dev1/ctr3")
task_ci_ctr3.channels.ci_count_edges_term = "/Dev1/100MHzTimebase"

# CTR 3 src=> PFI 5
task_ci_ctr3.timing.cfg_samp_clk_timing(rate=fs, source="/Dev1/PFI5", sample_mode=AcquisitionType.CONTINUOUS, samps_per_chan=nb_channels+1)

# CTR 3 Gate => PFI 6
# Specify the input terminal of the signal to reset the count:
task_ci_ctr3.channels.ci_count_edges_count_reset_term = "/Dev1/PFI6"
task_ci_ctr3.channels.ci_count_edges_count_reset_active_edge = Edge.RISING
# Specify whether to reset the count on the active edge specified with ci_count_edges_count_reset_term.
task_ci_ctr3.channels.ci_count_edges_count_reset_enable = True

task_ci_ctr3.start()

for i in range(0,10):
    counts_aux = 
task_ci_ctr3.read(number_of_samples_per_channel=nidaqmx.constants.READ_ALL_AVAILABLE)

task_ci_ctr3.stop()

Everything is fine for a little way, but then:

DaqError: 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.
Task Name: _unnamedTask<1>

Status Code: -201314

I checked and the problem is that sometimes there are two pulses coming from the detector very close in time and the DaqError is triggered. The pulses themselves are quite "clean" (negligible jitter).

My question is, there is a way to ignore the error and keep with the acquisition? I mean, this issue is normal and represents very few cases, but currently, if it happens one single time, the acquisition gets stopped!

I tried using the Python mechanism to handle errors:

for i in range(0,10):
    try:
        counts_aux = task_ci_ctr3.read(number_of_samples_per_channel=nidaqmx.constants.READ_ALL_AVAILABLE)
    except:
        print('Ups!')

But although the loop keeps going, the acquisition is de-facto aborted, as the counter is no longing responding.

I could use the "except" to stop and start again, but this is too slow and it is not at all elegant!!!

Any ideas/suggestions?

Thanks in advance.

For the record:
I notice that when I used the simple acquisitions test that can be done using NI-MAX software, the simple counter was not giving any error so I found a way round that uses two counters: ctr1 generate time bins (going to sample clock of ctr0), and the photon counts connected at source of ctr0.

This it is working but monopolises two counters for a task that should need only one and probably leads to lower time resolution (I have not tested yet the limits of this approach) and the counter is getting once in a while two consecutive pulses without rising an error! So I though that what I would like to do it is maybe possible after all...

[Kevin_Price]

The error code suggests that you're seeing 2 photon pulses within 1 interval of your 100 MHz timebase.  Is that right?  I didn't think the front-end of the multifunction boards were spec'ed to receive such high frequencies.

That being said, I can think of a few things to try.  They may not *all* work, but one (or more) probably will.

1. Configure digital filtering for the incoming photon signal PFI pin.

2. Change the setting for the deep-down property "Duplicate Count Prevention."   This rarely comes up anymore since the default settings and behavior got ironed out some years back, but it's possible this might help.  (Not real confident about this one though.)

3. Try doing period measurement on the photon pulses, while also exploring PFI pin filtering and "Duplicate Count Prevention."

4. Invert the measurement.  This is what you already tried with the 2-counter approach at the end of your post.  Count photon pulses, sample with a fixed-rate clock you control.  I'd expect you to be able to support 1 MHz or higher sample rates.  This approach may also require exploring Duplicate Count Prevention.

-Kevin P

[jpedrego]

Dear Kevin_Price,

Thanks for taking the time to reply to one of my questions!

You are right: I have 2 photon pulses within 1 interval of the 100MHz timebase. 

I can live with it and accept that I am missing some counts... the problem is that the hardware does not seem to be able to accept it if it is configured as a "edge counter"...

The Duplicate Count Prevention is could be use if my source is slow (slower than 20MHz) when the timebase is itself a slow one.

I forgot to mention that I had already tried the digital filtering, but it does not help as the incoming signal is itself already clean...

Thanks anyway!

[Kevin_Price]

- 2 pulses within a 10 nanosec interval is faster than the board is spec'ed for external signals.  It could be that my bag of tricks simply isn't sufficient to overcome a true hardware limitation when a >100 MHz signal is presented to the board

- digital filtering on PFI pins isn't about "cleaning up" signals to make them look more square or whatever.  It's about suppressing edges that arrive too soon after the previous one.  It helps suppress glitches, ringing artifacts, and switch bounce.   What happened when you tried it?

- there's an alternate way to try to get something like digital filtering.  You use a counter configured for retriggerable single pulse generation.  (You would then pass the pulse output along to your normal measurement task.)  Once triggered, subsequent triggers are ignored until the entire pulse time has passed.  In effect, this can also filter out high freq inputs.  

- not sure I totally follow what you tried or observed about Duplicate Count Prevention

- maybe your 2-counter solution will end up being your best alternative, where you *count* the photon pulses with one counter and generate a fixed sample clock with the other

-Kevin P