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

David Taylor (manx.net) drtaylor at manx.net
Sun Jul 26 10:06:51 EDT 2020


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 located using FindVOLKGNSSSDR  in /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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20200726/27925f08/attachment.html>


More information about the USRP-users mailing list