correlated time stamping

[riclambo]

Hello Forum,

                  My previous post went unanswered and so I've stumbled through on my own. My goal was to perform time correlated single photon spectroscopy. I'm using a 6321 X series DAQ card, a Perkin Elmer SPCM and a pulsed laser. I am exciting a sample with a laser and would like to obtain an accurate timestamp of the first photon detected after shutting down the laser. I would then repeat the measurement to build up a histogram from which I can obtain the lifetime of my sample (~1 micosecond).

                 As I understand it, the counter on X series cards can't be retriggered. My solution is to reset the counter with the falling edge of the signal that modulates the laser and then timestamp the first photon after that (attached). At the moment my program is giving me the timestamps of all the photons from the buffer, but I only want the first one. Is there a simple, elegant way to get just get the first element of the buffer on each shutdown without slowing down the  data Acquisition loop?

Thanks in advance,

                              R 

[Kevin_Price]

I'm away from my LabVIEW machine and have only a minute here.   It sounds like you could do this by setting up a "Two Edge Separation" measurement.  You'd configure for the laser falling edge to be the 1st signal and the photodetector to be the 2nd.  You can make it a buffered measurement and each element in the array would be a single measurement for your histogram & other analysis.

-Kevin P

[riclambo]

Hello Kevin, 

                 Thanks so much for your reply which has pointed me in the right direction. I've incorporated the "two edge signal separation measurement" into the SingleTimeStamping_v2.vi in my original post. My basic question is: will the resulting vi (attached) work bearing in my mind 3 things：

1. That the output of my photon counter is a TTL pulse with a width of only 30 ns. This is the rising edge that counter has to detect.

2. That I wish to plot a histogram with bins of width 10 ns i.e the minumum time resolution of my board. This is because the lifetime of my sample is approximately 1 microsecond. I figure then that I should be able to obtain roughly one hundred points for my lifetime measurement.

3. I would like the histogram to update itself during the measurment instead of just being plotted at the end. I'm not sure whether the histogram.vi that I've included in the vi will actually do the job. This may be a naive question, but without the full set of data (maximum and minum) before it starts plotting how will the histogram.vi know how wide each bin should be given a set number of intervals. Perhaps I should be using advanced histogram.

                I've muddled through so far, my challenges aggravated by the fact that I'm a Brazilian working in China on a chinese version of labview. If you could look at the attached vi and provide a little more help, it would be greatly appreciated.

Regards,

             R

[Alexander_Sobolev]

riclambo,

Can you save your VI for LV 2011?

>> pulse width

http://www.tritonimaginginc.com/site/content/hardware/NI6601specs.pdf

These are the specs for a previous generation PCI-6601 counter, it says 5 ns minimum pulse duration for edge detection mode. You are fine.

Regarding histogram

Histogram is a number of measurements in the bin. You can add Y values of the histogram to combine multiple measurements (if X scale is the same).

Simple histogram takes max and min from the array you specify. If these are not the same for different runs, X scale will be different.

For Advanced histogram you can specify max and min, then X scale will always be the same.

Measurement problem that I forsee.

What is your laser period and how stable is it? For correct measurements you should have 1 photon out of 50 - 100 laser shots. Othersise there is high chance of getting multiple photons per laser pulse and your lifetime will be distracted.

If you start counting from laser pulse, photon can be generated 50 laser pulses later, as I know 2 edge separation does not reset if gets the second "starting" pulse. You will need to subtract 50 laser periods from your measurements.

If you start counting from photon till next laser pulse that will always arrive not later than laser period, you can subtract measured value from laser period and get correct time measurement. But your lsaer period should be stable better than 10 ns.

You need to be able to delay one of the triggers (photons preferrably) by ~20 ns to be able to adjust time zero position - to have at least 2 bins of pretime zero measurements. 15 foot coaxial cable will work (delay is 1.5 ns / foot).

[riclambo]

Alexander,

                Thanks for the measurement issues that you raised and which clearly need to be addressed. I will be away from my computer until tomorrow evening so I cannot implement the changes to my program yet. In the meanwhile, though, I have attached a version for LV 2011 (attached) so that you can kindly take a look if you have the time.

To be continued...

                          R 

[Alexander_Sobolev]

a number of comments:

1) 2 event structures in one vi with the same event. Bad... It is better to stop acquisition loop by killing read task after control loop finishes for example.

2) Data read Timeout = -1. Your pulses stop (laser explodes), data never read, VI frozen, need to kill it with task manager that is not good. Much better to ignore timeout error by error code.

3) I would add DAQmx timing vi (Implicit (Counter) mode) to enforce continuous read, buffer size.

4) It is better to use histogram with fixed min, max ranges rather than to accumulate all data in build array. You will stream data to file anyway. Just add new histogram to the old one. With constant time bins I would even use waveform graph, not XY graph that is on histogram.vi output.

5) I believe, if you measure edge separation in time, not in ticks, and rollover, your offset per rollover will be 2**32 * timebase period (10 ns).

[Alexander_Sobolev]

One more thing:

Your read loop timeout is 100 ms. You are processing 1 queue element (250 counts) at a time, so your processing rate can be only 2500 counts/s. Not very much.

I would either make dequeue in front, make it 0 timeout and put event structure into dequeue timeout frame. If there are a lot of events, you will be processing them at top speed, but interface will become less responsive (higher priority for data processing).

Or put data processing into timeout of the event structure (also timeout = 0). Priority of interface events is higher - queue can grow large if interface becomes slow.

Both cases can cause error if you open modal dialog that will stop user interface (select file location for example).

You can avoid it if you separate acquisition and user interface into 2 loops, or avoid long events in user interface (no modal dialogs, no long waiting for other equipment to respond, etc).

[riclambo]

Hello Alexander,

                         I think I've managed to implement most of your suggestions, except for two of them. With regard to the read loop you say that I should  `place dequeue in front, make it 0 timeout and put event structure into dequeue timeout frame`. Alas, my abilities with labview are too limited to make this work and I keep getting errors. Could you please illustrate what you mean on the attached program itself?  

                         The other suggestion that I struggled with concerns the `2 event structures in one vi with the same event`. You did not mention the event, but I assume that it is the 'stop' one. Isn't enough for me just to delete the second stop event structure in the consumer loop.

                          Once I take care of these things the program should work smoothly. 

Thanks in advance,

                             R

[Alexander_Sobolev · Accepted solution]

A little modified vi...

>>  Isn't enough for me just to delete the second stop event structure in the consumer loop.

It is better to make producer loop only producer. consumer is also control loop that should handle usr controls.

[Alexander_Sobolev]

one more note...

I do not think you need rollovers. It starts counting timebase ticks when laser pulse arrives and stops counting with photon. Then takes number of ticks and multiplies by 10 ns. For the next measurement it resets counter and  starts counting from zero. It will rollover if photon is more than 10 ns * 2^32 away from the pulse. It is 40 seconds. I doubt you have that time window.