# GRC taps as parameter in hierarchical block? **URL:** \ **Category:** GNU Radio\ **Created:** [March 4, 2015, 8:56pm UTC](https://www.ruby-forum.com/t/grc-taps-as-parameter-in-hierarchical-block/234443 "2015-03-04T20:56:35Z")\ **Posts on this page:** 3\ **Page:** 1
**Author:** ![addis\_a](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/a/c4cdca/32.png) [@addis\_a](https://www.ruby-forum.com/u/addis_a)\ **Post date:** [March 4, 2015, 8:56pm UTC](https://www.ruby-forum.com/t/grc-taps-as-parameter-in-hierarchical-block/234443/1 "2015-03-04T20:56:35Z")
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 ---
**Author:** ![christophrost](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/c/a3d4f5/32.png) [@christophrost](https://www.ruby-forum.com/u/christophrost)\ **Post date:** [March 19, 2015, 4:28pm UTC](https://www.ruby-forum.com/t/grc-taps-as-parameter-in-hierarchical-block/234443/2 "2015-03-19T16:28:36Z")
On Wed, Mar 4, 2015 at 2:54 PM, Christopher F. [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) 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. ---
**Author:** ![christophrost](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/c/a3d4f5/32.png) [@christophrost](https://www.ruby-forum.com/u/christophrost)\ **Post date:** [March 20, 2015, 10:10am UTC](https://www.ruby-forum.com/t/grc-taps-as-parameter-in-hierarchical-block/234443/3 "2015-03-20T10:10:02Z")
-----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-----