Time stamping with NI 6210

[schokki]

Dear All,

I want to use the two counters of a NI USB 6210  and Labview v8.6 to count pulses from two photodetectors. The photon pulse rate in each channel is varying between 100-100000cps. The final goal is to measure coincidences between the channels, i.e. two pulses arriving within a defined time window. 

The approach shall be time stamping of the photodetector pulses to a hardware clock, i.e. the 80MHz onboard clock of the NI 6210, and subsequent analyses. The time resolution with that each pulse is time stamped has to be high, i.e. 20ns.

I found this example in the forum: http://forums.ni.com/attachments/ni/40/2323/1/TimeStamping.zip, which seems to be a good starting point.

Unfortunately I do not manage to get it running. Error -200141 occurs stating that 'Measurements: Data was overwritten before it could be read by the system'. Using DMA is suggested but I do not know how to do.

My question is whether it is principally possible to use the USB 6210 for timestamping with this stamping resolution and expected photon pulse rates or do I try something stupid?

Of course  any example vi or any other hint is highly appreciated.

Rolf

[John_P1]

Hi Rolf,

-200141 means that data has been overwritten in the on-board FIFO of the 6210 (the FIFO is 1023 samples per counter).  While you are acquiring, data is transferred automatically over through USB Bulk Transfers from the on-board FIFO to PC memory (DMA is only available on PCI/PCIe busses).  If the transfers cannot keep up with the data coming in, this is the error you would receive.

The 6210 hass been benchmarked at over1 MHz on a single counter so I don't think the 100 kHz pulses should be a problem.  From the information you have provided so far, I can think of two possible reasons that might explain what you are seeing:

1.   You might be picking up duplicate edges when counting photon pulses.  The way to correct for this is to enable the Digital filtering on the 6210 by expanding the DAQmx Channel Property Node as follows:

2.  Could you verify you are using a USB 2.0 port?  The transfer rates are going to be highly system dependant but using USB 1.x is almost guaranteed to result in problems at the rates you want.  If you are cabled through a hub I wouldsuggest trying to connect directly to the PC.

From experience, it sounds like the digital filtering should fix the issue and the noisy edges are the most likely culprit.  Let me know how it goes!

The 80 MHz timebase will give you a time resolution of 12.5 ns so it sounds like you are on the right track once we get past this issue.

Best Regards,

John

[schokki]

Hi John,

Thanks for your help. The vi works now without actually changing something. However I followed your hints with following results:

1. Digital filtering:  This did not work. I received an error message that this is not supported by the device. However it might be useful to implement it later on. Since the original pulses come directly from the photodetectors and have some jitter. The pulses are actually only 15-20ns long.  I checked that the NI 6210 detects them correctly.

2. I use USB 2. With one channel the memory overflows at a constant photon pulse rate of about 150kHz.

Now I want to use two counters/photodetectors (the two channels between the coincidences shall occur). For the tests I use one or two frequency generators providing TTL pulses with a constant frequency which are fed into the two channels. The attached vi works until about 25kHz before overflow. The trigger is used to start sampling of both counters at the time and provide at the start a constant time difference, i.e. 0s between the channels. Since I lack another source both counters are triggered to the source of counter0.

I encounter following problems:

1. Very often the vi stalls after the first loop but not always. But when it has passed once the first loop it runs fine if the same frequency is fed into both channels.

2. If one of the counter is unplugged from the frequency generator or  the pulse rate of one generator is reduced to low values (<2kHz) both counters stop immediately counting.

I assume that this is due how the vi is setup: It samples the 80MHz signal to the photon pulse signals. If one's frequency is too small, the channel is not sampled very often and teh fifo memory overflows. However if this is true I do not understand why there is an overflow at high pulse rates. This should improve the sampling and assure better memory transfer.

Question: Do I understand the setup correctly? And, how the vi can be changed so that it is running also at low frequencies at the counter sources respectively by rates which differ by a couple of  kHz bewteen teh channels?

Rolf

[John_P1]

Hi Rolf,

1.  Sorry about that, the Digital Filtering restriction is a limitation the DAQmx Driver, it looks like you can't configure this on a Count Edges task of a 6210.  We can work around this if we needed to, but what it sounds like you want to do is perform a Two-Edge Separation measurement.

Take a look at the following code to see if this is what you need (As an added bonus, DAQmx will allow you to configure the filters in this setup):

 

DAQmx Read is a blocking call, so if the requested amount of samples to read have not yet been acquired it will wait until 1) enough data is available or 2) the timeout has been reached.  This would explain why disconnecting one of the counters will result in the program stalling (if the sample clock is disconnected then no samples will be coming in so the DAQmx Read will always timeout).

The FIFO memory is going to overflow at high sample rates.  The sample clock is what latches in the value from the count register into the on-board memory.  At low rates the USB transfers can keep up, but at higher rates you get the overflow problem.  At very low rates, the loop is going to wait until enough samples have been read--if this takes longer than the timeout allows then you will break out of the loop with a timeout error.

Best Regards,

John

[John_P1]

*Edit:

I just noticed you mentioned your pulse widths are only 15-20 ns.  This is pushing the limits of the front-end bandwidth of the PFI lines--they can take in up to a 20 MHz signal as an input which would be 25 ns pulses at a 50% duty cycle.  The digital filter can't be used with such short pulses, the minimum filter setting is 125 ns.

Nonetheless, it would be worth trying the two-edge separation method.

If this doesn't work I'll have to think a bit on if/how we can work around the issue.  I am still under the assumption that you are picking up duplicate edges--the input signal isn't going to be too clean with such short pulses coming through our front-end.

Best Regards,

John