patch-gnuradio
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Patch-gnuradio] Re: assert (dac_rate () == 128000000);


From: Matt Ettus
Subject: Re: [Patch-gnuradio] Re: assert (dac_rate () == 128000000);
Date: Tue, 15 Dec 2009 21:38:12 -0800
User-agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.4pre) Gecko/20090922 Fedora/3.0-3.9.b4.fc12 Thunderbird/3.0b4


Correct. With nearly all DACs (not just on the USRP) you want to avoid multiples of half of the sample rate. The exception is that some new DACs from Analog Devices (and possibly others) come with a special mode to fix this issue.

Matt

On 12/15/2009 09:35 PM, Alexander Chemeris wrote:
Hi Matt,

So this value should be just scaled with DAC frequency change, right?

On Wed, Dec 16, 2009 at 08:22, Matt Ettus<address@hidden>  wrote:


The reason for the limit is that the DAC outputs have a sin(x)/x rolloff,
which puts a big null around multiples of 1/2 of the sampling frequency.
  Thus, 44-84 MHz is not really very useful.

Matt

On 12/12/2009 07:54 AM, Alexander Chemeris wrote:

Hi Erik,

Could you give me some insight why high value is set to 44e6?
Coarse modulator can be set to 128e6/4=32e6 and docs says
that fine modulation has range of 128e6/4=32e6 too. Thus it should
be possible to get as much as 32e6+32e6=64e6 offset. Was 44e6
chosen because of interpolation filtering limits or smth like that?


On Sat, Dec 5, 2009 at 17:34, Eric Blossom<address@hidden>    wrote:

On Thu, Dec 03, 2009 at 12:09:02AM +0300, Alexander Chemeris wrote:

Hi all,

Anyone to apply this one-liner?

Alexander,

The hard-coded magic numbers below the assert need to be corrected to
to be a function of the clock rate.  You're not seeing the problem
because of the daughterboard you're using, but if you're using a Basic
Tx, they come into play.

The existing magic numbers are particular percentages of 128e6.
The replacements, f(clock_rate), should be the same percentages.
They control when and which "coarse modulator" is used in the AD9862.

Can you please submit a slightly bigger patch?

I apologize for not writing earlier about what the problem was.

Thanks,
Eric


On Tue, Nov 3, 2009 at 01:01, Alexander Chemeris
<address@hidden>    wrote:

Hi all,

This assert is not valid, because you may use re-clocked USRP.
And we indeed do ;)

Patch to remove it is in attachment.

--
Regards,
Alexander Chemeris.














reply via email to

[Prev in Thread] Current Thread [Next in Thread]