GRC taps as parameter in hierarchical block?

GNU Radio
1

Hi list,

I’m looking for a pointer in using GRC when creating a hierarchical
block.

The hierarchical block has an parameter block of type None with ID
‘taps’. The Value of the block is ‘filter.firdes.root_raised_cosine(
nfilts, nfilts, 1.0, 0.35, 11 * samples_per_symbol * nfilts )’. nfilts
and samples_per_symbol are both also parameters. The ‘taps’ parameter
block evaluates properly.

The problem is, when I try to use the value of the ‘taps’ parameter
within a Polyphase Arbitrary Resampler block configured as type ccf
(Complex -> Complex ( Real Taps ) ), it does not evaluate the ‘taps’
parameter. The ‘taps’ field is brown, which obviously means it does
not interpret the field.

Value “taps” cannot be evaluated:
name ‘taps’ is not defined

However, when I use a Variable block for the exact same ‘taps’ value,
the resampler works properly.

Clearly the difference is that, with the variable block, the value is
evaluated at compile time, versus when using a parameter, it must be
compiled … well… later at compile time… or at ‘run time’, if one
could call it that.

My question is, do any of the gurus on the list have a suggestion on
how to ‘cast’ the parameter as a real_vector or something equivalent
to make it usable as a block?

If it matters why I’m doing this, I’d like to make the
generic_mod_demod more generic by allowing the pulse shape filter to
be specified as a parameter… and yes, I’m doing it in GRC rather
than python for a few reasons.

Cheers,

C

2

On Wed, Mar 4, 2015 at 2:54 PM, Christopher F.
[email protected]
wrote:

The problem is, when I try to use the value of the ‘taps’ parameter

generic_mod_demod more generic by allowing the pulse shape filter to
be specified as a parameter… and yes, I’m doing it in GRC rather
than python for a few reasons.

Cheers,

C

This is an interesting problem, and I don’t think that it has anything
to
do with the taps, data types, or the resampler block. I think it’s an
order
of operations issue.

First, the brown color of the field does not indicate that anything is
wrong. It’s just the color used when indicating a list of floats is
expected.

To resolve the issue – not as a real solution just to prove this to
yourself – is to plug in real numbers to the taps line instead of using
nfilts:

‘filter.firdes.root_raised_cosine(32, 32, 1.0, 0.35, 11 * 2 * 32)’

That should work. I just used 32 for nfilts and 2 for
samples_per_symbol.

I think the problem is how and when the parameters are evaluated when
used
in the block. We might have to consult Sebastian on this one.

In the meantime, perhaps using parameters to define other parameters
isn’t
really the right thing to do, anyways. You are setting the default value
based on the default value of another parameter. When actually using the
hier_block in another flowgraph, that nfilts doesn’t propagate through
to
reset the default value of the taps parameter. So I don’t think that
this
would even have the desired behavior you’re looking for.

Maybe just hard-code those numbers in for the defaults and then the
setup
in the flowgraph could change to using the variables set in the
flowgraph,
not the hier_block.

Does this make sense?

Tom

P.S. I don’t know where we came up with the constant 11 for our RRC
filters, but it’s probably overkill. I’d think you can reduce that down
to
5 or so to improve speed and not lose much in performance.

3

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On 03/19/2015 04:26 PM, Tom R. wrote:

In the meantime, perhaps using parameters to define other parameters isn’t
really the right thing to
do, anyways. You are setting the default value based on the default
value of another parameter. When actually using the hier_block in
another flowgraph, that nfilts doesn’t propagate through to reset the
default value of the taps parameter. So I don’t think that this would
even have the desired behavior you’re looking for.

GRC evaluates params in a separate namespace which is then merged with
the one holding variables and imports. While it is trivial to change
that, I must cite with Tom, params should not depend on each other.
However, your taps param should have been marked invalid.

If I understand your scenario correctly you could try one these (no
warranty):

    • if all you need is a default set of taps, use “taps or default_taps”
      in your filter block and set the taps param default to “()”
    • pass a filter generator function into the block. Using
      functools.partial you even preset (some) args (and standardize the call
      signature) in the parent fg and then call it in the filter block
      “taps_generator(param1, param2)”
    • pass the filter design call as a string and eval it. (Ugly)

Sebastian

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1

iQIcBAEBCAAGBQJVC+N9AAoJEIcqoDnyZkMDJOwQAKA7aNlN6J1R3un9wHFzmhld
yqLaPqVtR9S5f2I+GgmvAYSayKU7qdW8/jP6MvW8HzXmAMqwR+4+qC0yASJr+bfy
aQ19gZukxlQ0OTEgJ0Whx2qKQg0as0aIdpd5i08g/vr0Eh4m709cMPPnvkCjR9dG
zMtYkHS9a0WOQHbsgKTkwGUIolFNOvk6jS4UYYYxMJ/YOQgFf3blXgYmYN1YGec5
2k24pEOOLpr+RxhhRjbkItdap+axjijmg9pBDmghPspbHWAtw7z5jW3cAmb1GXUG
qr8WsdU/ALbigLn6KuPvTXEXv1pVzFZFAaOgrciY7McZEOjE3QZH6+KYNoUCak7D
QcuV4GWobvygUeBFmYB4au5f29tT+16KKDZpm+B54M6Oa9WFZ486HRjv1tEYAMcl
Dr1PqDtCbNJ4xsFA4Whf+71tgwY33yij1MkiQiKlAs6r5eu57gR8Xy9JPDxLLojJ
IbwGZKCN1JuZOTmaSjw2DQqLEEZ5QgPqmc9Uda8lnt9qv6Rd4Jbam0CoKraf1ATI
KO2v4aJBWOhSNyIXuwhPoA9P6fPqXeKhkgD7ZwAUQBsYwwsYqfZ6clZyhycGgMw7
2lqnx4ry0l4cxZR+VzXnkMpL0vW15vCdtRaIXZ7YaBtEvFaJCo9sSkax1+rHhCPf
9dF0ETCMhaJDp49innZ6
=FVo6
-----END PGP SIGNATURE-----