Counting TTL pulses within specified integration time

[joyce]

Dear all,

I have a PCI-6014 board, and I use Labview 7.1 and would like to do the following task with DAQmx7.4:

Analog source:  analog square wave (or = 1Hz TTL pulses) produced by a function generator

Signal: photon signals from a photomultiplier (random TTL pulses)

I would like to count the photon signals at 100ms integration time, repetitively. But I don't want cumulative counts, just the number of photons (TTL pulses)  in every 100ms.  I would also like to make sure that I synchronize the counter with the analog source, i.e. to make sure I get exactly 10 data points in each analog cycle. ( I can't use the computer to start the function generator and it just keeps running., so I want to make sure I start counting on the starting edge of the analog wave.)

I used to do this with the traditional DAQ and connected the analog source to the "GATE" pin of the counter , so i could count "while gate is high" ( or while gate low, or count on rising edge/ falling edge. ) However I found some problems and I think my counter wasn't counting correctly, and I would like to rewrite the task  with DAQmx anyway.  Ideally I would like to separate the signals that occur in the first 1/2 and the second 1/2 of each analog cycle. But if that is not quite achievable, I can do the separation later when I process the data, provided that I know each 10 data points from the counter correspond to each analog cycle.

I have read several threads on the discussion board, but I still couldn't configure my applications using those examples.

Also I wonder if the "Arm Start Trigger" function is not available on my PCI-6014 card ? Because I can not find it in the Start Trigger property node.

Thank you very much for your reply. Any hint or advice would be greatly appreciated.

Joyce

[Kevin_Price]

Only time for a few quick thoughts...

I would also like to make sure that I synchronize the counter with the analog source, i.e. to make sure I get exactly 10 data points in each analog cycle.

This goal will be rather difficult to achieve as stated.  You're looking to perform a frequency multiplication, but you're at the mercy of the available timing resolution.  Also, you're two independent timing sources may drift slightly over time.

Ideally I would like to separate the signals that occur in the first 1/2 and the second 1/2 of each analog cycle

Difficult for same reasons unless you can try alternate approach described further on...

I would like to count the photon signals at 100ms integration time, repetitively. But I don't want cumulative counts, just the number of photons (TTL pulses)  in every 100ms

This would be done with a buffered period measurement.  You would use a 100 msec (10 Hz) clock as the Sample Clock (aka the "Gate input") and the photomultiplier pulses as the Source signal which increments the count.

I used to do this with the traditional DAQ and connected the analog source to the "GATE" pin of the counter , so i could count "while gate is high" ...  However I found some problems and I think my counter wasn't counting correctly

Yeah, I can imagine there would be trouble there.  That method wouldn't let you create a hw-timed buffer of values, so you'd be counting on sync'ing your sw calls with times when the counting was paused.  A difficult prospect at best.

Also I wonder if the "Arm Start Trigger" function is not available on my PCI-6014 card ? Because I can not find it in the Start Trigger property node

I can't say for sure b/c I don't have similar hw to test, but I kinda think that isn't supported for E-series boards.

Response is continued in next post due to 5000-char limit...

-Kevin P.

[Kevin_Price]

...(Continued from prev post due to 500-char limit)

Now, here's a proposal for a method that should be able to work, though it'll require more data and more processing.  One key area to watch out for under DAQmx is the property node for "Duplicate Count Prevention."  The behavior changed between 7.1 and 7.3 (on E and/or M series, but not on TIO-based counters), then the defaults changed in 7.4, and something changed yet again in 7.5

Bottom line: you can set it to True or False.  One setting will allow you to buffer up 0 values for intervals where there are no Source signals (photon events) within a sampling period (10 Hz hw clock).  The other setting will not record anything in the buffer for those intervals.  Clearly, you need the former setting, so you can always experiment to see how it behaves.  I kinda gave up on trying to interpret it, understand it, or keep up with the differences by DAQmx version and DAQ board.

Ok, here goes:  I'm going to propose that you actually oversample by about 10x and that you capture the Analog square wave in sync with your photon counts.  Then your post-processing can determine for sure which samples correspond to Analog Square High and which to Low.  You'll also be able to adjust for times when you get 1 too many or one too few samples in a square wave cycle, due to having independent un-sync'ed timebases.

So on one counter you generate a 100 Hz clock.  The other one is programmed for buffered period measurement using the 100 Hz clock as a SampleClock and the photon pulses as the Source signal (this must be set up using a DAQmx Channel property node I believe).  Remeber to be careful also about the DuplicateCountPrevention property.

You would further setup an AI task using the same 100 Hz clock as a Sample clock.  Be sure that the 100 Hz clock task is started after starting both the other tasks.  Also, be sure to always read the same # of samples from both tasks to keep the counter period and AI data in sync.

Voila!  You now generate a data record of # of photon pulses for each 10 msec interval along with the voltage of the analog square wave at the end of that interval.  A bit of post-processing and you're covered.  If you're not required to manipulate data while the acq tasks are running, you can surely afford to bump up the oversampling rate considerably.  The main advantage is to gain resolution on the time of transition of the analog square wave.  For any interval ending with a TTL state change, you won't know where within that interval the transition occurred.

-Kevin P.

[joyce]

Hi Kevin,

Thank you very much for your suggestion.

I've been trying to create this task accordingly, but the error messages always tells me that :

-----------------------------------------------------------------------------------------

Error -89136 occurred at DAQmx Start Task.vi

Possible reason(s):

Specified route cannot be satisfied, because the hardware does not support it.

