David,
You don't need MPIR. The dependency can be resolved with libgmp. Here's
what that portion of my OOT CMake looks like:
-- Found LOG4CPP: /usr/lib/x86_64-linux-gnu/liblog4cpp.so
-- Found PkgConfig: /usr/bin/pkg-config (found version "0.29.1")
-- Checking for module 'gmp'
-- No package 'gmp' found
-- Found GMP: /usr/lib/x86_64-linux-gnu/libgmpxx.so
-- Checking for module 'mpir >= 3.0'
-- No package 'mpir' found
-- Could NOT find MPIR (missing: MPIRXX_LIBRARY MPIR_LIBRARY
MPIR_INCLUDE_DIR)
-- Found MPLIB: /usr/lib/x86_64-linux-gnu/libgmpxx.so
If you don't already have it:
sudo apt install libgmp-dev
For VOLKGNSSSDR, the techniques you used for 3.7.11 should still work fine.
Here's an example of an external library from one of my OOT's.
https://github.com/drmpeg/gr-dvbgse/blob/master/CMakeLists.txt#L128
https://github.com/drmpeg/gr-dvbgse/blob/master/lib/CMakeLists.txt#L38
https://github.com/drmpeg/gr-dvbgse/blob/master/cmake/Modules/FindPcap.cmake
Ron W6RZ
On 7/26/20 07:06, David Taylor (manx.net) via USRP-users wrote:
Apologies if this question is out of scope, or if the answer is to be
found elsewhere in the history.
I have been upgrading the GRC from 3.7.11 (with Ubuntu 18.04) to GRC
9.0 (with Ubuntu 20.04 LTS). See previous dialogue below, using
3.8.1.0~rc12build2
Currently, the synaptic package manager and $sudo apt install gnuradio
methods both align on GRC version 9.0. So I have persevered at this
version.
UHD is at v 3.15 and with Python3 the package is basically functional
using an available B210 over USB3.
--------------
The problem arises with OOT blocks transfer, CMake in its “modern
form” and with the new dependency of MPIR.
1). MPIR library has been installed independently and built at V3.0 ,
with libraries and header located in /usr/local/lib and
/usr/local/include respectively.
2). My 3.7.11 code also uses VOLKGNSSSDR in the build. As with the
3.7.11 version, VOLKGNSSSDR was installed and tested independently
with libraries and headers locatedusing FindVOLKGNSSSDRin
/cmake/modules and a find package reference added to CMakeLists.txt.
I have yet to check whether {VOLK_GNSSSDR_LIBRARIES} has to be added
to the target_link_libraries, noting the significantly different
approach now used in .. //my_development/lib/CMakeLists.txt
3). The standard VOLK library is found in CMake configure as it is now
part of the v 9.0 build package.
4). I have tried adapting the older find package method used in 2) for
MPIR without success, but note the following CMake configure output.
MPIRXX_LIBRARY-NOTFOUND
MPIR_INCLUDE_DIR-NOTFOUND
MPIR_LIBRARY/usr/local/lib/libmpir.so
Can anyone help with the MPIR problem please?
As an OOT build requirement at V 9.0., I would have expected expected
the gr-modtool to generate some boiler-plate code to cover this
dependency addition!
Is there a more elegant and better way of incorporating VOLKGNSSSDR
and the MPIR libraries using modern CMake?
Would reversion to 3.8.1 help in the short term, noting that the
output from my work might benefit and the later GRC scheduler
improvements?
Many thanks.
David
GD4FMB
*From:* Marcus D. Leech via USRP-users
*Sent:* Tuesday, June 23, 2020 8:30 PM
*To:* usrp-users@lists.ettus.com
*Subject:* Re: [USRP-users] GRC up-grade - installation issues
On 06/23/2020 03:23 PM, David Taylor (manx.net) via USRP-users wrote:
Marcus.
Many thanks for your prompt reply.
Complete removal of everything from /usr/share/uhd/images, then
running the images-downloader from /usr/bin works fine.
I have only managed to try this with a B210 as the other transceivers
remain in the laboratory under Covid19 university building closure
measures.
The N210 is yet to be used, but thanks for the advising on the
particular EEPROM image load method,
OK, so with B2xx, if they already have a loaded FPGA image, they won't
try to re-load from your host during start-up, unless you
power-cycle them first. So, this can result in you having upgraded
the host side of things, complete with host-resident images,
and getting a "mis-match" error with B2xx. The UHD code does NOT
attempt to re-load the FPGA image if the host side is
newer than the code resident on the B2xx--only after a power-cycle.
It was interesting to see the extra console UHD diagnostics,
particularly about clock sources and the 1 PPS input.
I have a Rubidium 10 MHz source and 1PPS generator source that will
eventually be incorporated for USRP synchronisation.
However, I am now in the process of setting up the toolchain and new
gr_modtool and transitioning the 3.7x OOT blocks
The GNU Radio 3.8 OOT Module Porting Guide looks helpful at 16 May 2020.
The only real issue I had before was to include FindVOLKGNSSSDRcmake
and the corresponding library.
Regards,
David.
*From:* Marcus D. Leech via USRP-users
*Sent:* Tuesday, June 23, 2020 1:47 AM
*To:* usrp-users@lists.ettus.com
*Subject:* Re: [USRP-users] GRC up-grade - installation issues
On 06/22/2020 02:45 PM, David Taylor (manx.net) via USRP-users wrote:
Dear all,
I have been successfully running a B200/ B210 research project for
two years based on Ubuntu 18.04 LTS and version 3.7x GRC.
This includes a number of OOT blocks developed for direct sequence
spread spectrum, using the Volk GNSSSDR library extensions. An N210
USRP is also at my disposal.
I now have a clean upgrade to Ubuntu 20.04 LTS and wish to refresh
the GRC & UHD drivers to the latest stable release, taking best
advice please to ensure project conclusion.
The issues:-
1). GRC version 3.8.1.0~rc12build2 works standalone and appears to
have similar Cmake files structure and content. (3.9.0.0 is listed
in the package manager as available, but with significant and
noticeable changes in the software migration and dependencies)?
2). Libuhd-dev at 3.15.0.0-2build5 correctly identifies the B210
over USB3. (I note that library-file libuhd003 no longer forms part
of this package).
3). Running “uhd_images_downloader.py” fully populates
/usr/share/images/.
There is an issue with FPGA compatibility, which I have seen before
in 3.7x GRC. “Expected FPGA compatibility number 16 expected got 14.”
This issue was solved under V3.7x simply by replacement of the FPGA
image from archive.
Is this compatibility issue with your N210 or B2xx? It isn't clear.
4). I have removed all FPGA images from the /usr/share/images
directory and have selectively tried installing a number of earlier
discrete images and boot-loader from the archive, but all without
success.
5). A re-run of the uhd-images-downloader now fails to re-populate
the images folder, however the python(3) script itself runs.
You might want to simply remove *everything* from
/usr/share/uhd/images, and re-run:
sudo uhd_images_downloader.py
[Making certain it's running the version you think it's running--if
you installed from pre-packaged, it'll be in /usr/bin]
If this doesn't work, please share the error messages produced with us.
Also, because I didn't see anything in your work-log about it, for
N210, you have to run:
uhd_image_loader --args addr=<addr-of-n210>,type=n200
This loads the appropriate image into the EEPROM of the N210. The
N2xxx series, unlike the B2xx series don't do this dynamically at
runtime. Once you load an image into them, that image is there
until it is reprogrammed, even across power-off. This is different than
B2xx, which manages this automatically after power-up.
Many thanks in advance and I look forward to being able to
contribute to the group.
Best regards,
David Taylor
Ph.D Researcher, Limerick University, Ireland. GD4FMB
_______________________________________________
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
------------------------------------------------------------------------
_______________________________________________
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
_______________________________________________
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
------------------------------------------------------------------------
_______________________________________________
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
_______________________________________________
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
_______________________________________________
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
