Re: Getting OOT's to run in GRC

[Vasil Velichkov]

Hi John,

On 13/06/2021 14.34, John Murphy wrote:
>  The blocks pull in
> gr-fft and (for the lfsr stuff) gr-digital. There is a source block, a
> general block, and a couple noblock utility classes in the custom OOT
> module.
> But when I attempt to run a flowgraph containing these OOT blocks in GRC I
> get the "module attribute error module has no component block" (sic).

One possible reason is that you have undefined references in the .so file. To 
resolve this you need to link both gr-fft and gr-digital. In you top level 
CMakeLists.txt you need to add gr-fft and gr-digital in the Gnuradio's 
find_package list. 
 
  find_package(Gnuradio "3.8" REQUIRED COMPONENTS blocks filter fft digital) 

And then in lib/CMakeLists.txt you need to link those to your OOT module

  target_link_libraries(myOOTblocks gnuradio::gnuradio-runtime 
gnuradio::gnuradio-fft gnuradio::gnuradio-digital)

Also open python/__init__.py and change

  except ImportError:

to

  except ModuleNotFoundError:


See also 
https://wiki.gnuradio.org/index.php/GNU_Radio_3.8_OOT_Module_Porting_Guide#GNU_Radio_Components

Regards,
Vasil

Re: Getting OOT's to run in GRC

[John Murphy]

Thanks Vasil.
That worked for the Manjaro system which is what I wanted. FYI had to also
add analog to the find_package as cmake threw an error without it so it
must be a dependency of one of those others.
Also for posterity I tried this in the Ubuntu LTS (ubuntu 20.04 gr 3.8) VM
but the Ubuntu LTS VM still can't get past the ModuleNotFound for my OOT
module when starting the flowgraph in GRC. But overcome by events since it
works in Manjaro which was just having the attribute error for the blocks
not the modulenotfound error.







On Mon, Jun 14, 2021 at 3:16 AM Vasil Velichkov 
wrote:

> Hi John,
>
> On 13/06/2021 14.34, John Murphy wrote:
> >  The blocks pull in
> > gr-fft and (for the lfsr stuff) gr-digital. There is a source block, a
> > general block, and a couple noblock utility classes in the custom OOT
> > module.
> > But when I attempt to run a flowgraph containing these OOT blocks in GRC
> I
> > get the "module attribute error module has no component block" (sic).
>
> One possible reason is that you have undefined references in the .so file.
> To resolve this you need to link both gr-fft and gr-digital. In you top
> level CMakeLists.txt you need to add gr-fft and gr-digital in the
> Gnuradio's find_package list.
>
>   find_package(Gnuradio "3.8" REQUIRED COMPONENTS blocks filter fft
> digital)
>
> And then in lib/CMakeLists.txt you need to link those to your OOT module
>
>   target_link_libraries(myOOTblocks gnuradio::gnuradio-runtime
> gnuradio::gnuradio-fft gnuradio::gnuradio-digital)
>
> Also open python/__init__.py and change
>
>   except ImportError:
>
> to
>
>   except ModuleNotFoundError:
>
>
> See also
> https://wiki.gnuradio.org/index.php/GNU_Radio_3.8_OOT_Module_Porting_Guide#GNU_Radio_Components
>
> Regards,
> Vasil
>


-- 
John Murphy
mr.john.joseph.mur...@gmail.com

Re: GSoC'21 - View Only Mode

[Oscar Ekholm]

Hello Bernard!

Input is very welcome, both regarding the UX as well as how to evaluate it
properly. Currently I'm working on the "backend" parts with most GUI/UX
coming later in the project so me and the mentors have not really discussed
those parts that much yet. I'd very much appreciate to hear your thoughts
on the UX, and I'm sure the same goes for my mentors (Sebastian Koslowski
and Marc Lichtman). I'm available in the chat as Oscar Ekholm (oscekh) if
you'd like to discuss it further on there.

Best regards,
Oscar

Den lör 12 juni 2021 13:20Bernard Tyers  skrev:

> Dear Oscar,
>
> I'm very interested in your View only mode project. I wish you luck with
> it.
>
> Is your proposed solution ("secure default behaviour with user settings to
> disable, or potentially modify the View-Only mode") fixed, or is there
> scope for input? If it is already fixed how do you plan to evaluate it's
> usability?
>
> If it is of help, I'd be happy to chat about the UX design, and how it's
> usability might be tested.
>
> Thanks,
> Bernard
>
>
> On 11 June 2021 17:24:43 CEST, Oscar Ekholm  wrote:
> >Hello everyone!
> >I have now published the first blog post for my GSoC work on the GRC
> >View-Only Mode. This week I have mainly worked at saving evaluated
> >values
> >of parameters in the grc-file. You can read about it here:
> >
> >https://oscekh.github.io/
> >
> >I will be posting an update on the blog each Friday, with a
> >corresponding
> >announcement on this list.
> >
> >Best regards,
> >Oscar Ekholm
> >
> >On Mon, May 24, 2021 at 11:19 AM Oscar Ekholm  wrote:
> >
> >> Hello,
> >>
> >> I've been accepted to work with GnuRadio for this year's Google
> >Summer of
> >> Code. I will be working on implementing a GRC View-Only Mode, which
> >is a
> >> security feature disabling execution of block parameters in untrusted
> >> flowgraphs.
> >>
> >> I will be posting weekly progress updates on my blog:
> >> https://oscekh.github.io/
> >>
> >> If you are interested in reading more about the View-Only mode it is
> >> described further in my project proposal:
> >>
> >>
> >
> https://docs.google.com/document/d/1dL6PziJSopcY3O7gJ6CXiedTSdbhrHVFhR-UJRTmsng/edit?usp=sharing
> >>
> >> Please reach out if you have any questions, advice or thoughts you
> >want to
> >> share.
> >>
> >> Best regards,
> >> Oscar Ekholm
> >>
>

gr_3.9 OOT generates strange .so files

[Tom McDermott]

I have successfully built my OOT in gnuradio 3.9.  This was done with a
plain vanilla gr_modtool
constructed build, and built using cmake, make, make install, etc.

One of the folks who uses my module and packages it for one of the linux
distributions noticed that
it is generating some strange output files, and I can confirm on my own
system.

The .so filenames are installed in /usr/lib (for that specific person)  or
/usr/x86-64-linux-gnu/   (for my system)

The correct .so is being generated and used without any issues:
libgnuradio.grhpsdr.so

But it is also generating:
libgnuradio.grhpsdr.so.1.0.0git
libgnuradio.grhpsdr.so.e487bf33

I noticed that other modules have a series of versioned soft links. For
example:

libgnuradio.analog.so -> libgnuradio.analog.so.3.9.1
libgnuradio.analog.so.3.9.1 -> libgnuradio.analog.so.3.9.1.0
libgnuradio.analog.so.3.9.1.0

Is the way my OOT's  .so files (and no soft links) being generated a
problem?
Will this fail on a subsequent update to my OOT?
Is there some sort of extra configuration I need to do to the
auto-generated make or cmake files ?

-- Tom, N5EG

European GNU Radio Days program and broadcast

[jmfriedt]

Dear GNU Radio enthusiasts,
the program of the European GNU Radio Days is being finalized and is now
published at https://gnuradio-eu-21.sciencesconf.org/program. 
Please expect a few minor adjustements as videos are being uploaded but
the coarse schedule is completed and available. The oral presentations 
including live interaction with the presenting speakers will be
broadcast on https://youtu.be/iXshTqIpgKk June 24th starting at 1:30 PM 
Central European Summer Time (UTC+2) to accomodate most participant
timezones, and will conclude around 6PM with an amazing description
of the challenge solution by the first winner of the prize that you
will no want to miss. 

The tutorials will be broadcast on https://youtu.be/NAIzz4oLWz8 for the
introductory tutorials and https://youtu.be/fWDbHHkz42k for the
advanced tutorials during June 25th. The videos of the tutorials are
being uploaded on the European GNU Radio Days YouTube channel at
https://www.youtube.com/channel/UCFzddPoztcHLuwFWRPJTNrQ 

Finally, a joint session with the Software Defined Radio Academy (SDRA)
during June 26th will highlight the connections between the fields of
software defined radio and ham radio in fabulous presentations
ranging from long range IoT communication to direction of arrival (DoA)
phase analysis and light digital communication. Please check the SDRA
announcements for the YouTube channel url. 

Best wishes, JM

-- 
JM Friedt, FEMTO-ST Time & Frequency, 26 rue de l'Epitaphe, 25000
Besancon, France

Re: gr_3.9 OOT generates strange .so files

[Ron Economos]

That's normal operation. The actual file is 
libgnuradio.grhpsdr.so.e487bf33 and libgnuradio.grhpsdr.so.1.0.0git and 
libgnuradio.grhpsdr.so are symbolic links.


The e487bf33 is the git hash of your last commit.

Ron

On 6/14/21 10:23 AM, Tom McDermott wrote:
I have successfully built my OOT in gnuradio 3.9.  This was done with 
a plain vanilla gr_modtool

constructed build, and built using cmake, make, make install, etc.

One of the folks who uses my module and packages it for one of the 
linux distributions noticed that
it is generating some strange output files, and I can confirm on my 
own system.


The .so filenames are installed in /usr/lib (for that specific 
person)  or  /usr/x86-64-linux-gnu/   (for my system)


The correct .so is being generated and used without any issues:
libgnuradio.grhpsdr.so 

But it is also generating:
libgnuradio.grhpsdr.so.1.0.0git
libgnuradio.grhpsdr.so.e487bf33

I noticed that other modules have a series of versioned soft links. 
For example:


libgnuradio.analog.so  -> 
libgnuradio.analog.so.3.9.1

libgnuradio.analog.so.3.9.1 -> libgnuradio.analog.so.3.9.1.0
libgnuradio.analog.so.3.9.1.0

Is the way my OOT's  .so files (and no soft links) being generated a 
problem?

Will this fail on a subsequent update to my OOT?
Is there some sort of extra configuration I need to do to the 
auto-generated make or cmake files ?


-- Tom, N5EG

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.
>

Packet_header vs Packet_format

[Solomon Tan]

Hi all,

I have trouble understanding the difference between "packet header" and
"packet format". They both appear to do the same thing - define a header
for some data packets for TX and RX. For RX, both appear to be able to
use the Header/Payload Demux block. Yet they appear to have different
names even for the generator and parser.

E.g. Packet header uses the "Packet Header Generator" and "Packet Header
Parser" blocks to generate and parse the header respectively. On the
other hand, packet format uses "Protocol Formatter" and "Protocol
Parser" blocks.

The documentation also appears to have switched to "packet format" from
"packet header". "Header Packet Parser" was used in the documentation
for GR 3.7 in the OFDM example.
(https://www.gnuradio.org/doc/doxygen-3.7.2.1/page_packet_data.html)
However, in the newest documentation I have (from
v3.9.0.0-155-g44cd1949), "packet format" is used instead.

Why is that so? What's the difference between the two and when would one
implementation be preferred over another?

Thanks.
Cheers,
Sol