NI-6602 acquistion delay and buffer overflow

[jl694]

Hi everyone,

I am using a NI PCI-6602 to record photon arrival times. Basically, it counts the number of rising edges on the 80MHz sample clock that occur between two rising
edges on the photon TTL signal. The array of integers can be converted to times by multiplying by 12.5ns. Please find my VI for the task and its subVI attached.

I have two problems:
1) I want to do this same measurement for two photon detector channels. I have set up two independent channels. My aim is to correlate the signals with a delay between them. I am able to implement a delay in the software, but from my data there appears to be a small inherent delay between the start of each channel.
The amount of delay is seemingly random and occurs in both the positive and negative direction. In the VI I have attached, I tried using the Arm Start Trigger in order to get both channels to start acquisition at the same time, but while this reduced the severity of the delay, it has not removed it completely. There is still a delay of between 1 and 500 microseconds. Have I implemented the Arm Start Trigger correctly, or is there another way to go about solving this?

2) I regularly receive an error stating that "data was overwritten before it could be read by the system". The number of samples that has been collected before this error varies wildly and also varies between the counters on the board. I had a theory that the sample transfer rate was not good enough, but according to the manual, the transfer rate should be about 2000kS/s. This is more than enough considering that the photon count rate is less than 50k/s. The PC I'm using has a PCI graphics card too. Is it possible that this is limiting the sampling rate? Here are the PC specs: Intel Pentium D processor (3.0GHz), 2GB RAM, nVidia GeForce 7300 LE graphics card.

Thanks in advance.

[John_P1]

1)  Try starting the starting ctr0 (the one generating the arm start signal) after you start the other two tasks (the counters can't be armed until they are started in software first).  You might need to add a wait until task is done to ensure the pulse is generated before you stop the task.  As it is right now, you're starting the trigger signal first--the 100 ms delay is allowing the trigger to still start your input tasks (although this implicit timing relationship is not guaranteed).  It would be better to explicitly issue the trigger signal after starting the other counter tasks so there's no question about what happens first.

That being said, what you have now shouldn't lead to a 1-500 us delay between the two counters.  How are you measuring the delay?

2)  It sounds like you're talking about error -200141.  You might want to try adding a digital filter as suggested here--perhaps the rising edge isn't completely smooth and is occasionally being detected as multiple edges.  Available settings (from the manual) are {5 us, 1 us, 500 ns, 100 ns}--pick the largest setting that guarantees that your legitimate photon counts are detected (e.g. if the photon TTL signal is 4 us wide, I'd start with the 1 us setting).

Best Regards,

[jl694]

Thanks for your reply John.

I have tried what you suggested in 1), but there is still some delay. My VI is attached.

My experiment is to measure correlations between photons in two channels with a delay between them, which I have introduced in the software. I should be getting a smooth peak with the maximum at zero ( when there is no software-induced delay). However, this peak is randomly shifted from measurement to measurement. I have inferred from this that there is an inherent delay between the channels before the software produces the delay. The photons are detected by a photomultiplier and the signal is amplified with a fast timing discriminator. This is the TTL pulse that arrives at the counting board. I'm reluctant to believe that the delay is due to the apparatus. Do you think this is a possibility?

In response to your second suggestion, I measured the pulse width of the photon signal to be about 17ns. As I understand from the manual, a pulse is blocked if it is narrower than the specification. Does this mean that even the 100ns filter setting is not good enough? Would it be useful to use the internal 80MHz timebase for the filter?

[John_P1]

The attachment didn't come through.  To test out the delay I would just wire an identical signal into each input of the counter and make sure you get identical timestamps.  I'm not clear on the software delay you are introducing--how is this implemented?  It sounds kind of suspicious.

If the pulses are that short then you won't be able to use the built-in digital filter (660x have a pretty limited digital filter compared to some newer DAQ product lines).

If the period of the filter clock timebase is tfltrclk, this filter guarantees to pass pulse widths that are 2*tfltrclk or longer and to block pulse widths that are tfltrclk or shorter.

Even if you could use the 80 MHz as the filter clock (I don't think you can, but didn't find this in the documentation), this would still only pass 25 ns pulses.

When you say that the photon rate is 50kHz, do you mean that at no point in time would you get two photons within 20 us (1/50 kHz) of each other?  The limitation is not sustained throughput but rather that two consecutive samples in rapid succession will overwrite the onboard register before the sample can be transferred out.  For this reason, I'd usually recommend an X Series device for this type of application (see here).

