DDS Spur-Reduction Patent

I'm sorry, what were those references again? I didn't see them.

I have never said the DACs will not cause spurs. This conversation started on how to minimize the close in spurs because they are hard to filter. The close in spurs are mostly generated by phase truncation. I have explained how I got around phase truncation. Now you are trying to say this is not of use since the DACs can't reproduce the full benefit of this improvement.

Really?

You don't know what most DDS use because you are focusing on single chip DDS from chip makers. Most DDS are fully custom, a part of a board design and do not use the chips you are thinking about. I didn't know DDS chips existed (other than a few of the early crude ones) when I was working with DDS in FPGAs where they are common.

I think you are getting mixed up here. You say Solbrig produces sine wave voltages which he feeds to a digital multiplier??? How do you feed analog signals to a digital multiplier? I have not seen any numbers that indicate he reduces spurs to -200 dBc. The patent I read used a DDS which has phase truncation to feed some circuitry to reduce the spurs which then feeds a DDS with no phase truncation. I don't have the author's name handy any more. This did not mention any spur numbers at all.

Someone posted that the term NCO is used for the digital DDS without a DAC. So I will call this an NCO from now on. However, my comment above is about the DAC as well. A DAC will produce harmonic spurs which can be reflected/folded by the sample rate. They will only be close in with poor design.

Yes, some 15 years ago. This technology is a bit dated since other methods are easy to use now and can work as well if not better.

Sure. The good news about doing that sort of band-aid is that the compensating spurs don't need to be generated with the same precision as the original sine wave. Even 8-bit accuracy would get you over 40 dB improvement.

Figuring out exactly what to generate is the trick, of course.

Cheers

Phil Hobbs

You have a very elastic idea of what constitutes evidence.

Cheers

Phil Hobbs

So far I've seen zero evidence of this effect, no analysis other than, "it happens".

Let's outline again what is being claimed... Bill is claiming that the variation in delays from the digital chip to the DAC will have an influence on the spurs of the DAC. This delay consists of the clock distribution path within the digital chip, the FF clock to out delay, routing delays and the delay in the I/O buffers, then the PCB routing delay and the input to FF delay in the DAC. All of this is designed so that the digital inputs to the DAC are within a tolerance so that they never violate the setup and hold time of the DAC. Once in the DAC chip they are clocked into a register.

Are you seriously going to suggest that the delays in the digital chip will have any significant impact on the output of the DAC??? I think this comes under the heading of an "extraordinary" claim which even if not requiring extraordinary evidence, requires *some* evidence.

Has *anyone* ever documented such an effect?

ck

to

ed

ly

To the extent that the power delivery system is outside the chip. What goes on inside the chip is hard to mitigate.

There are propagation delays inside the chip, and they can wander too. They won't be big, but when you talk about spurs 200dB down, you aren't talking about big effect.

It's there - just look at the propagation delay tolerances from clock edge to output in your DAC data sheet. If they aren't there get a better DAC.

nd

at

the

he

he

se

the

Actually I'm more interested in the delay from the DAC clock to the time th e data latched inside the DAC gets to the analog output.

In as far as the clock generation system is built into chips that also carr y the digital data used to feed the DAC (or keep track of phase) you can al so have data-dependent fluctuation in propagation delay, but you should be able to avoid that by careful design.

They shouldn't, but you've managed to misunderstand - or not read - what I' ve actually been saying. The delay from clock input to analog data output i nside the DAC could depend on the latched data being output. It could also vary - probably more - as new data was fed into the input side of the latch in preparation for the next output.

That is not an issue I am discussing. Once the power distribution system meets the DAC supplier spec this is purely a DAC design issue an not relevant to the discussion of the digital device generating the samples for the DAC.

Ok, you are talking about something completely different. I'm not designing DACs, so this is not my design issue.

And it's still only dealing with one non-ideality. Jitter on the clock controlling when the DAC makes its transitions may be another.

He can get the pointy head to perfection. The "signal processing" falls down on the preference for bang-bang (non-linear) phase detectors. That's more "signal bodging".

I don't think this makes much sense. There are two sources of spurs in the generation of the sine samples, one is phase truncation and the other is amplitude quantization. Mitigating phase truncation is not actually too hard. Phase truncation is a result of depending solely on a lookup table which limits the number of the phase bits which can be input to the table. Using more than a few input bits makes the table too large to be realistic. Throw 4 Gwords at it and problem solved, phase generated spurs down around -190 dBc! Otherwise you need to use some other techniques such as interpolation which can achieve similar results.

Amplitude quantization is similar but even easier to deal with. Make your output word 20+ bits wide and your AM related spurs drop to the

-120 dBc ballpark. At this point the limitation on spur generation is the DAC, not the data being fed to the DAC.

You might be able to use a separate DAC to produce a counter spur signal. Once you have optimized the NCO for your DAC word width trying to squeeze a correction into the existing DAC word would be impossible since the DAC word width is the ultimate limit, not the NCO.

That may work ok, but in reality he is attempting to solve the wrong problem. The way he is playing back the signal sample file, he is performing sample rate conversion from the recorded sample rate to 2 MSPS. He should be using sample rate conversion algorithms, not a wave table interpolation kludge.

