From 04:00 PM CDT – 08:00 PM CDT (09:00 PM UTC – 01:00 AM UTC) Tuesday, April 16, ni.com will undergo system upgrades that may result in temporary service interruption.

We appreciate your patience as we improve our online experience.

Counter/Timer

cancel
Showing results for 
Search instead for 
Did you mean: 

Time stamping photon arrival times

Solved!
Go to solution

I would like to do a two-photon cross correlation measurement.  Hardware auto correlators and cross correlators are available but expensive.  It seems many other users have come up with the idea of using the 80 or 100 MHz clocks into the counter input for each desired channel, starting the counters simultaneously, and putting each photon channel into the gate of the corresponding counter.  Then each photon triggers the counter to store the clock count in its internal register, i.e., the time stamp for that photon. Since overflows on a 32 bit counter running at 100 MHz only occur every 42 seconds, and average photon rates will be at least 100 Hz, overflows should be easily recognized and corrected in post processing.  So let's assume all we have to do is get the counter readings into a memory buffer.  There can be bursts of photons with arrival separations as small as few clock cycles.  Average rates might be a few hundred kHz or more on each channel.  We can adjust this rate by turning the laser power up or down---the source for the scatterer that produces the correlated photon stream.  I suspect many others would like to know what system is better for these kinds of measurements, the 6602 or the X-Series.  If FPGA is a good solution, we should maybe start a new thread on that.  But for 6602 or X-Series: What is the fastest they can do this for short bursts (how fast for how long) and what is the sustainable rate?  I realize the sustained rate will depend on hardware.  I thought I saw that the PXI beats the PCI bus in this kind of application.  So are the PXI versions any better?  In particular, what are the effects of the 128 sample FIFO on the X-Series versus the 2 sample buffer on 6602.  And I saw something about the speed of the front end for these two choices might be an issue in this regard.  TTL (photon) pulses on the gate will have 10-50 nsec widths.

0 Kudos
Message 1 of 18
(10,274 Views)
Solution
Accepted by topic author deserio@florida

For throughput X Series is going to be much faster than the 6602 mostly due to the onboard FIFO (but PCIe does give higher throughput than PCI as well).  PCI vs. PXI should have identical throughput (and PCIe vs PXIe would also have identical throughput).

 

Forum user (and NI employee) Andrew S has posted some X Series streaming benchmarks here.  On a single counter he was able to sustain ~20 MHz sample rate on PCIe X Series and ~8 MHz on USB X Series.  The 6602 benchmarks are much lower, somewhere between 200 and 300 kHz (although the system used for the benchmarks is quite old).

 

The 6602 does allow for shorter pulses than X Series.  The specifications page states a minimum pulse width of 6.25 ns for the 6602.  I didn't see a number directly specified for the X Series actually.  X Series devices do specify a maximum external base clock frequency of 25 MHz, which assuming 50% duty cycle would be 20 ns high and low times.  50 nsec would certainly be long enough of a pulse, but 10 ns *might* be pushing it.  You'll probably have to do some testing to confirm whether or not the X Series is able to detect all of the pulses for your setup--if it does then I'd suggest X Series (PCIe-6320 is the lowest cost one) over the 6602.

 

 

Best Regards,

John Passiak
Message 2 of 18
(10,249 Views)

John,

 

Thanks for the reply and the other references in it.  Very helpful.  I have a USB X-Series

and a PCI 6601 device I can test with a pulse generator.  That should help give me an answer

on what will happen during photon bursts--when several pulses may arrive in a short span.

I suspect the dreaded data overrun error will occur on the 6601, but hopefully not on the

X-Series.


Regards,

Bob

0 Kudos
Message 3 of 18
(10,229 Views)

When I do period measurements (low frequency with one counter---signal on the gate and the counter counting 100 MHz clock), I get the time between edges of the gate.  Is there a way to prevent the counter from resetting to zero on each gate so that I get the running time rather than the time difference?  I realize that I can create it by summing previous intervals, but I thought there was a simple switch to prevent the counter from resetting to zero on each gate trigger.  I am using a USB 6341.

 

Also, how do I start two counters (both counting the 100 MHz clock) simultaneously?  Is it the arm.start function applicable for this?  I hope I can use one or two digital output lines that I set low  before issuing the start command for each counter task (so that they are still disabled and not counting) and then set the digital line(s) high to start both counters counting at the exact same time. 

0 Kudos
Message 4 of 18
(10,184 Views)

To prevent the counter from resetting to 0, I would configure a "Count Edges" task instead.  Use the external photon signal as your sample clock and the timebase as the input terminal for the edge count task.  Keep in mind that the 32-bit counter will roll over in about 43 seconds if counting the 100 MHz timebase.

 

Configuring an arm start trigger is indeed how you would synchronize the starting of your counters.  Configure each task to use the same PFI line for the arm start trigger.  Start both tasks in software before issuing the trigger.

 

 

Best Regards,

John Passiak
0 Kudos
Message 5 of 18
(10,179 Views)

Hi John,

 

I would dearly love to see an example of this.  Counters 1 and 2, starting counting simultaneously from a common onboard clock, say 20MHz, always reading up, i.e., not rezeroing, and with readings on each counter triggered from the gate of each counter. 

0 Kudos
Message 6 of 18
(10,172 Views)

Sure (it's Friday afterall):

 

CtrSyncExample.png

 

The while loops aren't filled in--you'll need to figure out how to go about reading the data as it is being acquired, or just wait until the experiment is over and read -1 samples to get back everything at once (if you can fit all of your data into memory).  The U32 array will be in "counts", so multiply by 10 ns (or the inverse of whatever timebase you choose) to get times.

 

 

Best Regards,

John Passiak
Message 7 of 18
(10,168 Views)

John,

 

I love you man.  That worked perfectly.  I think there may be several others who find this example very useful.  Knew it should be doable, but it would have taken me forever to figure it out.

 

Bob

0 Kudos
Message 8 of 18
(10,162 Views)

So now I want to do this on all four counters.  So I can't use one of them to synchronize the start.  Is there a digital out event I can use to synchronize the starts of all four counters?

0 Kudos
Message 9 of 18
(7,558 Views)
Solution
Accepted by topic author deserio@florida

 

You can use a PFI input as the arm start trigger and toggle it with a digital output task.  Typically on an X-series device, port 1 line 0 will correspond to PFI0.  The digital task can set the state while the counter tasks use the transition edge as a trigger.

 

Starting from the previously posted screencap snippet, here's the part to be changed.  The digital task is started first and the output is set low.  The error cluster output is used for sequencing, making sure that the digital output is low before the counter tasks are armed.  After starting the counter tasks, simply toggle the digital line to create the triggering edge.  This method lets you sync up 4 counter tasks from the same trigger, and create the needed trigger signal without any physical wiring.

 

-Kevin P

 

 

shared arm start trigger.png

CAUTION! New LabVIEW adopters -- it's too late for me, but you *can* save yourself. The new subscription policy for LabVIEW puts NI's hand in your wallet for the rest of your working life. Are you sure you're *that* dedicated to LabVIEW? (Summary of my reasons in this post, part of a voluminous thread of mostly complaints starting here).
Message 10 of 18
(7,164 Views)