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
Sent: Monday, August 31, 2020 12:34 PM
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
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
Sent: Monday, August 24, 2020 8:09 PM
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
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
Sent: Monday, August 17, 2020 11:45 AM
Subject: Re: GRC version 3.9.0.0 git master (python 3.8.2) + OOT
blocks
David,
the one that usually gets me and causes the ModuleNotFoundError is
this
Does your library reference any GR modules, or any other external
libraries?
Josh
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
|