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) <drtay...@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) < > drtay...@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) < >> drtay...@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 >>> >>
