Photon Counting, Time Stamping, and basic help with how DAQmx works

[tdowd18]

I appriciate the responses... we were on our way to steal my boss's computer (upgrading) when Ryan's message came in! Not upgrading will save us some frustration, and he'll still have a desktop

We're trying to do fluorescence correlation spectroscopy, and one of the modes of generating an autocorrelation function works directly on photon times of arrival. So I think we'd prefer not to bin the data, although I guess that we could

I was thinking that maybe instead of generating the times of arrival I could do buffered period counting, and instead of using longs to use either an unsigned char or an unsigned short? I thought that this might decrease the strain on the FIFO buffer, and it wouldn't be a hard task to convert such an array to TOA data using a separate sub VI.



Tim

[Kevin_Price]

Re: unsigned char / short.  You really don't have any options to change the datatype as a means for helping with the FIFO issue.  How long of a total measurement time do you need to support?   What is the typical firing rate over that time?  Is it >1 MHz throughout, or would there only be a short burst at such a high rate?  How much post-processing is acceptable vs. having information available on-the-fly?

If you need to establish TOA for individual pulses at >1MHz for some seconds, I wouldn't count on getting there with a 6602.  A high-speed digital board like the 6534 would probably do the job, but you'd need to do a bunch of post-processing to find the pulses after the fact.  An alternative *might* be a high-speed digital board from Viewpoint Systems (an NI Alliance partner) which can be setup for change detection while also timestamping the changes.   I think you could ask it to detect only rising edge changes, then every entry's timestamp becomes your TOA.  I don't know details about its on-board FIFO or equivalent though.

Note that with either type of high-speed digital board, you could probably scale up to accept multiple photon sources.

-Kevin P.

[tdowd18]

Hello

Sorry for the lateness of this reply; I had some other things to work on and I backburnered this

Postprocessing is absolutely fine, this is what we do plan on doing. We'd like to be able to run the program for at least 30 minutes, but we don't expect it to be greater than 1Mhz for most of the time. We think that there's just occasional small bursts that are filling up the FIFO. The evidence that we have for this is that the amount of time the program will run is quite variable.... anywhere from a few seconds to a few minutes. We think that corresponds to some sort of light scattering event or something that is over very quickly, but happens rapidly enough to cause problems

A lot of what we need to work on I think is fixing our experimental setup. At one point though, someone had mentioned digital filtering? We were thinking of using the pulse generator vi example to turn the data collection off for a few hundred nanoseconds after one pulse was collected... so the first pulse it gets a pulse generator vi sends one to the vi but ignores ones during the delay.

Thanks

Tim

[Kevin_Price]

Tim,

Digital filtering can help to reduce the rate during those extremely high frequency bursts.  Of course it'll also mean entirely ignoring some of the pulses, so your photon count and rate would become artificially low.  Is this really acceptable?

The 6602 supports digital filtering on the PFI pins.  I haven't needed it yet in the DAQmx era, and seem to recall reading something suggesting that the behavior might have changed a bit.  I wasn't a big fan of the implementation circa traditional DAQ 6.9.x -- applying a filter seemed to quantize the pulse freqs rather than just slightly delay them.

The other way you might accomplish filtering is what you hinted at -- configure one of the 6602's counters for retriggerable pulse generation.  I'd set the delay (probably "low time") to be as small as possible so you cause minimal change to TOA.  The pulse duration ("high time") can then be chosen to produce a desired cutoff frequency.  You feed the real pulses in as the trigger, the counter generates its pulse which is passed on to the measurement counter, and while the pulse is in progress additional real pulses get ignored.

Another note is that you'll need to watch for counter rollover during a 30 minute measurement.  The 80 MHz timebase will cause the count to keep wrapping around 0 every 50-something seconds.  Now here's a really nifty new DAQmx feature to help!  You can query the measurement counter for a property with a name like "TC reached?" where TC means 'terminal count'.  This property gets set to True whenever the counter gets to the maximum u32 value and wraps back around to 0.  The really good thing in DAQmx is that once you've queried and received a True value, the property automatically resets itself back to False.  Then you can detect the next one, and so on.  Under trad. NI-DAQ, it didn't reset itself.

-Kevin P.

[Nepthar]

I'm a student at the University of Rochester and I'm working for one of the labs here over the summer.  I've been reading this thread and trying to use the VIs that people have posted here.  I've more or less gotten them to work... but I'm still far from being able to do what I want.  Just a little background - I've got a 6602 hooked up to an avalanch photodiode and I'm using it for single photon detection.  In the past, the group here has used binning to collect this kind of data, but presently they want each photon time-tagged.  The good news is, any amount of post-processing is fine.  A text file filled with time-tagged photons would be acceptable...  I can sometimes get file I/O to work.  My experience with labview is limited to these past two weeks.  While I understand most of the theory behind what we're doing, my lab experience is zero.  What I'm really having trouble understanding is why the single photon counter VI asks for both which counter is counter1 and then the source of photons.  If I set them the same, it errors.  Also, some other strange things happens, which I will post about tomorrow when I return to the lab.  Thanks for any help.  Also, if anyone knows of any sources of labview information/tutorials other than the ones included with the program, that would be very helpful.

