GRCON21: Proposal Submission and Survey are Live!

[Morman, Joshua]

Greetings GNU Radio Community!


The proposal submission system for GRCON 2021 is now live here 
(https://events.gnuradio.org/event/8/abstracts/) - and the first round of 
submissions are open through 9 June.  Please submit abstracts for your talks, 
papers, posters, lightning talks, workshops, for any work or topic that would 
benefit the SDR community.


Note: The determination of whether the event will run in-person will be made 
some time in April 2021, but we are gathering information in two ways to help 
with that decision:

1) There is a survey here (https://events.gnuradio.org/event/8/surveys/2) for 
us to gather information about all potential attendees plans for in-person vs 
remote attendance - whether you plan to present or not.
2) When submitting an abstract, please indicate your preference/plans for 
in-person vs remote attendance so we can gather this info specifically for the 
participants.


Sam has put together a step by step guide for how to use our new submission 
system (thanks to Andrej for setting this all up)

https://events.gnuradio.org/event/8/page/1-submission-instructions

Looking forward to seeing another amazing round of talks, papers, posters, and 
other ideas from our wonderful community!

Sincerely,
The GRCON21 Organizers



**


We are gearing up for GNU Radio Conference 2021, which will be held September 
20-24, 2021. GRCon 2021 celebrates and showcases the substantial and remarkable 
progress of GNU Radio and its usage in a diverse field of applications and 
industries.  It is a week-long conference that includes high-quality technical 
content and valuable networking opportunities. GRCon is a venue that highlights 
design, implementation, and theory that has been practically applied in a 
useful way. GRCon attendees come from a large variety of backgrounds, including 
industry, academia, government, and hobbyists.


GRCon21 is fully setup to run in-person in Charlotte, North Carolina. However 
with COVID still a significant concern the decision of whether to confirm that 
setup or move entirely online will not be made until April. This will be the 
next major breakpoint where the organizing committee will evaluate on the 
current conditions and make decisions on what is safe and sensible. In either 
case the main track talks will be livestreamed similar to GRCon20.

If in-person, Charlotte, NC - the home of NASCAR, is the perfect location to 
focus on the theme of SPEED: processing high rate high throughput data with GNU 
Radio and showcase many of the high performance platforms and applications that 
have been developed across our community.  To find out more about Charlotte, 
including venue information, please visit here: 
https://www.gnuradio.org/grcon/grcon21/charlotte

*** We invite developers and users from across the GNU Radio Community to 
present your projects, presentations, papers, posters, and problems at GNU 
Radio Conference 2021, so start thinking about what great work you would like 
to present at this year’s conference. ***  The proposal submission system will 
be up and running March 5th.


To sign up for email updates to find out about key upcoming decisions and dates 
(submissions, registrations, virtual vs in-person) - please pre-register here:  
 https://tickets.gnuradio.org/grcon21/

Key Dates

  *   March 5 - Open for Submissions
  *   April - Evaluation of in-person or purely online
  *   April - Start of ticket sales
  *   June 9 - 1st Round of Submissions closes
  *   August 2 - Main track schedule posted
  *   September 20 - Conference starts

Looking forward to another amazing conference!

Sincerely,
The GRCON21 Organizers

GNU Radio Conference 2021 - Call for Participation

[Morman, Joshua]

Greetings GNU Radio Community!


We are gearing up for GNU Radio Conference 2021, which will be held September 
20-24, 2021. GRCon 2021 celebrates and showcases the substantial and remarkable 
progress of GNU Radio and its usage in a diverse field of applications and 
industries.  It is a week-long conference that includes high-quality technical 
content and valuable networking opportunities. GRCon is a venue that highlights 
design, implementation, and theory that has been practically applied in a 
useful way. GRCon attendees come from a large variety of backgrounds, including 
industry, academia, government, and hobbyists.


GRCon21 is fully setup to run in-person in Charlotte, North Carolina. However 
with COVID still a significant concern the decision of whether to confirm that 
setup or move entirely online will not be made until April. This will be the 
next major breakpoint where the organizing committee will evaluate on the 
current conditions and make decisions on what is safe and sensible. In either 
case the main track talks will be livestreamed similar to GRCon20.