You may be on to something with this, or not. There is a lot of math to compute how to synthesize the correcting waveform.

nary.JPG

Use Simpsons rule smoothing for 5 point spans. Play with the math you may see why i like it so well. Less math than cubic splines at final value time as well and better matching the the nature of the sine function (all even).

e the data latched inside the DAC gets to the analog output.

carry the digital data used to feed the DAC (or keep track of phase) you ca n also have data-dependent fluctuation in propagation delay, but you should be able to avoid that by careful design.

Everybody else is.

gn

ice

But the spurs on the DAC output are what this thread's about.

t I've actually been saying. The delay from clock input to analog data outp ut inside the DAC could depend on the latched data being output. It could a lso vary - probably more - as new data was fed into the input side of the l atch in preparation for the next output.

But you seem to be designing stuff that outputs to DACs, so maybe you need to broaden your field of view.

Busting a gut to get to 200dB down when the DAC is going to degrade that by about 100dB may not be the best use of resources.

Actually they aren't. This was the first paragraph of the opening post.

The thread was about various means of generating low "close in" spurs which are hard to filter. Someone started talking about the logic delays in the digital NCO affecting the DAC and the conversation went south.

An NCO generates errors in the sine values which may or may not be fed to a DAC. Those errors have nothing to do with the DAC and so can be discussed totally independently.

I already pointed out my mistake that the design I had used was more like -120 dBc. Even so, you seem to keep making the mistaken assumption that sine waves have to be analog. Many circuits, including the one used in the originally discussed patent use NCO generated sine waves digitally without converting them to analog first.

crosstalk between channels can cause differing propgation delays, and when one of the signals is the DAC clock you get jitter.

esign

device

so

ey

hip

ip

hat I've actually been saying. The delay from clock input to analog data ou tput inside the DAC could depend on the latched data being output. It could also vary - probably more - as new data was fed into the input side of the latch in preparation for the next output.

eed to broaden your field of view.

t by about 100dB may not be the best use of resources.

A sine wave is am analog concept. You may have digital representations of a sine wave inside your hardware, but a string of digits isn't a sine wave.

And those digitally generated sine wave have spurs? You might digitise a si ne wave and multiply the digital representation of your digitised sine wave by a digital representation of another sine wave, but the timing issues in your analog-to-digital converter are much the same as those in a DAC.

Isn't that a board level design issue? I can reduce crosstalk to any level you care to spec. So it isn't an issue in a properly designed system.

They're equivalent. A linear N:1 interpolator has an impulse response that ramps up in N samples, and back down in same (1 2 3 4 3 2 1). A cubic spline interpolator has an impulse response that is that linear kernel, convolved with itself. That might not be the optimal filter kernel for the application, but there's nothing magical about it that makes it anything other than an FIR filter.

Now the Farrow filter trick (which is also oddly enough coming up in the Anti-Doppler thread right now) is that you can take that same filter kernel and generate a mathematical approximation of it. Given that approximation, you can rubber-band N to any value you'd like, integer or otherwise, and simply stretch the kernel in time at the output sample rate.

For a cubic spline fit, the mathematical approximation of that filter kernel is exact: it's the math that generated the kernel in the first place. As a result, you get the result that the solution of the cubic spline fit conceived of as a curve fitting operation is the same solution as the Farrow filter, treating each coefficient of the polynomial as an FIR filter on input samples.

That said, even the cubic interpolator winds up with a frequency domain response of sinc^4 Fi/Fo, so the "bouncing ball" still both lets a mess of aliased signal through near the original Nyquist and has an unpleasant amount of passband rolloff. Since this is all locked to the original sample rate, it can be corrected with a fixed 2:1 upsample followed by a fixed FIR filter at the 2*Fi, if one is willing to throw the compute cycles and additional latency at it.

Bingo! Exactly the point! He is looking at the problem from a poor perspective and so is selecting filters that will be very sub-optimal. Larkin knows little about signal processing and feels he is reason it out by treating it as a connect the dots exercise which is not appropriate for this problem.

Too bad a cubic spline is not a very good filter for resampling.

So why bother with the cubic spline in the first place? He is playing back files from a PC. I expect his best approach is to resample on the PC to a high degree of accuracy and play them back with nothing but an anti-alias filer. John knows so little about signal processing that he doesn't understand what is needed and how simple the solution can be.

It doesn't have to be mathematically perfect, it only needs to look good. If it makes a decent looking reproduction of a 250 KHz sine wave, the customer will be delighted.

My linear interpolator was pretty ratty, adding a bunch of AM to the output. Higher-order things will definitely be worth it. No reason to not have a little fun with this one.

I would prefer to keep the time delay down, 2 samples maybe. So zillion-tap FIR filters are not advised.

Ignore Rickman. I do, and my life is incrementally improved.

Except that you are in ignorance of the facts. If you are playing back a 250 kHz sine wave with a 2 MHz sample rate, what is the rate of the samples in your buffer? If they are at 2 MHz you will get very good reproduction without *any* resampling at all. If they are much slower than 1 MHz you will start to have problems with your resampling scheme and of course below 500 kHz sample rate you are below the Nyquist rate and the info will be aliased.

Is this really about playing a 250 kHz tone without resampling?