Thanks

Jordan Parker

[Kevin_Price]

Jordan,

Could you post some of the data acq code when you repost more details?  There's a good chance someone could zero right in on your problem(s)...

-Kevin P.

[Nepthar]

Kevin -

I am using a VI from this thread called SingleTimeStamping_v4.vi from Chris's post on page 1 (http://forums.ni.com/attachments/ni/40/2323/1/TimeStamping.zip).  I have not changed anything except the inputs.  Attached to this post is a screen cap of the VI, as I have it configured.  Physically, I have photon pulses (either from an avalanch photodiode or simulated from a signal generator or the photon simulation VI that was also posted somewher in this thread.) connected to counter 1 source.  As of now, I'm not using a gate... I'm just trying to get the VI to read something.  Ultimately, the goal is to timestamp each photon (I believe I'm repeating myself from the first post).  Anyway, there are a few things that leave me a bit confused.

  First, as you can see from the screen cap, the VI asks for counter channel, source of timebase, source of photons, and trigger source (plus a few other things, but those are fairly self-explainitory... also, this screencap was taken while I was using the photon generator VI on counter 2)  What confuses me is the fact that it asks for both a counter number and a source of photons.  In my mind, it would make sense to only require only a counter number as an input.  From that, it would use that counter's source and gate.  Also, I get an error when I set the counter channel to the same number as the photon source (ie, counter channel: /dev1/ctr1 and source: /dev1/ctr1source).   The error number is -89136 at DAQmx Start -- "Specified rout cannot be satisfied because hardware does not support it" and then it lists: "Property: SampleClk.Src, Property: SampleClk.ActiveEdge, Source Device: Dev1, Source Terminal: ctr1Source"

The second thing I do not understand is the output.  When I run the VI, no matter what signal is inputted, what any of the inputs are set to... basically no matter what I do to it, it outputs what you see on the graph in the screen cap.  Each time I run it, it makes one short upward sloping line.  Each line you see is a result of me running the VI.  Also, this line appears after I hit stop, not while it's running.

As I mentioned earlier, the photon source, counter channel, and trigger have me a bit confused as well.  What should I specify for each?  For the sake of explaination, say I've got the input from the photodiode attached to counter 1 source and the gate attached to counter 1 gate.  Also, I'm fairly certain my physical wiring is correct because I can sucessfully test it using the test pannel.

If any other info would be helpful, let me know and I'll post it ASAP.

Thank you

-Jordan

Message Edited by Nepthar on 06-13-2006 12:41 PM

[Kevin_Price]

What confuses me is the fact that it asks for both a counter number and a source of photons.  In my mind, it would make sense to only require only a counter number as an input.  From that, it would use that counter's source and gate

It certainly could be done that way, but you'd need to pull out a screwdriver and change the wiring each time you chose a different counter number.  As it stands now, you could use any counter you wanted without changing the wiring.  This type of flexibility can be a big advantage in many circumstances, even if there's not a specific need for it in your particular case.

Ultimately, the goal is to timestamp each photon

Then the internal 80 MHz timebase should continue to act as the counter Source signal and the photon pulses should act as the counter Gate (aka "Sampling Clock") signal.  In this mode, the counter continuously increments at 80 million counts/sec while each photon pulse buffers up an instantaneous count value.  When you read that buffer, you'll get an array of photon timestamps.  The triggering was there to support the original poster's need to synchronize multiple counters measuring multiple photodiodes.  You may not need it at all.

If you're simulating photon pulses by generating a pulsetrain with Ctr2, then the timestamping vi should specify a DIFFERENT counter for the timestamping task (Ctr1 is fine), and specify Ctr2InternalOutput as the source of photon pulses.

The attached file is missing some stuff that you'd probably need.  One key thing is that the buffered data is written to a queue but never read back out or displayed anywhere.

-Kevin P.

[Nepthar]

Ah, okay, the counter thing makes sense now.... and that solves the mystery of the trigger.  Many thanks for your help.  You mentioned an attachment... are you speaking of another post or should there have been an attachment with your post?  Unfortunately, this happens to me all the time when I send e-mails... including some where I've said I attached my resume.

Thanks again for your help.  This project has taught me a lot about how to use labview.

[Kevin_Price]

... "attached file" merely referred to "TimeStamping.zip" from your prior post

-Kevin P.