Spectral Purity Measurement

On Friday, 19 December 2014 20:37:03 UTC+5:30, rickman  wrote:
> I want to analyze the output of a DDS circuit and am wondering if an FFT 
> is the best way to do this.  I'm mainly concerned with the "close in" 
> spurs that are often generated by a DDS.  My analysis of the errors 
> involved in the sine generation is that they will be on the order of 1 
> ppm which I believe will be -240 dBc.  Is that right?  Sounds far too 
> easy to get such good results.  I guess I'm worried that it will be hard 
> to measure such low levels.
> 
> Any suggestions?  I'll be coding both the implementation and the 
> measurement code.  The implementation will be synthesizable and the 
> measurement code will not.  I'm thinking a fairly large FFT, 2048 or 
> maybe 4096 bins in floating point.
> 
> -- 
> 
> Rick

If one knows about the min ppm(1ppm, in this case) in the signal and the sine tone frequency one is measuring, I think taking the phase difference of samples 1e6 samples apart should tell about the timing drift as a result of the timing impurity in the signal. For better estimates, one can calculate this difference over many samples and take its average. 
ie, 
phOff = average(angle(x[i]*conj(x[i+1e6])))
phOffPerSam = phOff/1e6
ppm = phOffPerSam/2pi ;(freq offset normalized with sampling frequency)

Assumption is for ideal sine wave of the given freq, x[i] = x[i+1e6] holds true.
Otherwise, 1e6 should be replaced by min no. of samples greater than 1e6 which ensure the above equality.

Please correct me if im missing something...

On Sunday, 21 December 2014 12:21:03 UTC+5:30, rakesh...@gmail.com  wrote:
> On Friday, 19 December 2014 20:37:03 UTC+5:30, rickman  wrote:
> > I want to analyze the output of a DDS circuit and am wondering if an FFT 
> > is the best way to do this.  I'm mainly concerned with the "close in" 
> > spurs that are often generated by a DDS.  My analysis of the errors 
> > involved in the sine generation is that they will be on the order of 1 
> > ppm which I believe will be -240 dBc.  Is that right?  Sounds far too 
> > easy to get such good results.  I guess I'm worried that it will be hard 
> > to measure such low levels.
> > 
> > Any suggestions?  I'll be coding both the implementation and the 
> > measurement code.  The implementation will be synthesizable and the 
> > measurement code will not.  I'm thinking a fairly large FFT, 2048 or 
> > maybe 4096 bins in floating point.
> > 
> > -- 
> > 
> > Rick
> 
> If one knows about the min ppm(1ppm, in this case) in the signal and the sine tone frequency one is measuring, I think taking the phase difference of samples 1e6 samples apart should tell about the timing drift as a result of the timing impurity in the signal. For better estimates, one can calculate this difference over many samples and take its average. 
> ie, 
> phOff = average(angle(x[i]*conj(x[i+1e6])))
> phOffPerSam = phOff/1e6
> ppm = phOffPerSam/2pi ;(freq offset normalized with sampling frequency)
> 
> Assumption is for ideal sine wave of the given freq, x[i] = x[i+1e6] holds true.
> Otherwise, 1e6 should be replaced by min no. of samples greater than 1e6 which ensure the above equality.
> 
> Please correct me if im missing something...

Id like to correct myself a little, 
1e6 is not necessary.
1e6 should be replaced by the periodicity of the sine tone under test.

On Sun, 21 Dec 2014 01:28:00 -0500, rickman wrote:

> A reasonable assumption although I couldn't find info that said that
> reals were double precision (64 bit).  In fact, the info I found said
> they are only assured to be 32 bit, single precision.  Is that wrong?

That's a good point.  It's implementation dependent.

The old version of Modelsim that I have on this computer has this in the 
source for the std library:

	type real is range -1.0E308 to 1.0E308;

which is equivalent to 64 bit "double".  I don't imagine that any 
mainstream compiler would use less than 64 bits for real, but I could be 
wrong.
OTOH, if you know that all the compilers you're using support 64 bit, 
it's probably safe to rely on that.

Regards,
Allan

Am 19.12.2014 15:24, schrieb Tim Wescott:
> No spectrum analyzer in the world has a 240dB dynamic
> range

Hmm, yes analog based on the todays ADC limitations O:(

My PC based spectrum analyser supports more then an 240dB dynamic range, 
while internal calculations are done using double float and even 80 bit 
float O;)

Hp

www.hpw-works.com

On 12/21/2014 1:28 AM, rickman wrote:
<snip>
>
> I understand there are open source
> packages similar to Matlab.  I may try using one of these.
>
<snip>

I've found Scilab (http://www.scilab.org/) to be a very functional and 
well supported alternative to Matlab, at a compelling price point (free).

Am 21.12.2014 um 05:33 schrieb Allan Herriman:
> On Sat, 20 Dec 2014 19:43:33 +0000, glen herrmannsfeldt wrote:
>
>> In comp.dsp Allan Herriman <allanherriman@hotmail.com> wrote:
>
>>> 1.  Generate an "ideal" reference waveform.  Use floating point
>>        (but use it carefully).
>>
>> My choice would be fixed point.
>>
>> With fixed point, you know exactly how the rounding is done, and it is
>> done independent of the size of the values at any point in the
>> computation.  You could, for example, use 64 bit fixed point instead of
>> 64 bit floating point.
>
> Rickman appears to be writing a testbench in VHDL.  If that is the case,
> he already has double precision floating point trig functions built in to
> his simulator (in package ieee.math_real).  To use fixed point would be
> to reimplement and verify the trig functions from scratch - a task that
> is possibly harder than the original problem he is trying to solve.