If in-person, Charlotte, NC - the home of NASCAR, is the perfect location to 
focus on the theme of SPEED: processing high rate high throughput data with GNU 
Radio and showcase many of the high performance platforms and applications that 
have been developed across our community.  To find out more about Charlotte, 
including venue information, please visit here: 
https://www.gnuradio.org/grcon/grcon21/charlotte

*** We invite developers and users from across the GNU Radio Community to 
present your projects, presentations, papers, posters, and problems at GNU 
Radio Conference 2021, so start thinking about what great work you would like 
to present at this year’s conference. ***  The proposal submission system will 
be up and running March 5th.


To sign up for email updates to find out about key upcoming decisions and dates 
(submissions, registrations, virtual vs in-person) - please pre-register here:  
 https://tickets.gnuradio.org/grcon21/

Key Dates

  *   March 5 - Open for Submissions
  *   April - Evaluation of in-person or purely online
  *   April - Start of ticket sales
  *   June 9 - 1st Round of Submissions closes
  *   August 2 - Main track schedule posted
  *   September 20 - Conference starts

Looking forward to another amazing conference!

Sincerely,
The GRCON21 Organizers

Re: [announcement] master: SWIG -> Pybind11 (breaks OOT interface)

[Morman, Joshua]

Thank you Marcus for the merge, the introduction, and the warnings :)

For all the Ubuntu users - the GNU Radio Master PPA has been updated with 
builds pulled from the latest master, so it now includes the pybind11 bindings, 
and OOTs will need to start migrating to the new python binding structure.  
Only install from this PPA if you want to test the latest master branch and get 
your OOTs ready for 3.9 
(https://wiki.gnuradio.org/index.php/GNU_Radio_3.9_OOT_Module_Porting_Guide). 
Otherwise, it is better to stay with the gnuradio-releases PPA.   Here is the 
PPA info for master:


sudo add-apt-repository ppa:gnuradio/gnuradio-master
sudo apt-get update
sudo apt-get install gnuradio

Fedora COPR is not yet up to date, but I will let everyone know when that 
supports the current master branch with pybind11.

Josh



From: Marcus Müller mailto:mmuel...@gnuradio.org>>
Date: Thu, Jun 18, 2020 at 2:59 PM
Subject: [announcement] master: SWIG -> Pybind11 (breaks OOT interface)
To: Gnuradio Mailing List 
mailto:discuss-gnuradio@gnu.org>>


Hello, most prolific SDR community to wander this wide globe,

TL;DR: brace yourself. If you're on master, we'll be breaking your OOT.
You don't have to worry about anything if you're using GNU Radio 3.8.

We're close to merging the pybind branch into master – and that means
we're improving things a lot.

Formerly, we used SWIG to generate Python bindings for GNU Radio's C++
classes – a decision made much more than a decade ago[1], when it still
wasn't clear that Python would be the only language we support (SWIG can
generate wrappers for *a lot* of languages).

In what it does, SWIG is pretty impressive: give it some C++ header, and
it will generate the correct binding for python, including generating of
some mapper types, transparent handling of pointers etc. And, we've
really been using it a lot and in a lot of complex usage scenarios. I
honestly think that, together with OpenCV and LLDB, we really might be
the healthiest and largest project to use SWIG in such a wide way. I'm
very thankful SWIG exists!

Now, having said that, SWIG was always kind of a pain to work into our
source tree. The promise of "throwing in unmodified C++ headers, getting
out perfect Python bindings", far too often, turned out to be "after
massaging these headers quite a bit, then adding a bit of SWIG
directives here and there in swig .i files that we have to keep updated
whenever we change header structure"; and every time something broke our
SWIG bindings, be it a bug on our side or an unexpected change in SWIG
semantics, or be it that SWIG stubbornly refuses to use the include
paths we specify on some platforms, we sunk literal working days into
getting things fixed.

