CTR04 Basic Counter Specifications

[jom012265]

In the specifications for the CTR04, the 'Timebase' is listed as 96MHz.

Am I correct in assuming that this is the basic sampling freuquency, i.e. the frequency that the fpga samples the raw input signal coming in on an input channel with?

I assume this based on the fact that the specified 'Maximum input frequency', i.e. what I assume is the max frequency of the raw signal wired into a Ci port, is listed as 48MHz, i.e. the frequency one would get based on the Nyquist '1/2' criteria - 96/2 = 48.

Likewise, is the 'Counter read pacer' basically the polling rate, i.e. the 'rate' input to the ULx Timing (Sample Clock) LabVIEW vi?

So for example if this polling rate is 2Hz (e.g. twice a second), the count returned by each call of the ULx Read... LabVIEW vi would be the number of raw signal pulses that occured inbetween last two polling instances (assuming the 'clear after read' was set to True)?

Edited May 7 by jom012265
clarification added

[DAQman]

The 96 MHz clock drives the FPGA and is only remotely related to the sample rate. When you request a sample rate, a sub-clock is used to achieve the rate. If you were to request a sample rate of 100, the FPGA still runs at 96 Mhz, but data is recorded 100 times a second. When using the Totalize mode (counting), the count increases on each edge of the applied signal, whether you read it or not. Clear on Read does just that; after each read, the register is reset to the minimum value, typically zero. 

 

[jom012265]

OK, so the 96MHz is basically a base-clock. I'm trying to identify the difference between the sample rate input by the user (in your example 100 Hz), which seems to be a polling rate, and the sample rate at which the signal is sampled. For example if I input that 100Hz as a sample rate, and in between two consecutive reads (that were 1/100 sec apart) the signal had 3 pulses that were for example 10usec long each, I assume the count would be 3 when the last read returns, but in order to catch those three 10usec pulses, the rate at which the 3 pulse-signal was sampled would have to be at least 200kHz correct? How does the device know how fast the this raw signal has to be sampled?...or am I missing something?

Edited May 8 by jom012265
clarification

[DAQman]

If you are programming in Python, the function is c_in_scan, and one of the terms is scan rate. Let's say you program it to read a totalizing (counting) counter input with a 1000 hz square wave as the input signal. If the scan rate is set to 100, the data returned will be 10, 20, 30, 40, etc. 

If, instead, you were to use a polling function like c_in_32 and call this function within a loop, then you might get values like 9, 21, 30, 99, 41, etc. because the loop timing is not precise. 

[jom012265]

Thanks - I'm actually programming in LabVIEW, and I'm using the 'ULx Read (Counter U32 1CHan 1Samp).vi' when in a loop and 'ULx Read (Counter U32 1CHan NSamp).vi' when doing a finite sample count single data-batch grab.