5660 frequency accuracy

[terrill]

I am programming the 5660 to act as a counter. My thought is to sweep the entire frequency range to find the signal and then zoom in on the signal to make the reeding. My question is if this makes any sense. Does lowering the frequency span give a waveform that will result in a higher resolution frequency measurement? If so how far under the 20 MHz bandwidth is best. I would love to be pointed to some documentation that explains this if possible. Thanks.

Terrill

[Andy_Hinde]

Hi Terrill,
Your approach to this measurement is correct. Doing a coarse scan to find the peak in the spectrum will get you a coarse measurement of the frequency. At that point you would use the coarse measurement as your center frequency and zoom in by reducing your span and resolution bandwidth (RBW). The resolution bandwidth input is what will affect the accuracy, but to achieve a satisfactory measurement time with lower RBWs, a lower span is necessary. I would suggest a span <= 1.25 MHz, and the smaller the better. A span <= 1.25 MHz will ensure the PXI-5660's digital downconverter (DDC) present on the digitizer module will be enabled, thus accelerating the measurement greatly. Lower spans achieve even more DDC 'acceleration' - see the PXI-5660 documentation for more info.
When the DDC is enabled, you can use lower RBWs. The RBW setting determines the acquisition time, or amount of data sampled. This is known as 'gate time' in frequency counter terminology, so lowering the RBW in effect increases the gate time, which increases the accuracy of the measurement up to a point. I am attaching a VI which uses PXI-5660 specifications to calculate the expected frequency measurement accuracy you can expect based on the signal frequency and gate time of the measurement.

So in summary:
Span should be <= 1.25 MHz, and the lower the better because the lower the span, the more DDC help you get.
DDC help is important because greater measurement accuracy requires longer gate times, which is in effect the same as lower RBWs. Lower RBWs require more processing which the DDC helps.
The attached VI tells you what frequency measurement accuracy you can expect with the 5660. Best case is right after a fresh calibration. Worst case is after worst case aging specs of the onboard timebase after a year's use with no re-cal.

[terrill]

Andy,

Thanks for the great answer. I did this but I am having accuracy problems. For the final read I have a 20 Hz span and a 0.1 RBW. I have a sig gen with the output connected to both an agilent 53131 frequency counter and the NI 5660. I am using the PXI chassis reference for both the signal gen and frequency counter. The frequency counter says the signal generator is right on, 2.000006 MHz in this case. The NI 5660 reads the signal at 17 Hz off at 1.999989 Hz. I am sort of at a loss as to the difference. Do you have any Ideas? Also for your accuracy code, is there away t convert span and RBW to gate time? Thanks.

Terrill

[Andy_Hinde]

Hi Terrill,
The frequency offset is more than likely due to the fact that the source and receiver (5660) are not using the same 10 MHz reference clock. I believe that if you lock the sig gen to the PXI-5660 or vice versa, the frequency offset will be eliminated. The frequency offset in the measurement is due to the sig gen and 5660 having slightly different ideas about what 10 MHz is due to the fact they are using separate timebases. This is a common situation in communications where transmitters and receivers who cannot share a single timebase must be able to account for frequency offsets and null them out.
For future reference, the 10 MHz timebase on the PXI-5660 (the PXI-5600 module specifically) is more accurate and stable than then PXI chassis 10 MHZ reference. You should use the better timebase whenever possible, as the PXI-5660 is using its onboard reference, and not the chassis reference, by default. In fact, if you try to lock the PXI-5660 to the chassis 10 MHz reference, it will not work since the chassis clock is not high enough quality for the PXI-5660 to lock to as per the specifications in the spec sheet.

There is no easy way to convert span and RBW to gate time. An approximation is to take the inverse of your RBW, which in your case would be 10 seconds. This is probably overkill in my opinion and you could speed up your measurement time by using a larger RBW. Longer and longer gate times stop having any improving effect on the accuracy after a point, as you can demonstrate with the VI I posted last time.

[terrill]

Thanks again. That was the problem. I forgot about the seperate clock. I figured I would over do it in the beginning and then lower the settings to an optimal level. The one thing I am not sure of is that when I am finished I will need to tell others how accurate this is as a spec. As of now I have no idea how to calculate the accuracy of this thing. Thanks again.

Terrill

[Andy_Hinde]

Hi Terrill,
One thing you can do is look inside the ni5660 Read Averaged Power Spectrum routine. There is a subVI used in it called niScope Multi Read Cluster. The 'waveform' output contains a cluster with 'xIncrement' and 'wfm' parameters. If you use the Array Size routine in LabVIEW to determine how many samples were acquired and multiply it by 'xIncrement', you can determine the acquisition time or gate time.

Be careful about saving any changes you make to core VIs like this.

Thanks,
Andy

[terrill]

Andy,

Hate to bother you again. My counter function seems to work although it take over 3 seconds to sweep the 2.7G bandwidth. My next problem is that most counters have time-based measurements such as Vp-p and rise time. I have not been able to get a time domain signal out of the 5660. I thought the output of the NISCOPE Multi read would be the time domain signal but if I feed it into a graph it looks like noise and it I replace the Multi read with an NI Scope Read Measure I get an incorrect frequency reading. Could you steer me down the correct path to setup the tuner to the frequency I need and then obtaining a time domain signal. Thanks.

Terrill

[Andy_Hinde]

Hi Terrill,
Let me see if I can address your questions point by point:

"My counter function seems to work although it take over 3 seconds to sweep the 2.7G bandwidth."
This sounds about right. I ran a test on my system and swept the whole 2.7 GHz range in a little over 3 seconds. The 5660 sweeps in 20 MHz chunks, which for a 2.7 GHz span would be 135 segments. The PXI-5660 tuning specs show the time it takes the 5600 to tune from one segment to the next, so at 25 ms per tune, for example, 135 tunes would take 3.3 seconds or so. A lower RBW will increase the relative portion of measurement time that consists of data acquisition and SW processing, so the three second or so tuning time would be the lower bound on this.

"My next problem is that most counters have time-based measurements such as Vp-p and rise time."
The PXI-5660 returns complex, baseband IQ data when narrow spans like the ones you are using for your fine peak measurement are used. This IQ data is time domain data but is not the same type of data as time samples from a scope. The data that is fed into the digitizer is a downconverted (by the 5600) version of the RF input signal, which lowers the frequency and more than likely the rise time. The PXI-5660 is not the best choice for rise time measurements. The Vp-p measurement should be no problem. The IQ data can be converted to magnitude/phase data and the magnitude data can be converted to Vp-p. I am attaching an example which shows this (ni5660 Power vs. Time).

"...if I replace the Multi read with an NI Scope Read Measure I get an incorrect frequency reading"
You can't replace the NI-Scope Multi Read routine present in the ni5660 Read Spectrum or ni5660 Read IQ routines. When the PXI-5660 acquires IQ data directly from HW, then the Multi Read is necessary to acquire both I and Q data arrays from the HW.

Thanks,
Andy

[terrill]

Thanks again. 2 things:

1. You forget to attach the example VI.
2. While I was waiting I found the MT RFSA IQ Example.vi and decided to try this. I am having some issuses keeping some of there vi references open but it looks like it should work. Am I better off using the multi read?

Terrill

[Andy_Hinde]

Hi Terrill,
I thought I attached the example but will try again. As for the IQ example you reference, I would avoid using the examples with the MT RFSA prefix as they use the older API for interfacing to the HW. The attached (hopefully) example uses the newer, easier to use API. However, you are definitely on the right track since the example I am attaching converts the IQ data to Mag/Phase and then Vp-p.

Try this example and let me know if you have VI reference problems.

Thanks,
Andy