So, as awesome as SWIG's automatism are, using it on such a type-diverse
code base, with such a platform-diverse user community, was kind of
liable for a lot of time not spent on developing a better SDR framework,
but fixing tooling.

Thus, Josh took it upon himself to get this sorted out – and replace
SWIG with Pybind11. Now, Pybind11 is pretty different from SWIG. It's
actually pure C++11 code, and just compiles with standard compilers. No
extra tooling required.

It does come at the expense of you having to declare your interface
yourself. That sounds like a regression, but honestly, there's been so
much work put into making this automateable by Josh, for most blocks
that don't do anything "special", you can just let the automatism take
over. If that doesn't work, you'll typically get a compiler error,
telling you exactly what's wrong. To illustrate, I'll attach the code
generated to wrap a simple block below[2].

However, what that means is that we're also changing the way OOTs need
to wrap their C++ to Python so that they can still can work with GNU
Radio C++ objects wrapped to Python. gr_modtool has been updated to have
new stubs, and the aforementioned automatism is available, too. Small
problem: unlike compilation, the code generation does need an extra bit
of tooling, pygccxml to be specific. This is really only necessary when
you wrap a block that's not been wrapped before, not when compiling any
existing module or the GNU Radio source tree.

In terms of compile time: according to my current level of overview, for
proper multicore machines, building the many smaller C++ files tends to
be a bit faster than first running SWIG to generate 100kLOC-files and
then compile these monsters. For single- or dualcore machines, the
opposite tends to be true. It's my duty to remind you that compiling on
a RaspberryPi itself might get even more cumbersome than it currently
is, and that you should prefer the cross-building toolchains of the
operating system you're running on the embedded platform rather than
building directly on it. Especially debian makes that pretty easy.

Best regards,
and the happiest of hacking,

Marcus

[1]

No more Swig - GR with Pybind11 BETA Testers Needed!!

[Morman, Joshua]

Hello GR Community,


You may remember from previous emails and the developer calls that one of the 
key features for the next major GNU Radio release is removing SWIG from the 
codebase and replacing it with pybind11 to handle the python API bindings.  
This will have some very positive impacts on the codebase:

- One less giant dependency

- Faster/less memory usage during compile

- Less cryptic auto-generated code

- More deliberate binding of the API


I've just pushed a rebased version to the "pybind" branch of the main GNU Radio 
github - and we're ready to have more people try it out and work out any major 
kinks before we merge it onto master.

https://github.com/gnuradio/gnuradio/tree/pybind


A little primer of how it works here:  
https://github.com/gnuradio/gnuradio/blob/pybind/docs/PYBIND11.md


What you should be able to do at this point:

- Run GNU Radio flowgraphs using in-tree blocks

- Create an OOT using gr_modtool (add, bind)


What is known to not be working:

- ctrlport, video-sdl have not yet been given bindings

- Modtool commands beyond add and bind (rm, info, update, disable)

- Some of the qa tests and grc examples are failing, but I'm working through 
those issues (and could use help here as well)

- Some other issues and general status tracked here:  
https://github.com/gnuradio/gnuradio/projects/6


Please give it a shot if you have the time!  Help here is much appreciated.


Feedback about the general approach should be directed toward the GREP:

https://github.com/gnuradio/greps/blob/master/grep-0015-remove-swig.md


Feedback about issues encountered can be handled in the github issue tracker, 
just please be clear that this is the pybind branch


Thanks!

Josh

Re: gnuradio 3.8 errors with gr_modtool

[Morman, Joshua]

Hi Laura,


Thank you for raising this issue.  Maitland pinged me offline with the fixes he 
did on this issue in the Debian packages which are basically copied into the 
PPAs you are using with minor modifications.


I have now applied his fixes (and updated the ppa packages to the recent RC 
release), so the ppa cleans the byte compiled code from the installation for 
Ubuntu >= 19.  For Ubuntu 18 the issue still remains.


For Ubuntu 18 - navigate to /usr/share/gnuradio/modtool/templates/gr-newmod/

and run

sudo py3clean .


This should clean the files that are causing issue.



Josh


-- Forwarded message -
From: Laura Arjona mailto:arjo...@uw.edu>>
Date: Tue, Feb 25, 2020 at 5:25 PM
Subject: Re: gnuradio 3.8 errors with gr_modtool
To: Maitland Bottoms mailto:aa...@amrad.org>>
Cc: GNURadio Discussion List 
mailto:discuss-gnuradio@gnu.org>>


just in case, I removed the only .pyc file I found under 
/usr/share/gnuradio/modtool/templates/gr-newmod/python/__pycache
/usr/share/gnuradio/modtool/templates/gr-newmod/python/__pycache__$   sudo rm 
*pyc

The same error occurs.

Thank you!

On Tue, Feb 25, 2020 at 2:17 PM Laura Arjona 
mailto:arjo...@uw.edu>> wrote:
Thank you Maitland.
Is there a "safer" way of installing gnuradio 3.8?

Matiland - there is not such a folder in /modtool/gr-newmod.
I only have /usr/share/gnuradio/modtool/template

On Tue, Feb 25, 2020 at 1:13 PM Maitland Bottoms 
mailto:aa...@amrad.org>> wrote:
Laura Arjona mailto:arjo...@uw.edu>> writes:

> 1 - Installed fresh Ubuntu 18.04.4 LTS
> 2- Installed git, cmake, swig, gnuradio.
> To install gnuradio, I used:
>   $ sudo add-apt-repository ppa:gnuradio/gnuradio-releases
>$ sudo apt-get update
>$ sudo apt-get install gnuradio
>
At this point you have .pyc files where they do not belong, since as of
just now the ppa packages are still buggy.

You can
 `sudo rm /usr/share/gnuradio/modtool/gr-newmod/python/*pyc`
and get on with life.

Hopefully the ppa packegs will be fixed soon...

-Maitland


--
Laura Arjona
Washington Research Foundation Innovation Postdoctoral Fellow in 
Neuroengineering

Paul G. Allen School of Computer Science & Engineering
185 E Stevens Way NE
University of Washington
Seattle, WA 98195-2350


--
Laura Arjona
Washington Research Foundation Innovation Postdoctoral Fellow in 
Neuroengineering

Paul G. Allen School of Computer Science & Engineering
185 E Stevens Way NE
University of Washington
Seattle, WA 98195-2350

GNU Radio Transition from SWIG to pybind11 - looking for community involvement

[Morman, Joshua]

Hi All,


As was discussed on the project call yesterday, we are in the process of 
migrating away from SWIG for binding the C++ API into python.  This brings the 
following advantages:

- One less giant dependency

- Faster/less memory usage during compile

- Less cryptic auto-generated code

- More deliberate binding of the API


There are of course tradeoffs, and one of the downsides of moving away from 
SWIG, is that SWIG mostly automates the step of C++ header to compiled binding 
code conversion.  Both Boost.python and pybind11 require bindings to be written 
manually - it is this workflow where we need to focus effort so creating these 
bindings is as seamless as possible.


What I'm seeking involvement from the community is for is the following:

1) Feedback on the general approach

-  We should be having discussion about larger features such as these using the 
GREP (GNU Radio Enhancement Process) mechanism, which lives in github, for this 
specific feature as GREP0015:

https://github.com/gnuradio/greps/blob/master/grep-0015-remove-swig.md


More updated information about the current approach is proposed in this pull 
request:

https://github.com/gnuradio/greps/pull/24

So, feel free to comment, suggest ideas, concerns directly on the pull request 
(or via the mailing list if you are so inclined)


2) Tools for automating the workflow

- The current approach follows the pyuhd code structure and leverages the block 
header parsing tool developed by Arpit G. as a GSoC project for generating the 
binding code

- Needs further integration into modtool, cmake, whatever other mechanisms make 
for a smooth experience

- Especially needs to be as little overhead as possible for OOT transitions to 
the new mechanism


3) Building out GR module tree and updating OOTs (once key design decisions are 
solidified)

- I have pushed forward with making binding code for some of the larger modules

- Mainly to determine feasibility, and find gotchas - there are definitely 
improvements in compile time and memory utilization

- But it will be important to build out these bindings using the tools 
developed in (2)


The current work effort lives on my fork - pybind11 branch:

https://github.com/mormj/gnuradio/tree/pybind11

And I have tried to track progress, issues and improvement opportunities here:



https://github.com/mormj/gnuradio/projects/1


If you are interested in getting involved in this effort, please email me back 
here, or on slack @mormj


Thanks!

Josh

Re: [EXTERNAL] Re: GNU Radio PPA packages for Ubuntu Available

[Morman, Joshua]

Achilleas,


I have added 3.7 Releases to a separate PPA to host the latest 3.7 release 
(currently 3.7.13.5)

sudo add-apt-repository ppa:gnuradio/gnuradio-releases-3.7
sudo apt-get update


Please let me know if you run into any issues with this.


Thanks,

Josh


From: Achilleas Anastasopoulos 
Sent: Thursday, November 7, 2019 1:18 PM
To: Morman, Joshua
Subject: [EXTERNAL] Re: GNU Radio PPA packages for Ubuntu Available

Yes, so I was wondering if 3.7.13.4 can be made available for 18.04 as well.
I am used to installing everything from scratch but my experience is that this
is a substantial hurdle for students and also some of my colleagues who just 
want to try it...

best
Achilleas


> Apt comes up with 3.7.11 for both Ubuntu 16.04 and 18.04, and 3.7.13.4 for 
> 19.04

Re: GNU Radio PPA packages for Ubuntu Available

[Morman, Joshua]

Apt comes up with 3.7.11 for both Ubuntu 16.04 and 18.04, and 3.7.13.4 for 19.04


From: Müller, Marcus (CEL) 
Sent: Wednesday, November 6, 2019 2:02 PM
To: anas...@umich.edu; Morman, Joshua; discuss-gnuradio@gnu.org
Subject: [EXTERNAL] Re: GNU Radio PPA packages for Ubuntu Available

Correct me, but that's exactly the version that is currently in Ubuntu,
anyways?
On Wed, 2019-11-06 at 11:06 -0500, Achilleas Anastasopoulos wrote:
> Great work!
>
> So is there a package for the latest pre-8.0 version, say 3.7.14 or 
> 3.7.maintenance?
>
> thanks
> Achilleas

Re: [EXTERNAL] Re: GNU Radio PPA packages for Ubuntu Available

[Morman, Joshua]

Not currently - but I can pull it together either as a separate PPA, or in the 
same Releases PPA

Josh


From: Achilleas Anastasopoulos 
Sent: Wednesday, November 6, 2019 11:06 AM
To: Morman, Joshua; Discuss-gnuradio@gnu.org
Subject: [EXTERNAL] Re: GNU Radio PPA packages for Ubuntu Available

Great work!

So is there a package for the latest pre-8.0 version, say 3.7.14 or 
3.7.maintenance?

thanks
Achilleas

Re: [EXTERNAL] Re: Using function from OOT in another OOT

[Morman, Joshua]

Michael,


Thank you for the response.  Here is what I ended up doing:


If I have gr-myoot that I want to reference from gr-anotheroot


In gr-anotheroot/cmake/modules, create FindMyoot.cmake, which should look 
something like:




find_package(PkgConfig)
pkg_check_modules(PC_GNURADIO_RUNTIME gnuradio-runtime)

find_path(MYOOT_INCLUDE_DIR myoot/one_of_the_header_files.h
  HINTS ${PC_GNURADIO_RUNTIME_INCLUDEDIR} 
${PC_GNURADIO_RUNTIME_INCLUDE_DIRS}
  PATH_SUFFIXES myoot )

find_library(MYOOT_LIBRARY NAMES gnuradio-myoot
 HINTS ${PC_GNURADIO_RUNTIME_LIBDIR} 
${PC_GNURADIO_RUNTIME_LIBRARY_DIRS} )

include(FindPackageHandleStandardArgs)
# handle the QUIETLY and REQUIRED arguments and set MYOOT_FOUND to TRUE
# if all listed variables are TRUE
find_package_handle_standard_args(Myoot  DEFAULT_MSG
  MYOOT_LIBRARY MYOOT_INCLUDE_DIR)

mark_as_advanced(MYOOT_INCLUDE_DIR MYOOT_LIBRARY )

set(MYOOT_LIBRARIES ${MYOOT_LIBRARY} )
set(MYOOT_INCLUDE_DIRS ${MYOOT_INCLUDE_DIR} )


I'm sure there are better ways to do this, but this did the trick quick and 
dirty.  It looks like some other oots have .pc files installed which help with 
the process, but that doesn't look to be standard.




Josh


From: Michael Dickens 
Sent: Tuesday, November 5, 2019 2:14 PM
To: Morman, Joshua
Cc: discuss-gnuradio@gnu.org
Subject: [EXTERNAL] Re: Using function from OOT in another OOT

Hi Josh - I don't think there's a standard way to do this. -Most- OOTs install 
cmake scripts that can be used to "find" them, if you can determine the correct 
"find" name (might be "gr-OOT" or just "OOT", where 'OOT' is the name of the 
OOT module). Once found, you can then use either the target or returned 
variables (OOT_INCLUDE_DIRS, OOT_LIBRARIES most likely) to find the API and 
link against the ABI. Nothing special, but generic enough that it should work 
on different OSs & GR installs. Hope this is useful! - MLD

On Tue, Nov 5, 2019 at 1:42 PM Morman, Joshua 
mailto:jmor...@perspectalabs.com>> wrote:

Is there a prescribed method for including functions from one OOT in another 
OOT (c++ code)?


I could probably figure out how to do it in cmake, but is there some magical 
cmake find functions that already exist for OOTs to set the INCLUDE and LIBRARY 
variables relative to the GR prefix installation?


Thanks,

Josh


--
Michael Dickens
Ettus Research Technical Support
Email: supp...@ettus.com<mailto:supp...@ettus.com>
Web: https://ettus.com/ 
[ettus.com]<https://urldefense.proofpoint.com/v2/url?u=https-3A__ettus.com_=DwMFaQ=YC-d702opsuYKpiO2Bmlzg=-OttVOCFItYdAESKCAf54UYYCHv8xssKxCxab-nx5UA=Ef8z0W0VV0FJhO2Gi19L14SAnThIphzjnqAAgdGLv5k=2fWh96T2ZIoLHJl2x4asongRKo1Yc2zpJZUxPNTtzfc=>

Using function from OOT in another OOT

[Morman, Joshua]

Is there a prescribed method for including functions from one OOT in another 
OOT (c++ code)?


I could probably figure out how to do it in cmake, but is there some magical 
cmake find functions that already exist for OOTs to set the INCLUDE and LIBRARY 
variables relative to the GR prefix installation?


Thanks,

Josh

GNU Radio PPA packages for Ubuntu Available

[Morman, Joshua]

Hello - as mentioned on the last developers call, we have been working towards 
putting together Ubuntu packages for gnuradio (based on Maitland's Debian 
packaging) so that the latest and greatest can be installed more easily without 
having to compile from source.


Currently there are two separate PPAs


1) GNU Radio - Releases

Builds that have been tagged and officially released.  Currently this includes 
the 3.8.0.0 release from August.

sudo add-apt-repository ppa:gnuradio/gnuradio-releases
sudo apt-get update

2) GNU Radio - Master

Builds from the master branch.  The intent is to make this the output of 
weekly/nightly builds.

sudo add-apt-repository ppa:gnuradio/gnuradio-master
sudo apt-get update


Once the repository is added, simply

sudo apt-get install gnuradio

Currently these only include packages for bionic (Ubuntu 18.04) and disco 
(Ubuntu 19.04) but I am working towards getting Fedora packages up and running 
as well through COPR.  Please let me know if you run into any issues or have 
questions.



Thanks,

Josh Morman