Re: [Discuss-gnuradio] frequency tuning word quantization

[Eric Blossom]

On Sun, Mar 05, 2006 at 07:18:40PM -0500, David I. Emery wrote:
> On Sun, Mar 05, 2006 at 12:03:33PM -0800, Eric Blossom wrote:
> > Good question.  I've wanted to revisit it myself too.
> > As I recall it was to reduce the spurs in the DDC output.
> > If you get a chance, please see if you can find relevant papers.
> > I suggest searching for "DDS spurs", or something like that.
> > 
> > In looking at the DDS's from Analog Devices, etc., they maintain a
> > full precision frequency tuning word and phase accumulator, and then
> > use only the high part to feed into the sin/cos generator.  We also
> > do that in the FPGA.  The question is whether we should be doing the
> > coarse quanitization of the frequency tuning word the way we are, or
> > some other way, or not at all.

>       As for spurs resulting from this - I would have to do a
> literature check.   But the mechanism for generating them is not
> obvious.
> 
> 
> > 
> > Anybody else got something to contribute to this discussion?
> 
>       The above is my attempt...

Thanks Dave!

Googling "phase truncation spurs" turns up several good papers.

The truncation from the full accumulator width to whatever width the
sin/cos generation really supports eventually results in slight "phase
truncation spurs" -- effectively phase modulation.

The EDN article by David Brandon (Analog Devices) 
<http://www.edn.com/contents/images/415103.pdf> says that the
worst-case spurious magnitude attributable to phase-word width is
-6.02 * P dBc, where P is the number of bits in the phase word.
(The magnitude is proportional to the LSB weight in the phase word.)

In the FPGA, the phase word (not the accumulator) is approximately
15-bits wide.  This gives worst case phase-truncation spurs of -90 dBc.
This looks small enough that we can safely ignore it. Therefore, 
I suggest we stop truncating the tuning word on the host side.

Also, if we stop truncating on the host, then our frequency tuning
resolution will be 64e6 / 2**31 = 0.03 Hz.  Probably fine enough for
most uses.

Matt, do you concur?

Eric