Re: [Discuss-gnuradio] GRC taps as parameter in hierarchical block?

[Tom Rondeau]

On Wed, Mar 4, 2015 at 2:54 PM, Christopher Friedt <address@hidden> wrote:

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

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.