Data log rate of Counter Period acquisition

[a.yearsley]

I'm measuring and recording the period of a digital input pulse train (input to NI9421 card on a 'C' series DAQ chassis and recorded via LabVIEW SignalExpress 2009).  The 'Counter Period' acquisition step is configured to use '1 Counter' measurement method.

In order to record the data I have to use '1 Sample (On Demand)' Acquisition mode.  

When I review the recorded data, how can I determine:

a) the sample frequency of the recorded data points   ?

b) the absolute timestamp of any data point   ?

The log file has no information regarding the recording frequency, and from my experiments this seems to change based on the measured period of the input.

Any ideas??

[Brian_P]

By looking at the specs. the 9421 doesn't have any counter on it, how are you using it to do a Counter Period aquisition?  

Brian P

[a.yearsley]

If I insert the 9421 card into slot 5 or 6 then I can use it as a counter module (in-built PFI0/PFI1 channels).

I have subsequenty found that I can use an 'Edge Count' acquisition.  If I do this then I specify the sample rate (e.g. count number of edges within 100ms)  and then the sampling and logging is deterministic.  This means I need to do some post-processing to convert to period etc. but I can cope with that if I need to.

Would be great if I could capture the period of the input wave and log it every 'x' seconds (where 'x' is a fixed time-period).

[Brian_P]

I am glad that you were able to find a work around to your problem.  What chassis are you using with your 9421?

[John_P1 · Accepted solution]

Hi a.yearsley,

The counters on the 1st generation cDAQ chassis (9172) do not support sample-clocked period measurements.  I'm assuming you are using this chassis since you mentioned that you have the module in slot 5 or 6.

Your edge count workaround is very similar to the High Frequency 2 counter method.  In either case, you specify a time duration and count the edges of your external signal during this time.  The 2nd counter is used to generate the gate signal for the specified time duration.  Your measurement error with this method is up to 1 period of the external signal, so it is more commonly used with higher frequency signals (I'm not sure what the frequency of your signal is).

The standard 1 counter method counts the number of ticks of an internal timebase (80 MHz) during one period of your input signal.  Since the signal itself is what is gating the measurement, the sample is latched into the buffer on the edge of the signal and is not clocked independently.  If desired, you could configure Implicit Timing, which would give you a period measured for every edge of the input signal.

Taking the above idea one step further, you could just configure an edge count task with the 80 MHz timebase as the source.  Use the external signal as a sample clock.  The only difference between this and using the standard period measurement with implicit timing is that the counter is not reset after every sample.  This might make it easier to keep track if you want to log a sample every x seconds (i.e. once the total count passes a certain value).  You can find the period by subtracting consecutive counts and multiplying by the period of the timebase (12.5 ns).  The counter would rollover after about 53.69 seconds, but if you read the count as U32 there won't be any problem with the subtraction (0000 - FFFF = 1 if the numbers are U32).

If you are on a 2nd generation cDAQ chassis (e.g. 9174, 9178, 9188), then you actually do have support for a sample-clocked period measurement.  You can choose whether or not to enable averaging.  The 9178/9174 user manual has diagrams showing the sample-clocked frequency measurement which is essentially the same thing (the driver inverts the period measurement to obtain frequency).  You must guarantee at least 1 edge of your external signal between sample clocks if using this method.  The clock can come from a number of sources--I would probably recommend using another counter to generate it.

Best Regards,