How to lock sampling frequency for 5673 and 5663

[Andy_Hinde]

Hi Clayton_A,

So now I see the actual challenge you are facing. When you generate 3.65 GHz from a 5673 into a 5663, you see a 0.25 Hz offset when they are locked to a common reference clock. I'll try and reproduce this.

Regards,

Andy Hinde

RF Systems Engineer

National Instruments

[Clayton_A]

Andy_Hinde,

Thank you so much for the help. 

One more thing I just noticed which might shed some light ... Not all frequencies are producing a noticable offset.  For example, I just tried 3.5, 3.6, 3.7,3.8. 3.9 and 5.8 and things look beautiful (as shown below).

Multiples of 100MHz look ok.  I haven't tried them all obviously. 

Your help in solving or at least characterizing this problem is much appreciated. 

Thanks,

-Clayton_A

[Andy_Hinde · Accepted solution]

Hi Clayton_A,

I set this up and replicated the behavior you are seeing @ 3.65 GHz, as well as replicating the lack of frequency offset at other frequencies. I talked with our R&D engineers and this is expected behavior for our products, let me explain.

The PXIe-5673 is a direct upconversion architecture, so whatever center frequency you request, that is the RF frequency of the LO being generated by the PXIe-5652 module.

The PXIe-5663 is an IF downconversion architecture with an IF frequency of 187.5 MHz for the most part, meaning the RF frequency of the LO being generated by the PXIe-5652 is 187.5 MHz higher (usually) or lower than the requested center frequency.

The main point is that when the 5663 and 5673 are tuned to the same RF center frequency, the frequency being generated by the LO modules is different by 187.5 MHz (usually). Due to the architecture of the 5652 module, when synthesizing some RF frequencies there are some very small residual frequency offsets from the target frequency. Since the LOs are generating different frequencies when the instrumments are actually looking at the same RF frequency, the end result is some very small residual frequency offset between the two instruments like you are seeing.

For most applications this is negligible. However, if this is unacceptable you can remove this very slight residual offset. This is possible because of the presence of the Onboard Signal Processor (OSP) on both the 5673 and 5663. You can read more about the OSP in the help info for the two products, but they are located on the 5622 and 5450 (the digitizer and AWG) and operate at baseband digitally. They can both apply very fine frequency shifts to the IQ data. So long story short, you can correct for this residual error by applying a corresponding frequency shift in the opposite direction to either the 5673 or 5663. So if you have a 0.25 Hz offset between the 5663 and 5673, you can apply a 0.25 Hz shift in the OSP of the 5663 or 5673 to compensate.

I tweaked a simple NI-RFSA shipping example for the 5663 to demonstrate this. The example acquires the incoming data and measures the frequency of the I waveform, which corresponds to the offset. I can then copy/paste the measured frequency value as the shift I want to apply at baseband to compensate, removing the offset when I re-run the example. See the Before and After screenshots attached.

The OSP baseband shifting is performed via the center frequency and upconverter center frequency attributes for the 5673/NI-RFSG, and the center frequency and downconverter center frequency attributes for the 5663/NI-RFSA. The frequency you are actually trying to tune to/look at is the center frequency, and the up/downconverter center frequency in the center frequency of the up/downconverters. If the two are set differently, the difference is applied at baseband by the OSP. If I set a downconverter center frequency of 1001 MHz and a center frequency of 1000 MHz, my downconverter is tuned to 1001 MHz, but my OSP is tuned 1 MHz lower than normal operation (which has the OSP tuned to the center of the up/downconverter passband). 

Incidentally, we (NI) refer to this feature in our documentation as In-Band Retuning.

Regards,

Andy Hinde

RF Systems Engineer

National Instruments

[Clayton_A]

Thank you so much. 

So the issue is that the difference between the two LOs is not exactly +/-187.5 MHz.

I have one last question.

I noticed (for a few cases) that there is no offset when tuning to multiples of 100MHz, should this always hold true?

Is there a set of frequencies that should have a zero offset? In other words, is there a nice formula/rule (either based on the 5652 tuned frequency, or at the high level) that will show which frequencies have no offset? 

Thanks again. 

-Clayton_A

[Andy_Hinde]

Some RF center frequencies result in LO signals where there is no offset, as you have bserved for multiples of 100 MHz. This will always hold true for those frequencies in question, so for example, multiples of 100 MHz won't start having residual offsets one day in the future.

I don't know of any rule or formula to predict this a priori. I'll ask, but the algorithm used in NI-RFSG and NI-RFSA choosing of the various internal VCO frequencies is complicated and I don't know that it will lend itself to a simple formula, but we'll see.

Regards,

Andy Hinde

RF Systems Engineer

National Instruments

[Andy_Hinde]

Hi Clayton_A,

Unfortunately there is no easy formula to replicate what the drivers are doing 'under the hood'. Using the In-Band retuning feature is the best option for you to align the Tx and Rx frequencies to sub-Hz resolution. 

Hope this helps,

Andy Hinde

RF Systems Engineer

National Instruments

[mbb25]

Another (simpler) way to do this is to enable in-band retuning on the 5673.  Be default, the 5673 frequency shift on the arb is 0 Hz.  This allows you to synchronize multiple 5673's with a repeatable phase offset by daisy-chaining the LO signal.  With a non-zero frequency shift on the arb, you need to synchronize the phase of the arb frequency shift as well as daisy-chaining the LOs to get repeatable phase synchronization.  You can synchronize the arbs at the start of generation using TClk, but there isn't a way to keep the arb phases sychronized after an on-the-fly frequency change.  Sorry there's so much jargon in here.  This is just background info, so ignore it if it doesn't make sense.

Anyway, that's why we didn't enable the frequency shift on the arb ("in-band retuning") by default.

Since you aren't synchronizing multiple 5673s, my suggestion would be to turn on in-band retuning.  Turn in-band retuning on by setting the Upconverter Center Frequency attribute.  In your case, just setting the upconverter center frequency and the RF frequency to the same value will do the trick.  This gives RFSG permission to set a small frequency shift on the arb to account for the coerced LO frequency.

The 5663 adjusts for the LO coercion by doing a small frequency shift on the digitizer.  It does this by default.  It seems better to reduce the 5673 frequency coercion than to set the 5663 to the 5673's coerced LO frequency.  I hope this makes sense.

To be complete, there is still a finite resolution for the arb frequency shift and digitizer frequency shift.  However, this will be difficult to measure.  Enabling in-band retuning on the 5673 should drive the frequency difference down dramatically: instead of 1-2 Hz the offset should be < 650 nHz.  Just to put that into perspective, it would take over an hour for the 5663 and 5673 to drift apart by 1 degree.

Is 650 nHz of offset still a problem for you?  If so, I'd like to hear more about your use case.

It may be possible to eliminate this 650 nHz offset also, if you are willing to use an extreme (and out of specifications) offset of 187.5 MHz on the 5673.  You'd do this in order to use the same LO frequency on the 5663 and 5673 (you could even share the LOs).  This might be OK for you, if you don't need calibrated gain or much bandwidth out of the 5673.  I don't expect the driver to let you do this easily, but you could make it happen if 650 nHz of offset is still unacceptable.

I hope that helps.

-- McKay