Frequency resolution of AWG (PXI-5421)

[PTARlab]

I'm trying to use an AWG to clock a FlexRIO FPGA at ~30 MHz. The clock frequency needs to change when triggered by events on the FPGA.  Because of the freqency precision required for this application, we selected a AWG (model PXI-5421) for the job, and I have been figuring out how to program arbitrary sequences (the attached VI is a good example).

When I control the AWG with the FGEN soft front panel, the frequency resolution is fanastic.  I can change the freqency by the smallest increment my oscilloscope can distinguish, 1 kHz at 30 MHz.  Sadly though, I don't get the same performance from an arbitrary sequence executed in LabVIEW.  Apparently, the number of points in each wavefrom in the arbitrary sequence must be divisble by 4.  This is a serious problem in at high frequency when a waveform might contain only a few points.  

Why does the performance drop so dramatically?

[kirsch]

Short answer: PXI-5421 is an Arbitrary Waveform Generator, not a Function Generator (like the PXI-5406) nor a device with Onboard Signal Processing (like the PXI-5441). As such, it doesn't support changing Sample Rate on the fly nor natively support Function Mode in hardware.

Long answer: NI-FGEN implements Function Mode on the PXI-5421 on top of Arb Waveform fucntionality, which is what the instrument can physically do. Given a desired frequency, NI-FGEN creates a waveform in RAM and downloads it to the instrument. It tweaks with the Sample Rate and waveform length and number of cycles per waveform to give you a very accurate final frequency. But it needs to stop and reconfigure Sample Rate, and download a new waveform, and re-start whenever you change the frequency. This is very easy to see with a scope. If you had a function generator, the frequency changes would be seamless.

You are trying to accomplish a similar frequency resolution without reconfiguring the Sample Rate, so you are losing one of the variables you can tweak (Sample Rate), leaving you with number of points per waveform and number of cycles per waveform.

I hope this answers your question of "Why does the performance drop so dramatically?"

So now, some help with your problem: yes, high frequencies with only a few point per cycle would be a serious problem if you have only one cycle per waveform. If you can tolerate some delay and uncertainty in time when going from one frequency to the next, then create  larger waveforms, each containing a larger number of integer cycles. This gives you more control over the frequency of the waveform. You'll have to do a little bit of math to come up with your sweet spots. The waveforms for each frequency do not need to have the same number of samples, they just need to contain an integer number of cycles so when you loop them there are no discontinuities in the generated signal.

Hopefully this is of help, let me know if you need any clarification.

Good luck

Marcos

[kirsch]

If you can tolerate some delay and uncertainty in time when going from one frequency to the next

I wrote this making the assumption that the waveform needs to play out before you jump to the next one. If you use Script Mode, then you don't need to wait until the waveform finishes playing out. 

You can use this:

break on [scripttrigger]
// do your stuff
end break

Thanks to Liusdi for clarifying.

[PTARlab]

Thanks for your answer, Marcos.  That makes a lot of sense.

After doing your recommended little bit of math, I think adding additional cycles to each waveform will give me back most of the resolution I want.  What is the best way to define the number of cycles per wave, though?  Neither the example VI I attached to my original post nor the sub VI that creates the waveform data includes this parameter. 

[PTARlab]

Marcos,

You may be interested to hear that the PXI-5421 AWG is not well-suited for use as a flexible clock for other PXI hardware for a number of reasons:

1) As you discussed above, this AWG must operate at one sample rate for each sequence of waveforms.  Since we need to switch between output freqencies, operating at a fixed sample rate limits the output freqency resolution.

2) The long waveforms required to achieve reasonable freqency resolution at fixed sample rate quickly consume the AWG's onboard memory. For example, the waveform required to achieve 10 Hz resolution at 40 MHz with a sample rate or 100MS/s is 3.2 Mbytes.  A lengthy sequence just won't fit in memory.

3) Crucially, this AWG lacks a SYNC OUT line.  As you explained years ago in another thread (http://forums.ni.com/t5/Signal-Generators/export-sync-in-PXI-5421/td-p/906851) this deficit prevents clocking with the generated waveform after passing it through a comparator.  Your workaround of exporting the most significant bit as a "poor man's sync signal out" works, but it forces the output freqency to be an integer divisor of the sample rate since the I16 number being sent to the DAC is only updated once per clock cycle.

Thanks for your help,

G

[kirsch]

> You may be interested to hear that the PXI-5421 AWG is not well-suited for use as a flexible clock for other PXI hardware for a number of reasons:

Agreed. A better choice would be the PXI-5404 frequency generator, or one of our function generators which do have low-jitter square waveform generation: PXI-5402, PXI-5406.