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: Alexander Chemeris
Subject: Re: [Patch-gnuradio] Re: assert (dac_rate () == 128000000);
Date: Wed, 16 Dec 2009 08:35:00 +0300

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.
>>>
>>
>>
>>
>
>



-- 
Regards,
Alexander Chemeris.




reply via email to

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