Arbitrary resampler question on gnuradio 3.7.2.1

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

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi George,

I can’t really see what should have changed in the c2f / f2c behaviour.
My wild guess is: old (like, quite old) versions of GNU Radio UHD used
to have a 2^16 range, while modern USRP interfaces want samples with
im and re parts in [-1;1].

By the way: why the c2f → f2c thing?

Greetings and happy hacking,
Marcus

On 18.12.2013 03:06, George wrote:

that has to do with USRP transmissions.
Thanks, -George _______________________________________________
Discuss-gnuradio mailing list [email protected]
Discuss-gnuradio Info Page

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.15 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQEcBAEBAgAGBQJSsU6qAAoJEAFxB7BbsDrL3o8H/2Z6UtFG89sHHbBUX8cOa0D1
KKnTrMUWyKL9qPrvFprhM5h7dTZb/FdQFrfhag4MZJcvpbBNg98orf1FqIrMnnDG
r42M//iOJwIpdbc36rG/1Zb+hP4rRQ6H0gMUodjJyLiIH984zSAjaIaAOanJvqQv
i3xti96HzwiJXim41fpDsBvVoDoDV1yJtN+xBw0rclhhqmgzletLqRQyZgTA8ZlF
fAs2GfTGWFovjW+e7FnpW6Et0ZID2FvL/UFibnrsdkohfyUlRKTW74dl7IOVk+ns
rNzSO+azkTHFXWPy+0g8WzVvGD0v3xgoWejg/vHctzt6lrM1fZlKsoUD/uYs+P4=
=z4dM
-----END PGP SIGNATURE-----

On Tue, Dec 17, 2013 at 9:06 PM, George [email protected]
wrote:

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

Tom,

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

Thanks,
-George

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(11spbnfilts))
where nfilts=32, rolloff=0.35 and spb =4

Thanks,
-George

On Wed, Dec 18, 2013 at 7:47 PM, George [email protected]
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

Thanks, got it!

-George