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

[Tom Rondeau]

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