Counter return a large value

[nangroy]

Hi,

I am doing a low frequency measurement with 1 counter, here is my program. There is two counters which measure two channels.

I wonder why the result data sometimes get a very large value, say 10000000Hz, while my signal is around 1500Hz. And this happens irregularly.

[John_P1]

Hi nangroy,

The culprit is most likely noise on your input signal.  A small glitch on the line would cause you to measure a very high frequency.  For example, the 10MHz frequency that you measured in the image you attached would correspond to a glitch that lasted 2 ticks of the 20 MHz timebase. 

If you are using an M series DAQ device (62xx) or a Counter/Timer board (66xx), you can use the built-in digital filtering to remove the unwanted noise.  I suspect you might be using E series, which does not have built-in filtering on the digital lines.  If this is the case, you can use an external Schmitt trigger or use the Analog Triggering circuitry of your device to generate the digital pulse as described in the following KnowledgeBase:

    How Can I Use my non-TTL Signal to Generate a TTL Signal?

Alternatively, you could check for frequency values above a certain threshhold and choose to ignore them in your LabVIEW code so they don't throw off your average.

-John 

[nangroy]

Hi  John,

I also believe that it is the signal problem. But I wonder when I change the internal timebase from 20MHz to 100kHz, then there was no problem. Once I change it to 80MHz timebase, it happens more frequenctly. Thus I would like to try a internal timebase 1MHz. However, how could I alter it to 1MHz?

I try to set the timebase rate as 1000000. But it returns a error said that the rate must match the internal timebase.

Possible reason(s):

Counter timebase source and counter timebase rate settings are inconsistent with one another.

For internal counter timebase source selections, if the counter timebase rate is set, its value must match the rate corresponding to the counter timebase source. For example, 20 MHz corresponds to a rate of 20,000,000 Hz.

Channel Name: Dev1/ctr0

Task Name: _unnamedTask<4>

[John_P1]

Hi nangroy,

Thanks for the update.  If you have an 80 MHz timebase then you are using an M series (or a cDAQ-9172).  The three available timebases on M series devices are 100 kHz, 20 MHz, and 80 MHz.  See Chapter 9 of the M Series User Manual for more information about the timebases.  These are built-in clocks that are divided down from an 80 MHz reference clock, so you can't change the rate of the timebases directly.

If you want to generate a 1 MHz reference, your best option would be to use the FREQ OUT line.  However, I don't believe this should be necessary.  If you have a noisy line then it would make sense that the 80 MHz timebase would detect the noise more often.  Using a slower timebase would detect the noise less often, but I would imagine it will still detect it occasionally.  Using a slower timebase also compromises the resolution of your frequency measurement.  Your best bet is to use a higher timebase, but use the built-in digital filtering of the M series.

To use the digital filtering (see M series user manual), you simply need to use a DAQmx Channel Property Node in LabVIEW.  Call the property node to set the filter before you start the task, and this should prevent the noise on your input signal from having an impact:

Message Edited by John P on 04-23-2009 11:37 AM

[nangroy]

Hi John,

Thanks for your advice. After implement the digital filter and also add some shielding to my signal wire. The problem seems to be solved.

One more question want to verify, does the digital filter really "filter" the noise out or just read all the data and then ignore the unwanted data? Because my measurement aims to be a real time mode. Each data point should follow a corresponding time stamp.

[John_P1]

Hi nangroy,

The filtering is done completely in hardware--it will look like this:

Again, this information can be found in the M series user manual.   As indicated in the diagram above, there will be a slight delay to when the value is updated in the count register, depending on the minimum pulse width setting.  The timing diagram above corresponds to a setting of 125 ns (5 ticks of the 40 MHz filter clock).  The 6.425 us setting will result in a slight delay of 6.425 us (257 ticks of the 40 MHz clock).  The other option is 2.56 ms, which is too slow to measure your desired frequency.

Accurate Timestamping is tricky when using implicit timing, since the driver does not have a sample clock to derive a dt from--I am not completely sure what you mean by "real time" mode.  The accuracy of your frequency measurements that make it through the filter will not be affected since the small delay occurs on both the start and end of the period of your waveform.  For all practical purposes, the filter will remove the nosie that you are seeing and will have an insignificant affect on the rest of your measurements.

-John 

Message Edited by John P on 04-24-2009 10:15 AM