Re: [Discuss-gnuradio] Introducing gr-adapt

[Karel]

Hi Marcus,

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

[Discuss-gnuradio] NEWSDR 2018 Videos Have Been Posted

[Neel Pandeya]

The videos for NEWSDR 2018 at WPI have been posted on YouTube.

http://ecewp.ece.wpi.edu/wordpress/sdr-boston/workshops/newsdr-18/

https://www.youtube.com/playlist?list=PLBfTSoOqoRnNcNRe7cFoGPQmi1qKVVnKv

We hope to see you at NEWSDR 2019! The event will tentatively be held at
the University of Massachusetts at Boston in early June. A formal
announcement will be made in the Fall.
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Introducing gr-adapt

[CEL]

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

smime.p7s
Description: S/MIME cryptographic signature
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Remote Control of a Flowgraph

[Dave NotTelling]

If it's just variables that you need to change then you can use the XMLRPC
block.  I've used it in several graphs where I needed up update variables
on the fly.  I'm not sure if the XMLRPC block exposes all variables and
functions in the top block.  I think it's just functions.  The server block
works really easily with Python which is a big win.  Maybe control port
works for the same task?  Haven't really played with it though.

On Wed, Jul 4, 2018 at 3:57 PM mehtap özkan  wrote:

> Dear All,
>  I want to control a Flowgraph remotely from another computer. We have
> found an OOT module called gr-bokeh which is fine for controlling the
> flowgraph from a webpage.
>  Is there another way to control a flowgraph remotely using a stand-alone
> application?
> ___
> 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

[Discuss-gnuradio] Introducing gr-adapt

[Karel]

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

Re: [Discuss-gnuradio] Invalid packets in ofdm_rx example

[Usama Saeed]

Thanks for the reply, Michael. As you said, I found a lot of discussions
about this topic, but no answers as to the solution of the issue.

Some things that I tried to change were the fft length (changed to 128 from
default 64), CRC length (32 to 64) and I changed the constant multiplier
block such that the abs() of the Tx waveform was < 1.0 approximately. All
with no luck, sadly.

On Thu, Jul 5, 2018 at 8:06 PM, Michael Dickens 
wrote:

> Hi Usama - I'm confident that if you searched back through the GR
> discussion archives, you'd find discussions about this topic: <
> https://lists.gnu.org/archive/cgi-bin/namazu.cgi?
> query=header_payload_demux0&submit=Search%21&idxname=
> discuss-gnuradio&max=20&result=normal&sort=score >.
>
> The "Parser returned #f" means that the OFDM header didn't pass CRC, which
> generally means that the "SNR" isn't adequate, but it could mean other
> things too. There are numerous possible issues that you will encounter when
> using GR's OFDM.
>
> * Start with the -default- OFDM settings (e.g., FFT of 128, C/P of 32) and
> see if those work.
>
> * Add a "gain" block immediately after the Tx OFDM block, with settings
> from (say) -10 dB to +10 dB; play around & see what happens on Rx. You'll
> want the Tx OFDM block abs() output to average around sqrt(1/2) or so, but
> less than 1.0; peaks will typically be over 1.0. Get the gain from above
> such that this is the case & you're one step closer. This value decreases
> the chances of saturating the USRP on Tx.
>
> * After you've gotten a stable system working (gain is the key when using
> default OFDM parameters), start playing with other OFDM parameters:
> constellation, FFT length, and so forth --> BUT: one at a time.
>
> * If you find one that doesn't work, reset its values and go to another
> one. If some parameter continues to be stubborn, post back here with your
> progress, tests & actual GRC script asking for help again.
>
> Hope this is useful! - MLD
>
> On Thu, Jul 5, 2018, at 4:57 AM, Usama Saeed wrote:
>
> Hello, this is my first time posting a question:
> I tried using the ofdm_tx and ofdm_rx examples with two USRP B200s, but
> even though I could see the ofdm spectrum on the receiver end, the time
> graph at the end of the demodulation was blank (straight line at 0) and I
> received the error
>
> "gr::log :INFO: header_payload_demux0 - Parser returned #f
> gr::log :INFO: packet_headerparser_b0 - Detected an invalid packet at item
> 6720"
>
> The associated screenshots are posted on this page:
>
> https://dsp.stackexchange.com/questions/50283/why-does-my-
> ofdm-demod-in-gnu-radio-not-return-anything
>
> Thank you for any assistance.
>
> *___*
> 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

[Discuss-gnuradio] [GSoC18] gr-modtool overhaul: Blog Post

[swapnil negi]

Hello everyone, the blog
 post
for the week 8 has been updated with the tasks for the upcoming week. The
GitHub project  has also
been updated.




Regards
Swapnil Negi
Indian Institute of Technology Roorkee
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio