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 <t...@trondeau.com> wrote: > On Tue, Dec 17, 2013 at 9:06 PM, George <george.sklivani...@gmail.com> 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 _______________________________________________ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
