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

[George]

Tom, 

Is there going to be a fix soon or should I go with the 3.6.5 version of 
gnuradio?

Thanks,
-George

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
>