[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: |
Wed, 18 Dec 2013 19:01:34 -0500 |
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