Having said that, you could use a extra counter per channel and implement your own sort of digital filter.  Configure a retriggerable counter output (single pulse) with a 20 us high time (or whatever time interval that you want to ignore additional triggers).  Have this signal trigger from your photon.  If multiple triggers are registered during the generaiton of the pulse they would be ignored.  Use this 20 us output signal as the sample clock for your counter input task rather than the photon signal directly.

Best Regards,

[jl694]

Sorry about that. You should get the attachment now.

The software delay I'm referring to is basically adding a constant (the delay time) to each timestamp on one channel only. The delayed and undelayed channels are then compared.

There is a (small) probability to get two photons within 20 us of each other. Am I correct in thinking that lowering the photon count rate will alleviate the problem?

[John_P1]

Hi jl694,

It seems like the counters should be synchronized--what does the raw data from the counter tasks (without the correlation algorithm applied) look like if you use the same signal as the sample clock?

As for the overwriting of samples--it seems to me the problem could either be photons too close together, or that a single photon is being registered as multiple edges do to noise on the input line.  In this second case, lowering the frequency of photons wouldn't likely make a difference (but in the first case I guess it might).

Are you using all of the counters on your 6602 (there are 8)?  The arm start trigger could come from a static digital output task so you could save a counter there.  Anyway, if you filter the external photon signal using a counter output task like I mentioned previously this should fix the overflow issue.  

You would need one additional counter for each photon input channel (2 counters total for each photon channel).  Each counter output would generate a single pulse triggered from the external photon signal (but if multiple edges are issued while the pulse is being generated they would be ignored, which is what you want), and you would use this generated pulse as the sample clock for your input task.  The counters are grouped in fours on the 6602, so you should only pair counters 0:3 with 0:3, and 4:7 with 4:7 (if that makes sense).

Best Regards,

[jl694]

Hi John,

In my current setup it's a bit awkward to change around the counters for the filtering. It sounds like it would work though. I can live with the buffer overflow problem for the moment by reducing the photon count rate, but I'll keep your idea in mind for the future.

At the moment I am more concerned about the delay. I checked the same signal like you suggested. The delay had disappeared. This led me to an idea about the cause. Since the buffered measurement is counting the edges of the 80MHz timebase between rising edges on the photon signal, the counting only starts on the rising edge of the photon pulse in that particular channel. However, there won't be a photon arrival at exactly the same time for both channels, so although the counters are synchronised, the actual timing measurements are not. Do you know a way that I can start the counting measurement at the same absolute time on both channels? Is there a way to produce an artificial rising edge on both photon channels in order to start the edge counting tasks simultaneously?

Kind regards,

James

[John_P1 · Accepted solution]

Hi James,

I think you might be interchanging the terms "counting" and "sampling".

The counting starts with the arm start trigger, which should be the same time for both channels (with maybe a 1 tick offset, which would be 12.5 ns on the 6602).  Counting refers to incrementing the hardware count register on every tick of the input terminal (80 MHz timebase in your case).

The sampling of the count register will occur at different times on each channel depending on when the photons are detected.  So the timing measurements on each channel will be different, but if a photon were to occur on each channel at the exact same time you would get an identical timestamp on each channel for that one sample.  Sampling refers to latching the value of the count register into a buffer that you can read back later in software.

This image (from the M Series user manual actually, but the 6602 should work the same way) shows your use-case:

The time that the counter is armed is identical between channels, so each counter's value at any given time would be equal.  The sample clock times are not identical on each channel, so the values latched into the buffer would not be the same.

Using the identical external signal to sample the count registers simultaneously demonstrates that the arm start trigger is working (that is, if you give the counters the same sample clock, you get identical results).  If the arm start was not working, you would see different results on each counter even with an identical sample clock (the sample clock does not arm the counter).  Taking out the arm start trigger would confirm this--arming the tasks in software (which is what happens with no arm start trigger configured) will give an unpredictable delay between when each task is started--you'd see a difference between channels even with a shared sample clock.

It sounds like the issue is that you might have expected photons to occur on the two separate channels at closer to the same time?  You could try scoping the photon detector outputs to confirm whether or not there is a delay present.  It sounds like there is--but isn't this what you're trying to measure?  Are you expecting photons to be detected by each channel at exactly the same time?

Best Regards,

[jl694]

Hi John,

Thanks to all your clear explanations of the way that the Arm Start trigger works, I discovered that the problem laid in a section of my code which was meant to correct for counter rollover. I had forgotten to assign an initial value for a shift register which meant that the first value in the array of raw data was huge (somewhere around 2^31). I didn't think much of this at first because I had heard that the first value in buffered measurements was not reliable. Once I initialised the shift register, the delay shift problem disappeared entirely. 

Thanks again for all your advice. I understand the way data acquisition works much better now 🙂

Kind regards,

James