Re: GRC 3.9.4.0 - module porting problem
Hi Ryan,
I eventually managed to port the working GRC code from 3.8.2.0 to 3.9.4.0 by
rebuilding the GRC with pybind11 2.5.0 installed and having replaced version
2.4.3, for all binding operations.
pygxxxml 2.2.1 was also retained.
The porting guide document after re-read is entirely correct about
compatibility.
Thanks again,
David
-Original Message-
From: Ryan Volz
Sent: Friday, March 4, 2022 10:22 PM
To: discuss-gnuradio@gnu.org
Subject: Re: GRC 3.9.4.0 - module porting problem
Hi David,
If it works somewhere with GR 3.9, then it's not a porting problem and
you've done everything right there.
I've recently discovered for myself that an OOT's Python bindings will throw
this error when even the compiler version is different between building GNU
Radio and the OOT, in addition to needing the same pybind11 version. Is
there a chance this is what you're seeing? Run "gnuradio-config-info --cxx"
to see what compiler GNU Radio was built with, and compare with what you're
using to build the OOT module.
(For me, this has happened in building OOT modules for conda-forge when the
conda-forge project recently started using GCC 10 instead of GCC 9. Modules
built with GCC 10 were not compatible with a GNU Radio built with GCC 9. It
turns out that they actually would be compatible, and pybind11 is being too
careful, but I would have had to know that ahead of time to avoid the
problem. So for now I have to stick to the same compiler version for
everything.)
Cheers,
Ryan
On 3/4/22 3:35 PM, David Taylor (manx.net) wrote:
Hi All,
I am sorry to be covering what is old ground, but I am having a final
loading issue with an otherwise working OOT block.
The block works under GRC 3.8.2.0 and GRC 3.9.4.0 was built on another
computer without issue.
ImportError:generic_type "channel_signal_generator_cc" referenced unknown
base type "gr::sync_block"
Ubuntu 20.04
python 3.8
pybind11 2.5.0 – replacing 2.4.3 in accordance with the latest 3.9 Module
Porting Guide (28 Feb 2022)
pygccxml 2.2.1
Additional libraries are found at cmake and during the build. The block
imports correctly with no changes necessary to the .yml file.
The new block was created using 3.9 gr_modtool and code dropped in, noting
the changes to shared_ptr use.
The block was sync_block type at definition, with the virtual block
classes noted in the porting guide automatically inserted during bind in
/python/bindings/
void bind_channel_signal_generator_cc(py::module& m)
{
using channel_signal_generator_cc=
::gr::oot::channel_signal_generator_cc;
py::class_gr::basic_block,
std::shared_ptr>(m,
"channel_signal_generator_cc", D(channel_signal_generator_cc))
.def(py::init(&channel_signal_generator_cc::make),
py::arg("samp_rate"),
py::arg("length_chips"),
py::arg("duration_sec"),
py::arg("filename"),
py::arg("CN0_dB"),
D(channel_signal_generator_cc,make)
)
Any comments would be welcome.
Many thanks,
David GD4FMB
Re: GRC 3.9.4.0 - module porting problem
Hi Ryan,
Thanks for the prompt reply.
The C++ compiler version used to first build GRC 3.9.4.0 and then compile
the OOT GRC block code is (Ubuntu 9.3.0-17ubuntu1~20.04) 9.3.0
I will check the same on the computer being used for GRC 3.8.2.0 use shortly
and critically look at the cmake output for clues in discrepancy.
I have found in the past that an incremental inclusion of the C++ source
code through the build process helps to identify the cause of the import
failure. - He says, stating the obvious!!
All the best,
David
-Original Message-
From: Ryan Volz
Sent: Friday, March 4, 2022 10:22 PM
To: discuss-gnuradio@gnu.org
Subject: Re: GRC 3.9.4.0 - module porting problem
Hi David,
If it works somewhere with GR 3.9, then it's not a porting problem and
you've done everything right there.
I've recently discovered for myself that an OOT's Python bindings will throw
this error when even the compiler version is different between building GNU
Radio and the OOT, in addition to needing the same pybind11 version. Is
there a chance this is what you're seeing? Run "gnuradio-config-info --cxx"
to see what compiler GNU Radio was built with, and compare with what you're
using to build the OOT module.
(For me, this has happened in building OOT modules for conda-forge when the
conda-forge project recently started using GCC 10 instead of GCC 9. Modules
built with GCC 10 were not compatible with a GNU Radio built with GCC 9. It
turns out that they actually would be compatible, and pybind11 is being too
careful, but I would have had to know that ahead of time to avoid the
problem. So for now I have to stick to the same compiler version for
everything.)
Cheers,
Ryan
On 3/4/22 3:35 PM, David Taylor (manx.net) wrote:
Hi All,
I am sorry to be covering what is old ground, but I am having a final
loading issue with an otherwise working OOT block.
The block works under GRC 3.8.2.0 and GRC 3.9.4.0 was built on another
computer without issue.
ImportError:generic_type "channel_signal_generator_cc" referenced unknown
base type "gr::sync_block"
Ubuntu 20.04
python 3.8
pybind11 2.5.0 – replacing 2.4.3 in accordance with the latest 3.9 Module
Porting Guide (28 Feb 2022)
pygccxml 2.2.1
Additional libraries are found at cmake and during the build. The block
imports correctly with no changes necessary to the .yml file.
The new block was created using 3.9 gr_modtool and code dropped in, noting
the changes to shared_ptr use.
The block was sync_block type at definition, with the virtual block
classes noted in the porting guide automatically inserted during bind in
/python/bindings/
void bind_channel_signal_generator_cc(py::module& m)
{
using channel_signal_generator_cc=
::gr::oot::channel_signal_generator_cc;
py::class_gr::basic_block,
std::shared_ptr>(m,
"channel_signal_generator_cc", D(channel_signal_generator_cc))
.def(py::init(&channel_signal_generator_cc::make),
py::arg("samp_rate"),
py::arg("length_chips"),
py::arg("duration_sec"),
py::arg("filename"),
py::arg("CN0_dB"),
D(channel_signal_generator_cc,make)
)
Any comments would be welcome.
Many thanks,
David GD4FMB
GRC 3.9.4.0 - module porting problem
Hi All,
I am sorry to be covering what is old ground, but I am having a final loading
issue with an otherwise working OOT block.
The block works under GRC 3.8.2.0 and GRC 3.9.4.0 was built on another computer
without issue.
ImportError:generic_type "channel_signal_generator_cc" referenced unknown base
type "gr::sync_block"
Ubuntu 20.04
python 3.8
pybind11 2.5.0 – replacing 2.4.3 in accordance with the latest 3.9 Module
Porting Guide (28 Feb 2022)
pygccxml 2.2.1
Additional libraries are found at cmake and during the build. The block imports
correctly with no changes necessary to the .yml file.
The new block was created using 3.9 gr_modtool and code dropped in, noting the
changes to shared_ptr use.
The block was sync_block type at definition, with the virtual block classes
noted in the porting guide automatically inserted during bind in
/python/bindings/
void bind_channel_signal_generator_cc(py::module& m)
{
using channel_signal_generator_cc=
::gr::oot::channel_signal_generator_cc;
py::class_>(m,
"channel_signal_generator_cc", D(channel_signal_generator_cc))
.def(py::init(&channel_signal_generator_cc::make),
py::arg("samp_rate"),
py::arg("length_chips"),
py::arg("duration_sec"),
py::arg("filename"),
py::arg("CN0_dB"),
D(channel_signal_generator_cc,make)
)
Any comments would be welcome.
Many thanks,
David GD4FMB
Re: GRC Filter Taps read from file. (3.8.2.0 - from source)
Marcus, Jeff,
The files were simply not being recognised. A combination of path and format/
endianess.
Now working with both space de-limited text as per Jeff’s example and
numpy.float32 files as source.
Many thanks.
David
From: Jeff Long
Sent: Wednesday, September 16, 2020 9:14 PM
To: GNURadio Discussion List
Subject: Re: GRC Filter Taps read from file. (3.8.2.0 - from source)
This works for me ... add an import block with "import numpy as np" ... for
taps use "np.genfromtxt('/tmp/taps.txt')" where the file contains a
space-delimited set of values.
On Wed, Sep 16, 2020 at 1:23 PM Marcus D. Leech wrote:
On 09/16/2020 01:10 PM, David Taylor (manx.net) wrote:
Hi,
I am trying to import a large number of taps (1023) into a Decimating FIR
Filter, in order to repeat (as reference), a GRC experiment that was published
about four years ago.
The taps import method used at the time was numpy.genfromtxt(), that much
is clear.
I have tried using numpy.fromfile, numpy.genfromtxt and others in the
Filter block itself without success and have been looking for possible examples
of file import use in the 3.8.2.0 installed /example folders and elsewhere.
The filter taps do however populate directly from a GRC variable python
list as real(floats), [1,1, –1, 1,1 ]
Firdes is operable and the python wrappers for filter design populate the
taps in much the same way.
The coefficient values are externally generated complex floats, but can be
easily converted into other numeric or delimited text formats, as BPSK coding
is being used. This much has been tried.
On a completely unrelated matter, I hope, the Filter Design Tool is
inoperative.
I apologise if this is covering old ground again.
Regards,
David GD4FMB
David:
When you say "without success", what is the nature of the problem? Filter
response doesn't look right, you're getting an exception, etc etc.
Your externally-generated complex-floats--how are they represented in the
file? Do you specify dtype correctly when you read the file in?
GRC Filter Taps read from file. (3.8.2.0 - from source)
Hi, I am trying to import a large number of taps (1023) into a Decimating FIR Filter, in order to repeat (as reference), a GRC experiment that was published about four years ago. The taps import method used at the time was numpy.genfromtxt(), that much is clear. I have tried using numpy.fromfile, numpy.genfromtxt and others in the Filter block itself without success and have been looking for possible examples of file import use in the 3.8.2.0 installed /example folders and elsewhere. The filter taps do however populate directly from a GRC variable python list as real(floats), [1,1, –1, 1,1 ] Firdes is operable and the python wrappers for filter design populate the taps in much the same way. The coefficient values are externally generated complex floats, but can be easily converted into other numeric or delimited text formats, as BPSK coding is being used. This much has been tried. On a completely unrelated matter, I hope, the Filter Design Tool is inoperative. I apologise if this is covering old ground again. Regards, David GD4FMB
Re: GRC version 3.9.0.0 git master (python 3.8.2) + OOT blocks
Josh, To close off on this one, I built UHD 3.15.0.0 from source and then ran CMake again on GRC 3.8.2. No omissions to the GRC build were reported in the configuration and the build was then completed. Its been running for a few days now, works well and is stable. I had a USB issue with the B210, but this was quickly rectified, with reference to the build and install USRP note dated 11 Nov 2019. I might rebuild 3.9 from source, rather than ppa., when time allows and look a little more closely at the installation paths. I am confident that this will solve the issue and being able to test OOT code on a secondary platform will be beneficial. Many thanks David From: Josh Sent: Monday, August 31, 2020 12:34 PM To: David Taylor (manx.net) Cc: GNURadio Discussion List Subject: Re: GRC version 3.9.0.0 git master (python 3.8.2) + OOT blocks David, As far as I know, 3.15 is the long term support UHD release, and should be considered the most stable. 4.0 has not been officially released yet (looks like release candidate went out last week). If your research does not involve the newest features of GNU Radio, but you need a stable version, I'd recommend sticking with 3.8.2 - which it it sounds like you have successfully done from source. It looks like there are two variables in play here - how GR is installed, and the version of GR. You can also install GR 3.8 from the PPA (gnuradio-releases), and of course 3.9 from source. But if having installed 3.8 from source is working for you, that seems like a good path to go down. For gr-uhd to be installed, you have to install uhd (either from the package manager - 20.04 has 3.15.0.0-1build5, or from source) before compiling GR. Take a look at the CMake stdout for GR to see if there are any other dependencies or issues that would prevent gr-uhd from being installed. Josh On Sun, Aug 30, 2020 at 1:26 PM David Taylor (manx.net) wrote: Josh, Many thanks for your questions and apologies for the delay in replying. From a clean 20.04 Ubuntu, I installed 3.9 using the package installer from the master branch. $ sudo add-apt-repository ppa:gnuradio/gnuradio -master There were no major issues with the GRC install, transfer of old 3.7 OOT blocks, their new python binding, libraries linkage or block import for that matter. The 3.9 OOT porting guide proved, helpful with some additional and relevant information to be found in the 3.8 porting guide particularly on external libraries inclusion. UHD 3.15.0.0-2build5 from a package manager install works fine. PYTHONPATH =/usr/local/lib/python3/dist-packages. The OOT blocks are being installed to: /usr/local/lib/python3/dist-packages/test and the blocks to: /usr/local/share/gnuradio/grc/blocks In all other respects the GRC works fine.. - Noting this release last weekend, on a separate drive, with a clean 20.04 Ubuntu, I have installed and built GRC 3.8.2.0 from gnuradio-3.8.2.0.tar.gz OOT blocks import without issue as per 3.7.11 using the older SWIG bindings. VOLKGNSSSDR as an external library is both visible and useable. I noticed that during the build the UHD interface was disabled and consequently the GRC source and sink blocks are both missing. These are available for build under ~/gr-uhd. Is there a reason for this please? Is 3.15 compatible and stable as a UHD interface, noting the very recent emergence of 4.0 RC? My research in the first instance, is to investigate the intrinsic carrier phase stability of an SDR system in RF loop-back and then through a geo-stationary satellite. The OOT blocks in development are of flexible direct spread spectrum coding and reception type. It’s therefore important that I settle on stable GRC/UHD variants for the next twelve months or so. Best regards, David GD4FMB From: Josh Sent: Monday, August 24, 2020 8:09 PM To: David Taylor (manx.net) Cc: GNURadio Discussion List Subject: Re: GRC version 3.9.0.0 git master (python 3.8.2) + OOT blocks David, 1) How is your GNU Radio installed in this system? 2) It sounds a lot like PYTHONPATH is misconfigured for OOT - where are your OOT files being installed to? Thanks, Josh On Fri, Aug 21, 2020 at 12:23 PM David Taylor (manx.net) wrote: Josh, Sorry to go over old ground yet again. In order to remove any additional problems caused by the use of external libraries, I have created a separate OOT branch that is void of external libraries. Stripped to the bone python and C++ blocks have been created using gr_modtool. Test codes validate the blocks code content as functional and they import correctly into the GRC with simple .yml. The top level CMakeLists.txt and others are unmodified from a clean new module. The current issue has been traced so far to the __init__.py file and its inability to resolve ‘__path__’ Consequently the pybind11 link fails to find my
Re: GRC version 3.9.0.0 git master (python 3.8.2) + OOT blocks
Josh, Many thanks for your questions and apologies for the delay in replying. >From a clean 20.04 Ubuntu, I installed 3.9 using the package installer from >the master branch. $ sudo add-apt-repository ppa:gnuradio/gnuradio -master There were no major issues with the GRC install, transfer of old 3.7 OOT blocks, their new python binding, libraries linkage or block import for that matter. The 3.9 OOT porting guide proved, helpful with some additional and relevant information to be found in the 3.8 porting guide particularly on external libraries inclusion. UHD 3.15.0.0-2build5 from a package manager install works fine. PYTHONPATH =/usr/local/lib/python3/dist-packages. The OOT blocks are being installed to: /usr/local/lib/python3/dist-packages/test and the blocks to: /usr/local/share/gnuradio/grc/blocks In all other respects the GRC works fine.. - Noting this release last weekend, on a separate drive, with a clean 20.04 Ubuntu, I have installed and built GRC 3.8.2.0 from gnuradio-3.8.2.0.tar.gz OOT blocks import without issue as per 3.7.11 using the older SWIG bindings. VOLKGNSSSDR as an external library is both visible and useable. I noticed that during the build the UHD interface was disabled and consequently the GRC source and sink blocks are both missing. These are available for build under ~/gr-uhd. Is there a reason for this please? Is 3.15 compatible and stable as a UHD interface, noting the very recent emergence of 4.0 RC? My research in the first instance, is to investigate the intrinsic carrier phase stability of an SDR system in RF loop-back and then through a geo-stationary satellite. The OOT blocks in development are of flexible direct spread spectrum coding and reception type. It’s therefore important that I settle on stable GRC/UHD variants for the next twelve months or so. Best regards, David GD4FMB From: Josh Sent: Monday, August 24, 2020 8:09 PM To: David Taylor (manx.net) Cc: GNURadio Discussion List Subject: Re: GRC version 3.9.0.0 git master (python 3.8.2) + OOT blocks David, 1) How is your GNU Radio installed in this system? 2) It sounds a lot like PYTHONPATH is misconfigured for OOT - where are your OOT files being installed to? Thanks, Josh On Fri, Aug 21, 2020 at 12:23 PM David Taylor (manx.net) wrote: Josh, Sorry to go over old ground yet again. In order to remove any additional problems caused by the use of external libraries, I have created a separate OOT branch that is void of external libraries. Stripped to the bone python and C++ blocks have been created using gr_modtool. Test codes validate the blocks code content as functional and they import correctly into the GRC with simple .yml. The top level CMakeLists.txt and others are unmodified from a clean new module. The current issue has been traced so far to the __init__.py file and its inability to resolve ‘__path__’ Consequently the pybind11 link fails to find my ‘test’ directory and the subsequent imported python block fails with no known parent package. I am unclear how and where this is initialised under python3? I have attended to the usual library and path ~./bashrc changes to no avail. The GRC outputs the AttributeError: message for the python and C++ OOT block. Once resolved, I can move forward again with the external library inclusion. Many thanks, David GD4FMB From: Josh Sent: Monday, August 17, 2020 11:45 AM To: David Taylor (manx.net) Cc: GNURadio Discussion List Subject: Re: GRC version 3.9.0.0 git master (python 3.8.2) + OOT blocks David, I've found most of the time I get the "No module named ..." error it is due to C++ linkage issues in setting up the CMake. There was a big jump in CMake modernization from GR 3.7 to 3.8, so be sure to use gr_modtool (from 3.9) to create a new module and copy your blocks in from there is usually the easiest way. Porting guide is here: https://wiki.gnuradio.org/index.php/GNU_Radio_3.8_OOT_Module_Porting_Guide and here: https://wiki.gnuradio.org/index.php/GNU_Radio_3.9_OOT_Module_Porting_Guide the one that usually gets me and causes the ModuleNotFoundError is this https://wiki.gnuradio.org/index.php/GNU_Radio_3.8_OOT_Module_Porting_Guide#GNU_Radio_Components Does your library reference any GR modules, or any other external libraries? Josh On Mon, Aug 17, 2020 at 3:58 AM David Taylor (manx.net) wrote: Hi, I have been developing a number of direct spread spectrum OOT blocks as part of a research project. Working blocks were originally developed using GRC 3.7.11, however I wish to move forward and have installed and persevered so far with GRC 3.9 from the master branch. The GRC, UHD, CMAKE (3.16) pybind11 (2.4.3) and other dependencies have been installed and build correctly. I have chosen to migrate the (3.7.11) C++ blocks and for completeness of the build process checking, have include
Re: GRC version 3.9.0.0 git master (python 3.8.2) + OOT blocks
Josh, Sorry to go over old ground yet again. In order to remove any additional problems caused by the use of external libraries, I have created a separate OOT branch that is void of external libraries. Stripped to the bone python and C++ blocks have been created using gr_modtool. Test codes validate the blocks code content as functional and they import correctly into the GRC with simple .yml. The top level CMakeLists.txt and others are unmodified from a clean new module. The current issue has been traced so far to the __init__.py file and its inability to resolve ‘__path__’ Consequently the pybind11 link fails to find my ‘test’ directory and the subsequent imported python block fails with no known parent package. I am unclear how and where this is initialised under python3? I have attended to the usual library and path ~./bashrc changes to no avail. The GRC outputs the AttributeError: message for the python and C++ OOT block. Once resolved, I can move forward again with the external library inclusion. Many thanks, David GD4FMB From: Josh Sent: Monday, August 17, 2020 11:45 AM To: David Taylor (manx.net) Cc: GNURadio Discussion List Subject: Re: GRC version 3.9.0.0 git master (python 3.8.2) + OOT blocks David, I've found most of the time I get the "No module named ..." error it is due to C++ linkage issues in setting up the CMake. There was a big jump in CMake modernization from GR 3.7 to 3.8, so be sure to use gr_modtool (from 3.9) to create a new module and copy your blocks in from there is usually the easiest way. Porting guide is here: https://wiki.gnuradio.org/index.php/GNU_Radio_3.8_OOT_Module_Porting_Guide and here: https://wiki.gnuradio.org/index.php/GNU_Radio_3.9_OOT_Module_Porting_Guide the one that usually gets me and causes the ModuleNotFoundError is this https://wiki.gnuradio.org/index.php/GNU_Radio_3.8_OOT_Module_Porting_Guide#GNU_Radio_Components Does your library reference any GR modules, or any other external libraries? Josh On Mon, Aug 17, 2020 at 3:58 AM David Taylor (manx.net) wrote: Hi, I have been developing a number of direct spread spectrum OOT blocks as part of a research project. Working blocks were originally developed using GRC 3.7.11, however I wish to move forward and have installed and persevered so far with GRC 3.9 from the master branch. The GRC, UHD, CMAKE (3.16) pybind11 (2.4.3) and other dependencies have been installed and build correctly. I have chosen to migrate the (3.7.11) C++ blocks and for completeness of the build process checking, have included a simple python OOT. The C++ to python code binding, make and install under Ubuntu 20.04 all work and the new blocks import correctly to flow-graph using modified .yml descriptors. 1). GRC 9.0 works standalone from git-master install and with the UHD, in my case a B210. 2). OOT blocks including the aforementioned python OOT block all fail at import. In my case ModuleNotFoundError: No module named ‘development’ i.e. failure of ‘import development’ in the flow-graph python script 3). I have tried and retained the library workarounds with PYTHONPATH and LD_LIBRARY_PATH, but these now seem irrelevant as the GRC basically loads and runs. 4). I have looked at the gr_modtool __init_.py file for indicators as to why both python and C++ blocks (using python bindings) both fail. The inability of python 3.8.2 in my case to resolve the import is clearly at its core. 5). The OOT GRC blocks themselves import correctly into the flow-graph produce error free python script and all have relatively primitive interfaces. Many thanks, David Taylor
Re: GRC version 3.9.0.0 git master (python 3.8.2) + OOT blocks
Josh,
Many thanks for your prompt reply and suggestions.
I have followed both of the porting guide documents, settling on the GRC 3.9
version install and using its particular gr_modtool variant for all OOT block
operations.
I am aware of the CMake modernisation changes through GRC 3.8, but confess to
not being a CMake expert!
However, my original 3.7.11 code uses FFT, added as a component together with
VOLK and VOLKGNSSDR. VOLKGNSSSDR has been included and both VOLK variants are
correctly notified in the CMake configure.
In the case of VOLKGNSSDR this required a separate find package in
/cmake/Modules/and ${VOLK_GNSSSDR_LIBRARIES} appended to target_link_libraries
as before.
Volk itself requires no special treatment other than profiling before use.
I will continue to check the detail.
David
From: Josh
Sent: Monday, August 17, 2020 11:45 AM
To: David Taylor (manx.net)
Cc: GNURadio Discussion List
Subject: Re: GRC version 3.9.0.0 git master (python 3.8.2) + OOT blocks
David,
I've found most of the time I get the "No module named ..." error it is due to
C++ linkage issues in setting up the CMake. There was a big jump in CMake
modernization from GR 3.7 to 3.8, so be sure to use gr_modtool (from 3.9) to
create a new module and copy your blocks in from there is usually the easiest
way. Porting guide is here:
https://wiki.gnuradio.org/index.php/GNU_Radio_3.8_OOT_Module_Porting_Guide and
here: https://wiki.gnuradio.org/index.php/GNU_Radio_3.9_OOT_Module_Porting_Guide
the one that usually gets me and causes the ModuleNotFoundError is this
https://wiki.gnuradio.org/index.php/GNU_Radio_3.8_OOT_Module_Porting_Guide#GNU_Radio_Components
Does your library reference any GR modules, or any other external libraries?
Josh
On Mon, Aug 17, 2020 at 3:58 AM David Taylor (manx.net)
wrote:
Hi,
I have been developing a number of direct spread spectrum OOT blocks as part
of a research project.
Working blocks were originally developed using GRC 3.7.11, however I wish to
move forward and have installed and persevered so far with GRC 3.9 from the
master branch.
The GRC, UHD, CMAKE (3.16) pybind11 (2.4.3) and other dependencies have been
installed and build correctly.
I have chosen to migrate the (3.7.11) C++ blocks and for completeness of the
build process checking, have included a simple python OOT.
The C++ to python code binding, make and install under Ubuntu 20.04 all work
and the new blocks import correctly to flow-graph using modified .yml
descriptors.
1). GRC 9.0 works standalone from git-master install and with the UHD, in my
case a B210.
2). OOT blocks including the aforementioned python OOT block all fail at
import. In my case ModuleNotFoundError: No module named ‘development’
i.e. failure of ‘import development’ in the flow-graph python script
3). I have tried and retained the library workarounds with PYTHONPATH and
LD_LIBRARY_PATH, but these now seem irrelevant as the GRC basically loads and
runs.
4). I have looked at the gr_modtool __init_.py file for indicators as to why
both python and C++ blocks (using python bindings) both fail.
The inability of python 3.8.2 in my case to resolve the import is clearly at
its core.
5). The OOT GRC blocks themselves import correctly into the flow-graph
produce error free python script and all have relatively primitive interfaces.
Many thanks,
David Taylor
GRC version 3.9.0.0 git master (python 3.8.2) + OOT blocks
Hi, I have been developing a number of direct spread spectrum OOT blocks as part of a research project. Working blocks were originally developed using GRC 3.7.11, however I wish to move forward and have installed and persevered so far with GRC 3.9 from the master branch. The GRC, UHD, CMAKE (3.16) pybind11 (2.4.3) and other dependencies have been installed and build correctly. I have chosen to migrate the (3.7.11) C++ blocks and for completeness of the build process checking, have included a simple python OOT. The C++ to python code binding, make and install under Ubuntu 20.04 all work and the new blocks import correctly to flow-graph using modified .yml descriptors. 1). GRC 9.0 works standalone from git-master install and with the UHD, in my case a B210. 2). OOT blocks including the aforementioned python OOT block all fail at import. In my case ModuleNotFoundError: No module named ‘development’ i.e. failure of ‘import development’ in the flow-graph python script 3). I have tried and retained the library workarounds with PYTHONPATH and LD_LIBRARY_PATH, but these now seem irrelevant as the GRC basically loads and runs. 4). I have looked at the gr_modtool __init_.py file for indicators as to why both python and C++ blocks (using python bindings) both fail. The inability of python 3.8.2 in my case to resolve the import is clearly at its core. 5). The OOT GRC blocks themselves import correctly into the flow-graph produce error free python script and all have relatively primitive interfaces. Many thanks, David Taylor