The test bed for my sine & cos functions on opencores can write
the time series generated by a DDS to a file that could be used
for further processing with matlab or whatever.

There are also functions to convert between float and un/signed
and fractional un/signed. They expect however, that
the floats are higher resolution than the signed vectors, they
will cease to work when one approaches 48 bit or whatever the
size of the mantissa happens to be.

Going via int/natural would be even more limiting (31 bit).

regards, Gerhard

< http://opencores.org/project,sincos >

On 12/21/2014 11:11 AM, Gerhard Hoffmann wrote:
> Am 21.12.2014 um 05:33 schrieb Allan Herriman:
>> On Sat, 20 Dec 2014 19:43:33 +0000, glen herrmannsfeldt wrote:
>>
>>> In comp.dsp Allan Herriman <allanherriman@hotmail.com> wrote:
>>
>>>> 1.  Generate an "ideal" reference waveform.  Use floating point
>>>        (but use it carefully).
>>>
>>> My choice would be fixed point.
>>>
>>> With fixed point, you know exactly how the rounding is done, and it is
>>> done independent of the size of the values at any point in the
>>> computation.  You could, for example, use 64 bit fixed point instead of
>>> 64 bit floating point.
>>
>> Rickman appears to be writing a testbench in VHDL.  If that is the case,
>> he already has double precision floating point trig functions built in to
>> his simulator (in package ieee.math_real).  To use fixed point would be
>> to reimplement and verify the trig functions from scratch - a task that
>> is possibly harder than the original problem he is trying to solve.
>
> The test bed for my sine & cos functions on opencores can write
> the time series generated by a DDS to a file that could be used
> for further processing with matlab or whatever.
>
> There are also functions to convert between float and un/signed
> and fractional un/signed. They expect however, that
> the floats are higher resolution than the signed vectors, they
> will cease to work when one approaches 48 bit or whatever the
> size of the mantissa happens to be.
>
> Going via int/natural would be even more limiting (31 bit).
>
> regards, Gerhard
>
> < http://opencores.org/project,sincos >

Thanks, I'll take a look.  :)

-- 

Rick

On 12/19/14 11:04 PM, Eric Jacobsen wrote:
> On Fri, 19 Dec 2014 18:19:24 -0500, robert bristow-johnson
> <rbj@audioimagination.com>  wrote:
>
>> On 12/19/14 10:06 AM, rickman wrote:
>>> I want to analyze the output of a DDS circuit and am wondering if an FFT
>>> is the best way to do this. I'm mainly concerned with the "close in"
>>> spurs that are often generated by a DDS.
>>
>> i still get the concepts of DDS and NCO mixed up.  what are the differences?
>
> One is spelled DDS and the other is spelled NCO.

is the NCO the typical table-lookup kind (with phase accumulator)?  or 
can it be algorithmic?  like

    y[n]  =  (2*cos(omega_0))*y[n-1]  -  y[n-2]

where omega_0 is the normalized angular frequency of the sinusoid and 
with appropriate initial states, y[-1] and y[-2] to result in the 
amplitude and initial phase desired.

is that an NCO that can be used in this DDS?  or must it be LUT?

anyway, in either case, the oscillator frequency is well defined and i 
don't understand why rickman would just put in a simple sharp notch 
filter tuned to the very same frequency and whack the sinusoid and 
analyze (however he does) what is residual.




-- 

r b-j                  rbj@audioimagination.com

"Imagination is more important than knowledge."

On Sun, 21 Dec 2014 11:03:38 +0000, Allan Herriman wrote:

> On Sun, 21 Dec 2014 01:28:00 -0500, rickman wrote:
> 
>> A reasonable assumption although I couldn't find info that said that
>> reals were double precision (64 bit).  In fact, the info I found said
>> they are only assured to be 32 bit, single precision.  Is that wrong?
> 
> That's a good point.  It's implementation dependent.
> 
> The old version of Modelsim that I have on this computer has this in the
> source for the std library:
> 
> 	type real is range -1.0E308 to 1.0E308;
> 
> which is equivalent to 64 bit "double".  I don't imagine that any
> mainstream compiler would use less than 64 bits for real, but I could be
> wrong.
> OTOH, if you know that all the compilers you're using support 64 bit,
> it's probably safe to rely on that.

If by "compiler" you mean VHDL, I can't speak to that.

However, there are a distressingly large number of C compilers for 8- and 
16-bit machines that use 32-bit floating point even when you call out 
"double".

This just torques me.  While there is every reason for making 
comprehensive libraries that work with 32-bit floating point numbers in 
resource-constrained machines, you don't have to make non-ANSI-compliant 
code to do it.

-- 
www.wescottdesign.com

On Sun, 21 Dec 2014 09:49:42 -0500, chrisabele wrote:

> On 12/21/2014 1:28 AM, rickman wrote:
> <snip>
>>
>> I understand there are open source packages similar to Matlab.  I may
>> try using one of these.
>>
> <snip>
> 
> I've found Scilab (http://www.scilab.org/) to be a very functional and
> well supported alternative to Matlab, at a compelling price point
> (free).

+1 on using Scilab, at least if you were incorrect on your 240dBc 
calculation.  At this point, I would prefer Scilab even if it were priced 
the same as Matlab.  It doesn't have Matlab's bells and whistle's, but it 
does edge Matlab out in git-er-done utility.

-- 
www.wescottdesign.com