Normally, the best way to capture TTL pulses would be to use a counter task with the signal wired to a PFI terminal. What do you want to characterize about these pulses?
Based on prior threads, I suspect it's one of two things:
1. Raw pulse rate measurement, capturing every individual pulse interval. This method is more prone to acquisition errors if the APD pulse rate gets too high for the system to accomodate. (Old benchmarks for older hw like yours seemed to top out in the high 10's to low 100's of kHz.)
2. "Binning" operations where you count the # of pulses occurring within a series of fixed intervals. This method gives you less detailed info but is more robust. It would also require the use of both counters -- one to generate the fixed-rate clock, the other to count edges while using that clock for sampling.
You also *might* find the need to configure a special property known as "duplicate count prevention". Back in the days when your devices was less ancient, it used to come up more often. It's been much less of an issue with drivers and devices from the last 15 years or so, but your device predates that, so there's a chance it's still vulnerable.
-Kevin P
ALERT! LabVIEW's subscription-only policy came to an end (finally!). Unfortunately, pricing favors the captured and committed over new adopters -- so tread carefully.
