A brief update on the new features added to the filter design tool[1]
–IIR Filter Design (Scipy Based)
-Butterworth
-Elliptic
-Chebyshev-1
-Chebyshev-2
-Bessel
–Pole-zero plot now supports addition, deletion of poles/zeros with
conjugate support.
A small video showing some of the added features can be found here[2].
At first I started using Robert McGwier’s existing code[3] and added
features to that as suggested by Tom and Martin. Later finding that
Scipy’s filter design functions[4] are very much optimized and robust, I
decided to use those. Martin also pointed out that it will just be a
duplication of work and suggested me to use scipy for IIR design.
I did a basic integration of the code to gr-filter component of GNU
Radio[5]. I haven’t pushed icons yet to the branch. It would be really
helpful if anyone can comment on the current integration, so that I can
make suitable modifications.
In next few weeks I will be adding some special filters like half-band
filter to the design tool, then will proceed with integration of
gr_filter_design to GRC and will try to add QA tests for filter design
routines wherever they are missing.
In next few weeks I will be adding some special filters like
half-band filter to the design tool, then will proceed with
integration of gr_filter_design to GRC and will try to add QA tests
for filter design routines wherever they are missing.
Need any help with the GRC integration? I know there was some talk about
creating modules to call into, etc so the hooks into GRC would be
simpler.
In next few weeks I will be adding some special filters like
half-band filter to the design tool, then will proceed with
integration of gr_filter_design to GRC and will try to add QA tests
for filter design routines wherever they are missing.
Need any help with the GRC integration? I know there was some talk about
creating modules to call into, etc so the hooks into GRC would be simpler.
In next few weeks I will be adding some special filters like
half-band filter to the design tool, then will proceed with
integration of gr_filter_design to GRC and will try to add QA tests
for filter design routines wherever they are missing.
Need any help with the GRC integration? I know there was some talk about
creating modules to call into, etc so the hooks into GRC would be simpler.
Let me know.
Thanks!
-josh
Could you please share the discussion link if there is one. You and
Martin already gave me various hints regarding this before. Still if
there is a standard way of doing this, that info will be really helpful.
Could you please share the discussion link if there is one. You and
Martin already gave me various hints regarding this before. Still if
there is a standard way of doing this, that info will be really
helpful.
I didnt mean to imply that there was some kind of formal discussion tool
like a forum thread. I was just referring to these emails:
I think that a new parameter tag would include an import statement and a
function to call. Example:
Taps
taps
[0]
float_vector
from gnuradio.filter import awesome
awesome.function_to_call
I guess the idea would be that GRC adds a gui button the parameter
that will invoke this launcher. It then calls
awesome.function_to_call(current_param_setting) and when the function
returns, the new value is set for the parameter.
Its not the only way to do this but that is one way to solve the
problem in a generic fashion. I think the important part vs the idea you
first purposed is that GRC does not have to know how to execute a
program, it just calls a python function, which is something that it can
easily do.
Once such a launcher is possible, it would not only be nice to add
this to blocks with parameters that take taps. But it would also be nice
to add a new variable block to GRC that simultaneously allows the user
to use this tool, but set its output to a GRC variable. Because I think
that it will be more desirable in certain cases to set the result to a
variable.
Another block idea, how-about a GRC block that instantiates a GUI
element that also calls the filter generation tool and sets the taps in
a callback like fashion. This would give you access to using this tool
in a live/running flowgraph!
I guess the idea would be that GRC adds a gui button the parameter
that will invoke this launcher. It then calls
awesome.function_to_call(current_param_setting) and when the function
returns, the new value is set for the parameter.
Its not the only way to do this but that is one way to solve the
problem in a generic fashion. I think the important part vs the idea you
first purposed is that GRC does not have to know how to execute a
program, it just calls a python function, which is something that it can
easily do.
Ok. I will proceed as you mentioned.
Once such a launcher is possible, it would not only be nice to add
this to blocks with parameters that take taps. But it would also be nice
to add a new variable block to GRC that simultaneously allows the user
to use this tool, but set its output to a GRC variable. Because I think
that it will be more desirable in certain cases to set the result to a
variable.
Another block idea, how-about a GRC block that instantiates a GUI
element that also calls the filter generation tool and sets the taps in
a callback like fashion. This would give you access to using this tool
in a live/running flowgraph!
Let me know what you think,
-josh
Some users may just need fixed taps and some would like change those
during runtime. I haven’t looked into the code for flowgraph creation
and execution of GRC yet, still it seems to be reasonable to give access
to the filter design tool while the flowgraph is running. I will discuss
this with Martin during the next call (I am sure he will see this mail )
and will start GRC integration ASAP. Integrating the tool to GRC will
help me to find more bugs in my code, as many users will actually try
filter design tool. I will try to accomodate all the features that you
suggested.