I'm glad to hear it's interesting to you. I believe that having this
module part of GNU Radio would make it easier to use and I support that.
I look forward to release 3.8!
Best regards,
Karel
On 07/07/2018 06:12 PM, Müller, Marcus (CEL) wrote:
> 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
>> Discuss-gnuradio@gnu.org
>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
_______________________________________________
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
No comments:
Post a Comment