6602 - frequency meausremenr

[MYWONG]

Dear all,

I am now using 6602 to measure frequency of clock signal.

I try to use the example from LabVIEW " Low Freq 1 Ctr.vi" to use Counter 0 to measure a frequency (~140KHz)

I connect my signal to Gate input of Counter 0 and try to run the program serveal time, However, sometimes the reading is not correct. Most of the time, i will get "139860 Hz", which is correct reading, but sometimes i will get "139616"Hz, which is wrong. Anyone know the reason?

By the way, should i need to connect any signal to the Source input of Counter 0, if i am planning to use the internal 80M timebase??

Please help...

M.Y

[JB]

This document should help you to select the most appropriate method for your measurement.

[MYWONG]

I am totally understand what these 3 method is taking. However, my problem is the reading getting from method 1 is not stable. It rary all the time even my input frequency is very slow...

[JB]

Please read this document (linked in above referenced one) carefully. In particular the description for Method 1 in the Measurement Error and Three Frequency Measurement Methods paragraph.

Applied to your application :

Timebase = 80MHZ
Frequency of signal = 140kHz

--> Theoretical number of pulses of the timebase during a period of the signal = 80M/140k = 571.42

Because the number of increments is an integer value, the counter will return 571 pulses or 572 pulses.

--> Resulting Frequency

• 571 pulses : 80M/571 = 140.105kHz
• 572 pulses : 80M/572 = 139.860kHz
• 573 pulses : 80M/573 = 139.616kHz
• 574 pulses : 80M/574 = 139.372kHz
  

I assume the frequency to be a little bit lower than 140kHz and therefore the counter will return 572 for a period and 573 for the next...

With a frequency of 140kHz and a timebase of 80MHz, the error will be 140k/(80M-140k) = 0.175% and the resolution about 0.24kHz.

Unlike your statement, 140kHz is not a very slow frequency and another method may give better results !

Message Edité par JB le 07-25-2007 10:28 AM

[MYWONG]

Hi JB,

Thank you for your detailed answer, you really help me to break the ice....thank you very much...

In fact, i need to measure 8MHz signal, so i think i need to use method 2 (2 counter) to measure this frequency...do you think it is a much more suitable way to measure this frequency? How's the resolution?

By the way, do you know signalexpress? I try to use signalexpress to config 2 counter to make the measurement, but it seems failed to plot the data into a graph, as the frequency i measured from counter is in array data type. I only can show it out in table format and logging is also not allowed...

[JB]

For a 8MHz signal, the 2nd method is the right choice !

Two counters are used for this method wich consist to count the number of pulses in a known time.
So one counter will generate a pulse on its output. This pulse must be connected to the gate of the other counter. Doing so, the number of pulses of the signal will be counted during this very precise duration. --> Frequency = Number of pulses / time

This shows that for a given timebase and a given signal, the resolution of the measurement depends on the time.

Timebase = 80Mhz, signal = 8MHz

• time = 0.01s --> number of pulses = 80k
• 79999/0.01 = 7.9999MHz
• 80000/0.01 = 8MHz
• 80001/0.01 = 8.0001MHz
• --> resolution = 100Hz

• time = 0.1s --> number of pulses = 800k
• 799999/0.1 = 7.99999MHz
• 800000/0.1 = 8MHz
• 800001/0.1 = 8.00001MHz
• --> resolution = 10Hz

• time = 1s --> number of pulses = 8M
• 7999999/1 = 7.999999MHz
• 8000000/1 = 8MHz
• 8000001/1 = 8.000001MHz
• --> resolution = 1Hz

I recommend you to post your SignalExpress question to the specific discussion group.

[acanivell]

Hello

Just one question:

- 6602 clock runs at 80Mhz and stability is 200ppm

Therefore, 80,000,000 * 200 / 1,000,000 = 16,000 Hz

So no matter the method you use, you always get 16Khz error due to the clock stability.

Am I wrong? I just hope not, because that 'll mean that I can not measure frequency in my design using NI 6602 or 6608 even not with FPGA ... 

[aNIta B]

That's correct that the stability of the clock is 200 ppm, your calculations are correct as well.  However, the document linked also explains that when in the PXI chassis, it will phase lock and the accuracy will go down to 75ppm.   Additionally, with the 6608, because of the OCXO your accuracy increases dramatically to only have a 45ppb/year drift.

[acanivell]

Thanks for the response!

That is actually no good news for me, as I want to make a 0.1Hz resolution measurement.

Yes, I already read this document, quite nice indeed. But in fact, I think it is slightly better: I read in the 6602 manual that the stability is 50ppm when attached to a chassis.

In any case, even if I can get a 75ppm I get a 4Khz error.

If I use 6608 instead (75ppb) then I get this error as having a 80Mhz clock:

75ppb * 80Mhz = 6Hz

Which is still too much error.

I just wonder: 6608 has 3 time bases available:

 

So maybe if I use the 100Khz time base I get this error:

75ppb * 100Khz = 0.075Hz

Which would be indeed perfect. However I am not sure THIS calculation is right, as I find no reference on this in the manuals/specs sheets.

[aNIta B]

Thanks for catching that- you are right about that information.  Just one correction on your calculation 100,000Hz*(75/1,000,000,000)=.0075Hz, so slightly better than you thought 🙂  Have a great day!