[USRP-users] GRC up-grade - installation issues

Ron Economos w6rz at comcast.net
Sun Jul 26 10:59:30 EDT 2020


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 at 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 at 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 at lists.ettus.com
>>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>>
>> ------------------------------------------------------------------------
>> _______________________________________________
>> USRP-users mailing list
>> USRP-users at lists.ettus.com
>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>>
>>
>> _______________________________________________
>> USRP-users mailing list
>> USRP-users at lists.ettus.com
>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
> ------------------------------------------------------------------------
> _______________________________________________
> USRP-users mailing list
> USRP-users at lists.ettus.com
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
> _______________________________________________
> USRP-users mailing list
> USRP-users at lists.ettus.com
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20200726/06ad1162/attachment.html>


More information about the USRP-users mailing list