gr-filter: Polyphase Arbitrary Resampler Block filter taps

[basti-schr]

Description

The Polyphase Arbitrary Resampler Block trimmed of the first and last character in taps. Therfore the Example gr-analog/fm_tx.grc failed cpp code generation as described in #6103.

Related Issue

Fixes #6103
Fixes #3638

Which blocks/areas does this affect?

• Polyphase Arbitrary Resampler
• FFT Filter
• Interpolating FIR Filter
• Decimating FIR Filter
• IIR Filter
• Band Pass Filter
• Band Reject Filter
• FFT Low Pass Filter
• Filter Delay (?)
• High Pass Filter
• Low Pass Filter

Testing Done

In the gr-analog fm_tx Example example i run cpp code generation.

Checklist

• I have read the CONTRIBUTING document.
• I have squashed my commits to have one significant change per commit.
• I have signed my commits before making this PR
• My code follows the code style of this project. See GREP1.md.
• I have updated the documentation where necessary.
• I have added tests to cover my changes, and all previous tests pass.

[willcode]

As a guess, this was a way of stripping off [ ] but not sure. Does anyone know of a reason?

[willcode]

@basti-schr We can't change the example to C++, though. Could you remove the changes to the grc file?

[basti-schr]

I noticed this still not works in all cases!
There are two scenarios i tested:

1. As in the example an main: define the Taps in one expression in the Text field.
2. Define a new Low-pass Filter Taps Block and paste the variable name in the Polyphase Arbitrary Resampler Block.

in this version only the second scenario is working.

As i am new to the yaml code i will try to understand this better and try to make it work in both scenarios.

[basti-schr]

Now the block will work for the two scenarios described. I had to manually import the firdes file when defining the filter taps as strings in the resampler block. I would appreciate some feedback as I am new to contributing to gnuradio.

[willcode]

@basti-schr For muliple commits, unless they are meant to be separable, squash to one commit and force push.

[willcode]

Tried this out. I think the [1:-1] was intentional. If the taps are specified for Python, they would be of the form [x0, x1, ...] and the slicing strips the brackets for C++. However, if something like lpf_taps (referencing a separate block) is specified, then it is transformed to pf_tap for C++. We need a solution that handles both of these cases.

I tried Decimating FIR Filter and it does not strip, so variable names work, brackets or raw lists of numbers do not. FFT Filter failed for another reason. Interpolating FIR Filter does strip, so a bracketed list works but a variable name does not. Let's look for some opinions on this and try to make everything work at once.

I would suggest that allowing the user to specify taps the same way for Python and C++ would be good, and Python has always used list format with brackets. Obviously, we shouldn't strip off the beginning and end of variable names.

[basti-schr]

Thank you for taking a look. I tweaked it a bit more so that it now works with a list. But it looks a bit messy and I think there might be a nicer solution.

If you use other filter types, you need to import them as well. However, in my opinion, it would be a bit more of a mess to import all kinds of filters in this template.
But at this point I have much less insight into gnuradio. I thought this might be an easy fix.

[willcode]

That works. Maybe there's a cleaner way, but it now works better than the other blocks.

Do you have any inclination to look through all the other filter blocks that support C++?

[basti-schr]

Yes, I started with the FIR filters as they were quite simple. The other filters have some problems that I need to look at more closely.

I have identified ten more blocks to work on and added them to the comment above as checklist. Do you see another one?
I use this flowchart to check the results: test_filter.grc.txt

I have a question about testing: when installing gnuradio the classic way (cmake .. / make / sudo make install) the modified yaml files are not copied to the /usr/local/share/gnuradio/grc/blocks/ directory. So my solution is to manually copy the *.block.yml files to that location. Is this intended?

[willcode]

The yml blocks should be installed. Make sure you hit the refresh blocks button on GRC (or restart it) after installing so it reads the new yml files.

Have you tested set_taps() in C++? Elsewhere, it always seems to be set_x(${x}), rather than set_x(x). See Add Const for example. I haven't looked at the generated code both ways to see what the difference is.