Hi Karel,
wow, this looks interesting! Thank you for that contribution :)
I haven't played around with it yet, just browsed the source code a
tiny bit, and I've got to say: I love this module :)
Things that I'd like to especially point out:
* It's great that you actually have pretty much self-explaining
examples. The idea to have a screenshot of the system-identifying flow
graph in the examples/README.md is great!
* The /python directory, the number of qa tests alone AND the fact that
you're even explaining what you're testing in the Readme: this should
be held as a great example.
* You add a new dependency – armadillo – but instead of just requiring
that globally, you say explicitly what component you mandatorily
require it for, and wherever you use it, you have #ifdefs for the case
that it's not there. That makes it very easy to use your software on
different platforms, only using the functionality that really depends
on armadillo if that's not there, and maybe performance (?).
I think you've just set a bar for well-documented, thoughtfully
designed OOT modules. Congrats!
As a maintainer: We're head over heels in getting next into master to
get our 3.8 release (candidate) with enough advance to GRCon, but it's
my declared goal as maintainer to integrate more OOT functionality into
GNU Radio's main source tree — both in spirits of "coming with
batteries included", and, more importantly to me, avoiding breaking
commonly employed blocks when making changes in the future.
I think a lot of GNU Radio users, from very different fields (from
people actually into academic systems identification / channel
estimation to amateur radio enthusiasts actually trying to do duplex
where formerly simplex was the only possible way to adaptive interferer
suppression etc) are looking at adaptive systems, and GNU Radio can
certainly use more of these. Upstreaming an OOT would always put a
large load on the maintainer, by requiring high standards in testing
and documentation (we need to become better w.r.t. that compared to
what our tree looks like now). I'd argue that at least at first sight,
your module looks like it'd fulfill (and exceed) my criteria for tests
and documentation, so I'd assume that your module stands a good chance
to become part of GNU Radio, if, and only if, you'd want that, as soon
as we can relax a bit after progressing to 3.8, so maybe part of GNU
Radio 3.9 or .10. Would that sound interesting to you?
Best regards,
Marcus
On Sat, 2018-07-07 at 16:52 +0300, Karel wrote:
Hi all,
I've created a GNU Radio out-of-tree module, gr-adapt, that provides
different adaptive filter blocks (LMS, NLMS, and variants of RLS).
I've
included performance and convergence comparisons in the python
folder.
There's also a separate branch which allows to use LMS in filtered-x
configuration. I'm hopeful someone finds it useful.
https://github.com/karel/gr-adapt
Best regards,
karel
_______________________________________________
Discuss-gnuradio mailing list
address@hidden
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio