GRCon24 Schedule Updates

[Josh Morman (GNU Radio)]

With GRCon less than 2 weeks away, we wanted to provide a few updates -
please take a look at the entire schedule as things may have changed since
you last checked it out!
https://events.gnuradio.org/event/24/timetable/#all.detailed

1) Thursday 10AM: Dr. Ralph Steinhagen from GSI-FAIR is going to present
the current development status of* GNU Radio 4.0 *as it is being used at
the FAIR particle accelerator, and outline the features that will enable
future high performance SDR applications.  There will also be a breakout
Q&A session/workshop that will enable us to go into more detail on specific
aspects of the development.

2) Wednesday 10AM: We have added a new workshop to the schedule - *Basics
of SDR*, led by Paul Comitz, PhD from the University of South Carolina,
Beaufort.  This will provide an overview of SDR and a solid entrypoint into
GNU Radio.

3) Wednesday 10AM: NI/Ettus is again presenting their *RFNoC workshop*
which has been very popular in past GRCons.  This workshop provides a
tutorial on the RFNoC framework, including a discussion on its design and
capabilities, demonstrations of several practical examples, and a
walk-through of implementing a user-defined RFNoC Block and integrating it
into both UHD and GNU Radio.

Of course, check out the rest of the program which is full of exciting
keynotes, talks, and workshops, and we look forward to seeing you at the
event!
tickets.gnuradio.org/grcon24
gnuradio.org/grcon24

Sincerely,
GRCon24 Organizers

GRCon24 Schedule, Keynotes, and Registration

[Josh Morman (GNU Radio)]

Greetings!

GRCon24 registration is underway - https://tickets.gnuradio.org/grcon24.
We have an amazing lineup of talks, keynote speakers, workshops, and
networking events.  Please register now to avoid a price increase coming up
after Aug. 29.  Registering early also helps us significantly in planning
the event.

*Our Keynotes:
(https://events.gnuradio.org/event/24/page/147-keynote-speakers
<https://events.gnuradio.org/event/24/page/147-keynote-speakers>)*
We are deeply honored to welcome our keynote and invited speakers this year:

*Tuesday: Jack Dongarra* - Pioneer in High Performance Computation and
mathematical software (https://en.wikipedia.org/wiki/Jack_Dongarra)
*Wednesday: Shahriar Sharamian* -Director of the Communication & Sensing
ASICs Research Group at Noka Bell Laboratories
*Thursday: Philip Erickson* - Director of MIT's Haystack Observatory and a
Principal Research Scientist at MIT.
*Friday: Kristina Collins* - Space Science Institute and HamSCI

We also have invited workshops from *Dan Boeschen* throughout the week -
Dan is a contributor to DSPRelated.com <https://dsprelated.com/> and Signal
Processing Stack Exchange <https://dsp.stackexchange.com/>, and is
currently at Microchip leading design efforts for advanced frequency and
time solutions.

Additionally, we have an invited talk from *John Moss*, who serves as the
RF Systems WBS Manager (L2) for the Proton Power Upgrade and the RF Systems
Group Leader for the Accelerator Systems section in the Research
Accelerator Division at Oak Ridge National Labs.

The full schedule is posted:
https://events.gnuradio.org/event/24/timetable/#all.detailed

Look forward to seeing you all there!

Josh Morman

GRCon'24 Updates!! Schedule, Keynotes

[Josh Morman (GNU Radio)]

Lots of exciting news about GRCon24 - get all the information
gnuradio.org/grcon24
Registration is open and tickets are available tickets.gnuradio.org

- The Schedule of talks and workshops has been posted.  More information
will be sent directly to presenters with more information about details.
- I want to highlight our Keynote Speakers (Jack Dongarra, Shahriar
Sharamian, Philip Erickson) as well as our invited workshop host, Dan
Boschen, who will be presenting two workshops on signal processing topics.

As always we are grateful to our sponsors, without whom we would not be
able to run this event.  If you would like to join us as a sponsor, please
see the information here
,
or contact us at spon...@gnuradio.org.

*Keynote and Invited Speakers:*

*Tuesday:* *Jack Dongarra*
Jack Dongarra received a Bachelor of Science in Mathematics from Chicago
State University in 1972 and a Master of Science in Computer Science from
the Illinois Institute of Technology in 1973. He received his Ph.D. in
Applied Mathematics from the University of New Mexico in 1980. He worked at
the Argonne National Laboratory until 1989, becoming a senior scientist. He
now holds an appointment as University Distinguished Professor of Computer
Science in the Electrical Engineering and Computer Science Department at
the University of Tennessee and holds the title of Distinguished Research
Staff in the Computer Science and Mathematics Division at Oak Ridge
National Laboratory (ORNL); Turing Fellow at Manchester University; an
Adjunct Professor in the Computer Science Department at Rice University. He
is the director of the Innovative Computing Laboratory at the University of
Tennessee. He is also the director of the Center for Information Technology
Research at the University of Tennessee which coordinates and facilitates
IT research efforts at the University.

*Wednesday: Shahriar Shahramian*
Shahriar Shahramian (SM ’06) received his Ph.D. degree from University of
Toronto in 2010 where he focused on the design of mm-wave data converters
and transceivers. Shahriar has been with the Bell Laboratories – Nokia
since 2009 and is currently the Director of the Communication & Sensing
ASICs Research Group. He is also the chair of the mm-Wave & THz
subcommittee of IEEE BCICTS and member of the technical program committee
of IEEE RFIC & ISSCC. He is also a guest Editor of the IEEE Journal of
Solid-State Circuits (JSSC). His research focus includes the design of
mm-wave wireless and wireline integrated circuits and systems. Shahriar is
a Bell Labs Fellow and leads the design and architecture of several
state-of-the-art ASICs for optical coherent and wireless backhaul products.

Shahriar has been the recipient of Ontario Graduate Scholarship, University
of Toronto Fellowship and the best paper award at the CSICS Symposium in
2005, 2015 and RFIC Symposium in 2015, 2020 and ISSCC in 2018. He holds an
Adjunct Associate Professor position at Columbia University, has received
several teaching awards and is the founder and host of The Signal Path
educational video series.

*Thursday: Philip Erickson*
Philip Erickson is director of MIT's Haystack Observatory and a Principal
Research Scientist at MIT. MIT Haystack is a multi-disciplinary radio and
radar observatory, conducting fundamental research for a variety of
sponsors in the fields of radio astronomy, geospace/near-Earth space, very
long baseline interferometry, and geodesy. Techniques pioneered at Haystack
include active and passive radio-based experiments and data analysis using
a variety of remote sensing approaches involving ground- and space-based
data. Phil's background concentrates on the experimental techniques, signal
processing, and first-principles physics of near-Earth ionospheric
(charged) and thermospheric (neutral) remote sensing using high power large
aperture radars, software radars and software radio architectures, and
plasma physics. Phil also is a co-director of the education and public
outreach efforts at MIT Haystack, spanning undergraduate research programs,
graduate student interactions, K–12 classroom units and outreach, and
public Observatory tours and lectures. He has an electrical engineering
background and received a PhD in space plasma physics from Cornell
University in 1998.

*Invited Workshops: Dan Boschen*
Dan Boschen has an MSEE degree in Communications and Signal Processing from
Northeastern University, with over 25 years of experience in system and
hardware design for radio transceivers and modems. He has held various
positions at Signal Technologies (acquired by Crane), MITRE, Airvana
(acquired by CommScope) and Hittite Microwave (acquired by Analog Devices)
designing and developing transceiver hardware from baseband to antenna for
wireless communications systems, and has taught popular courses on DSP for
over 15 years. Dan is a contributor to DSPRelated.com
 and Signal 

LAST CHANCE - GRCon24 Abstract Submission ENDS TODAY

[Josh Morman (GNU Radio)]

One final reminder that the Abstract Submission window for GRCon24 closes
today (23:59 EDT).

gnuradio.org/grcon24

If you have any issues, please contact us gr...@gnuradio.org.

Thanks!
Josh


On Tue, Jul 2, 2024 at 11:12 AM Josh Morman (GNU Radio) <
jmor...@gnuradio.org> wrote:

> Just a quick reminder that our Call for Participation Abstract Deadline
> submission has been extended to
> *July 8 [Monday] - less than 1 week away.*
>
> If you thought you missed it but have a great project or idea for a
> presentation/workshop/poster/tutorial - go ahead and submit your abstract
> by *July 8*
>
> All the information is at
> gnuradio.org/grcon24
>
> And of course registration is open as well:
> tickets.gnuradio.org
> We have some especially exciting keynote speakers and workshops already
> planned for this year's event, as well as evening socials.
>
> Look forward to seeing everyone there!
>
> Sincerely,
> The GRCon24 Organizing Committee
>

LAST CHANCE - GRCon24 Abstracts Due July 8

[Josh Morman (GNU Radio)]

Just a quick reminder that our Call for Participation Abstract Deadline
submission has been extended to
*July 8 [Monday] - less than 1 week away.*

If you thought you missed it but have a great project or idea for a
presentation/workshop/poster/tutorial - go ahead and submit your abstract
by *July 8*

All the information is at
gnuradio.org/grcon24

And of course registration is open as well:
tickets.gnuradio.org
We have some especially exciting keynote speakers and workshops already
planned for this year's event, as well as evening socials.

Look forward to seeing everyone there!

Sincerely,
The GRCon24 Organizing Committee

May 2024 GNU Radio Project Update

[Josh Morman (GNU Radio)]

Hi GR Community!

Sorry for the long delay on a project update call on YouTube - but we just
posted our latest set of news and updates.

https://www.youtube.com/watch?v=GGKL-dGAfcw

Highlights include:
*EVENTS:*
- EU GR Days, Darmstadt, Germany, August 27-31 (*CfP Deadline June 1*)
- GRCon24, Knoxville, TN, Sept 16-20 (*Abstract Deadline June 17*)
- RADAR 2024, Rennes, France, 21-25 Oct (Best Open Source Experiment Award
category co-sponsored by GNU Radio project)
*RELEASES:*
- 3.10.9.2 in Ubuntu 24.04 LTS
- 3.10.10 - latest which includes gnruradio-companion --qt
- Volk 3.1.1 and 3.1.2
*DEVELOPMENT*
- Work continues in several key areas under the ARDC grant
*OTHER UPDATES*
- LGPL licensing of GR4 Core
- Public Money / Public Code Initiative
- Website refresh - gnuradio.org
- Users of GNU Radio - Logos on main page


Looking forward to hearing your feedback and seeing you out at our
conferences and community events!

Josh

Re: Simulation halts using repeat block in GRC with a picture and the grc file.

[Josh Morman (GNU Radio)]

This is because the Time Sink is assuming the two streams are coming in at
the same rate, but the repeat block increases the number of samples by a
factor of 4.  So the input buffer of the first input will be starved and
the simulation will hang.  You can fix this by using 2 separate
time/frequency sink blocks instead of ones with 2 inputs.

Josh

On Sun, May 5, 2024 at 3:03 PM tom sutherland  wrote:

> I am trying to use a repeat block to increase the number of samples per
> bit of a data source. It only runs once if the repeat number is anything
> but 1. I have a attached a simple example of my code.
> Thanks...Tom
>
> [image: Inline image]
>
>

Re: Python Bindings Out of Sync: Which files are out of sync?

[Josh Morman]

When cmake is run, it does an md5 hash on the public header files and makes
sure the value matches what is written in *_python.cc
Even a single character change in the .h file will disturb the hash and
require a rebinding.  If you are sure that you don't want to rebind, then
you can call:
gr_modtool bind -u blockname
This will only update the hash and not regenerate the *_python.cc file

Ignoring these errors via a cmake flag would be possible, but it is not
implemented currently.


On Fri, Jan 5, 2024 at 8:14 AM Glen Langston 
wrote:

> Thanks Josh for your quick response.
>
> I’ve written c++ code for gnuradio successfully before.   I’m not
> sure what is different about this, very simple, code.
>
> What does “out of sync” mean specifically?   I’ve got the same calling
> arguments in both files, modulo the different programming styles for
> python and c++.
>
> Is there an “ignore this error” flag in “cmake”?
>
> Thanks
>
> Glen
> > On Jan 4, 2024, at 4:52 PM, Josh Morman  wrote:
> >
> > Hi Glen,
> >
> > The file that is out of sync is
> > vsum_python.cc
> >
> > This can be updated using
> > gr_modtool bind vsum
> >
> > This ensures that changes in vsum.h are reflected in the python bindings.
> >
> > Josh
> >
> > On Thu, Jan 4, 2024 at 2:05 PM Glen Langston 
> wrote:
> > Hello
> >
> > I’m running gnuradio 3.9.x and am writing a couple simple C++ blocks.
> >
> > in ~/test/lib
> >
> > I have vsum_impl.cc <http://vsum_impl.cc/> and vsum_impl.h
> >
> > In ~/test/python/radio_astro/bindings
> >
> > I have vsum.h
> >
> > I get these messages in the build “make ..” step:
> >
> > ...
> > -- PYTHON and GRC components are enabled
> > -- Python checking for pygccxml - not found
> > -- Found PythonLibs: /usr/lib/aarch64-linux-gnu/libpython3.9.so
> > -- Performing Test HAS_FLTO
> > -- Performing Test HAS_FLTO - Success
> > -- Found pybind11: /usr/include (found version "2.6.2" )
> > CMake Error at /usr/local/lib/cmake/gnuradio/GrPybind.cmake:221
> (message):
> >   Python bindings for vsum.h are out of sync
> > Call Stack (most recent call first):
> >   python/radio_astro/bindings/CMakeLists.txt:39 (GR_PYBIND_MAKE_OOT)
> >
> >
> > -- Configuring incomplete, errors occurred!
> > See also
> "/home/radioastro/Research/gr-radio_astro/build/CMakeFiles/CMakeOutput.log".
> > See also
> "/home/radioastro/Research/gr-radio_astro/build/CMakeFiles/CMakeError.log".
> >
> > Could someone remind me exactly which files are “out of sync”?
> >
> > vsum.h must be one, but which is the other?   I think that vsum_impl.h
> and vsum.h are consistent
> > (but not, of course, identical).
> >
> > Thanks!
> >
> > Glen
> >
> >
> >
> > > On Dec 30, 2023, at 8:16 AM, Marcus Müller 
> wrote:
> > >
> > > Heyo Kimmo,
> > > sorry for the delayed response:
> > > On 29.12.23 01:00, Kimmo Lehtinen wrote:
> > >> I would like to make modifications to the following two GNURadio
> blocks:
> > >> 1) QT GUI number sink---
> > >> I would like to modify it so that it can also display integers and
> strings. Currently it can display floats, shorts and bytes.
> > >> I raised an issue about this at the Github page of GNURadio, and I
> got the following reply:"A number of GR blocks infer type from item size,
> and that's what this block does (in its constructor). Unfortunately, float
> and int32 are the same size, so int32 is not usable.It would be possible to
> add another constructor that uses an explicit type instead of item size."
> > > Warning: this is probably more involved than you hoped for. If you've
> worked with C++ before: No problem, you can at any point always ask for
> help. It's also super helpful to use "Draft PR" on github to share your
> current state of affairs!
> > > If you haven't: I think this might be a bit too hard.
> > > Yep, you would need to copy the make function as declared in
> number_sink.h in [0]:
> > > static sptr make(size_t itemsize,
> > >  float average = 0,
> > >  graph_t graph_type = NUM_GRAPH_HORIZ,
> > >  int nconnections = 1,
> > >  QWidget* parent = NULL);
> > >
> > > to a second make function that has a different signature, for example
> > > static sptr make(item_type_t itemtype,
> > > 

Re: Python Bindings Out of Sync: Which files are out of sync?

[Josh Morman]

Hi Glen,

The file that is out of sync is
vsum_python.cc

This can be updated using
gr_modtool bind vsum

This ensures that changes in vsum.h are reflected in the python bindings.

Josh

On Thu, Jan 4, 2024 at 2:05 PM Glen Langston 
wrote:

> Hello
>
> I’m running gnuradio 3.9.x and am writing a couple simple C++ blocks.
>
> in ~/test/lib
>
> I have vsum_impl.cc  and vsum_impl.h
>
> In ~/test/python/radio_astro/bindings
>
> I have vsum.h
>
> I get these messages in the build “make ..” step:
>
> ...
> -- PYTHON and GRC components are enabled
> -- Python checking for pygccxml - not found
> -- Found PythonLibs: /usr/lib/aarch64-linux-gnu/libpython3.9.so
> -- Performing Test HAS_FLTO
> -- Performing Test HAS_FLTO - Success
> -- Found pybind11: /usr/include (found version "2.6.2" )
> CMake Error at /usr/local/lib/cmake/gnuradio/GrPybind.cmake:221 (message):
>   Python bindings for vsum.h are out of sync
> Call Stack (most recent call first):
>   python/radio_astro/bindings/CMakeLists.txt:39 (GR_PYBIND_MAKE_OOT)
>
>
> -- Configuring incomplete, errors occurred!
> See also
> "/home/radioastro/Research/gr-radio_astro/build/CMakeFiles/CMakeOutput.log".
> See also
> "/home/radioastro/Research/gr-radio_astro/build/CMakeFiles/CMakeError.log".
>
> Could someone remind me exactly which files are “out of sync”?
>
> vsum.h must be one, but which is the other?   I think that vsum_impl.h and
> vsum.h are consistent
> (but not, of course, identical).
>
> Thanks!
>
> Glen
>
>
>
> > On Dec 30, 2023, at 8:16 AM, Marcus Müller 
> wrote:
> >
> > Heyo Kimmo,
> > sorry for the delayed response:
> > On 29.12.23 01:00, Kimmo Lehtinen wrote:
> >> I would like to make modifications to the following two GNURadio blocks:
> >> 1) QT GUI number sink---
> >> I would like to modify it so that it can also display integers and
> strings. Currently it can display floats, shorts and bytes.
> >> I raised an issue about this at the Github page of GNURadio, and I got
> the following reply:"A number of GR blocks infer type from item size, and
> that's what this block does (in its constructor). Unfortunately, float and
> int32 are the same size, so int32 is not usable.It would be possible to add
> another constructor that uses an explicit type instead of item size."
> > Warning: this is probably more involved than you hoped for. If you've
> worked with C++ before: No problem, you can at any point always ask for
> help. It's also super helpful to use "Draft PR" on github to share your
> current state of affairs!
> > If you haven't: I think this might be a bit too hard.
> > Yep, you would need to copy the make function as declared in
> number_sink.h in [0]:
> > static sptr make(size_t itemsize,
> >  float average = 0,
> >  graph_t graph_type = NUM_GRAPH_HORIZ,
> >  int nconnections = 1,
> >  QWidget* parent = NULL);
> >
> > to a second make function that has a different signature, for example
> > static sptr make(item_type_t itemtype,
> >  float average = 0,
> >  graph_t graph_type = NUM_GRAPH_HORIZ,
> >  int nconnections = 1,
> >  QWidget* parent = NULL);
> > where item_type_t is a "Scoped enum"/class enum [1]; something like,
> within number_sink class,
> > enum class item_type_t { FLOAT, INT32 , INT16, INT8 }; // or whatever
> types you want to support
> > Then you would actually need to implement that in number_sink_impl.cc
> like [2]. But for that you need to modify the actual constructor to not
> take size_t itemsize as argument [3], but item_type_t itemtype!
> > You would add a field const item_type_t d_itemtype and remove d_itemsize
> in number_sink_impl.h [4] and add it to the initializer list [5]; you'd
> want a switch()/case construct to set the alignment_multiple [6].
> > Then, you replace the switch (d_itemsize) in get_item [7] with an
> appropriate switch(d_itemtype).
> > Test it successfully compiles!
> > Now you only need to do two things to
> gr-qtgui/python/qtgui/bindings/number_sink_python.cc
> > • add the new class enum item_type_t to bind_number_sink [8],
> > • add the new make function:
> > • modify the existing definition and
> > • copy it to replace size_t itemsize with
> number_sink::item_type_t itemtype
> > In detail: following [9], you need to change
> > py::class_ >gr::sync_block,
> >gr::block,
> >gr::basic_block,
> >std::shared_ptr>(m, "number_sink",
> D(number_sink))
> >
> > .def(py::init(&number_sink::make),
> > ………
> >
> > into
> > py::class_ >gr::sync_block,
> >gr::block,
> >gr::basic_block,
> >std::shared_ptr>
> > number_sink_wrapper(m, "number_sink", D(number_sink));
> >
> > py::enum_(number_sink_wrapper,
> "item_ty

Survey regarding Open Source Licensing of GR 4.0

[Josh Morman]

A quick follow up on one topic that was presented in the Q4 Project Update
video:

Tl;dr - the core of the code being merged as “GR 4.0” is LGPL.  We want
your opinion on how this will impact you and if further action is needed
for licensing considerations.  Please submit your feedback here:


https://forms.gle/u7PjYGhzfrshkngd9

Look forward to your responses.


Thanks,

Josh

—--

As has been widely discussed, the upcoming major version of GNU Radio, GR
4.0, is based on a new codebase developed by the team at GSI-FAIR and is
being migrated into the GNU Radio GitHub Repository.  Apart from the vast
and promising changes of this major revision, the code being migrated is
currently licensed as LGPL, which means that there are different
ramifications than the entirety of GNU Radio 3.x being GPLv3.  The plan is
that blocks ported over with IP from GR3 (apart from very trivial blocks)
will remain in modules that are licensed as GPLv3.  So for the vast
majority of GNU Radio use cases, the situation for derived works of
flowgraphs using signal processing blocks will not change.



But with the core (base classes and schedulers) being LGPL, this allows
derived works to link with GR, but have a different license.  Source
changes to the core GR codebase would still need to be provided to those
receiving any derived works.  This could enable the following situations:

   1.

   A GNU Radio user could create an OOT not bound by GPLv3 - so long as the
   OOT does not link against any of the GR GPL code (e.g. gr-filter or
   gr-digital)
   1.

  The OOT could not be distributed in binary form if it is built
  against GPLv3 modules without the artifact being licensed as GPLv3
  2.

  Realistically, this would limit non-GPL usage of GR4 OOTs in
  flowgraphs to custom blocks that have been licensed accordingly
  2.

   An application such as a graphical frontend linking to GR4 under the
   hood could be created under a non-GPL license


Note: The above is not legal guidance to any users of this codebase, but a
statement of a licensing change compared to previous GNU Radio revisions.
Each user should consult counsel where needed to understand their own usage

Links:

https://github.com/fair-acc/graph-prototype

https://events.gnuradio.org/event/21/contributions/390/

GRCon24 Announcement - Sept 16-20, Knoxville [Save the Date!]

[Josh Morman]

Greetings GNU Radio Community!

We are excited to announce that GNU Radio Conference 2024 (GRCon24) will be
run as an in-person event September 16*-20 at the Knoxville Convention
Center in downtown Knoxville, TN .

GRCon24 will celebrate and showcase the substantial and remarkable progress
of GNU Radio and its usage in a diverse field of applications and
industries.  It is a 4 day conference (Main Track Tues-Fri)  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.  Even though the main track will start on Tuesday Sept. 17, this
year we are planning a “soft start” to the conference with various hands-on
activities on Monday afternoon/evening, such as beginner tutorials and
in-person help installing and getting started using GNU Radio.


Preliminary details about the event for participants and attendees are
available on the event website here: 
https://events.gnuradio.org/event/24/, but please go ahead and start
thinking about what great work you would like to present at this year’s
conference - the Call for Participation will be opening soon..

If you have questions or would like to find out more about becoming one of
our valued sponsors please contact us at gr...@gnuradio.org.  Note that
this event can only be successful because of our sponsors - please see the
sponsors  that
made GRCon23 possible.

Since GRCon is run by a group of volunteers, we are also looking for people
to help with both the planning of and assisting during the event. If you
are interested in volunteering in any capacity, please reach out to us
gr...@gnuradio.org

Sincerely,

The GRCon24 Organizers

GNU Radio Q4 2023 Project Update

[Josh Morman]

Hello GNU Radio Community -

Lots of project updates posted the other day in our video update on YouTube:
https://www.youtube.com/watch?v=gyGcB-xODxQ

Have a look/listen when you get a chance - some exciting announcements in
there as well.

0:00  Introduction (Josh)
0:33  3.10 Releases
(Jeff)
11:00  Volk Update
(Jeff)
13:00  ARDC Grant
Updates (Derek)
17:45  GRC
Enhancements Overview (Hakon)
22:35  GRC
Enhancements Demo (Hakon)
33:10  ARDC Installer
Improvements Plan (Derek)
35:08  Dr. Gajjar's
Radio SETI Curriculum (Derek)
37:00  GNU Radio 4.0
Update (Josh)
39:20  GNU Radio 4.0
Licensing Plan/LGPL (Josh)
42:50  GRCon23
Reflection (Josh + Derek)
48:35  GRCon24
Announcement- in Knoxville on Sept 16-20! (Josh)
52:15  FOSDEM'24 - SDR
track and GNU Radio Booth - Feb 4 in Brussels (Derek)
53:45  GNU Radio
Hackfest in May'24 at Hat Creek Radio Observ. in CA (Derek)
56:25  European GNU
Radio Days '24, Aug 27-30 in Germany (Josh + Derek)
1:03:00  How to get
involved in GNU Radio leadership (Josh)


Josh

Re: GRCon23 Registration Reminder: Aug 18 begins late registration

[Josh Morman]

One last reminder that prices go up AFTER TOMORROW.

Please register today if you have not already done so

Look forward to seeing you all there!

Josh

On Thu, Aug 10, 2023 at 9:39 AM Josh Morman  wrote:

> Hello GNU Radio Community,
>
> Just a reminder if you plan on attending GRCon23 in Tempe, AZ that regular
> registration prices are only in effect until *Aug. 17* - so go ahead and
> register if you have not already.  Starting Aug 18, prices go up by $100.
> Registering early also helps us out tremendously in the planning process.
>
> All registration info is here:
> https://events.gnuradio.org/event/21/page/99-registration-info
>
> And, tickets can be purchased here:
> https://tickets.gnuradio.org/grcon23/
>
> Thanks!
> GRCon23 Organizing Committee
>

GRCon23 Registration Reminder: Aug 18 begins late registration

[Josh Morman]

Hello GNU Radio Community,

Just a reminder if you plan on attending GRCon23 in Tempe, AZ that regular
registration prices are only in effect until *Aug. 17* - so go ahead and
register if you have not already.  Starting Aug 18, prices go up by $100.
Registering early also helps us out tremendously in the planning process.

All registration info is here:
https://events.gnuradio.org/event/21/page/99-registration-info

And, tickets can be purchased here:
https://tickets.gnuradio.org/grcon23/

Thanks!
GRCon23 Organizing Committee

[GRCon'23] - Abstract Submission Deadline TODAY - 23 June!

[Josh Morman]

Reminder that the deadline for abstract submission is *today* 23 June

Things to consider if you are the fence about submitting:
* There is no minimum length for the abstract, and it can be updated after
the deadline if necessary - just a basic description of what you plan to
present.
* We accept submissions on a broad range of topics related to software
radio, or of interest to the software radio community - not just GNU Radio
specifically.
* If you cannot attend in person, consider submitting a paper, they are
published openly at pubs.gnuradio.org and indexed by Google Scholar

Please let me know if you have any questions.

Looking forward to meeting you all in Tempe in September.

Josh

On Fri, Jun 9, 2023 at 3:36 PM Josh Morman  wrote:

> Just a quick update that our Call for Participation Abstract Deadline
> submission has been extended to *June 23rd.*
>
> If you thought you missed it but have a great project or idea for a
> presentation/workshop/poster/tutorial - go ahead and submit your abstract
> by *June 23*
>
> https://events.gnuradio.org/event/21/abstracts/
> https://gnuradio.org/grcon23
>
> And of course registration is open as well:
> tickets.gnuradio.org
>
> Look forward to seeing everyone there!
>
> Josh
>
>
>
> On Fri, May 12, 2023 at 5:30 AM Marcus Müller 
> wrote:
>
>> Dear Community,
>>
>> GRCon'23 is happening in early September this year – so our submission
>> deadlines are a bit
>> tighter than usual.
>>
>> Submission for talks, papers, workshops, and other contributions are
>> accepted through the
>> GRCon'23 website:
>>
>> https://events.gnuradio.org/event/21/abstracts/
>>
>> This call for participation closes on 5 June 2022!
>>
>> A tiny bit about the GNU Radio conference:
>>
>> GRCon is GNU Radio's annual conference, being held in changing cities in
>> the U.S., and
>> also live-streamed and chat-interacted online. Watching the main track
>> online and
>> interacting with the audience and speakers via chat are free.
>> Registration for the
>> in-person event started in March.
>>
>> GRCon'23 happens 5 – 9 September in Tempe, Arizona at ASU.
>>
>> What GRCon offers is a main track of presentations with topics on GNU
>> Radio, applications
>> of SDR / high-rate signal processing, computational radio science,
>> scientific and industry
>> developments, policy and technological breakthroughs.
>>
>> Next to that, there's tutorials on specific topics, a poster session,
>> Special Interest
>> Groups and the developer's summit, which is the get-together for the
>> project developers.
>> Oh, and of course, there's social events, happening at local highlight
>> locations.
>>
>> If you have *any* question (and I mean that – we're trying to make GRCon
>> as accommodating
>> as possible) about GRCon, be it about attendance, online participation,
>> content submission
>> or other problems related to the conference, we want you to reach out:
>> Here on the mailing
>> list, on the chat (https://chat.gnuradio.org), or in a private email to
>> the GRCon
>> organizers (gr...@gnuradio.org).
>>
>> Now, clearly, this all requires significant funds to set up – with a
>> history of more than
>> 300 in-person attendees prior to COVID (last year's in-person attendance
>> was around 200
>> attendees), and the live video streams achieving 3900 views last year,
>> there's a large
>> responsibility to organize a smooth conference and offer an excellent
>> in-person and remote
>> experience.
>>
>> As in previous years, we do not intend to push all these costs onto the
>> attendees alone
>> (this year's tickets are cheaper than last year!); instead, it has proven
>> mutually
>> advantageous to have sponsors contribute to the conference, and be
>> present in various
>> forms to the audience. If your company is interested in reaching a
>> high-profile, technical
>> and social audience, please do see
>> https://events.gnuradio.org/event/21/page/106-sponsorship-opportunities
>> and reach out to
>> spon...@gnuradio.org .
>>
>> Best regards, and: see you in person in Arizona or online in September,
>> Marcus
>>
>>

[GRCon'23] [Deadline Extended] Call for Participation for the GNU Radio Conference 2023

[Josh Morman]

Just a quick update that our Call for Participation Abstract Deadline
submission has been extended to *June 23rd.*

If you thought you missed it but have a great project or idea for a
presentation/workshop/poster/tutorial - go ahead and submit your abstract
by *June 23*

https://events.gnuradio.org/event/21/abstracts/
https://gnuradio.org/grcon23

And of course registration is open as well:
tickets.gnuradio.org

Look forward to seeing everyone there!

Josh



On Fri, May 12, 2023 at 5:30 AM Marcus Müller  wrote:

> Dear Community,
>
> GRCon'23 is happening in early September this year – so our submission
> deadlines are a bit
> tighter than usual.
>
> Submission for talks, papers, workshops, and other contributions are
> accepted through the
> GRCon'23 website:
>
> https://events.gnuradio.org/event/21/abstracts/
>
> This call for participation closes on 5 June 2022!
>
> A tiny bit about the GNU Radio conference:
>
> GRCon is GNU Radio's annual conference, being held in changing cities in
> the U.S., and
> also live-streamed and chat-interacted online. Watching the main track
> online and
> interacting with the audience and speakers via chat are free. Registration
> for the
> in-person event started in March.
>
> GRCon'23 happens 5 – 9 September in Tempe, Arizona at ASU.
>
> What GRCon offers is a main track of presentations with topics on GNU
> Radio, applications
> of SDR / high-rate signal processing, computational radio science,
> scientific and industry
> developments, policy and technological breakthroughs.
>
> Next to that, there's tutorials on specific topics, a poster session,
> Special Interest
> Groups and the developer's summit, which is the get-together for the
> project developers.
> Oh, and of course, there's social events, happening at local highlight
> locations.
>
> If you have *any* question (and I mean that – we're trying to make GRCon
> as accommodating
> as possible) about GRCon, be it about attendance, online participation,
> content submission
> or other problems related to the conference, we want you to reach out:
> Here on the mailing
> list, on the chat (https://chat.gnuradio.org), or in a private email to
> the GRCon
> organizers (gr...@gnuradio.org).
>
> Now, clearly, this all requires significant funds to set up – with a
> history of more than
> 300 in-person attendees prior to COVID (last year's in-person attendance
> was around 200
> attendees), and the live video streams achieving 3900 views last year,
> there's a large
> responsibility to organize a smooth conference and offer an excellent
> in-person and remote
> experience.
>
> As in previous years, we do not intend to push all these costs onto the
> attendees alone
> (this year's tickets are cheaper than last year!); instead, it has proven
> mutually
> advantageous to have sponsors contribute to the conference, and be present
> in various
> forms to the audience. If your company is interested in reaching a
> high-profile, technical
> and social audience, please do see
> https://events.gnuradio.org/event/21/page/106-sponsorship-opportunities
> and reach out to
> spon...@gnuradio.org .
>
> Best regards, and: see you in person in Arizona or online in September,
> Marcus
>
>

Re: [GRCon'23] Call for Participation for the GNU Radio Conference 2023

[Josh Morman]

*Reminder:*  The abstract submission date (June 5) for GRCon23 is less than
a week away!

Please submit your ideas for technical talks, workshops, posters here:

https://events.gnuradio.org/event/21/abstracts/

Thanks!
Josh


On Fri, May 12, 2023 at 5:30 AM Marcus Müller  wrote:

> Dear Community,
>
> GRCon'23 is happening in early September this year – so our submission
> deadlines are a bit
> tighter than usual.
>
> Submission for talks, papers, workshops, and other contributions are
> accepted through the
> GRCon'23 website:
>
> https://events.gnuradio.org/event/21/abstracts/
>
> This call for participation closes on 5 June 2022!
>
> A tiny bit about the GNU Radio conference:
>
> GRCon is GNU Radio's annual conference, being held in changing cities in
> the U.S., and
> also live-streamed and chat-interacted online. Watching the main track
> online and
> interacting with the audience and speakers via chat are free. Registration
> for the
> in-person event started in March.
>
> GRCon'23 happens 5 – 9 September in Tempe, Arizona at ASU.
>
> What GRCon offers is a main track of presentations with topics on GNU
> Radio, applications
> of SDR / high-rate signal processing, computational radio science,
> scientific and industry
> developments, policy and technological breakthroughs.
>
> Next to that, there's tutorials on specific topics, a poster session,
> Special Interest
> Groups and the developer's summit, which is the get-together for the
> project developers.
> Oh, and of course, there's social events, happening at local highlight
> locations.
>
> If you have *any* question (and I mean that – we're trying to make GRCon
> as accommodating
> as possible) about GRCon, be it about attendance, online participation,
> content submission
> or other problems related to the conference, we want you to reach out:
> Here on the mailing
> list, on the chat (https://chat.gnuradio.org), or in a private email to
> the GRCon
> organizers (gr...@gnuradio.org).
>
> Now, clearly, this all requires significant funds to set up – with a
> history of more than
> 300 in-person attendees prior to COVID (last year's in-person attendance
> was around 200
> attendees), and the live video streams achieving 3900 views last year,
> there's a large
> responsibility to organize a smooth conference and offer an excellent
> in-person and remote
> experience.
>
> As in previous years, we do not intend to push all these costs onto the
> attendees alone
> (this year's tickets are cheaper than last year!); instead, it has proven
> mutually
> advantageous to have sponsors contribute to the conference, and be present
> in various
> forms to the audience. If your company is interested in reaching a
> high-profile, technical
> and social audience, please do see
> https://events.gnuradio.org/event/21/page/106-sponsorship-opportunities
> and reach out to
> spon...@gnuradio.org .
>
> Best regards, and: see you in person in Arizona or online in September,
> Marcus
>
>

Re: porting OOT to 3.10.5 missing memory.h

[Josh Morman]

Do you have pygccxml and castxml installed on this machine?  And if so, are
they recent versions (pygccxml >= 2.0)

When gr_modtool bind is called, pygccxml compiles the project headers then
scrapes the symbol information to generate the python bindings.  Not
finding memory.h sounds like an outdated version of pygccxml.

If you are on e.g. Ubuntu 20.04, uninstall pygccxml (apt remove
python3-pygccxml) and install it from pip (pip3 install pygccxml)



On Mon, Apr 24, 2023 at 12:14 PM Grace Yeung  wrote:

> Hi, I am trying to port my OOTs from gr 3.8 to 3.10. Following the
> porting guide and running "gr_modtool bind" work on all our machines
> running 3.10 except one that is on 3.10.5 where block.h tries to include
> memory.h which is missing. What's the best way to get around this
> besides just copying the file over? Thank you for any advice.
>
> Grace
>
> --
> Grace K. Yeung, MS
> NorthWest Research Associates
> 301 Webster Street
> Monterey, CA 93940
> gr...@nwra.com
> https://www.nwra.com
>
>

GNU Radio Conference 2023 - Sep 5-9, Tempe AZ

[Josh Morman]

Greetings GNU Radio Community!

We are excited to announce that GNU Radio Conference 2023 (GRCon23) will be
held as an in-person event September 5-9 at Arizona State University in Tempe,
AZ.

GRCon23 will celebrate and showcase the substantial and remarkable progress
of GNU Radio and its usage in a diverse field of applications and
industries.  It is a 4 day conference (Tues-Fri), with events continuing
through Saturday, 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.

More details about the event for participants and attendees are available
on the event website here: 
https://gnuradio.org/grcon23, but please go ahead and start thinking about
what great work you would like to present at this year’s conference - the
Call for Participation is currently open (abstracts due June 5).

If you have questions or would like to find out more about becoming one of
our valued sponsors please contact us at gr...@gnuradio.org.  Note that
this event can only be successful because of our sponsors - please see the
sponsors  that
made GRCon22 possible.

Since GRCon is run by a group of volunteers, we are also looking for people
to help with both the planning of and assisting during the event.  If you
are interested in volunteering in any capacity, please reach out to us
gr...@gnuradio.org

Sincerely,

The GRCon23 Organizers

Re: Is there a way to add break point or watch point in gnuradio

[Josh Morman]

You can hit breakpoints in the C++ code using VS Code:
https://wiki.gnuradio.org/index.php?title=UsingVSCode

Hitting the python called from a running flowgraph is not as
straightforward, but stepping through the flowgraph setup in the top level
python file can be done with the Python debugger in VS Code

Also, a talk at GRCon last year about different mechanisms for debugging
flowgraphs:
https://www.youtube.com/watch?v=JUt-a_L1Muo

Josh

On Tue, Feb 14, 2023 at 2:12 AM wieniawski  wrote:

> hi, all,
>
> As you know, GNU Radio will generate python file and execute.
> And probably it will not work correctly at the first time. So we need to
> debug. My question is about the debug method:
> 1. Is there a way to add break point in python file (or C++ file)?
> 2. And how about watch point?
> 3. Generated python file will call some library, how can I step into the
> library file? or just browse the library?
>
> Thanks
>
>
>

Re: gr_modtool bind makes incorrect file

[Josh Morman]

Hi Jameson,

This should be fixed as Ryan mentioned by having pygccxml installed.  But
for blocks with default interfaces as you described, gr_modtool bind should
produce the same output as the default as of this fix:
https://github.com/gnuradio/gnuradio/pull/6264 which got integrated after
GR 3.10.2.0.  So updating to the latest 3.10.5.0 should resolve the issue
(or installing pygccxml).

Josh

On Thu, Jan 19, 2023 at 3:20 PM Ryan Volz  wrote:

> Hi Jameson,
>
> On 1/19/23 1:03 PM, Jameson Collins wrote:
> > I am using gnuradio 3.10.2 from conda.  If I make a new module and
> > simply edit its _impl.cc and yaml files then everything works correctly.
> >
> > If I take the same module, and run `gr_modtool bind` on it then the new
> > binding file will be different and I'll get errors when trying to run.
> >
> > Here is the code to start with:
> > ```
> >  py::class_ >  std::shared_ptr>(m, "newmod2", D(newmod2))
> >
> >  .def(py::init(&newmod2::make),
> > D(newmod2,make)
> >  )
> > ```
> >
> > Here is the code after running `gr_modtool bind`:
> > ```
> >  py::class_ >  std::shared_ptr>(m, "newmod2", D(newmod2))
> >
> >  .def(py::init(&newmod2::make),
> > py::arg("myarg") =  false,
> > D(newmod2,make)
> >  )
> > ```
>
> I'm not an expert on `gr_modtool bind` (never used it), but I do know
> that the conda packages do not include pygccxml as a dependency and that
> that is important when autogenerating pybind11 bindings. If I had to
> guess, you probably need to install pygccxml. Pip install should work,
> although it will make maintaining that conda environment more of a
> challenge.
>
> If that's not it, then someone more familiar with `gr_modtool bind`
> should be able to clarify.
>
> Cheers,
> Ryan
>
>

Re: VS Code for QA Tests

[Josh Morman]

Jeff,

1) Is the c++ code built with Debug symbols (CMAKE_BUILD_TYPE=Debug)
2) Have you installed your built files?  When running from python, VSCode
uses the current PYTHONPATH in the environment and loads the .so files from
there, not from the build directory

Josh

On Mon, Nov 14, 2022 at 8:29 PM Jeff S  wrote:

> I have been using VS Code for debugging code according to
> https://wiki.gnuradio.org/index.php/UsingVSCode.  I thought I would try
> doing the same thing but using the Python QA tests to start the code rather
> than the flow graph Python.  I can’t seem to get the C++ code to break when
> using the QA Test as starting point and just wondered if anyone could, and
> what the launch.json configuration was for doing that.  I’ve tried both
> launching from VS Code and attaching to a process with the same results.
>
>
>
> I’m currently at GR v3.9.5.0 and VSC v1.73.
>
>
>
> Regards,
>
> Jeff
>

Re: Referring to a block by a specific name

[Josh Morman]

Hi T.K.

First you have enable the "Show All Block IDs" in GRC, then you can change
the ID of the block to whatever you want it to be.

In the snippet, then just refer to the block as self.blockname

Hope this helps.

Josh

On Wed, Sep 14, 2022 at 1:08 PM Temir Karakurum 
wrote:

> Hi,
>
> I have some python snippets within the GRC that refer to certain blocks.
> However, the GRC generated names can be quite unintuitive (like
> blocks_stream_to_vector_1_0 etc.) . I was wondering whether it is possible
> to refer to certain blocks by user-defined names.
>
> I understand that there is an alias option in each block's GUI that
> corresponds to a set_block_alias() call in the top_block python script.
> Apparently there is a block registry (
> https://github.com/gnuradio/gnuradio/blob/main/gnuradio-runtime/lib/block_registry.cc)
> that allows you lookups by alias but I could not figure out how to do that
> in python.
>
> What is the recommended approach for my scenario? Any help would be much
> appreciated.
>
> Best regards,
> T.K.
>
>
>

GRCon22 Announcements and Reminders

[Josh Morman]

GNU Radio Conference 2022 is just over 1 month away and we have an exciting
schedule,  outstanding speakers, and engaging activities planned for this
year's event.

Just a reminder to please register at https://tickets.gnuradio.org - this
helps us tremendously in having an accurate count of people for food and
space needs.

NOTE: You can even register without paying right away if needed - just
select "wire transfer" as the payment type, and you can come back later (by
the conference start) and complete or change the payment type (to credit
card).

Also, the venue for this year - Capital Hilton - has provided a special
rate for attendees that is very competitive with other rates in the area.
If you plan on staying at the venue hotel, please book
https://book.passkey.com/go/GNU2022 no later than August 26, so that our
room block is credited towards the event.

The initial schedule has been published:
https://events.gnuradio.org/event/18/timetable/#all.detailed. We have a
broad range of technical talks related to GNU Radio, SDR, and wireless
communications as well as:

   -

   Keynotes:
   -

  Dr. Stefanie Tomkins, Director, Defense Advanced Research Projects
  Agency
  -

  Dr. Tony Beasley, Director, National Radio Astronomy Observatory
  -

  Dr. Nicholas Laneman, Founding Director SpectrumX and Co-Director of
  the Wireless Institute, College of Engineering, Notre Dame
  -

   Breakout Sessions
   -

  Work collaboratively with active members of the development community
  in specific topics related to SDR research and planned development
  -

   Workshops
   -

   Expo Hall
   -

  Come see the latest offerings and demos from our sponsors throughout
  the conference
  -

   Hands-on Day/Hackfest
   -

  Friday will be dedicated to hands-on activity working closely with GR
  developers


If you are presenting, please review the presenter's guide:

https://events.gnuradio.org/event/18/page/84-conference-presenters-guide

For all the information, please visit the conference website:

https://events.gnuradio.org/e/grcon22

And of course, we are grateful to this year's conference sponsors, without
whom none of this would be possible:
https://events.gnuradio.org/event/18/page/60-our-sponsors

Any questions please email gr...@gnuradio.org

GRCon22 Abstract Submission Deadline Extended - July 17

[Josh Morman]

***The deadline for submitting abstracts for work to be presented at
GRCon22 has been extended until July 17. ***


GRCon22 is less than three months away!  Please consider submitting a short
abstract of your proposed talk, paper, or other participation option. Check
out our Call for Participation page for more details:
https://events.gnuradio.org/event/18/abstracts/


Key Dates

   -

   June 27 Extended to July 17 - Call for Participation Abstract
   Submissions Close
   -

   August 26 - Initial Main Track Schedule Posted
   -

   September 26 - Conference Begins


We look forward to seeing you at GRCon22!

Re: Regression in GR3.10

[Josh Morman]

I think the way to properly handle GIL from long running calls is to add
py::call_guard() to the definition of the method
binding

.def("delete_head", &msg_queue::delete_head, D(msg_queue, delete_head))

I haven't tried this here, but I've used it on similar python bindings

https://pybind11.readthedocs.io/en/stable/advanced/misc.html?highlight=call_guard#global-interpreter-lock-gil

Josh

On Wed, Jun 15, 2022 at 3:28 PM ikjtel  wrote:

> Josh
>
> Many thanks for your reply.   I needed some direction - this is
> exactly what I was looking for.
>
> > msgq API probably should be deprecated, but it is in fact there in 3.10.
>
> Yeah, I remember reading a pronouncement many moons ago from M. Braun
> about nuking msgq.  Always dreaded this day - OP25 is a heavy user of it.
> Ref: https://osmocom.org/projects/op25
>
> A few quick stats: OP25 has 160 lines in 25 files (.cc and .h) matching
> 'msg_q' or 'msgq'; 7 calls to insert_tail() from 5 files (.cc and .h);
> 34 calls to insert_tail() or delete_head() from 5 files (.py).
>
> > Are you able to use delete_head_nowait instead?
>
> delete_head_nowait never used to work for me, but seems to have
> improved in gr3.10.  The script pasted below should (and does
> in gr3.10) print no output but in gr3.8 you get a seg fault.
>
> A preliminary diagnosis (speaking imprecisely - it was long ago)
> suggested delete_head_nowait in gr3.8 was returning some kind of
> "fancy_pointer(nil)" rather than simply "nil" which would have
> been properly rendered back to python as "None" (and gr3.10 looks
> like it gets this right).
>
> Short term I think we could visit the approx. 10 sites in python code
> and change delete_head over to _nowait.  Since the returned value can't
> be trusted (gr3.8 and below in the no-message case) we'll need to skip
> if empty_p() is true.
>
> One problem with the _nowait is what to do with all the processor
> time we suddenly have on our hands.  If we sleep for some arbitrary
> period it adds latency in the app that wasn't there before.
>
> Longer term is the question of what to do about msgq in OP25.  The
> idea of getting rid of all the code that relies on it is agonizing.
> It may make more sense to fork the msgq code out of gnuradio-runtime.
> We could probably find some hack that would take care of the GIL problem
> in a proper way...Comments certainly welcome.
>
> Max
>
> ~~~
> #!/usr/bin/env python   # seg faults in gr 3.8
>
> import sys
>
> from gnuradio import gr
>
> my_msgq = gr.msg_queue(1)
>
> p = my_msgq.delete_head_nowait()
> if p:
> sys.stderr.write('found msg\n')
> sys.stderr.flush()
> print('type is %s' % p.type())
>
>

Re: Regression in GR3.10

[Josh Morman]

Max,

The msgq API probably should be deprecated, but it is in fact there in
3.10.  I think you are right that it is an issue with the GIL because
delete_head it is a long blocking function.  Are you able to use
delete_head_nowait instead?

Thanks,
Josh

On Wed, Jun 15, 2022 at 10:08 AM ikjtel  wrote:

> The script pasted below runs OK in 3.8 but hangs (with no iteration
> output) in 3.10 (Ubuntu 22.04).  Naturally no message is anticipated - but
> the script should not hang!
>
> This problem is blocking the release of OP25 for GR3.10.
>
> I suspect deadlock due to failure to release the Python GIL.
>
> Kindly advise - thx
>
> Max
> ~~
> #!/usr/bin/env python
>
> import os
> import sys
> import threading
> import time
>
> from gnuradio import gr
>
> class queue_watcher(threading.Thread):
>
> def __init__(self, msgq,  callback, **kwds):
> threading.Thread.__init__ (self, **kwds)
> self.msgq = msgq
> self.callback = callback
> self.keep_running = True
> print ('starting thread')
> self.start()
>
> def run(self):
> while(self.keep_running):
> msg = self.msgq.delete_head()
> if not self.keep_running:
> break
> self.callback(msg)
>
> def callback(msg):
>  print('callback: msg received: %d' % msg.type())
>
> my_msgq = gr.msg_queue(1)
>
> watcher = queue_watcher(my_msgq, callback)
>
> i = 0
> while True:
> time.sleep(1)
> print('main loop running iteration %d' % i)
> i += 1
>
>
>

newsched (GR4 proposed runtime) v0.3.0 Released

[Josh Morman]

Greetings GNU Radio Community!

newsched v0.3.0 has been released here:
https://github.com/gnuradio/newsched/releases/tag/v0.3.0

This release involves a lot of cleanup, and enabling features, and a
handful of useful blocks.  Take a look at the release notes for more
details.

The goal moving forward is to move newsched into a dev-4.0 branch of the
main gnuradio repo.  Not sure exactly when this will happen, but when it
does, newsched will cease development and all work will be directly toward
GR 4.0.  This is why you will notice the use of the term "newsched" has
been minimized in the code and replaced with "gnuradio" for the most part.

If you are interested in this development, please join the chat in the
#scheduler room at chat.gnuradio.org.  The Scheduler Working Group that
hangs out there and joins periodic feature and code reviews has been
invaluable in guiding the features that have gone into this effort.

Thanks!
Josh

Re: gr_modtool rm in v3.9

[Josh Morman]

Jeff,

I'm guessing the issue is with the tool.  Modtool went through some changes
3.8-->3.9 as Swig was removed and the extra step of `modtool bind` was
added.

Josh

On Tue, Mar 22, 2022 at 11:28 AM Jeff S  wrote:

> I tried using gr_modtool in v3.9.5.0 to add a block, including python and
> C++ QA code.  I then did a gr_modtool rm on that block, but the C++ QA code
> file was not removed, and the file shows up in the lib/CMakeLists.txt file.
>
>
>
> I tried a test with the same thing in v3.8.5.0, and it seems like the C++
> file and reference were removed.  I couldn’t find any reference to it being
> changed, so I guess I’m just checking to see if there is an issue with me,
> or the tool.
>
>
>
> Regards,
>
> Jeff
>

Re: Problem with adjusting value during runtime in my OOT block

[Josh Morman]

Yes, that is the problem - not sure why modtool bind is not doing the
trick.  You can manually add the method if you want, which would just look
like:

.def(py::init(&adding_ff::make),
py::arg("constant0"),
D(adding_ff,make)
)
.def("set_constant0", &adding_ff::set_constant0)
;

The only thing then to be careful of is if you run modtool bind again, it
would blow away your changes

It may be worth trying to figure out why modtool bind is not doing the full
set of methods that pygccxml would find, such as trying a new oot from
scratch and see if the same problem exists, now that pygccxml is installed


On Mon, Mar 14, 2022 at 7:53 AM Nikoloz Glonti  wrote:

> adding_ff_python.cc looks like that - https://pastebin.com/nmpshmvj
>
>
> On 3/14/22 11:26, Josh Morman wrote:
> > Those files look good to me - I'm wondering how the python bindings
> > look.  Can you share the file python/bindings/adding_ff_python.cc ?
>

Re: Problem with adjusting value during runtime in my OOT block

[Josh Morman]

Those files look good to me - I'm wondering how the python bindings look.
Can you share the file python/bindings/adding_ff_python.cc ?

On Sun, Mar 13, 2022 at 8:04 PM Nikoloz Glonti  wrote:

> Thanks for Your response! I'm using gnuradio 3.9.4.0
>
> void set_constant0(int constant0); is inside of my block header -
> "adding_ff_impl.h". then I made "gr_modtool bind adding_ff" before I asked.
> I also installed pygccxml, but it didn't helped - doing gr_modtool bind
> adding_ff takes  longer time than before.
>
> Do You have any other suggestions?
>
> adding_ff_impl.cc looks like https://pastebin.com/JUnxQtYi
>
> and adding_ff_impl.h looks like https://pastebin.com/MF93s9WD
>
> Niko
> On 3/13/22 21:32, Josh Morman wrote:
>
> This sounds like it could be an issue with the python bindings
>
> 1) did you run “gr_modtool bind” after adding the callback to your block
> header
> 2) is pygccxml installed?  Without it the binding using modtool can only
> do the basic block things
>
> Josh
>
> On Sun, Mar 13, 2022 at 4:09 PM Nikoloz Glonti  wrote:
>
>> Dear Gnuradio community,
>>
>> I wrote my block in OOT module. It has function set_constant0(int
>> constant0) which should change value on the go.
>> I also added callback to grc yaml file. But when I run my flowgraph, I'm
>> having this error "AttributeError: 'SiNK.SiNK_python.adding_ff' object
>> has no attribute 'set_constant0'" .
>>
>> How can i fix it?
>>
>> Niko
>>
>

Re: Problem with adjusting value during runtime in my OOT block

[Josh Morman]

This sounds like it could be an issue with the python bindings

1) did you run “gr_modtool bind” after adding the callback to your block
header
2) is pygccxml installed?  Without it the binding using modtool can only do
the basic block things

Josh

On Sun, Mar 13, 2022 at 4:09 PM Nikoloz Glonti  wrote:

> Dear Gnuradio community,
>
> I wrote my block in OOT module. It has function set_constant0(int
> constant0) which should change value on the go.
> I also added callback to grc yaml file. But when I run my flowgraph, I'm
> having this error "AttributeError: 'SiNK.SiNK_python.adding_ff' object
> has no attribute 'set_constant0'" .
>
> How can i fix it?
>
> Niko
>

Re: QA Tests: Python vs C++

[Josh Morman]

Jeff,

When tests are done in C++, they also must be compiled, which adds to the
overall gnuradio compilation time.  In-tree the c++ tests are reserved
mainly for testing the really low level like buffers.
I agree with you that an all c++ target makes debugging easy, but you can
launch the python flowgraphs with the GDB debugger using program:
"/usr/bin/python3" and args: /path/to/the/qa_xxx.py.

Josh



On Mon, Mar 7, 2022 at 8:37 AM Jeff S  wrote:

> I started writing some QA tests which were missing for some blocks I’m
> working on (in maint-3.9).  I decided to compare using Python vs using C++
> when building new tests.  When I started looking into the C++ tests, it
> seems that there are not a lot of examples around, so I started wondering
> why people may stick to Python over C++.
>
>
>
> I found Python quicker to code and easier to see what’s being tested, but
> C++ would run the same test as the Python much quicker (according to the
> time output from make test).  Writing in C++ also gives me the ability to
> run Visual Studio Code in debug easier and target sections of code under
> test, which is a very nice feature.  Visual Studio Code seems to have
> problems with mixed languages under its visual debugging.
>
>
>
> Are there other aspects of Python for QA tests that I’m missing as to why
> it’s the preferred method?  I’m indifferent as to the tool used because
> I’ll use whatever gets the job done, so I’m not trying to make this a
> language pro/con question.
>
>
>
> Thanks,
>
> Jeff
>

Re: Selecting a SDR as a sink

[Josh Morman]

David,

There are a couple of problems with using the selector in this
configuration.

1) If you plan to just disable the sinks in GRC, then you don't need the
selector at all.  That block is intended to be used to change the
configuration during runtime.  You can just connect all the sinks to the
same output and disable with the D key.
2) In the case where devices are present when the flowgraph is run, when
the selector output is set to, e.g. 0, the outputs 1 and 2 produce no
samples.  This will starve the SDR sinks of samples and have some
consequences (depends on the sdr)

As far as the SDRs being instantiated, this is just how GRC works - it
instantiates all the blocks that are present in the flowgraph.  So if an
SDR isn't present, then the block needs to be disabled - selector doesn't
help you.

Josh

On Thu, Mar 3, 2022 at 11:07 PM David Cherkus  wrote:

> Asked this on chat, thought it might need a broader audience so am asking
> here too...
>
> Part of my flowgraph looks like:
>
> [image: Inline image]
>
>
>
> I.e. a selector that selects between output to null sink, osmocom sink or
> PlutoSDR sink.
>
> Problem is when I run the flow and no SDR is present (I select Null Sink
> by default) the code still tries to instantiate the osmocom Sink and that
> fails.  If I disable the sinks for radios that aren't present with the 'D'
> key, then the selector complains that the output is no longer connected.
> Any ideas how to work around this?
>
> Regards,
> Dave, N1AI
>
>
>

GRCon 2022 - Washington DC - Sept. 26 - 30

[Josh Morman]

Greetings GNU Radio Community!

We are excited to announce that we are planning for GRCon 2022 to be run as
an in-person event September 26-30 at the Capital Hilton
 in Washington DC.  If you know you
will be planning to come, you are encouraged to go ahead and book your room
here:

https://book.passkey.com/go/GNU2022

Reservation line: (800) 405-0064

Group Code: GNU

GRCon 2022 will celebrate and showcase 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.

More details about the event for participants and attendees will be updated
on the event website here: https://events.gnuradio.org/e/grcon22, but
please go ahead and start thinking about what great work you would like to
present at this year’s conference - the Call for Participation will be
announced soon.

If you have questions or would like to find out more about becoming one of
our valued sponsors please contact us at gr...@gnuradio.org.  Note that
this event can only be successful because of our sponsors - please see the
sponsors  that made
GRCon21 possible.

Since GRCon is run by a group of volunteers, we are also looking for people
to help with both the planning of and assisting during the event.  If you
are interested in volunteering in any capacity, please reach out to us
gr...@gnuradio.org

Sincerely,

The GRCon22 Organizers

Re: segfault in 3.10.1.1

[Josh Morman]

Hi Steve,

Can you please share more information about how GR is installed in your
case
- OS/distribution?
- Installation method (compiled from source, distro packages?

Thanks!
Josh

On Mon, Feb 7, 2022 at 7:58 PM Steven Barbo  wrote:

> Hello all, hope this day finds you well.
> Having issue with gnuradio-companion, GUI comes up briefly...
>
> dmesg
> [ 1341.843803] traps: gnuradio-compan[372] general protection fault
> ip:7f81ca4f77c8 sp:7f81c7137010 error:0 in
> libgirepository-1.0.so.1.0.0[7f81ca4ed000+2]
>
>
> have compiled various gr versions over the years, they have always just
> worked :)
>
> any help or pointers are very much appreciated. what an amazing tool,
> thank you.
>
> gnuradio-config --print-all
> /usr/
> /etc
> /etc/gnuradio/conf.d
> /.gnuradio
> Mon, 07 Feb 2022 03:07:35Z
> testing-support;python-support;post-install;man-pages;gnuradio-runtime;common-precompiled-headers;gr-ctrlport;*
> thrift;gnuradio-companion;gr-blocks;gr-fec;gr-fft;gr-filter;gr-analog;gr-digital;gr-dtv;gr-audio;*
> alsa;*
> oss;gr-channels;gr-pdu;gr-qtgui;gr-trellis;gr-utils;gr_modtool;gr_blocktool;gr-video-sdl;gr-vocoder;*
> gsm;gr-wavelet;gr-network;gr-soapy
> 3.10.1.1
> cc (The Illustrious Industries, Ltd.) 10.3.0
> Copyright (C) 2020 Free Software Foundation, Inc.
> This is free software see the source for copying conditions.  There is NO
> warranty not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
> c++ (The Illustrious Industries, Ltd.) 10.3.0
> Copyright (C) 2020 Free Software Foundation, Inc.
> This is free software see the source for copying conditions.  There is NO
> warranty not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
> /usr/bin/cc:::-g -O2  -fvisibility=hidden -Wsign-compare -Wall
> -Wno-uninitialized
> /usr/bin/c++:::-g -O2  -fvisibility=hidden -Wsign-compare -Wall
> -Wno-uninitialized
> 2.9.0
>
>
> apologies for the ugly script and gdb output, tried to disable control
> characters...
> shorten so as to not pollute
>
> sh-5.1# gdb -q /bin/python3 core
> ^[[?2004l^MReading symbols from ^[[32m/bin/python3^[[m...
> ^M
> warning: Can't open file /SYSV (deleted) during file-backed
> mapping note processing^M
> ^M
> warning: core file may not match specified executable file.^M
> [New LWP 372]^M
> [New LWP 358]^M
> [New LWP 359]^M
> [New LWP 361]^M
> [New LWP 360]^M
> [New LWP 363]^M
> [New LWP 362]^M
> [New LWP 370]^M
> [New LWP 364]^M
> [New LWP 369]^M
> [New LWP 367]^M
> [New LWP 368]^M
> [New LWP 387]^M
> [New LWP 365]^M
> [New LWP 366]^M
> [New LWP 395]^M
> [New LWP 357]^M
> ^M
> warning: Cannot parse .gnu_debugdata section; LZMA support was disabled at
> compile time^M
> [Thread debugging using libthread_db enabled]^M
> Using host libthread_db library "^[[32m/lib64/libthread_db.so.1^[[m".^M
> Core was generated by `/usr/bin/python3 /usr/bin/gnuradio-companion --log
> critical'.^M
> Program terminated with signal SIGSEGV, Segmentation fault.^M
> ^[[?2004h--Type  for more, q to quit, c to continue without paging--^M
> ^[[?2004l^M#0  ^[[34m0x7f81ca4f77c8^[[m in
> ^[[33mg_callable_info_free_closure^[[m (^M
> ^[[36mcallable_info^[[m=0x7f81c00034f0,
> ^[[36mclosure^[[m=0x7f81c9cf3f20)^M
> at ^[[32m../girepository/girffi.c^[[m:428^M
> 428   g_free (wrapper->ffi_closure.cif->arg_types);^M
> [Current thread is 1 (Thread 0x7f81c7138640 (LWP 372))]^M
> ^[[?2004h(gdb) bt^M
> ^[[?2004l^M#0  ^[[34m0x7f81ca4f77c8^[[m in
> ^[[33mg_callable_info_free_closure^[[m (^M
> ^[[36mcallable_info^[[m=0x7f81c00034f0,
> ^[[36mclosure^[[m=0x7f81c9cf3f20)^M
> at ^[[32m../girepository/girffi.c^[[m:428^M
> #1  ^[[34m0x7f81c9a83a56^[[m in ^[[33m_pygi_invoke_closure_free^[[m
> (^[[36mdata^[[m=0x7f81c0001630)^M
> at ^[[32mgi/pygi-closure.c^[[m:635^M
> #2  ^[[34m0x7f81c9a8e3e5^[[m in
> ^[[33mpygi_marshal_cleanup_args_from_py_marshal_success^[[m (^M
> ^[[36mstate=state@entry^[[m=0x7f81c7137150, ^[[36mcache=cache@entry
> ^[[m=0x7f81c00128b0)^M
> at ^[[32mgi/pygi-marshal-cleanup.c^[[m:116^M
> #3  ^[[34m0x7f81c9a8d072^[[m in ^[[33mpygi_invoke_c_callable^[[m (^M
> ^[[36mfunction_cache^[[m=0x7f81c00128b0, ^[[36mstate^[[m= out>, ^M
> ^[[36mpy_args^[[m=, ^[[36mpy_kwargs^[[m= out>) at ^[[32mgi/pygi-invoke.c^[[m:712^M
> #4  ^[[34m0x7f81c9a8311a^[[m in ^[[33mpygi_function_cache_invoke^[[m
> (^M
> ^[[36mfunction_cache^[[m=, 
> ^[[36mpy_args=py_args@entry^[[m=0x7f81c659ae40,
> ^M
> ^[[36mpy_kwargs=py_kwargs@entry^[[m=0x0) at
> ^[[32mgi/pygi-cache.c^[[m:862^M
> #5  ^[[34m0x7f81c9a8d615^[[m in ^[[33mpygi_callable_info_invoke^[[m
> (^[[36muser_data^[[m=0x0, ^M
> ^[[36mcache^[[m=, ^[[36mkwargs^[[m=0x0,
> ^[[36mpy_args^[[m=0x7f81c659ae40, ^M
>
>
> --
> If something is requisite, how can it possibly be, prerequisite?
>
> vanitas vanitatum omnia vanitas
> later, steve
> http://umn.edu/~barbo
>

Re: Can I change Gnuradio 3.8 to 3.7 ?

[Josh Morman]

By change the version, do you mean uninstall GNU Radio 3.8 and install 3.7,
or do you mean make the 3.7 modules work with 3.8 - the latter is not
possible because the changes in GR from 3.7 to 3.8 were significant and not
API compatible.

Josh

On Tue, Feb 1, 2022 at 4:47 AM Rachida SAROUI 
wrote:

> Hello everyone,
>
> I'm working with Gnuradio 3.8 but I need a module that is compatible only
> with 3.7. Can I change the version of Gnuradio from 3.8 to 3.7?
>
> Thank you
>

Git Default Branch Naming

[Josh Morman]

Hello GR Users and Developers!

The master branch has now been renamed to "main" to be more in line with
the github defaults and the direction that so many other projects have
moved.

All active PRs have been retargeted to main, and the master branch still
exists for compatibility reasons (but will receive no updates).  All new
PRs should be opened against 'main'

On your local repository (github will give instructions as well), you just
need to do the following (assuming your remote is named "origin"):
$ git branch -m master main
$ git fetch origin
$ git branch -u origin/main main
$ git remote set-head origin -a

Sorry for any inconvenience this change causes, but it should make things
more consistent down the line as more projects have a `main` branch, and
now is as good a time as any to make this change.

Thanks!
Josh

GNU Radio Release v3.10.0.0

[Josh Morman]

darsh Singh 79402080+furiousl...@users.noreply.github.com
Aditya Thomas sepia_t...@protonmail.com
Adrien Michel adrien...@users.noreply.github.com
André Apitzsch andre.apitz...@etit.tu-chemnitz.de
Andrej Rode m...@andrejro.de
Artem Pisarenko artem.k.pisare...@gmail.com
Bernard Tyers - Sane UX Design bernard+w...@ei8fdb.org
beroset bero...@users.noreply.github.com
Bill Muzika bill.muz...@outlook.com
Callyan sufo...@gmail.com
Chris christopher.dono...@gmail.com
Christophe Seguinot christophe.segui...@univ-lille.fr
Christoph Koehler ckoe...@sandia.gov
Chuang Zhu geneloca...@yandex.com
Clayton Smith arg...@gmail.com
cmrincon cmrincon...@hotmail.com
Codey McCodeface codey.mccodef...@gmail.com
Daniel Estévez dan...@destevez.net
David Pi david.pi...@gmail.com
David Sorber david.sor...@blacklynx.tech
David Winter david.win...@analog.com
Derek Kozel 
Doron Behar doron.be...@gmail.com
duggabe ba...@dcsmail.net
efardin efar...@ieee.org
Elof Wecksell e...@wecksell.se
Emmanuel Blot emmanuel.b...@free.fr
Ferenc Gerlits fgerl...@gmail.com
GitHub 
gnieboer gnieb...@corpcomm.net
Håkon Vågsether hakon.vagset...@gmail.com
Igor Freire i...@blockstream.com
Ipsit mmkip...@gmail.com
Jacob Gilbert jacob.gilb...@protonmail.com
japm48 jap...@users.noreply.github.com
JaredD jaredd...@gmail.com
Jason Uher jason.u...@jhuapl.edu
Jeff Dumps jeffdu...@gmail.com
Jeff Long 
Jeppe Ledet-Pedersen j...@satlab.com
jfmadeira jf.made...@campus.fct.unl.pt
jmadeira jmade...@pdmfc.com
Johannes Demel de...@ant.uni-bremen.de
John Sallay jasal...@gmail.com
Josh Blum j...@joshknows.com
Josh Morman jmor...@gnuradio.org
karel 5636152+ka...@users.noreply.github.com
lenhart malte.lenh...@t-online.de
Liu, Andrew Z liu.and...@vast-inc.com
luz paz luz...@users.noreply.github.com
Marc L mar...@vt.edu
Marcus Müller 
Mark Bauer mar...@illinois.edu
Mark Pentler tehhust...@hotmail.com
Martin Braun 
Martyn van Dijke martijnvdijke...@gmail.com
masw m...@masw.tech
Matt Ettus mattet...@users.noreply.github.com
Matt Mills mmi...@2bn.net
muaddib1984 70996692+muaddib1...@users.noreply.github.com
Nicholas Bruce saltair93+git...@gmail.com
Nicholas Corgan n.cor...@gmail.com
Nick Foster bistrom...@gmail.com
Nick M tacl...@users.noreply.github.com
Nick Østergaard oe.n...@gmail.com
Niki n...@aveer.io
Notou barth...@laposte.net
Oleksandr Kravchuk open.sou...@oleksandr-kravchuk.com
Pavon pa...@protonmail.com
Philip Balister phi...@balister.org
rear1019 rear1...@posteo.de
Rohan Sharma rhnsharma5...@gmail.com
Ron Economos w...@comcast.net
Ryan Volz ryan.v...@gmail.com
schneider42 schnei...@blinkenlichts.net
Sebastian Koslowski sebastian.koslow...@gmail.com
Seth Hitefield sdhitefi...@gmail.com
shwhiti shwh...@sandia.gov
Solomon Tan solomonbsto...@yahoo.com.au
Sylvain Munaut t...@246tnt.com
Terry May terryd...@gmail.com
Thomas Habets tho...@habets.se
Tim Huggins tim.hugg...@systemminnovationgroup.org
Travis F. Collins travis.coll...@analog.com
Vasilis Tsiligiannis acino...@openwrt.gr
Vasil Velichkov vvvelich...@gmail.com
Victor Wollesen victo...@pervices.com
Volker Schroer 3470424+dl1...@users.noreply.github.com
Zackery Spytz zsp...@gmail.com

Thanks again - and please reach out on email (here) or chat (
chat.gnuradio.org) if you have questions, run into issues, or to join the
ongoing discussion of what should be next for GNU Radio.

One minor note - the master branch will be renamed early next week as
"main" to align with the github defaults and the direction that most
projects have moved.  This should be minimally if at all disruptive.

Josh

Release Candidate v3.10.0.0-rc4

[Josh Morman]

https://github.com/gnuradio/gnuradio/releases/tag/v3.10.0.0-rc4

Sorry for all the churn here at the last minute.  RC4 contains the drmpeg
fixes described below as well as some minor QT gui fixes.

Hopefully this is it and RC4 will become the official 3.10.0.0 at the end
of this week.

Thanks!
Josh

On Mon, Jan 10, 2022 at 7:12 AM Josh Morman  wrote:

> Please note that there is an issue with the RC3 that has been resolved on
> the master branch (thanks to drmpeg for catching and fixing a cmake build
> order dependency that prevented the grc files from being installed).
>
> The current master branch has this fixed and will be the basis of 3.10.
> Please raise the alarms if you run into any other issues either here or on
> #development
>
> Josh
>
> On Sat, Jan 8, 2022 at 9:23 PM Josh Morman  wrote:
>
>> 3.10.0.0-rc3 is now available:
>> https://github.com/gnuradio/gnuradio/releases/tag/v3.10.0.0-rc3
>>
>> There were a few changes since RC2, but this should be basically it for
>> 3.10 (hard freeze unless something critical is discovered), so please give
>> it a test if you have a chance.
>>
>> If things go well, the plan is to release the final 3.10.0.0 next Friday
>> Jan 14!  Thanks to all who have been contributing and participating in the
>> discussions.
>>
>> Josh
>>
>>
>>
>> On Sat, Dec 11, 2021 at 8:51 AM Josh Morman  wrote:
>>
>>>
>>> 3.10.0.0-rc2 is now available:
>>> https://github.com/gnuradio/gnuradio/releases/tag/v3.10.0.0-rc2
>>> and you can see the current changelog here:
>>> https://github.com/gnuradio/gnuradio/blob/master/CHANGELOG.md
>>> The plan is to make a final release mid-January, so this may involve one
>>> more RC if there are any more major issues to sort out.
>>>
>>> Have a great weekend!
>>>
>>> Josh
>>>
>>> On Sat, Nov 27, 2021 at 10:29 AM Josh Morman 
>>> wrote:
>>>
>>>> Greetings GNU Radio Community!
>>>>
>>>> Release 3.10 is expected to drop sometime in the new year, but to get
>>>> the ball rolling with testing and packaging - we are expecting a longer
>>>> than usual Release Candidate cycle, and likely there will be *at least*
>>>> one more RC, so here is v3.10.0.0-rc1
>>>> <https://github.com/gnuradio/gnuradio/releases/tag/v3.10.0.0-rc1>
>>>>
>>>> We have been fortunate this year to have extremely active backporting
>>>> and consistent maintenance releases from co-maintainter Jeff Long - so many
>>>> of the fixes and smaller feature (and larger ones) have already seen the
>>>> light of day in the 3.9.x.x and even 3.8.x.x releases.  Here are some of
>>>> the bigger features that are bringing about this major release.
>>>>
>>>> *gr-pdu*
>>>> PDUs (protocol data units) in GNU Radio are a special type of PMT that
>>>> have a dictionary and a uniform vector type representing a burst of data
>>>> with some metadata.  Up to this point, support of pdus has been scattered
>>>> throughout the codebase with minimal support for handling this type of data
>>>> consistently.  Fortunately, Jacob Gilbert has been able to upstream much of
>>>> the amazing work from himself and the team at Sandia National Labs which
>>>> brings in-tree a suite of tools for manipulating these data objects (see
>>>> https://github.com/sandialabs/gr-pdu_utils).  Also, many of the
>>>> previous PDU processing blocks that existed in other in-tree modules have
>>>> been migrated to this module, so there has been some block re-arrangement.
>>>> Please see https://www.youtube.com/watch?v=bT60hVVte48 for more
>>>> detailed information
>>>>
>>>> *gr-iio*
>>>> IIO is the industrial I/O framework that provides an industry standard
>>>> method for communicating with a wide-range of devices including many of the
>>>> ADI SDR platforms.  Analog Devices has supported out of tree a gr-iio
>>>> module that brings this capability into GNU Radio and now upstreamed this
>>>> module so support for devices like the PlutoSDR are available out of the
>>>> box.  Special thanks here to Adam Horden, Travis Collins, Dave Winter,
>>>> Volker Shroer, and Jeff Long for bringing this in-tree and working through
>>>> many of the complexities.
>>>> Please see https://www.youtube.com/watch?v=2gKbollW6wg for a more
>>>> technical description of IIO and gr-iio.
>>>>
>>>> *Custom Buffer

Re: Release Candidate v3.10.0.0-rc3

[Josh Morman]

Please note that there is an issue with the RC3 that has been resolved on
the master branch (thanks to drmpeg for catching and fixing a cmake build
order dependency that prevented the grc files from being installed).

The current master branch has this fixed and will be the basis of 3.10.
Please raise the alarms if you run into any other issues either here or on
#development

Josh

On Sat, Jan 8, 2022 at 9:23 PM Josh Morman  wrote:

> 3.10.0.0-rc3 is now available:
> https://github.com/gnuradio/gnuradio/releases/tag/v3.10.0.0-rc3
>
> There were a few changes since RC2, but this should be basically it for
> 3.10 (hard freeze unless something critical is discovered), so please give
> it a test if you have a chance.
>
> If things go well, the plan is to release the final 3.10.0.0 next Friday
> Jan 14!  Thanks to all who have been contributing and participating in the
> discussions.
>
> Josh
>
>
>
> On Sat, Dec 11, 2021 at 8:51 AM Josh Morman  wrote:
>
>>
>> 3.10.0.0-rc2 is now available:
>> https://github.com/gnuradio/gnuradio/releases/tag/v3.10.0.0-rc2
>> and you can see the current changelog here:
>> https://github.com/gnuradio/gnuradio/blob/master/CHANGELOG.md
>> The plan is to make a final release mid-January, so this may involve one
>> more RC if there are any more major issues to sort out.
>>
>> Have a great weekend!
>>
>> Josh
>>
>> On Sat, Nov 27, 2021 at 10:29 AM Josh Morman 
>> wrote:
>>
>>> Greetings GNU Radio Community!
>>>
>>> Release 3.10 is expected to drop sometime in the new year, but to get
>>> the ball rolling with testing and packaging - we are expecting a longer
>>> than usual Release Candidate cycle, and likely there will be *at least*
>>> one more RC, so here is v3.10.0.0-rc1
>>> <https://github.com/gnuradio/gnuradio/releases/tag/v3.10.0.0-rc1>
>>>
>>> We have been fortunate this year to have extremely active backporting
>>> and consistent maintenance releases from co-maintainter Jeff Long - so many
>>> of the fixes and smaller feature (and larger ones) have already seen the
>>> light of day in the 3.9.x.x and even 3.8.x.x releases.  Here are some of
>>> the bigger features that are bringing about this major release.
>>>
>>> *gr-pdu*
>>> PDUs (protocol data units) in GNU Radio are a special type of PMT that
>>> have a dictionary and a uniform vector type representing a burst of data
>>> with some metadata.  Up to this point, support of pdus has been scattered
>>> throughout the codebase with minimal support for handling this type of data
>>> consistently.  Fortunately, Jacob Gilbert has been able to upstream much of
>>> the amazing work from himself and the team at Sandia National Labs which
>>> brings in-tree a suite of tools for manipulating these data objects (see
>>> https://github.com/sandialabs/gr-pdu_utils).  Also, many of the
>>> previous PDU processing blocks that existed in other in-tree modules have
>>> been migrated to this module, so there has been some block re-arrangement.
>>> Please see https://www.youtube.com/watch?v=bT60hVVte48 for more
>>> detailed information
>>>
>>> *gr-iio*
>>> IIO is the industrial I/O framework that provides an industry standard
>>> method for communicating with a wide-range of devices including many of the
>>> ADI SDR platforms.  Analog Devices has supported out of tree a gr-iio
>>> module that brings this capability into GNU Radio and now upstreamed this
>>> module so support for devices like the PlutoSDR are available out of the
>>> box.  Special thanks here to Adam Horden, Travis Collins, Dave Winter,
>>> Volker Shroer, and Jeff Long for bringing this in-tree and working through
>>> many of the complexities.
>>> Please see https://www.youtube.com/watch?v=2gKbollW6wg for a more
>>> technical description of IIO and gr-iio.
>>>
>>> *Custom Buffers Support*
>>> NOTE: this is an advanced "experimental" feature that if not actively
>>> employed will not affect normal GNU Radio usage.
>>> David Sorber from Black Lynx has introduced a feature that enables
>>> streamlined data movement between GNU Radio blocks and hardware
>>> accelerators.  By creating a "custom buffer" class (or using one that is
>>> provided by someone else), blocks can be made to abstract the data movement
>>> behind the scenes so that when the `work` function is reached, data already
>>> exists in the device memory.
>>> Let me give a quick example - previously if you wante

Release Candidate v3.10.0.0-rc3

[Josh Morman]

3.10.0.0-rc3 is now available:
https://github.com/gnuradio/gnuradio/releases/tag/v3.10.0.0-rc3

There were a few changes since RC2, but this should be basically it for
3.10 (hard freeze unless something critical is discovered), so please give
it a test if you have a chance.

If things go well, the plan is to release the final 3.10.0.0 next Friday
Jan 14!  Thanks to all who have been contributing and participating in the
discussions.

Josh



On Sat, Dec 11, 2021 at 8:51 AM Josh Morman  wrote:

>
> 3.10.0.0-rc2 is now available:
> https://github.com/gnuradio/gnuradio/releases/tag/v3.10.0.0-rc2
> and you can see the current changelog here:
> https://github.com/gnuradio/gnuradio/blob/master/CHANGELOG.md
> The plan is to make a final release mid-January, so this may involve one
> more RC if there are any more major issues to sort out.
>
> Have a great weekend!
>
> Josh
>
> On Sat, Nov 27, 2021 at 10:29 AM Josh Morman  wrote:
>
>> Greetings GNU Radio Community!
>>
>> Release 3.10 is expected to drop sometime in the new year, but to get the
>> ball rolling with testing and packaging - we are expecting a longer than
>> usual Release Candidate cycle, and likely there will be *at least* one
>> more RC, so here is v3.10.0.0-rc1
>> <https://github.com/gnuradio/gnuradio/releases/tag/v3.10.0.0-rc1>
>>
>> We have been fortunate this year to have extremely active backporting and
>> consistent maintenance releases from co-maintainter Jeff Long - so many of
>> the fixes and smaller feature (and larger ones) have already seen the light
>> of day in the 3.9.x.x and even 3.8.x.x releases.  Here are some of the
>> bigger features that are bringing about this major release.
>>
>> *gr-pdu*
>> PDUs (protocol data units) in GNU Radio are a special type of PMT that
>> have a dictionary and a uniform vector type representing a burst of data
>> with some metadata.  Up to this point, support of pdus has been scattered
>> throughout the codebase with minimal support for handling this type of data
>> consistently.  Fortunately, Jacob Gilbert has been able to upstream much of
>> the amazing work from himself and the team at Sandia National Labs which
>> brings in-tree a suite of tools for manipulating these data objects (see
>> https://github.com/sandialabs/gr-pdu_utils).  Also, many of the previous
>> PDU processing blocks that existed in other in-tree modules have been
>> migrated to this module, so there has been some block re-arrangement.
>> Please see https://www.youtube.com/watch?v=bT60hVVte48 for more detailed
>> information
>>
>> *gr-iio*
>> IIO is the industrial I/O framework that provides an industry standard
>> method for communicating with a wide-range of devices including many of the
>> ADI SDR platforms.  Analog Devices has supported out of tree a gr-iio
>> module that brings this capability into GNU Radio and now upstreamed this
>> module so support for devices like the PlutoSDR are available out of the
>> box.  Special thanks here to Adam Horden, Travis Collins, Dave Winter,
>> Volker Shroer, and Jeff Long for bringing this in-tree and working through
>> many of the complexities.
>> Please see https://www.youtube.com/watch?v=2gKbollW6wg for a more
>> technical description of IIO and gr-iio.
>>
>> *Custom Buffers Support*
>> NOTE: this is an advanced "experimental" feature that if not actively
>> employed will not affect normal GNU Radio usage.
>> David Sorber from Black Lynx has introduced a feature that enables
>> streamlined data movement between GNU Radio blocks and hardware
>> accelerators.  By creating a "custom buffer" class (or using one that is
>> provided by someone else), blocks can be made to abstract the data movement
>> behind the scenes so that when the `work` function is reached, data already
>> exists in the device memory.
>> Let me give a quick example - previously if you wanted to write a GPU
>> accelerated block with CUDA, you would have to get into the work function,
>> move the data from the GNU Radio circular buffers to GPU device memory,
>> execute the CUDA kernels, then move the data back to GR buffers.  Now that
>> data movement is done behind the scenes if the block is set up right so
>> that when the work function is hit, the data is in GPU device memory and
>> will get transferred back to CPU memory behind the scenes as well.  This
>> allows back to back HW accelerated blocks to not have to ingress/egress in
>> and out of GR memory unnecessarily.  Also, the single mapped buffer
>> abstraction brings huge performance benefits as can be seen here:
>> https://www.youtube.com/w

Re: OOT Binding problem

[Josh Morman]

Happy New Year to you as well!

If your bindings are simple you can rely on the regex parsing that is used
when pygccxml is not installed.  To try this out, just uninstall pygccxml
and re-run gr_modtool bind

Josh

On Fri, Jan 7, 2022 at 5:28 AM Fabien PELLET  wrote:

> Hello and happy new year !
>
> I rebuild all my SDCard based on the lastest Raspios bullseye which
> natively provided with python 3.9.2, rebuild all (UHD, VOLK, GNURADIO,
> CASTXML, etc.) and I always have the same issue with "gr_modtool bind"
> command...
>
> Any other idea to manage make it working on raspberrypi ?
>
> Best regards,
>
> Fabien, F4CTZ.
>
> Le 14/12/2021 à 15:18, Marcus Müller a écrit :
> > You can't, GNU Radio links against that.
> > I'd recommend not updating Python, you essentially can't.
> >
> > On 14.12.21 14:44, Fabien PELLET wrote:
> >> castxml was installed, pygccxml also in v1.9.1. I upgrade pygccxml to
> >> 2.2.1 without success.
> >>
> >> How to update python version (3.7 actually) without having to
> >> recompile gnuradio ?
> >>
> >> Le 14/12/2021 à 12:44, Josh Morman a écrit :
> >>> Sounds like castxml could be playing a role here.  Along the same
> >>> lines Ron suggested, you could try installing both pygccxml and
> >>> castxml from pip3
> >>>
> >>> Josh
> >>>
> >>> On Tue, Dec 14, 2021 at 6:23 AM Ron Economos  wrote:
> >>>
> >>> I've tried it on both Ubuntu 18.04 and 20.04, so I don't think
> >>> it's due
> >>> to the Python version.
> >>>
> >>> You could try the latest pygccxml. Use pip or pip3 to install.
> >>>
> >>> You could also try building CastXML from source. That's where
> >>> some of
> >>> the compiler dirty work is being done. For example, you need the
> >>> latest
> >>> CastXML for gcc 11.
> >>>
> >>> https://github.com/CastXML/CastXML
> >>>
> >>> You'll need to install clang and libclang-xx-dev (where xx
> >>> matches the
> >>> version of clang that was installed).
> >>>
> >>> Ron
> >>>
> >>> On 12/14/21 2:57 AM, Fabien PELLET wrote:
> >>> > Is that could be an incompatibility between Python3.7 that is
> >>> provide
> >>> > by RaspiOS repo and Pybind11 ?
> >>> >
> >>> > Fabien.
> >>> >
> >>> > Le 14/12/2021 à 11:54, Marcus Müller a écrit :
> >>> >> Uh, since bindtool is Python-only, this should really not be
> >>> >> platform-dependent. Unless we've got a problem with pygccxml,
> >>> that is...
> >>> >>
> >>> >> On 14/12/2021 11.51, Ron Economos wrote:
> >>> >>> I've never been able to get gr_modtool bind to work on
> >>> 32-bit ARM
> >>> >>> architecture (Ubuntu on a Beagleboard-X15). I get the same
> >>> error
> >>> >>> message.
> >>> >>>
> >>> >>> Ron
> >>> >>>
> >>> >>> On 12/14/21 2:15 AM, Fabien PELLET wrote:
> >>> >>>> Hello,
> >>> >>>>
> >>> >>>> I'm trying to write a simple OOT module. For exemple, I
> >>> create a
> >>> >>>> module "test" (gr-modtool newmod test) and I create a
> >>> general block
> >>> >>>> inside (gr-modtool add blablamodule) : everything fine up
> >>> to this
> >>> >>>> point.
> >>> >>>>
> >>> >>>> If now I modify the file "blablamodule.h" I have do a
> >>> "gr_modtool
> >>> >>>> bind blablamodule" to update the file
> >>> "blablamodule_python.cc" that
> >>> >>>> is in python/bindings" (if I do not do this, the cmake will
> >>> >>>> complain). I get in return after the parsing of my file
> >>> >>>> "blablamodule.h" the following error :
> >>> >>>>
> >>> >>>> ERROR error occured, while parsing element with name
> >>> "Field" and
> >>> >>>> attrs "['id', 'name', 'type', 'context', 'access', 'offset']"
> >>> >>>> Error: 'file'.
> >>> >>>> 'file'
> >>> >>>>
> >>> >>>> After several try without any success, I delete all file and
> >>> >>>> recreate the module and the block using gr-modtool and then
> >>> I try
> >>> >>>> just after creating it without modifying it to execute
> >>> "gr_modtool
> >>> >>>> bind blablamodule" inside the fresh newly created module
> >>> >>>> directory Same error !
> >>> >>>>
> >>> >>>> I read that I need to get pybind11 with a version > 2.5 so I
> >>> >>>> install it from source the v2.8 (well recognized as a cmake
> >>> command
> >>> >>>> tell that it detects the v2.8.1).
> >>> >>>>
> >>> >>>> I'm on a raspberry PI4 with GNURADIO 3.9.4, PYTHON 3.7.3,
> >>> PYBIND11
> >>> >>>> 2.8.1. What am I doing wrong ?
> >>> >>>>
> >>> >>>> I try on a other computer with GNURADIO 3.9.3, PYTHON
> >>> 3.8.10 and I
> >>> >>>> do not see the research of PYBIND11 but "gr_modtool bind
> >>> >>>> blablamodule" is working well
> >>> >>>>
> >>> >>>> Thanks for your help,
> >>> >>>>
> >>> >>>> Best regards,
> >>> >>>>
> >>> >>>> Fabien, F4CTZ.
> >>> >>>>
> >>> >>>>
> >>> >>>
> >>> >
> >>>
>
>

Re: Regarding open source

[Josh Morman]

Gunesh,

If you are generally interested in open source, find a project that you
would like to contribute to - maybe that is GNU Radio, maybe something else
you find along the way.  Familiarize yourself with the software and reach
out on the chat asking for ways you can get involved.  This might be at
first improving documentation or fixing minor issues.  There is a tag in
the github which is "good first issue" which can be good to tackle.  Once
you are ready to submit a pull request (contributing your code back to the
main repository), myself or others can help guide on some of the
particulars.

Josh

On Mon, Jan 3, 2022 at 11:57 AM Gunesh  wrote:

> hello sir,
> thank you for having me on board.
> As I am new to open source could you help me with getting started.
> and i have done only c++ language so could you help me by guiding me about
> where should i contribute.
>
>
>
> Regards
> Gunesh munjal
>
>
> On Mon, Jan 3, 2022 at 9:19 PM Josh Morman  wrote:
>
>> Hi Gunesh,
>>
>> Glad to hear you would like to contribute.  This is a great starting
>> point:
>> https://wiki.gnuradio.org/index.php/Development
>>
>> And also, it can be useful to join the conversation at chat.gnuradio.org
>> to ask questions
>>
>> Looking forward to seeing you get involved - it can be a great experience
>> and it is an excellent community to work with!
>>
>> Josh
>>
>> On Mon, Jan 3, 2022 at 10:02 AM Gunesh  wrote:
>>
>>>   Hello sir,
>>> I am Gunesh Munjal currently in 1st year. I am new to open source and
>>> want to contribute. As, I don't know how to get started with open source it
>>> would be great if you could help me out sir. I am having the knowledge of
>>> c++.Hoping to hear from you soon.
>>>
>>>
>>> regards
>>> gunesh munjal
>>>
>>>

Re: Regarding open source

[Josh Morman]

Hi Gunesh,

Glad to hear you would like to contribute.  This is a great starting point:
https://wiki.gnuradio.org/index.php/Development

And also, it can be useful to join the conversation at chat.gnuradio.org to
ask questions

Looking forward to seeing you get involved - it can be a great experience
and it is an excellent community to work with!

Josh

On Mon, Jan 3, 2022 at 10:02 AM Gunesh  wrote:

>   Hello sir,
> I am Gunesh Munjal currently in 1st year. I am new to open source and want
> to contribute. As, I don't know how to get started with open source it
> would be great if you could help me out sir. I am having the knowledge of
> c++.Hoping to hear from you soon.
>
>
> regards
> gunesh munjal
>
>

Re: OOT Binding problem

[Josh Morman]

Sounds like castxml could be playing a role here.  Along the same lines Ron
suggested, you could try installing both pygccxml and castxml from pip3

Josh

On Tue, Dec 14, 2021 at 6:23 AM Ron Economos  wrote:

> I've tried it on both Ubuntu 18.04 and 20.04, so I don't think it's due
> to the Python version.
>
> You could try the latest pygccxml. Use pip or pip3 to install.
>
> You could also try building CastXML from source. That's where some of
> the compiler dirty work is being done. For example, you need the latest
> CastXML for gcc 11.
>
> https://github.com/CastXML/CastXML
>
> You'll need to install clang and libclang-xx-dev (where xx matches the
> version of clang that was installed).
>
> Ron
>
> On 12/14/21 2:57 AM, Fabien PELLET wrote:
> > Is that could be an incompatibility between Python3.7 that is provide
> > by RaspiOS repo and Pybind11 ?
> >
> > Fabien.
> >
> > Le 14/12/2021 à 11:54, Marcus Müller a écrit :
> >> Uh, since bindtool is Python-only, this should really not be
> >> platform-dependent. Unless we've got a problem with pygccxml, that is...
> >>
> >> On 14/12/2021 11.51, Ron Economos wrote:
> >>> I've never been able to get gr_modtool bind to work on 32-bit ARM
> >>> architecture (Ubuntu on a Beagleboard-X15). I get the same error
> >>> message.
> >>>
> >>> Ron
> >>>
> >>> On 12/14/21 2:15 AM, Fabien PELLET wrote:
>  Hello,
> 
>  I'm trying to write a simple OOT module. For exemple, I create a
>  module "test" (gr-modtool newmod test) and I create a general block
>  inside (gr-modtool add blablamodule) : everything fine up to this
>  point.
> 
>  If now I modify the file "blablamodule.h" I have do a "gr_modtool
>  bind blablamodule" to update the file "blablamodule_python.cc" that
>  is in python/bindings" (if I do not do this, the cmake will
>  complain). I get in return after the parsing of my file
>  "blablamodule.h" the following error :
> 
>  ERROR error occured, while parsing element with name "Field" and
>  attrs "['id', 'name', 'type', 'context', 'access', 'offset']"
>  Error: 'file'.
>  'file'
> 
>  After several try without any success, I delete all file and
>  recreate the module and the block using gr-modtool and then I try
>  just after creating it without modifying it to execute "gr_modtool
>  bind blablamodule" inside the fresh newly created module
>  directory Same error !
> 
>  I read that I need to get pybind11 with a version > 2.5 so I
>  install it from source the v2.8 (well recognized as a cmake command
>  tell that it detects the v2.8.1).
> 
>  I'm on a raspberry PI4 with GNURADIO 3.9.4, PYTHON 3.7.3, PYBIND11
>  2.8.1. What am I doing wrong ?
> 
>  I try on a other computer with GNURADIO 3.9.3, PYTHON 3.8.10 and I
>  do not see the research of PYBIND11 but "gr_modtool bind
>  blablamodule" is working well
> 
>  Thanks for your help,
> 
>  Best regards,
> 
>  Fabien, F4CTZ.
> 
> 
> >>>
> >
>
>

Re: Release Candidate v3.10.0.0-rc1

[Josh Morman]

3.10.0.0-rc2 is now available:
https://github.com/gnuradio/gnuradio/releases/tag/v3.10.0.0-rc2
and you can see the current changelog here:
https://github.com/gnuradio/gnuradio/blob/master/CHANGELOG.md
The plan is to make a final release mid-January, so this may involve one
more RC if there are any more major issues to sort out.

Have a great weekend!

Josh

On Sat, Nov 27, 2021 at 10:29 AM Josh Morman  wrote:

> Greetings GNU Radio Community!
>
> Release 3.10 is expected to drop sometime in the new year, but to get the
> ball rolling with testing and packaging - we are expecting a longer than
> usual Release Candidate cycle, and likely there will be *at least* one
> more RC, so here is v3.10.0.0-rc1
> <https://github.com/gnuradio/gnuradio/releases/tag/v3.10.0.0-rc1>
>
> We have been fortunate this year to have extremely active backporting and
> consistent maintenance releases from co-maintainter Jeff Long - so many of
> the fixes and smaller feature (and larger ones) have already seen the light
> of day in the 3.9.x.x and even 3.8.x.x releases.  Here are some of the
> bigger features that are bringing about this major release.
>
> *gr-pdu*
> PDUs (protocol data units) in GNU Radio are a special type of PMT that
> have a dictionary and a uniform vector type representing a burst of data
> with some metadata.  Up to this point, support of pdus has been scattered
> throughout the codebase with minimal support for handling this type of data
> consistently.  Fortunately, Jacob Gilbert has been able to upstream much of
> the amazing work from himself and the team at Sandia National Labs which
> brings in-tree a suite of tools for manipulating these data objects (see
> https://github.com/sandialabs/gr-pdu_utils).  Also, many of the previous
> PDU processing blocks that existed in other in-tree modules have been
> migrated to this module, so there has been some block re-arrangement.
> Please see https://www.youtube.com/watch?v=bT60hVVte48 for more detailed
> information
>
> *gr-iio*
> IIO is the industrial I/O framework that provides an industry standard
> method for communicating with a wide-range of devices including many of the
> ADI SDR platforms.  Analog Devices has supported out of tree a gr-iio
> module that brings this capability into GNU Radio and now upstreamed this
> module so support for devices like the PlutoSDR are available out of the
> box.  Special thanks here to Adam Horden, Travis Collins, Dave Winter,
> Volker Shroer, and Jeff Long for bringing this in-tree and working through
> many of the complexities.
> Please see https://www.youtube.com/watch?v=2gKbollW6wg for a more
> technical description of IIO and gr-iio.
>
> *Custom Buffers Support*
> NOTE: this is an advanced "experimental" feature that if not actively
> employed will not affect normal GNU Radio usage.
> David Sorber from Black Lynx has introduced a feature that enables
> streamlined data movement between GNU Radio blocks and hardware
> accelerators.  By creating a "custom buffer" class (or using one that is
> provided by someone else), blocks can be made to abstract the data movement
> behind the scenes so that when the `work` function is reached, data already
> exists in the device memory.
> Let me give a quick example - previously if you wanted to write a GPU
> accelerated block with CUDA, you would have to get into the work function,
> move the data from the GNU Radio circular buffers to GPU device memory,
> execute the CUDA kernels, then move the data back to GR buffers.  Now that
> data movement is done behind the scenes if the block is set up right so
> that when the work function is hit, the data is in GPU device memory and
> will get transferred back to CPU memory behind the scenes as well.  This
> allows back to back HW accelerated blocks to not have to ingress/egress in
> and out of GR memory unnecessarily.  Also, the single mapped buffer
> abstraction brings huge performance benefits as can be seen here:
> https://www.youtube.com/watch?v=VO1zMXowezg for a much better description
>  For examples of this in action, please see the following repositories:
> https://github.com/BlackLynx-Inc/gr-cuda_buffer
> https://github.com/BlackLynx-Inc/gr-blnxngsched
> This out of tree support will soon find its way into the gnuradio github
> repo as a set of CUDA buffers and blocks.
>
> *Logging Infrastructure*
> Log4CPP has previously been our logging backend library, but has become a
> troublesome dependency.  A huge thanks to Marcus Müller for fixing all of
> this up, replacing Log4CPP with spdlog - a more modern logging library.
> This also opens up the door for more modern logging statements that don't
> rely on Boost.format, and libfmt (which is now also a dependency) can be
> used fo

Re: Calling blocks directly

[Josh Morman]

This sounds like a very interesting project - but separating out the calls
to blocks from the underlying framework is very difficult in GNU Radio for
many reasons, but one being that the blocks call back into the scheduler
for things like getting the number of items read/written, and updating
buffer pointers and such.

Separating the block API so the blocks can be used for this purpose
(integration of the core signal processing work() calls with external
frameworks) is a goal of the GR 4.0 framework (newsched).  If you are
interested in doing this with newsched (https://github.com/gnuradio/newsched)
- we can port more blocks in from GNU Radio that might be of interest.

Josh

On Mon, Nov 29, 2021 at 2:01 PM Jeff Long  wrote:

> To do this, you write a "mock" framework that calls the block init, then
> calls general_work() or work() with the proper parameters. I'd say you need
> to understand the C++ API for blocks pretty well to make this work. How
> much of the framework you need to implement will depend on which blocks you
> use.
>
> On Mon, Nov 29, 2021 at 1:28 PM Andra-Maria Ilies <
> andramariail...@gmail.com> wrote:
>
>> Hello,
>>
>>
>> I am trying to write a full-program optimizer for GNURadio flow graphs in
>> C++. For this purpose, I need to call GNURadio blocks separately inside my
>> program.
>>
>>
>> I have 2 questions:
>>
>>1. How to directly feed a local vector input to a block?
>>2. How can I set a local array as the output array of the used block?
>>
>>
>> I would like to mention that I want to do this directly, without using
>> GNU Radio specific functions such as connect(), because I will be using
>> only certain blocks, whose operation I find useful for my application.
>>
>>
>> Thank you in advance!
>>
>> Andra
>>
>

Release Candidate v3.10.0.0-rc1

[Josh Morman]

Greetings GNU Radio Community!

Release 3.10 is expected to drop sometime in the new year, but to get the
ball rolling with testing and packaging - we are expecting a longer than
usual Release Candidate cycle, and likely there will be *at least* one more
RC, so here is v3.10.0.0-rc1


We have been fortunate this year to have extremely active backporting and
consistent maintenance releases from co-maintainter Jeff Long - so many of
the fixes and smaller feature (and larger ones) have already seen the light
of day in the 3.9.x.x and even 3.8.x.x releases.  Here are some of the
bigger features that are bringing about this major release.

*gr-pdu*
PDUs (protocol data units) in GNU Radio are a special type of PMT that have
a dictionary and a uniform vector type representing a burst of data with
some metadata.  Up to this point, support of pdus has been scattered
throughout the codebase with minimal support for handling this type of data
consistently.  Fortunately, Jacob Gilbert has been able to upstream much of
the amazing work from himself and the team at Sandia National Labs which
brings in-tree a suite of tools for manipulating these data objects (see
https://github.com/sandialabs/gr-pdu_utils).  Also, many of the previous
PDU processing blocks that existed in other in-tree modules have been
migrated to this module, so there has been some block re-arrangement.
Please see https://www.youtube.com/watch?v=bT60hVVte48 for more detailed
information

*gr-iio*
IIO is the industrial I/O framework that provides an industry standard
method for communicating with a wide-range of devices including many of the
ADI SDR platforms.  Analog Devices has supported out of tree a gr-iio
module that brings this capability into GNU Radio and now upstreamed this
module so support for devices like the PlutoSDR are available out of the
box.  Special thanks here to Adam Horden, Travis Collins, Dave Winter,
Volker Shroer, and Jeff Long for bringing this in-tree and working through
many of the complexities.
Please see https://www.youtube.com/watch?v=2gKbollW6wg for a more technical
description of IIO and gr-iio.

*Custom Buffers Support*
NOTE: this is an advanced "experimental" feature that if not actively
employed will not affect normal GNU Radio usage.
David Sorber from Black Lynx has introduced a feature that enables
streamlined data movement between GNU Radio blocks and hardware
accelerators.  By creating a "custom buffer" class (or using one that is
provided by someone else), blocks can be made to abstract the data movement
behind the scenes so that when the `work` function is reached, data already
exists in the device memory.
Let me give a quick example - previously if you wanted to write a GPU
accelerated block with CUDA, you would have to get into the work function,
move the data from the GNU Radio circular buffers to GPU device memory,
execute the CUDA kernels, then move the data back to GR buffers.  Now that
data movement is done behind the scenes if the block is set up right so
that when the work function is hit, the data is in GPU device memory and
will get transferred back to CPU memory behind the scenes as well.  This
allows back to back HW accelerated blocks to not have to ingress/egress in
and out of GR memory unnecessarily.  Also, the single mapped buffer
abstraction brings huge performance benefits as can be seen here:
https://www.youtube.com/watch?v=VO1zMXowezg for a much better description
 For examples of this in action, please see the following repositories:
https://github.com/BlackLynx-Inc/gr-cuda_buffer
https://github.com/BlackLynx-Inc/gr-blnxngsched
This out of tree support will soon find its way into the gnuradio github
repo as a set of CUDA buffers and blocks.

*Logging Infrastructure*
Log4CPP has previously been our logging backend library, but has become a
troublesome dependency.  A huge thanks to Marcus Müller for fixing all of
this up, replacing Log4CPP with spdlog - a more modern logging library.
This also opens up the door for more modern logging statements that don't
rely on Boost.format, and libfmt (which is now also a dependency) can be
used for general string manipulation as well.  All the previous methods and
macros still exist (except for the log4cpp specific ones), but there is now
new capability to log in a more convenient way using the libfmt statements.

Old: GR_LOG_INFO(this->d_logger, boost::format("this happened: %d") % code)
New: this->d_logger->info("this happened {:d}", code)

As always, please reach out here or on chat.gnuradio.org if you have any
questions - and file GitHub issues if you find bugs or problems with the
release.  The step from 3.9 should be pretty minimal, but if you are
migrating your OOTs - please update the porting guide if you come across
differences that need to be documented:
https://wiki.gnuradio.org/index.php/GNU_Radio_3.10_OOT_Module_Porting_Guide

Have a happy Holiday season and much thanks to all 

newsched (GR4 proposed runtime) v0.1.0 Released

[Josh Morman]

Hello GR Community!

It has finally come time to put out a newsched release - up to this point
the codebase has been rapidly evolving, but has converged on a set of core
features as of recently.

https://github.com/gnuradio/newsched/releases/tag/v0.1.0

Newsched is the proof of concept framework for a future GNU Radio 4.0

Core Features

   - Modular Scheduler Framework
  - interfaces based on a single input queue
  - default scheduler with N blocks/thread
   - Custom Buffers
   - YAML-driven Block Workflow
   - Consolidated Parameter Access Mechanisms
   - Simplified Block APIs

Detailed documentation can be found here


With this release of newsched, you can easily create your own blocks,
custom buffers, and even your own scheduler if you are so inclined

Special thanks to Bastian Bloessl and Marcus Müller for leading the effort
to architect the runtime and provide guidance as to the design decisions

Also want to acknowledge the Scheduler Working Group who have consulted and
provided feedback and ideas on a regular basis about design decisions. I
apologize if I have left anyone out here, but another special thanks to:
Seth Hitefield, Jeff Long, David Sorber, Mike Piscopo, Jacob Gilbert, Marc
Lichtman, Philip Balister, Jim Kulp, Wylie Standage, Garrett Vanhoy, John
Sallay, and all the people associated with with the DARPA DSSoC program
that shared their research giving valuable insight.

Please reach out to me here or on chat.gnuradio.org - #scheduler room if
you have any questions or would like to get involved

Josh

Re: Calculating Symbol Sync Parameters

[Josh Morman]

There is a lot of information in this talk from GRCon:

https://youtu.be/uMEfx_l5Oxk


On Tue, Nov 9, 2021 at 10:15 PM  wrote:

> Hello all,
>
>
>
> I’ve been working with the symbol sync block and I was wondering how to
> calculate the parameters (TED Gain, Loop bandwidth, etc) given information
> from the protocol.  There are some answers to how to calculate the TED gain
> on the internet but are still unclear to me, so hopefully someone out there
> can clarify.  Any help would be appreciated
>
>
>
> Thanks,
>
> Patrick
>

Re: Information on the hackfest2110

[Josh Morman]

Hi Mike,

It looks like the streamed videos from twitch have disappeared (as they do
after a couple weeks).  Official support for the "custom buffers"
functionality will be a part of the 3.10 release, and I'm working on
putting together a gr-cuda OOT that will capture the basics of how to use
these custom buffers and do processing in CUDA.

In the meantime, the OOT used for the hackfest session is here:
https://github.com/mormj/gr-cudademo

Mainly, take a look at the differences between the main and custom_buffers
branches to see how custom buffers are used.

Thanks,
Josh

On Tue, Nov 9, 2021 at 5:54 PM Michael Seguin  wrote:

> Hello Gnuradio list,
>
> I was wondering if anyone had any info on the hackfest2110. I didn't know
> it was going on as I am new to GNUradio and would like to use CUDA with
> GNUradio on USRPs.
>
> Thanks,
>
> Mike Seguin
>

Re: ModuleNotFoundError: No module named 'tutorial'

[Josh Morman]

Sounds like a python path issue.  Please ensure that the PYTHONPATH
environment variable is set to include wherever directory `make install`
placed things.  PYTHONPATH by default includes /usr/lib/python3.8/... but
does not automatically search for /usr/local/lib/python3.8/...

Can you share where things went when you did `make install`?

Thanks,
Josh

On Sun, Oct 31, 2021 at 8:07 AM Nikoloz Glonti  wrote:

> Dear Gnuradio Community,
>
> I built and installed tutorial module with qpsk demod block inside -
> just from tutorial on
> "https://wiki.gnuradio.org/index.php/Guided_Tutorial_GNU_Radio_in_C%2B%2B";
> .
> I get an error:
>
>File "/home/ng/test.py", line 35, in 
>  import tutorial
> ModuleNotFoundError: No module named 'tutorial'
>
>
> How can I fix that? I use GRC version 3.9.
>
> Thanks for help
>
> Niko
>
>
>

Re: Problem building OOTs with GR 3.9.3.0 PPA package

[Josh Morman]

I've requested deletion of the pybind11 package from the PPA (this takes a
few hours) - it should not be in there as 20.04 has a decent version of
pybind11.  So at least by tomorrow, uninstalling  pybind11 and reinstalling
should resolve the issue.


On Sat, Oct 16, 2021 at 2:56 PM schneider  wrote:

> Hi,
>
> so I think I have an idea what happened:
>
> My guess is that the 20.04 PPA was built using pybind11 2.4.3-2build2:
>
> https://launchpadlibrarian.net/563330294/buildlog_ubuntu-focal-amd64.gnuradio_3.9.3.0-0~gnuradio~focal-3_BUILDING.txt.gz
>
> If I uninstall the pybind11 version from the PPA and install pybind11
> from the Ubuntu repositories, I can compile and run our OOT:
>
> apt install pybind11-dev=2.4.3-2build2
>
> I guess the PPA needs to be built again against the pybind11 version
> which is included in the PPA.
>
> Best
> schneider
>
>
> On 16.10.21 20:35, Daniel Estévez wrote:
> > Hi,
> >
> > I can confirm that when the Docker container builds, it's installing
> > pybind11-dev 2.5.0 from the PPA, as schneider mentions.
> >
> > This happens in
> > https://github.com/daniestevez/gr-satellites/runs/3910245472
> >
> > Get:406 http://ppa.launchpad.net/gnuradio/gnuradio-releases/ubuntu
> > focal/main amd64 pybind11-dev all 2.5.0-4~ubuntu20.04.1~ppa1 [138 kB]
> >
> > Yet I get the import error. So it seems something is wrong regarding the
> > pybind11-dev package in the PPA?
> >
> > Best,
> >
> > Dani
> >
> > El 16/10/21 a las 20:10, schneider escribió:
> >> Hi
> >>
> >> I'm experiencing the same issue with our OOT. I've got pybind11-devc
> >> 2.5.0-4~ubuntu20.04.1~ppa1 installed from the PPA.
> >>
> >> If I also install gnuradio-dev from the PPA, I get the error mentioned
> >> by Daniel. If I build GNURadio 3.9.3 from source (same pybind version as
> >> mentioned above), the error goes away.
> >>
> >> It's not obvious to me what happening. My first questions would be: Was
> >> gnuradio-dev in the PPA built using the pybind11 version which is
> >> available in the PPA? Does pybind11 version in the PPA need an update?
> >>
> >> Best
> >> schneider
> >>
> >> On 15.10.21 22:55, Ron Economos wrote:
> >>> I just went through this myself with a user of my OOT's. It's due to a
> >>> pybind11 version mismatch. The PPA is built with pybind11 v2.5.0 and if
> >>> your system (such as Ubuntu 20.04) has a different version, you get
> that
> >>> import error.
> >>>
> >>> You have to build/install pybind11 v2.5.0 on your system to resolve the
> >>> issue.
> >>>
> >>> Here's the issue on my Github for reference.
> >>>
> >>> https://github.com/drmpeg/gr-dvbgse/issues/3
> >>>
> >>> Ron
> >>>
> >>> On 10/15/21 12:30 PM, Daniel Estévez wrote:
>  Hi,
> 
>  I've encountered a problem in the gr-satellites continuous integration
>  that I've traced to the change from GNU Radio 3.9.2.0 to 3.9.3.0 in
>  the Ubuntu 20.04 PPA package (which is what I'm using in my CI Docker
>  container).
> 
>  The problem is that after building gr-satellites from source using GNU
>  Radio 3.9.3.0 from the PPA package I get this error when importing the
>  Python module:
> 
>  Traceback (most recent call last):
> File "", line 1, in 
> File "/usr/local/lib/python3/dist-packages/satellites/__init__.py",
>  line 44, in 
>   from .satellites_python import *
>  ImportError: generic_type: type "ax100_decode" referenced unknown base
>  type "gr::block"
> 
>  The are no unusual messages during the compilation of gr-satellites.
> 
>  If instead of using the PPA package I build GNU Radio 3.9.3.0 from
>  source, then everything works.
> 
>  I haven't tried to do this with other OOT modules. Has anyone
>  encountered this problem?
> 
>  I have some Dockerfiles that can be used to replicate this problem.
>  See here:
> 
> 
> https://github.com/daniestevez/gr-satellites/issues/303#issuecomment-944604966
> 
> 
> 
>  Best,
>  Dani.
> 
> >>>
> >>
> >
> >
>
>

Re: ModToolException: Could not find gr-newmod source dir.

[Josh Morman]

What OS/Distribution and how is GNU Radio installed?

Josh

On Tue, Oct 5, 2021 at 5:20 AM sp h  wrote:

> in Gnuradio-dev 3.9 when I want to create a block I am faced with this
> error... how can solve it...
>
> gr_modtool newmod tutorial ModToolException: Could not find gr-newmod
> source dir.
>
>
> thanks in advance
>

GRCon21 Regular Registration Ends Tomorrow

[Josh Morman]

GRCon21 in Charlotte, NC is just 3 weeks away!

Late Registration for GRCon21 starts September 1, so please make sure to
register by tomorrow:
https://tickets.gnuradio.org/grcon21/

The schedule is quite full but we are still accepting any last minute
submissions, especially for workshops, so please submit anything ASAP.
https://events.gnuradio.org/event/8/

We look forward to seeing you there (or virtually if that is the case)!

Josh

Re: How to debug GNU Radio's C++ program from source code?

[Josh Morman]

Step 1: Open the source tree in VScode. What does the source tree here
refer to? A directory? I am using GNUradio built from source installation.
Which directory should I open? Is it the one before or after the
installation? Where is the source tree after installation?
-- source tree referring to the level of code where you clone it from
github - https://github.com/gnuradio/gnuradio/  <-- at that level
-- the source tree is the same before and after installation, you just
compile into a build/ directory and install the compiled libraries
somewhere in /usr or a custom prefix.   But the source stays where it is

Step 2: Is the setting of "args" the absolute path of the Python program I
want to debug?
-- Yes
Whether it can exist anywhere on the computer, but after I entered the
path, the font turned red. Obviously, something went wrong.
-- be sure to enclose in double quotes for this json file

One last question: If I want to modify the function of an existing module,
do I create a new OOT module and then copy the content of the original
module to modify it?
-- that is one way to do it.  if it something that you are fixing within
gnuradio and plan to push back to the main repo, then you can change things
directly in the gnuradio source, but if it is just for experimentation or
adding some non-standard functionality, OOT will save you some compile time
and make it easier to debug.

Josh

On Tue, Aug 3, 2021 at 10:23 PM 能书能言 <2127629...@qq.com> wrote:

> Hi,
> Thank you very much for your suggestions, this is exactly what I want, I
> am a novice, do not have a lot of experience in program debugging, and
> there are some details I haven't figured out.
>
> Step 1: Open the source tree in VScode. What does the source tree here
> refer to? A directory? I am using GNUradio built from source installation.
> Which directory should I open? Is it the one before or after the
> installation? Where is the source tree after installation?
>
> Step 2: Is the setting of "args" the absolute path of the Python program I
> want to debug? Whether it can exist anywhere on the computer, but after I
> entered the path, the font turned red. Obviously, something went wrong.
>
> One last question: If I want to modify the function of an existing module,
> do I create a new OOT module and then copy the content of the original
> module to modify it?
> Sincerely
>
>
> -- 原始邮件 --
> *发件人:* "Josh Morman" ;
> *发送时间:* 2021年8月3日(星期二) 晚上9:48
> *收件人:* "能书能言"<2127629...@qq.com>;
> *抄送:* "discuss-gnuradio";
> *主题:* Re: How to debug GNU Radio's C++ program from source code?
>
> Hello!
>
> Even though GNU Radio has python bindings with swig or pybind11, the
> underlying code c++ symbols are still accessible with GDB. Using Visual
> Studio Code and GNU Radio compiled from source with Debug Symbols this is
> pretty straightforward:
> 1) Open up the source tree of gnuradio in visual studio code
> 2) edit the launch.json and add a C++/GDB configuration where program is
> python and args is the output of the GRC rendering
> {
> "name": "(gdb) Launch",
> "type": "cppdbg",
> "request": "launch",
> "program": "/usr/bin/python3",
> "args": ["/path/to/grc_output.py"],
> "stopAtEntry": false,
> "cwd": "${workspaceFolder}",
> "environment": [],
> "externalConsole": false,
> "MIMode": "gdb",
> "setupCommands": [
> {
> "description": "Enable pretty-printing for gdb",
> "text": "-enable-pretty-printing",
> "ignoreFailures": true
> }
> ]
> },
> 3) put the breakpoint where you want to hit - note that GR will have been
> compiled with optimizations, so the breakpoints might be a bit funky
> 4) F5 to run the application
>
> If you are debugging your own OOT, this makes it even simpler because you
> can compile as "-DCMAKE_BUILD_TYPE=Debug" and then your breakpoints will be
> very predictable - in this case you just open up VS code from the root of
> your project and follow the same steps.
>
> Hope this helps.
>
> Josh
>
>
>
> On Tue, Aug 3, 2021 at 8:41 AM 能书能言 <2127629...@qq.com> wrote:
>
>> Hi guys!
>> I want to know how to debug c++ code in gnuradio. As far as I know, after
>> we run GRC, a Python file will be generated. The Python file conne

Re: How to debug GNU Radio's C++ program from source code?

[Josh Morman]

Hello!

Even though GNU Radio has python bindings with swig or pybind11, the
underlying code c++ symbols are still accessible with GDB. Using Visual
Studio Code and GNU Radio compiled from source with Debug Symbols this is
pretty straightforward:
1) Open up the source tree of gnuradio in visual studio code
2) edit the launch.json and add a C++/GDB configuration where program is
python and args is the output of the GRC rendering
{
"name": "(gdb) Launch",
"type": "cppdbg",
"request": "launch",
"program": "/usr/bin/python3",
"args": ["/path/to/grc_output.py"],
"stopAtEntry": false,
"cwd": "${workspaceFolder}",
"environment": [],
"externalConsole": false,
"MIMode": "gdb",
"setupCommands": [
{
"description": "Enable pretty-printing for gdb",
"text": "-enable-pretty-printing",
"ignoreFailures": true
}
]
},
3) put the breakpoint where you want to hit - note that GR will have been
compiled with optimizations, so the breakpoints might be a bit funky
4) F5 to run the application

If you are debugging your own OOT, this makes it even simpler because you
can compile as "-DCMAKE_BUILD_TYPE=Debug" and then your breakpoints will be
very predictable - in this case you just open up VS code from the root of
your project and follow the same steps.

Hope this helps.

Josh



On Tue, Aug 3, 2021 at 8:41 AM 能书能言 <2127629...@qq.com> wrote:

> Hi guys!
> I want to know how to debug c++ code in gnuradio. As far as I know, after
> we run GRC, a Python file will be generated. The Python file connects
> various blocks, but if I debug this Python file directly, I cannot observe
> the internal operations of the C++ block. I want to know if there is any
> way to let me Can I see the contents of the c++work function when I run the
> python file? It's like executing a pure Python or pure C++ program.
> If this is not possible because of the swig connection method, how can I
> observe the work of a C++ block's work function? If I look at the code
> directly, it is definitely not accurate enough. Can I write a demo by
> myself? Or other ways.
> In addition, how to edit an existing block? I just want to modify its
> function slightly. Do I have to use gr_modtool to create a new OOT module
> and rewrite it based on the contents of the original block? You must also
> use debugging methods when writing, but I don't know how to do it.
> in addition. I have tried the tutorials on the official website, but none
> of them worked. I also checked the previous mailing list, but it was not
> very helpful. I think anyone has a better solution?
> Sincerely
>
>

Re: GRC port type assignment in Python Block

[Josh Morman]

Hi Jerrid,

Your attempt at using structures to map to a complex type is sensible, but
it appears that GRC doesn't parse this very well for at least the embedded
python blocks.  The UHD blocks are c++ based which just uses the
io_signature object in the constructor which specifies a size, not a type.

You may want to try just using non-vectored int16's as an interleaved
stream and deinterleave in your python block

Josh

On Thu, Jul 22, 2021 at 7:21 PM Jerrid Plymale 
wrote:

> Hello All,
>
>
>
> I am trying to write a python block that will convert shorts to complex
> int16, and I am having some difficulties. I have a need for this block so
> that I can read int16 data from a file using the file source block, and
> then transmit that data to a USRP X310 using a UHD USRP sink using complex
> int16 input type.
>
>
>
> The problem I am having is being able to set out_sig within the block init
> to a numpy dtype representation of complex int16. I tried using the
> following: np.dtype([(‘re’, np.int16), (‘im’, np.int16)]). I get the
> following error when using this: Can’t map dtype([(‘re’, ‘ ’
>
>
> Does anyone know of a way to set the out_sig in a python block to a
> complex int16 type that will map to the complex int16 GRC port type? I
> figure this must be doable if the UHD USRP blocks have complex int16 GRC
> port types.
>
>
>
> Best Regards,
>
> Jerrid
>

GNU Radio 3.10 Release Plans - OOT migration

[Josh Morman]

Hello Everyone!

As we've mentioned on the project calls and elsewhere, the current plan is
to release v3.10 of GNU Radio prior to GRCon (Sept 20-24, go register here:
events.gnuradio.org/e/grcon21).  3.10 is a much smaller step from 3.9 than
was 3.8 from 3.7 or 3.9 from 3.8.  There are, however, some things that
could impact your OOTs in the process of migration - but we haven't
captured all of them yet, only that there is some more c++ modernization
(up to c++17 features) and changes to includes in headers.

We encourage OOT authors to follow the branching strategy of the main
gnuradio repo, that is the master branch in the OOT should be compatible
with the master branch in gnuradio, maint-3.9 compatible with maint-3.9,
etc.

So as you migrate your OOTs to work with the master branch, please note any
special steps involved by editing the wiki here:

https://wiki.gnuradio.org/index.php/GNU_Radio_3.10_OOT_Module_Porting_Guide

as it will be useful to the entire community.  Or, just respond to this
email if you don't want to bother with the wiki.

Again, I'm hoping the step is very small, but would be great to figure out
earlier rather than later, and any issues in the main codebase can be
ironed out and/or documented ahead of the release.

Josh

Re: Releases v3.8.3.1 and v3.9.2.0

[Josh Morman]

Thanks Jeff for pulling together these releases.  The Ubuntu PPAs have been
updated to reflect the latest (thanks to Maitland for the updated debian
build projects to copy from):

https://wiki.gnuradio.org/index.php/InstallingGR#Ubuntu_PPA_Installation



On Thu, Jun 10, 2021 at 5:51 PM Jeff Long  wrote:

> Releases v3.8.3.1 and v3.9.2.0 are tagged and available on Github.
> Download tar/zip files from https://github.com/gnuradio/gnuradio/releases,
> or git clone your preferred tag/branch, and enjoy!
>
> The most visible changes for users:
> - Both releases have a number of updates to GRC.
> - v3.9 now includes gr-soapy. See
> https://wiki.gnuradio.org/index.php/Soapy for more details.
>
> See the release notes on the Github releases page or the CHANGELOG.md in
> each release for a longer list.
>

gr-iio now merged onto master branch

[Josh Morman]

Greetings GR community!

Thanks to the work of many people over a long period of time, gr-iio, which
brings in direct support for Analog Devices hardware including the Pluto
SDR into GNU Radio, has been merged in-tree.

Special thanks the people that put the effort in here to develop this
module and bring it in-tree (sorry for anyone I miss):
Travis Collins and the team at ADI  (original gr-iio OOT and original PR)
Adam Horden (Managed the feature branch, CI, shepherding the contributions
to the latest PR, getting up to 3.9/3.10 interfaces)
Ryan Long
Volker Schroer
Jeff Long
Edward Kigwana

gr-iio will build from source as long as CMake detects appropriately
versioned libiio and optionally libad9361.

Currently the pluto sdr is supported with Pluto Source and Pluto Sink
blocks.  We intend to re-enable the fmcomms2/5 blocks after any issues are
worked out with the pluto blocks.  Please report any issues you come across
either here or to the github tracker (if you are sure it is an issue).

Josh

Re: issues porting C++ OOT to 3.9 - fails at runtime import

[Josh Morman]

Tom,

It looks like the OOT might be using a different version of pybind11 than
the ppa version of gnuradio was built against.  The PPA for 20.04 appears
to have been built using pybind11 v2.5.0, but the default with Ubuntu 20.04
is 2.4.3.

I can repeat the symptom you see when creating a docker that has
pybind11-dev v.2.4.3 from the main Ubuntu repos, but then pull gnuradio
from ppa:gnuradio-releases.  After installing gnuradio from the ppa, if I
then do:
apt upgrade pybind11-dev

then the OOT will compile and load properly.

I can probably fix this in the PPA by removing the pybind11 packages and
just relying on what gets shipped with Ubuntu, but for now, maybe a ` apt
upgrade pybind11-dev ` will fix the issue.

Josh

On Sun, May 9, 2021 at 7:18 PM Tom McDermott  wrote:

> I built a new VM from zero.  Ubuntu 20.04
> apt install build-essential
> apt install git
> apt install cmake
> apt install python3-pip
> pip3 install pygccxml
> build, install pybind11 from 2.4.3 tarball
> setup gnuradio repository to releases
> apt install gnuradio
>This gives gnuradio 3.9.1.0
>
> git-cloning both Ron's gr-iqlevels and my gr-hpsdr, going through cmake,
> make, sudo make install, sudo ldconfig
> yields exactly the same results as before:  the gr:sync_block
> (gr-iqlevels)  or the gr::block (gr-hpsdr)  are not imported.
>
> -- Tom, N5EG
>
>
>
>
>
>
> On Sun, May 9, 2021 at 11:44 AM Tom McDermott  wrote:
>
>> Hi Ron - thank you for sending me the link to your 3.9 gr-iqlevels module
>> !
>> It builds and installs OK, but when trying to run it gives me the same
>> type of error as my own module:
>>
>> Note: cmake .. -DCMAKE_INSTALL_PREFIX=/usr   was used for for gr-iqlevels
>>
>> $ python3
>> Python 3.8.5 (default, Jan 27 2021, 15:41:15)
>> [GCC 9.3.0] on linux
>> Type "help", "copyright", "credits" or "license" for more information.
>> >>> import gnuradio
>> >>> import iqlevels
>> Traceback (most recent call last):
>>   File "", line 1, in 
>>   File "/usr/lib/python3/dist-packages/iqlevels/__init__.py", line 18, in
>> 
>> from .iqlevels_python import *
>> ImportError: generic_type: type "iqlevels" referenced unknown base type
>> "gr::sync_block"
>> >>>
>>
>> And when run from GRC:
>>
>> Traceback (most recent call last):
>>   File "/home/tom/Desktop/iqlevels.py", line 142, in 
>> main()
>>   File "/home/tom/Desktop/iqlevels.py", line 120, in main
>> tb = top_block_cls()
>>   File "/home/tom/Desktop/iqlevels.py", line 81, in __init__
>> self.iqlevels_iqlevels_0 = iqlevels.iqlevels(samp_rate, 1)
>> AttributeError: type object 'iqlevels' has no attribute 'iqlevels'
>>
>>
>> So it appears there is something wrong or misconfigured in my system.
>> I am baffled as to what that might be.
>>
>> Ubuntu 20.04
>> Gnuradio 3.9.0.0
>> Python 3.8.5
>> Cmake 3.16.3
>> GCC 9.3.0
>> pygccxml  2.1.0  installed using pip3
>> pybind11-2.4.3 installed from tarball according to the OOT 3.9
>> instructions
>>   pybind11 build, cmake, make, make install by the above directions.
>>it put the various pybind headers into /usr/local/include/pybind11/
>>
>> Is there some other configuration, path, or other thing that needs to be
>> setup?
>>
>> -- Tom, N5EG
>>
>>
>>
>>
>>

Re: gr 3.9 OOT execution error: unknown base type gr::block

[Josh Morman]

That looks right.  And in python_bindings.cc, do you see the import of base
block methods like:

PYBIND11_MODULE(blocks_python, m)
{
// Initialize the numpy C API
// (otherwise we will see segmentation faults)
init_numpy();

// Allow access to base block methods
py::module::import("gnuradio.gr");

On Wed, May 5, 2021 at 11:21 AM Tom McDermott  wrote:

> Hi Josh - thanks for your help.
>
> from ./python/bindings/hermesNB_python.cc:
>
> void bind_hermesNB(py::module& m)
> {
>
> using hermesNB= ::gr::hpsdr::hermesNB;
>
>
> py::class_ std::shared_ptr>(m, "hermesNB", D(hermesNB))
>
> .def(py::init(&hermesNB::make),
>py::arg("RxFreq0"),
> ... long list of arguments...
>   D(hermesNB,make)
> )
>
> -- Tom, N5EG
>
>
> On Wed, May 5, 2021 at 7:26 AM Josh Morman  wrote:
>
>> Tom,
>>
>> What does your hermesNB_python.cc look like?
>>
>> There should be a declaration for the binding in there that looks like:
>> py::class_>gr::sync_block,
>>gr::block,
>>gr::basic_block,
>>
>> or something to that effect.  It could be that modtool didn't add the
>> parent classes so that the inherited methods show up in the bindings.  If
>> so, that is a bug.  I'm just thinking that what you are seeing would be the
>> case if gr:;block wasn't a part of the declaration of the binding (which
>> should happen automatically)
>>
>> I don't think it is related to the capitalization of the category name -
>> in the code, the module is all lowercase.
>>
>> Josh
>>
>> On Wed, May 5, 2021 at 10:20 AM Tom McDermott  wrote:
>>
>>> I'm working on porting my OOT to gr 3.9  The 3.7 and 3.8 versions work
>>> fine.
>>> The ported code is compiled and make installed.  My OOT is visible in
>>> GRC, and
>>> I've added to a new flowgraph.
>>>
>>> My OOT is in category HPSDR  and the module is hermesNB (of several).
>>>
>>> When I try to execute a simple flowgraph in GRC with this OOT I get the
>>> following error:
>>>
>>> Traceback (most recent call last):
>>>   File "/home/tom/Desktop/Test_AM.py", line 38, in 
>>> import hpsdr
>>>   File "/usr/lib/python3/dist-packages/hpsdr/__init__.py", line 18, in
>>> 
>>> from .hpsdr_python import *
>>> ImportError: generic_type: type "hermesNB" referenced unknown base type
>>> "gr::block"
>>>
>>> Do I need to add code somewhere to import gr::block   ??
>>>
>>> Is there an issue with capitalization of  hpsdr  vs. category name of
>>> HPSDR  ??
>>>
>>> -- Tom, N5EG
>>>
>>>
>>>
>>>
>>>

Re: gr 3.9 OOT execution error: unknown base type gr::block

[Josh Morman]

Tom,

What does your hermesNB_python.cc look like?

There should be a declaration for the binding in there that looks like:
py::class_ wrote:

> I'm working on porting my OOT to gr 3.9  The 3.7 and 3.8 versions work
> fine.
> The ported code is compiled and make installed.  My OOT is visible in GRC,
> and
> I've added to a new flowgraph.
>
> My OOT is in category HPSDR  and the module is hermesNB (of several).
>
> When I try to execute a simple flowgraph in GRC with this OOT I get the
> following error:
>
> Traceback (most recent call last):
>   File "/home/tom/Desktop/Test_AM.py", line 38, in 
> import hpsdr
>   File "/usr/lib/python3/dist-packages/hpsdr/__init__.py", line 18, in
> 
> from .hpsdr_python import *
> ImportError: generic_type: type "hermesNB" referenced unknown base type
> "gr::block"
>
> Do I need to add code somewhere to import gr::block   ??
>
> Is there an issue with capitalization of  hpsdr  vs. category name of
> HPSDR  ??
>
> -- Tom, N5EG
>
>
>
>
>

Re: GNU Radio 3.9 gr_modtool problem

[Josh Morman]

Check your ~/.gnuradio/config.conf file.  In there is a section [modtool]
and a "newmod_path=..."
Verify that matches the value of your installed path.
On mine it says:
[modtool]
newmod_path =
/share/gnuradio/gr39/share/gnuradio/modtool/templates/gr-newmod
For 3.9, there was a slight change in the behavior how GR finds the newmod
path:
https://github.com/gnuradio/gnuradio/pull/3266
in that it will look wherever the currently installed prefix is, which can
be seen with
gnuradio-config-info --prefix
Make sure your environment variables are sourced correctly - PATH,
PYTHONPATH, LD_LIBRARY_PATH, and LIBRARY_PATH


On Tue, May 4, 2021 at 5:50 PM Ralf Gorholt  wrote:

> Dear all,
>
> on my Linux Mint (Ubuntu) box, I have installed and compiled GNU Radio
> 3.9 from source (master branch) as described here:
>
> https://wiki.gnuradio.org/index.php/UbuntuInstall#Focal_Fossa_.2820.04.29
>
> and here:
>
> https://wiki.gnuradio.org/index.php/InstallingGR#From_Source
>
> CMAKE_INSTALL_PREFIX is /usr.
>
> GNU Radio compiles (without UHD and soapy support) and the tests are ok.
> gnuradio-companion starts and everything seems ok. However, when I try
> to create a new module with "gr_modtool newmod dl5eu", I get the error
> message: ModToolException: Could not find gr-newmod source dir.
>
> I have also tried what was necessary for Ubuntu 18:
>
> $ cd /usr/share/gnuradio/modtool/templates/gr-newmod
> $ sudo py3clean .
>
> but this did not solve the problem.
>
> With version 3.8 compiled from the maint-3.8 branch I don't have this
> problem. Do you have an idea what I am doing wrong here?
>
> Thank you very much.
>
> Kind regards,
>
> Ralf
>
>

Re: Merging Multiple blocks into one

[Josh Morman]

There is currently no way to merge blocks in GNU Radio without manually
merging as you describe.  In the future we are aiming to be able to run
multiple blocks within a single thread, and have more control over the
buffers that are created in the blocks.

In the meantime, perhaps this presentation on controlling latency could be
of use:
https://www.youtube.com/watch?v=jq0RewceCwc&list=PLE7tQUdRKcyaaF1pm1MfQm_g1TF2CP1JZ&index=35

To use it I believe would involve using some out of tree blocks.

Josh


On Tue, Apr 27, 2021 at 5:34 AM mehtap özkan  wrote:

> Dear All,
> I have a flowgraph where I use multiple Standart Blocks.
> The Application requires low sample and symbol rates, therefore the
> buffers between the blocks cause a lot of Latency.
>  Is there a way to merge the standart blocks or do I have to manually
> merge the c++ sources and   re-compile them.
> Thank you in advance.
>

Re: Solved! - Re: USRP UHD Source problem

[Josh Morman]

Thank you for following up on this issue. The grc cache has turned up a few
times recently as the cause of a few issues. So yes a github issue would be
a very good idea to track this.

Thanks!

On Sun, Apr 25, 2021 at 3:52 PM Christophe Seguinot <
christophe.segui...@orange.fr> wrote:

> Hi
>
> I effectively proposed Mike to remove the cache.json file, in case it
> could help. As I thought this was probably not the solution I sent him a
> private email and asked him to answer to the list in case of success.
>
> So to resume; it appears that the problem originates from simply
> upgrading GNURadio installed from PPA.
>
> Question: should we fire an issue on Github? I think that this cache
> problem should be solved by cleaning the cache each time GR is updated
> or its version is changed (some users may also downgrade GR in some case)
>
> Regards, Christophe
>
>
> On 25/04/2021 15:06, Mike Markowski wrote:
> > With thanks to Christophe for his excellent advice, removing
> > ~/.cache/grc_gnuradio/cache.json fixed things up.  After needing to do
> > this now & then, I have a new gr heuristic:
> >
> >   if (weirdnessReigns) { delete cache.json; }
> >
> > Thanks, Christophe!
> >
> > Mike
> >
> > On 4/24/21 2:55 PM, Mike Markowski wrote:
> >> Some progress.  When I log in as another user, gr runs fine with a
> >> usrp.   Logging in as me, I get the errors previously posted.  My
> >> environment seems to (suddenly) be the issue, so I:
> >>
> >> 1. Moved ~/.bashrc to a new name to avoid any improper env var settings.
> >>
> >> 2. Moved ~/.config/GNU\ RADIO
> >>
> >> But I still get errors previously posted.  Are there other files
> >> gnuradio-companion is looking at that could be the culprit?
> >>
> >> Thanks,
> >> Mike
> >>
> >> On 4/24/21 1:04 PM, Mike Markowski wrote:
> >>> Thanks for checking, Christophe.  I agree that it's strange.  I've
> >>> been away from gnuradio doing some cyclostationary work, so haven't
> >>> touched any flowgraphs in weeks.  I see that my newest flowgraphs
> >>> were built April 7 and that gnuradio-companion, no doubt after an
> >>> Ubuntu upgrade, shows a date of April 9.
> >>>
> >>> I'll share debugging breakthroughs, but would be glad to hear from
> >>> others if your GR 3.8.1.0 is or isn't running fine.  Most likely,
> >>> it's my environment since I don't see a flurry of 'me too' notes.
> >>>
> >>> Mike
> >>>
> >>> On 4/24/21 12:16 PM, Christophe Seguinot wrote:
>  This flowgraph is correctly build under GR 3.9.0.0 (no USRP source
>  to test further)
> 
>  The error is quite strange, I think there is no "len_tag_name"
>  parameter in such a simple flowgraph
> 
>  On 24/04/2021 16:35, Mike Markowski wrote:
> > I'm running gnuradio companion 3.8.1.0 (Python 3.8.6) on Ubuntu
> > 2020.10.  After a few weeks away from gnuradio, today I get errors
> > with the USRP UHD Source, and previously working flowgraphs no
> > longer build. (Previously built flowgraph python files still run
> > fine.)  The attached flowgraph doesn't get much simpler, but
> > building yields:
> >
> > Generating: '/home/mm/sdr/fm/uhdTest.py'
> > Generate Error: (NameError("'len_tag_name' is not defined"),
> > 'uhd.usrp_source(\n",".join((${dev_addr}, ${dev_args})),\n
> > uhd.stream_args(\n cpu_format="${type}",\n
> >
> > [... on and on ...]
> >
> > , uhd.ALL_MBOARDS)\n% else:\n# No synchronization enforced.\n%
> > endif\n')
> > >>> Failure
> > Traceback (most recent call last):
> >   File "memory:0x7f3082ab36d0", line 136, in render_body
> >   File "/usr/lib/python3/dist-packages/mako/runtime.py", line 106,
> > in __getitem__
> > return compat_builtins.__dict__[key]
> > KeyError: 'len_tag_name'
> >
> > [... still more...]
> >
> > Is anyone else seeing this error?
> >
> > Thanks,
> > Mike
> 
> >
>
>

Re: 3.9 -->3.8 downgrade - a few GRC keyboard keys don't work correctly.

[Josh Morman]

Is it possible that the "Hide Disabled Blocks" option is enabled in GRC?
This would make disabling appear to delete the block.

Josh

On Wed, Apr 21, 2021 at 12:16 PM Tom McDermott  wrote:

> On Ubuntu 20.04, I downgraded a gnuradio 3.9 installation to gnuradio 3.8.
> Using sudo apt remove.
>
> I had to manually delete the ~/.cache/grc_gnuradio/cache.json file to
> remove some
> cached block parameters left over from 3.9 that were different from 3.8
>
> However even after that I have a few keystrokes in 3.8 that used to work
> but now
> do not.  Particularly trying to Disable a selected block now deleted that
> block rather
> than deselecting it - whether the disable command is invoked typing the
> keyboard D character
> or the mouse on the context-menu.
>
> Is there perhaps some other cached file or config file left over from the
> 3.9 installation
> that is changing the nominal 3.8 GRC keyboard functions?
>
> -- Tom, N5EG
>
>
>

Re: Teething problems with new GNU Radio 3.9 installation

[Josh Morman]

I haven't tried this in quite a while, but Ettus maintains a PPA as well,
and has 18.04 binaries for 3.15:
https://launchpad.net/~ettusresearch/+archive/ubuntu/uhd

If you remove gnuradio and uhd as installed via apt
then add that PPA
then install uhd
then install gnuradio from PPA
It *should* allow you to have a relatively up to date UHD driver.  I am not
sure, though, if these are built with PYTHON enable.

Perhaps someone with more UHD experience can chime in on how best to get
UHD 4.0 but still install GNU Radio from binaries.

Josh


On Wed, Apr 21, 2021 at 7:09 AM Brendan Horsfield <
brendan.horsfi...@vectalabs.com> wrote:

> Hi Josh,
>
> Thanks for the advice.  On balance, I would prefer to stick with Ubuntu
> 18.04 and roll back GNU Radio to version to 3.8.  I'm running some fairly
> "experimental" (i.e. fragile) software applications on my laptop at the
> moment, and I am a bit nervous about breaking them with an OS upgrade.
>
> Normally I would never install anything from source, being a relatively
> inexperienced user.  However, in this case I don't have much choice, as the
> Ettus USRP driver I am using (UHD v4.0) is not supported by the standard
> GNU Radio binaries.  If you know of a way to install a GNU Radio binary
> that will let me use a USRP driver of my choosing, please let me know.
>
> Note that I am willing to switch to an older version of the USRP driver if
> it will help.  However, regardless of which driver version I use, it will
> have to be built from source with the -DENABLE_PYTHON_API compiler flag set
> to ON (the default is OFF), as I require this API for my project.  (The
> obvious alternative would be to import the GNU Radio library into my Python
> project, rather than the Ettus API.  I don't have any experience with this,
> but I would be willing to give it a try.)
>
> Thanks,
> Brendan.
>
>
> On Wed, Apr 21, 2021 at 8:26 PM Josh Morman  wrote:
>
>> Brendan,
>>
>> If you are able to, I would recommend updating to Ubuntu 20.04 and then
>> using the ppa to install 3.9:
>> https://wiki.gnuradio.org/index.php/InstallingGR (from PPA section)
>> If you are stuck with 18.04, I would recommend dropping back to v3.8 and
>> follow the same instructions.
>>
>> If you must install from source, I have been able to build 3.9 on 18.04
>> using these prerequisites (and then volk from source):
>>
>> https://github.com/mormj/gnuradio-docker/blob/maint-3.9/ubuntu/18.04/buildreqs.Dockerfile
>>
>>
>> Josh
>>
>>
>> On Wed, Apr 21, 2021 at 2:21 AM Brendan Horsfield <
>> brendan.horsfi...@vectalabs.com> wrote:
>>
>>> Hi Everyone,
>>>
>>> I have just finished installing GNU Radio 3.9.0.0 on my Ubuntu laptop,
>>> and I am having some difficulties getting it to work properly.  It feels
>>> like I have missed a step, but I don't know what it could be.
>>>
>>> I installed GNU Radio by building it from source as per the instructions
>>> in https://wiki.gnuradio.org/index.php/InstallingGR#From_Source and
>>> https://wiki.gnuradio.org/index.php/UbuntuInstall#Install_the_Pre-Requisites
>>> (see below for details).  The process seemed to go smoothly, with no errors
>>> reported.
>>>
>>> However, when I open a bash terminal and type "gnuradio-companion", I
>>> get the following warning messages:
>>>
>>> <<< Welcome to GNU Radio Companion 3.9.0.0 >>>
>>> Block paths: /usr/local/share/gnuradio/grc/blocks
>>> Loading:
>>> "/home/anyone/Documents/Brendan/GNU-Radio/GNR-Radio-3_9_0_0/test.grc"
>>> >>> Done
>>> Warning: restarting the docstring loader (crashed while loading
>>> 'qtgui_grbackground')
>>> Warning: restarting the docstring loader (crashed while loading
>>> 'qtgui_auto_correlator_sink')
>>> Warning: restarting the docstring loader (crashed while loading
>>> 'qtgui_bercurve_sink')
>>> Warning: restarting the docstring loader (crashed while loading
>>> 'qtgui_compass')
>>> Warning: restarting the docstring loader (crashed while loading
>>> 'qtgui_const_sink_x')
>>> Warning: docstring loader crashed too often
>>>
>>> GNU Radio Companion then opens up OK, but it won't run any flowgraphs,
>>> even very simple ones.  It simply returns Code-11 each time, with no
>>> further information.
>>>
>>> Also, if I try to add any Instrumentation blocks (e.g. QT GUI Frequency
>>> Sink), the application shuts down immediately, and p

Re: Teething problems with new GNU Radio 3.9 installation

[Josh Morman]

Brendan,

If you are able to, I would recommend updating to Ubuntu 20.04 and then
using the ppa to install 3.9:
https://wiki.gnuradio.org/index.php/InstallingGR (from PPA section)
If you are stuck with 18.04, I would recommend dropping back to v3.8 and
follow the same instructions.

If you must install from source, I have been able to build 3.9 on 18.04
using these prerequisites (and then volk from source):
https://github.com/mormj/gnuradio-docker/blob/maint-3.9/ubuntu/18.04/buildreqs.Dockerfile


Josh


On Wed, Apr 21, 2021 at 2:21 AM Brendan Horsfield <
brendan.horsfi...@vectalabs.com> wrote:

> Hi Everyone,
>
> I have just finished installing GNU Radio 3.9.0.0 on my Ubuntu laptop, and
> I am having some difficulties getting it to work properly.  It feels like I
> have missed a step, but I don't know what it could be.
>
> I installed GNU Radio by building it from source as per the instructions
> in https://wiki.gnuradio.org/index.php/InstallingGR#From_Source and
> https://wiki.gnuradio.org/index.php/UbuntuInstall#Install_the_Pre-Requisites
> (see below for details).  The process seemed to go smoothly, with no errors
> reported.
>
> However, when I open a bash terminal and type "gnuradio-companion", I get
> the following warning messages:
>
> <<< Welcome to GNU Radio Companion 3.9.0.0 >>>
> Block paths: /usr/local/share/gnuradio/grc/blocks
> Loading:
> "/home/anyone/Documents/Brendan/GNU-Radio/GNR-Radio-3_9_0_0/test.grc"
> >>> Done
> Warning: restarting the docstring loader (crashed while loading
> 'qtgui_grbackground')
> Warning: restarting the docstring loader (crashed while loading
> 'qtgui_auto_correlator_sink')
> Warning: restarting the docstring loader (crashed while loading
> 'qtgui_bercurve_sink')
> Warning: restarting the docstring loader (crashed while loading
> 'qtgui_compass')
> Warning: restarting the docstring loader (crashed while loading
> 'qtgui_const_sink_x')
> Warning: docstring loader crashed too often
>
> GNU Radio Companion then opens up OK, but it won't run any flowgraphs,
> even very simple ones.  It simply returns Code-11 each time, with no
> further information.
>
> Also, if I try to add any Instrumentation blocks (e.g. QT GUI Frequency
> Sink), the application shuts down immediately, and prints the message
> "Segmentation fault (core dumped)" to the terminal.
>
> Details of my equipment setup are as follows:
>
> HP Omen laptop
> Intel Core i7-8750H CPU @ 2.20GHz × 12
> 32GB RAM
> Ubuntu 18.04.5 LTS
>
> Ettus B210 USRP
> UHD driver v4.0.0.0 with Python API enabled
> (USRP operation has been verified using Ettus examples and my own Python
> scripts.)
>
> GNU Radio Installation Process:
> 1.  Install dependencies as per gnuradio wiki page, including pybind11
> v2.6.2 and Volk v2.4.1 (both built from source)
> 2.  Install GNU Radio as follows:
> mkdir workarea-gnuradio
> cd workarea-gnuradio
> git clone https://github.com/gnuradio/gnuradio.git
> cd gnuradio
> git checkout v3.9.0.0
> mkdir build
> cd build
> cmake -DCMAKE_BUILD_TYPE=Release -DPYTHON_EXECUTABLE=/usr/bin/python3 ../
> make -j8
> make test  (NOTE:  THIS RETURNED A MESSAGE THAT "NO TESTS WERE FOUND")
> sudo make install
> sudo ldconfig
> Updated PYTHONPATH and LD_LIBRARY_PATH in $HOME/.bashrc file
> sudo ldconfig
> volk_profile
> Reboot laptop
> Open terminal, run "gnuradio-companion", make sad face.
>
> Has anyone encountered this problem before?  Any assistance you can
> provide would be greatly appreciated!
>
> Thanks & Regards,
> Brendan.
>
>
>

In-tree packaging update

[Josh Morman]

A quick update on the efforts to provide distribution packaging in-tree,
where the goal is to keep distribution builds up to date with the tip of
each branch.

There are currently 2 Ubuntu PPAs that get the latest from
master (https://launchpad.net/~gnuradio/+archive/ubuntu/gnuradio-master)
maint-3.9 (
https://launchpad.net/~gnuradio/+archive/ubuntu/gnuradio-maint-3.9)  (new!!)

Previously these were done with out-of-tree scripts, dockers, and manual
process, so the hope is that with these living in-tree, all of this can be
automated to the extent that builds happen once a week or something.  As of
now, through github actions, it is just a button press to kick off the
process so it is easier to stay on top of it.  (Note: all of the debian
packaging files are copied from Mait's awesome work maintaining the
official packages).

The copr website has not been behaving, so I haven't gotten to verify what
has been pushed to fedora using this mechanism, but hopefully soon the copr
builds will stay up to date as well.

Please let me know if you run into any issues with these, or would like to
see anything done differently here, or if you would like to help with this
overall effort.

Thanks,
Josh

Re: problem porting OOT to gr_3.9 : gr_modtool bind error

[Josh Morman]

I haven't been able to replicate this on my system with Ubuntu 20.04 and
Python 3.8.5  - created a 3.8 OOT with one block, and followed the steps to
copy the 3.9 content back in, and it got past the `gr_modtool bind` step.

Is there anything non-standard about your 3.8 OOT - e.g. are the files in
the usual place as generated by modtool?

On Fri, Apr 9, 2021 at 1:49 PM Tom McDermott  wrote:

> Hi Josh - for creating the new 3.9 skeleton, I ran gr_modtool from within
> the 3.9 directory.
> For step 4, I ran gr_modtool from within the 3.8 directory (as per the
> guide).
>
> Quite frankly, it looks like gr_modtool is throwing an error when trying to
> concatenate the module name and path and the .h suffix and suffering
> a type mismatch  (NoneType vs. str).  Is this possibly a Python 3.x
> version dependency?
>
> -- Tom, N5EG
>
>
>
>
>
> On Fri, Apr 9, 2021 at 10:37 AM Josh Morman  wrote:
>
>> You are right - that is an easier process than merging the 3.8 code into
>> 3.9.  The wiki should be correct in this case.
>>
>> Which directory are you running gr_modtool from?  Same directory as you
>> would for doing things like gr_modtool add?
>>
>>
>> On Fri, Apr 9, 2021 at 1:24 PM Tom McDermott  wrote:
>>
>>> Hi Josh - thank you for your help !
>>>
>>> I have been following the instructions from the porting guide:
>>>
>>> https://wiki.gnuradio.org/index.php/GNU_Radio_3.9_OOT_Module_Porting_Guide
>>>
>>> 
>>>
>>> Porting from 3.8 to 3.9 can be achieved most simply by creating a new
>>> OOT module (with the same name as the 3.8 OOT but in a different
>>> directory), then performing some manual steps
>>>
>>> 1. Use the 3.9 gr_modtool to generate a module with the same name (in
>>> another directory)
>>>
>>> 2. Copy the python folder from 3.9 OOT into your 3.8 OOT
>>>
>>> 3. (in 3.8 OOT) Add the bindings directory to the python directory
>>> CMakeLists
>>>
>>>./python/CMakeLists.txt  → add the line:
>>>add_subdirectory(bindings)
>>>
>>> 4. (in 3.8 OOT) Call gr_modtool bind for each block in your OOT
>>>
>>> ...
>>>
>>> -
>>> I have not created anything in the 3.9 directory except using gr_modtool
>>> new and add, nor have I copied in any code
>>> from 3.8 directory to the 3.9 directory.  I was under the impression
>>> that step 4 would modify my 3.8 code so that I could
>>> then copy it from the 3.8 directory over to the 3.9 directory.
>>>
>>> There are significant file differences between the newly created 3.9 and
>>> the existing 3.8  with conflicts in the /lib directory:
>>> the  hermesNB_impl.h and .cc   and hermesWB.h and .cc files differ
>>> significantly in content.
>>>
>>> Do I need to first look through the code and figure out how to merge the
>>> 3.8 and 3.9 .h and .cc files together?
>>> Then do I put those merged file into the 3.8 or the 3.9 directory?
>>>
>>> -- Tom, N5EG
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> On Fri, Apr 9, 2021 at 9:27 AM Josh Morman  wrote:
>>>
>>>> Tom,
>>>>
>>>> If I am following correctly, it looks like you are running gr_modtool
>>>> (which is the 3.9 version since that is what you have installed in the VM)
>>>> in the 3.8 OOT directory?
>>>> What happens when you run `gr_modtool bind` in the gr-hpsdr_3.9
>>>> directory
>>>>
>>>> The process you are following seems sound to have created a 3.9 OOT
>>>> with 3.9 modtool, and then copied code in from 3.8.
>>>>
>>>> Josh
>>>>
>>>> On Fri, Apr 9, 2021 at 12:08 PM Tom McDermott 
>>>> wrote:
>>>>
>>>>> I am having difficulty porting an OOT module to gr 3.9.
>>>>> * VM with only gnuradio 3.9.0.0 installed.
>>>>> *The functional 3.8 OOT module is cloned into this VM.
>>>>>
>>>>> Installed is 3.9.0.0
>>>>> Python 3.8.5
>>>>> pygccxml 2.1.0
>>>>> pybind11 2.6.2
>>>>>
>>>>> *  Created the gr-hpsdr_3.9  directory, populated it using gr_modtool
>>>>> newmod, added the
>>>>> two modules hermesNB and hermesWB with constructor parameters.
>>>>>
>>>>> In the 3.8 directory:
>>>>>  hermesNB.h and hermesWB.h  both exist

Re: problem porting OOT to gr_3.9 : gr_modtool bind error

[Josh Morman]

You are right - that is an easier process than merging the 3.8 code into
3.9.  The wiki should be correct in this case.

Which directory are you running gr_modtool from?  Same directory as you
would for doing things like gr_modtool add?


On Fri, Apr 9, 2021 at 1:24 PM Tom McDermott  wrote:

> Hi Josh - thank you for your help !
>
> I have been following the instructions from the porting guide:
> https://wiki.gnuradio.org/index.php/GNU_Radio_3.9_OOT_Module_Porting_Guide
>
> 
>
> Porting from 3.8 to 3.9 can be achieved most simply by creating a new OOT
> module (with the same name as the 3.8 OOT but in a different directory),
> then performing some manual steps
>
> 1. Use the 3.9 gr_modtool to generate a module with the same name (in
> another directory)
>
> 2. Copy the python folder from 3.9 OOT into your 3.8 OOT
>
> 3. (in 3.8 OOT) Add the bindings directory to the python directory
> CMakeLists
>
>./python/CMakeLists.txt  → add the line:
>add_subdirectory(bindings)
>
> 4. (in 3.8 OOT) Call gr_modtool bind for each block in your OOT
>
> ...
>
> -
> I have not created anything in the 3.9 directory except using gr_modtool
> new and add, nor have I copied in any code
> from 3.8 directory to the 3.9 directory.  I was under the impression that
> step 4 would modify my 3.8 code so that I could
> then copy it from the 3.8 directory over to the 3.9 directory.
>
> There are significant file differences between the newly created 3.9 and
> the existing 3.8  with conflicts in the /lib directory:
> the  hermesNB_impl.h and .cc   and hermesWB.h and .cc files differ
> significantly in content.
>
> Do I need to first look through the code and figure out how to merge the
> 3.8 and 3.9 .h and .cc files together?
> Then do I put those merged file into the 3.8 or the 3.9 directory?
>
> -- Tom, N5EG
>
>
>
>
>
>
>
> On Fri, Apr 9, 2021 at 9:27 AM Josh Morman  wrote:
>
>> Tom,
>>
>> If I am following correctly, it looks like you are running gr_modtool
>> (which is the 3.9 version since that is what you have installed in the VM)
>> in the 3.8 OOT directory?
>> What happens when you run `gr_modtool bind` in the gr-hpsdr_3.9  directory
>>
>> The process you are following seems sound to have created a 3.9 OOT with
>> 3.9 modtool, and then copied code in from 3.8.
>>
>> Josh
>>
>> On Fri, Apr 9, 2021 at 12:08 PM Tom McDermott  wrote:
>>
>>> I am having difficulty porting an OOT module to gr 3.9.
>>> * VM with only gnuradio 3.9.0.0 installed.
>>> *The functional 3.8 OOT module is cloned into this VM.
>>>
>>> Installed is 3.9.0.0
>>> Python 3.8.5
>>> pygccxml 2.1.0
>>> pybind11 2.6.2
>>>
>>> *  Created the gr-hpsdr_3.9  directory, populated it using gr_modtool
>>> newmod, added the
>>> two modules hermesNB and hermesWB with constructor parameters.
>>>
>>> In the 3.8 directory:
>>>  hermesNB.h and hermesWB.h  both exist in the /include directory, and
>>>  hermesWB_impl.cc and hermesNB_impl.cc both  exist in the /lib directory
>>>  Edited the ./python/Cmakelists.txt file to add the bindings
>>> subdirectory.
>>>  From the directory gr-hpsdr_3.8/gr-hpsdr, I execute gr_modtool bind
>>>  It prompts for the block name. I used the base module name without any
>>> suffixes:
>>>
>>> hermesNB
>>>
>>> (also tried  hermesNB.h, hermesNB_impl.cc, hermesWB, hermewWB.h,
>>> hermesWB_impl.cc)
>>>
>>> I always get the following error message:
>>>
>>>
>>> tom@tom-Standard-PC-Q35-ICH9-2009:~/gr-hpsdr_3.8/gr-hpsdr$ gr_modtool
>>> bind
>>> GNU Radio module name identified: hpsdr
>>> Which blocks do you want to parse? (Regex): hermesNB
>>> /usr/lib/python3/dist-packages/apport/report.py:13: DeprecationWarning:
>>> the imp module is deprecated in favour of importlib; see the module's
>>> documentation for alternative uses
>>>   import fnmatch, glob, traceback, errno, sys, atexit, locale, imp, stat
>>> Traceback (most recent call last):
>>>   File "/usr/bin/gr_modtool", line 18, in 
>>> cli()
>>>   File "/usr/lib/python3/dist-packages/click/core.py", line 764, in
>>> __call__
>>> return self.main(*args, **kwargs)
>>>   File "/usr/lib/python3/dist-packages/click/core.py", line 717, in main
>>> rv = self.invoke(ctx)
>>>   File "/usr/lib/python3/dist-packages/click/core.py", line 1137, in
>>> 

Re: problem porting OOT to gr_3.9 : gr_modtool bind error

[Josh Morman]

Tom,

If I am following correctly, it looks like you are running gr_modtool
(which is the 3.9 version since that is what you have installed in the VM)
in the 3.8 OOT directory?
What happens when you run `gr_modtool bind` in the gr-hpsdr_3.9  directory

The process you are following seems sound to have created a 3.9 OOT with
3.9 modtool, and then copied code in from 3.8.

Josh

On Fri, Apr 9, 2021 at 12:08 PM Tom McDermott  wrote:

> I am having difficulty porting an OOT module to gr 3.9.
> * VM with only gnuradio 3.9.0.0 installed.
> *The functional 3.8 OOT module is cloned into this VM.
>
> Installed is 3.9.0.0
> Python 3.8.5
> pygccxml 2.1.0
> pybind11 2.6.2
>
> *  Created the gr-hpsdr_3.9  directory, populated it using gr_modtool
> newmod, added the
> two modules hermesNB and hermesWB with constructor parameters.
>
> In the 3.8 directory:
>  hermesNB.h and hermesWB.h  both exist in the /include directory, and
>  hermesWB_impl.cc and hermesNB_impl.cc both  exist in the /lib directory
>  Edited the ./python/Cmakelists.txt file to add the bindings subdirectory.
>  From the directory gr-hpsdr_3.8/gr-hpsdr, I execute gr_modtool bind
>  It prompts for the block name. I used the base module name without any
> suffixes:
>
> hermesNB
>
> (also tried  hermesNB.h, hermesNB_impl.cc, hermesWB, hermewWB.h,
> hermesWB_impl.cc)
>
> I always get the following error message:
>
>
> tom@tom-Standard-PC-Q35-ICH9-2009:~/gr-hpsdr_3.8/gr-hpsdr$ gr_modtool bind
> GNU Radio module name identified: hpsdr
> Which blocks do you want to parse? (Regex): hermesNB
> /usr/lib/python3/dist-packages/apport/report.py:13: DeprecationWarning:
> the imp module is deprecated in favour of importlib; see the module's
> documentation for alternative uses
>   import fnmatch, glob, traceback, errno, sys, atexit, locale, imp, stat
> Traceback (most recent call last):
>   File "/usr/bin/gr_modtool", line 18, in 
> cli()
>   File "/usr/lib/python3/dist-packages/click/core.py", line 764, in
> __call__
> return self.main(*args, **kwargs)
>   File "/usr/lib/python3/dist-packages/click/core.py", line 717, in main
> rv = self.invoke(ctx)
>   File "/usr/lib/python3/dist-packages/click/core.py", line 1137, in invoke
> return _process_result(sub_ctx.command.invoke(sub_ctx))
>   File "/usr/lib/python3/dist-packages/click/core.py", line 956, in invoke
> return ctx.invoke(self.callback, **ctx.params)
>   File "/usr/lib/python3/dist-packages/click/core.py", line 555, in invoke
> return callback(*args, **kwargs)
>   File "/usr/lib/python3/dist-packages/gnuradio/modtool/cli/base.py", line
> 133, in wrapper
> return func(*args, **kwargs)
>   File "/usr/lib/python3/dist-packages/gnuradio/modtool/cli/bind.py", line
> 46, in cli
> run(self)
>   File "/usr/lib/python3/dist-packages/gnuradio/modtool/cli/base.py", line
> 152, in run
> module.run()
>   File "/usr/lib/python3/dist-packages/gnuradio/modtool/core/bind.py",
> line 61, in run
> file_to_process = os.path.join(self.dir, self.info['includedir'],
> self.info['blockname'] + '.h')
> TypeError: unsupported operand type(s) for +: 'NoneType' and 'str'
>
> Thus am stuck at this time.Is there a new or revised gr_modtool ?
>
> -- Tom, N5EG
>
>
>
>

Re: PMT thoughts

[Josh Morman]

John,

Thank you for sharing the issues you have come across and recommendation
for a cleaned up API.  As Johannes mentioned, the GREP highlights our
current thinking on PMTs also by leveraging a flatbuffers backend for
standardized serialization.  There is currently a proof of concept
implementation of this in the "newsched" codebase which is our sandbox for
developing the GNU Radio 4.0 runtime:
https://github.com/gnuradio/newsched/tree/master/pmt and we would love to
have any feedback on the GREP and help pushing the concept further.

Thanks,
Josh

On Fri, Mar 26, 2021 at 5:44 AM Johannes Demel 
wrote:

> Hi John,
>
> you're not alone with your concerns. There's a GREP (GNU Radio
> Enhancement Proposal) [0] where issues with PMTs are discussed. This
> would be an excellent place to discuss more details and contribute.
>
> Cheers
> Johannes
>
> [0] https://github.com/gnuradio/greps/pull/31
>
> On 25.03.21 23:43, John Sallay wrote:
> > I appreciate the effort that you guys have put into cleaning up gnuradio
> > and making it easier to work with over the past few years (python2 -
> > python3, swig to pybind11).  I see that you are going to improve the
> > logging as well which is great.
> > I've recently been doing some message based processing, and been using
> > PMTs.  I think that PMTs could use an overhaul too.
> > Here are some of my concerns:
> > The interface is inconsistent.  Here are a few examples:
> > is_integer, but from/to_long
> > is_dict, is_vector, not no is_list
> > make_dict, make_vector, but list1, list2, etc
> >
> > Type safety doesn't really work in several cases:
> > # apt install of gr 3.9 on ubuntu 20.04
> > a = pmt.make_dict()
> > a = pmt.dict_add(a, pmt.intern("a"), pmt.intern("a"))
> > pmt.is_dict(a) # True
> > a = pmt.list_add(a, pmt.intern("b"))   # I believe that this changes the
> > dictionary to a list
> > pmt.is_dict(b) # False
> > I could come up with more examples, but they illustrate roughly the same
> > point.  I should note that something changed in GR3.9.  It was even
> > worse in 3.8.  For example, on a list, pmt.is_dict() returns True.  I
> > can call some of the dict functions which return unexpected results,
> > while others raise an error.
> >
> > The interface doesn't feel like modern C++.  The pmt object doesn't
> > really have any useful functions associated with it.  You have to use
> > the functions in pmt namespace to operate on any pmt.  I believe that
> > PMTs are using boost::any under the hood.  I can get why some of the
> > choices were made, but I think that there may be some alternatives
> > available that could lead to an easier interface.
> >
> > I've been playing around with std::variant (in c++17, boost::variant
> > prior to that).  I have some ideas for how we could use it to wrap the
> > scalar types as well as the vector and dynamic types.  I would be happy
> > to explore the idea if there is interest.  We could also use variadic
> > templates to avoid things like list1, ..., list6.
> >
> > Using std::variant, I would envision an interface like:
> > pmt my_dict();
> > my_dict["abc"] = 4.0 // Automatically convert the string and the number
> > to the proper type.
> > std::get(my_dict["abc"]))
> >
> > pmt_list my_list();
> > my_list.append(pmt(my_dict));
> > for (auto& element : my_list) {
> > // Do something
> > }
> > std::cout << my_list.type() << " " << my_list << std::endl;
> >
> > We should be able to deprecate, but maintain the current functions for
> > dealing with PMTs.  I believe that these changes could be made without
> > breaking existing code.
> >
> > To be clear, I haven't implemented any of this.  My goal right now is
> > just to see if there is interest in doing something like this.  If there
> > is, I am happy to look into it and try to create a proof of concept.
> > I'm also open to suggestions and feedback.
> >
> > Thanks,
> >
> > John
> >
>
>