Counting TTL pulses

[VVV]

I need to count random TTL pulses in specified adjustable time (0.01 sec to 100 sec) with USB6251 or USB6211.

It looks that the example: “Meas Dig Frequency-Buffered-Finite-High Freq 2 Ctr.vi” is appropriate choice for me and it does work for me but with some drawbacks.

I am attaching the modify example and shot screen of operating vi.

The TTL source is attached to the counter 0 and produced 100,000Hz. In output array I have first data is wrong but rest are okay, so I use second element in the array. I’ve tried to reconfigure DAQmx Read.vi to single element reading (with one sample per channel), but it brought only the wrong first element from the array.

The question what I am doing wrong? I have not done any internal connection except the input of the counter 0 to a generator. Is it possible to read only one element (not array) at the time? I need measurement to be done in frame of specified time: in the attached example the specified time is 1 sec, but measurement took 1.150 sec I presume the extra 0.15 sec is combined measurement overhead plus acquisition of first element which is anyway wrong. When I increase the measurement time to 10 sec the total acquisition time is 10.15. it looks that measurement of first array element takes 0.15 sec no mutter what time specified. Can measurement be done with minimum overheads?

thanks

[samantham]

Hello,

Yes, it seems that the high frequency measurement is the right counter method for you if you are interested in specifying the measurement time.  However, please do consider that if you are measuring lower frequencies with this method the known period (measurement time) will need to be very long in order to properly measure the low frequency.  This is because the method is more generic than a typical period measurement.  For more detailed information about each of the three counter task frequency measurements, please refer to Making Accurate Frequency Measurements.

The first output of the high frequency measurement is indeed incorrect.  It does not compare the known period to the unknown signal’s rising edges.  (Refer to the images below of known period and unknown signal reference.)  This is because the unknown signal was not tracked prior to the first rising edge of the known period.  However, upon the next rising edge of the known period, the past number of rising edges of the unknown signal is then compared against the known period to compute the frequency.  In summary, the first measurement was written out, since there was a rising edge on the known period; however the unknown signal was not being monitored yet.  Thus, a correct frequency measurement is not produced until the second output.  Please refer to the images below of known period and unknown signal reference.

You are not doing anything wrong and I do not believe this method (high frequency measurement) was intended for signal element results.  However, I will be double checking with R&D about this issue. 

How are you tracking the 1.15 seconds that you referenced?  This .15 seconds is likely due to overhead.  The task takes a small amount of time to create/initiate the channel, configure timing, start the task, and clear the task other than the measurement execution. 

Message Edited by samantham on 02-04-2008 06:34 AM

[VVV]

Hi Samantha:

Thank you very much for your response. It clarified the high frequency measurement but did not help in my particular case. I need somehow to reduce overhead…

It may help if I will explain about my particular task: I need to count random TTL pulses, which are product of photon counting measurement. We both agreed that “the high frequency measurement is the right counter method”. With your diagram I know for sure that connection is okay. Also we know that second element of the measurement in the array is correct and could be used (probably first element of the array is indication of overhead). Unfortunately, the first counter does not start immediately with rising edge: it takes app. 0.15 sec. for  the first counter to produce the rising edge (when actual measurement started) : it probably is our most overhead time. Now the questions: if I want to start analog input I can do it instantaneously, even I can do it by precise triggering by additional sync signal; can I do the same with counting input? I mean can I reset somehow the first counter in advance before acquisition? The acquisition overall is relatively simple: I need move a stepper motor and then acquire count rate in a specified measurement period. When I am doing it with analog input with 0.1 sec measuring time there is no problem. With the counter it adds at each acquisition point 0.15 overhead time and makes my scanning speed 2.5 time longer, so, need somehow to reduce the overhead time. Could you please advice some ideas or at least direction. I can add on top of the board some electronic schematic. Can I use digital output to gate the second counter?: it looks that digital could be starts instantaneous?    

I am attaching overhead test loop.       

Best regards,

Vassiliy

[samantham]

Hello,

Sorry that there was a time lapse related to by response, however I have been tracking your technical support e-mail based service request. 

To share the solution with future forum post viewers, I have attached an example that manually configures the High Frequency 2 Counter method of the Counter Input task for digital frequency measurements.  Please note that the example is executed differently if the USB 6251 or USB 6211 is used.  This difference relates to a slight difference in the internal paths of the two devices. 

Please note that a manual configuration was used in this case to accommodate a specific application.  This application is limited to a variable measurement time to acquiring a single frequency measurement with minimal overhead with M series USB DAQ devices.  The shipping example titled Meas Dig Frequency-Buffered-Finite-High Freq 2 Ctr.vi and other frequency examples in the Example Finder are still relevant and helpful examples.  Please use the shipping examples prior to focusing on this manual case.