discuss-gnuradio
[Top][All Lists]
Advanced

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

Re: [Discuss-gnuradio] Arbitrary resampler question on gnuradio 3.7.2.1


From: George
Subject: Re: [Discuss-gnuradio] Arbitrary resampler question on gnuradio 3.7.2.1
Date: Thu, 19 Dec 2013 17:59:04 -0500

Thanks, got it!

-George


On Dec 19, 2013, at 9:21 AM, Tom Rondeau <address@hidden> wrote:

> On Wed, Dec 18, 2013 at 7:47 PM, George <address@hidden> wrote:
>> Tom,
>> 
>> Is there going to be a fix soon or should I go with the 3.6.5 version of 
>> gnuradio?
>> 
>> Thanks,
>> -George
> 
> George,
> 
> The patch was pushed last night. I will make it into the next bug
> release, which will probably be in a month, plus or minus. In the
> meantime, you can get the patch by looking at commit
> b3b8a1f4965f8283f2c3d22ae45b569b2fe6d713
> 
> Tom
> 
> 
> 
>> On Dec 18, 2013, at 7:01 PM, George <address@hidden> wrote:
>> 
>>> Hi Tom,
>>> 
>>> You are right increasing the number of taps by 100 is not the case, after I 
>>> debugged the results a bit more.
>>> The problem seems to be in the number of samples consumed as you mentioned 
>>> above.
>>> 
>>> The full definition for the filter I am using is
>>> firdes.root_raised_cosine(nfilts, 1.0, 1.0/nfilts, rolloff, 
>>> int(11*spb*nfilts))
>>> where nfilts=32, rolloff=0.35 and spb =4
>>> 
>>> Thanks,
>>> -George
>>> 
>>> On Dec 18, 2013, at 5:54 PM, Tom Rondeau <address@hidden> wrote:
>>> 
>>>> On Tue, Dec 17, 2013 at 9:06 PM, George <address@hidden> wrote:
>>>>> Hello all,
>>>>> 
>>>>> Considering a simple gnuradio flowgraph as the following
>>>>> 
>>>>> Random source -> chunks2symbols -> complex2float -> float2complex -> 
>>>>> pfb_arb_resampler-> USRP sink
>>>>> 
>>>>> which used to work without any problem in the older gnuradio 
>>>>> distributions, in the newer 3.7.2.1 seems that the conversion above (from 
>>>>> complex to float and float to complex) introduces a problem, that has to 
>>>>> do with USRP transmissions.
>>>>> 
>>>>> However, when I increased the number of taps used for the root raised 
>>>>> cosine filter in pfb_arb_resampler by a factor of 100, everything seems 
>>>>> to work properly.
>>>>> 
>>>>> Note that if the conversions float2complex and complex2float miss 
>>>>> everything works.
>>>>> 
>>>>> Any ideas why?
>>>>> 
>>>>> Thanks,
>>>>> -George
>>>> 
>>>> Bug it the pfb_arb_resampler. I was trying to be too conscientious
>>>> about calls to work but made an assumption in the forecast function
>>>> that's not always correct. I'm testing a few things out, still, but I
>>>> should push this fix soon.
>>>> 
>>>> Still, your behavior of the filter length (increasing it by 100, that
>>>> is) doesn't fit with what I'm seeing. What's the full filter
>>>> definition you're using for the block?
>>>> 
>>>> Tom
>>> 
>> 




reply via email to

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