Property: CI.CtrTimebaseSrc
Property: CI.CtrTimebaseActiveEdge
Source Device: Dev1
Source Terminal: Ctr1InternalOutput

Task Name: _unnamedTask<5>

--------------------------------------------------------------------------------------------

I wonder if my device (PCI-6014) does not support this , or that i am missing some key points in this task?

I have tried different chanel property node settings, and I've played with the source input for the timing property but none worked.

Could you please give me some more advices?

Thank you very much.

Attached is the current scheme:

Joyce

[Kevin_Price]

Joyce,

Despite the appropriate-sounding name, I don't think CI.CtrTimebaseSource is the correct property to work with.  I think you need to use CTR1 as the SampClk.Src under a DAQmx Timing property node.  Then you further need to define where the photon pulses are coming in using the DAQmx Channel property node for CI.Period.Term

I'm attaching a code snippet pic.  I think this should work, but I couldn't verify it because an executable was using the hw when I whipped it up.   Good luck!

-Kevin P.

[joyce]

Hi Kevin,

I've changed the property nodes but I still get the error message saying that the Ctr1InternalOut is being used. If I start counting photon pulses first, then it says that Ctr1InternalOutput is  being used by Ctr0Gate;  if AI is started first, then the error message says that Ctr1InternalOutput is used by AI/sample clock.

Could it be that the InternalOutput of Ctr1 can only be used as sample clock source  at one place? I've read somewhere else on the website saying that once the AI Sample Clock is set, the whole board uses the same clock ? But when I tried to set the DAQmxTiming property->SampClk.Src to "Ai/ SampleClock", it wouldn't work either.

If it is true that I can't share the sample clock for AI and CI from another CtrOutput, perhaps I should try to Trigger one of them with the other? Or I am still not configuring it correctly ?

Thank you very much for your help.

Joyce

[Kevin_Price]

Joyce,

Hmmmm.  I put together a very minimalist example that doesn't create any DAQmx errors on an E-series board here.  The only notable difference is that I configured the pulsetrain counter first but started it last.  There's a boolean constant on the block diagram to try to different methods for routing the pulsetrain output to act as the sample clock for both AI and period measurement.  Also, I think now maybe your choice of CI.CtrTimebaseSrc was the correct DAQmx property node -- that's what's in my example, though it also ran without error when using CI.Period.Term

I couldn't try to measure anything real, so all I could test was that I was able to configure and start all 3 tasks without generating a DAQmx error.

-Kevin P.

Message Edited by Kevin Price on 09-28-2005 12:19 PM

[joyce]

Hi Kevin,

Thank you for your help. I was having trouble last week because the error message always said there was no DMA channels available. After chaning this property and some other miscelleneous settings i've finally made it work. Thank you.

However, the PCI-6014 card that I have doesn't support the "Duplicate count prevention" property thus the program will fail if the signal is small or zero.  I can still do my experiment by keeping the detector on at all times. But I am just very curious about the old Labview VI that I had been using (I didn't write it), in which the counter would spit out the number of photon TTL pulses in every iteration of the While loop, controlled by the "Wait until next ms multiple" function.  I've tried to translate this into the DAQmx but couldn't make it work. I wonder if you could give me some suggestions or explanations ? I just thought i'd be great if I could count "edge" instead of "period ticks" so that I can count small or zero signal, but I haven't been able to write it up successfully.

If not, it is fine because the program is very close to what I'd like to do anyway. So thank you very much.

Joyce

Message Edited by joyce on 10-03-2005 05:45 PM

[Kevin_Price]

I wouldn't advise designing your app to operate like the old code you posted.  I see the following issues:

1. All measurement timing is software-based rather than hardware based.  This will definitely lead to variable interval times between samples.  There is also no synchronization between the counters -- their readings represent different points in time.

2. Extra processing in the data acq loop is liable to increase the timing variability.  The file write operation actually will open, write, and close on every loop iteration.

If you don't have the "Duplicate Count Prevention" property available, you should still be able to configure your buffered counter to do edge counting rather than period measurement.  That'll create a hw-timed buffer of cumulative counts.  A simple finite difference will then get you the counts per interval data.

Going back to the latest DAQmx example I posted, I think you should be able to simply change the first DAQmx Create Channel vi to select the Edge Counting function.  The rest of it looks like it ought to be able to stay the same, other than the extra DMA/interrupt stuff you had to deal with (I hadn't looked up your card to realize that you only had 1 available).   What specific problem are you having?

Again, despite the fact that the old code "works", I don't really think it's worth pursuing.  The new stuff will be able to perform much better measurements.

-Kevin P.

[joyce]

Hi Kevin,

Could you please take a look at this VI and kindly tell me if this is OK?

I should rephrase my intention again, ie. what i'd like to do now is to read off the analog input voltage each time I read a counter sample. I have tried many combinations of Timing and Read functions on CI and AI tasks, and this setup seems to give me the most synchronized data points. When using  this Express Write LMF , I get 4 columns of data:

 x1|  counts | x2 | analog voltage

x1 and x2 are almost exactly the same (sometimes differ by 0.001, but would be synchronized again later on). So is this "really" synchronized reading ? I have assigned the same Sample Clock to both AI and CI but I choose "hardware timed single point" for AI.  I have tried "continuous" mode for AI (setting AI DataXferMech to "Interrupts" because I don't have enough DMA channel) but the "x" values (timing) are not the same.  At the end, I think the current configuration seems to work best for my purpose.

 I just hope that this is OK, if not, could you please give me some advices?

Thank you very much.

Joyce

Message Edited by joyce on 10-05-2005 03:04 PM

Message Edited by joyce on 10-05-2005 03:05 PM