Hello, I'm also experiencing the same issues - I tried using the commits that you said Paul and they still gave me the RuntimeErrors. I thought I was doing something wrong, so I was trying a fresh install in the meantime, but had little success. This is what I tried:
In the e300 folder (on host machine, i.e. my laptop) I used "git checkout xxxx" to checkout the uhd and gr-ettus branches. Then I remade uhd and gr-ettus and copied them over to my E312 and ran "uhd_usrp_probe" and the benchmark test uhd example - both gave errors and the benchmark test gave the same RuntimeError as above. Did I make a mistake/misunderstand what you were saying Paul? Having said that, I am able to run GNU Radio flowgraphs that use the RFNoC Radio blocks (instead of UHD USRP Sink/Source) but the performance is limited (i.e. the sample rate of my flowchart has to be below 500 kHz) due to, from my understanding, the limitations of the ARM processor. Also, were any of you able to receive/transmit on channel B on the E310/E312? I was unable to do this by selecting "B" in the RFNoC Radio block as it gave me an error regarding missing block "Radio_1". I was unable to find how to add this block in with a custom fpga image. Thank you for your help so far gentlemen. Hopefully the USRP folks are able to fix this issue soon :). Kind regards, Ronakraj On Wed, Feb 7, 2018 at 3:01 AM, Brais Ares <ba...@gradiant.org> wrote: > Hello, > > I'm experiencing the same problems as Paul and Ronakraj did. > > It seems the automatic installation using PyBOMBS falls in that error: > "RuntimeError: > RuntimeError: On node 0/FIFO_0, output port 0 is already connected". > Will it be fixed soon or is there any easy workaround? > > I also tried the uhd commit mentioned by Paul (I'm planning to develop > through C API, so I don't need gr-ettus) but I didn't manage to make it > work. Even though I load environment variables for cross-compilation, after > using cmake, make and make install (following this guide > <https://kb.ettus.com/Software_Development_on_the_E310_and_E312>) I end > up with executables compiled for x86_64 architecture, instead of ARM. I'm > in a dead end. > > Regards, > ~Brais > > > > > 2018-02-02 0:36 GMT+01:00 Paul Sorensen via USRP-users < > usrp-users@lists.ettus.com>: > >> I was able to get it up and running by following this guide: >> >> https://kb.ettus.com/Software_Development_on_the_E3xx_USRP_- >> _Building_RFNoC_UHD_/_GNU_Radio_/_gr-ettus_from_Source >> >> BUT: using the gr-ettus commit of 30302780a44f3f0b146e9b81f88e70c9d983f559 >> and the uhd commit of 12a34d6ef6b9666e29a23039291138f989c7c2ce >> >> -Paul Sorensen >> >> On Thu, Feb 1, 2018 at 5:27 PM Ronakraj Gosalia via USRP-users < >> usrp-users@lists.ettus.com> wrote: >> >>> Hey everyone! >>> >>> >>> This is my very first message, so apologies if I didnt send this >>> correctly 😊. >>> >>> >>> I am also facing the same issue outlined by Paul and would really >>> appreciate some assistance with this. I am using an Ettus USRP E312, GNU >>> Radio 3.7.10.2 <+6137102> and Ubuntu 16.04.3. <+6116043> Here is what I >>> tried. >>> >>> >>> I first started by following the PyBOMBS process in [1] to setup the >>> cross-compile environment on my host machine (laptop). After using sshfs on >>> my sdr (USRP E312) I was unable to use the set_env file in the ~/usr >>> directory, but instead had to source the set_env file in ~/usr/usr. After >>> this, uhd_find_devices was routed properly, but uhd_usrp_probe gave me the >>> following error: >>> >>> >>> Error: RuntimeError: Expected FPGA compatibility number 255.x, but got >>> 14.0: >>> The FPGA build is not compatible with the host code build. >>> >>> Now I think this error is due to the fact that the script was trying to >>> run the default fpga image stored >>> in/usr/share/uhd/images/usrp_e310_fpga_sg3.bit which >>> was developed for an older (or different?) version of UHD. From the >>> uhd_usrp_probe output it says that my current version >>> is UHD_4.0.0.rfnoc-devel-409-gec9138eb so I tried to download the FPGA >>> images for this version and store them inside ~/usr/usr/share/uhd/images/ >>> and running "uhd_usrp_probe --args='fpga=/home/root/usr/us >>> r/share/uhd/images/usrp_e3xx_fpga_idle_sg3.bit'" this loaded up and >>> gave me the exact same output error as what Paul got. I also cannot run any >>> uhd examples and get the same runtime error. >>> >>> >>> Following this, I tried [2], and the fosphor example at the end ran >>> really well. However, again I was unable to run any of the uhd examples >>> after this. I also found issues trying to run a simple BPSK transmitter >>> that I made with the B205. I was unable to use the USRP sink/sources in my >>> GNU Radio flowchart as it gave me the following error when running the >>> python script: >>> >>> >>> Traceback (most recent call last): >>> File "simple_tx_e312.py", line 229, in <module> >>> main() >>> File "simple_tx_e312.py", line 218, in main >>> tb = top_block_cls() >>> File "simple_tx_e312.py", line 68, in __init__ >>> channels=range(1), >>> File >>> "/home/root/usr/usr/lib/python2.7/site-packages/gnuradio/uhd/__init__.py", >>> line 122, in constructor_interceptor >>> return old_constructor(*args) >>> File >>> "/home/root/usr/usr/lib/python2.7/site-packages/gnuradio/uhd/uhd_swig.py", >>> line 2082, in make >>> return _uhd_swig.usrp_sink_make(*args) >>> RuntimeError: RuntimeError: On node 0/FIFO_0, output port 0 is already >>> connected >>> >>> >>> I was able to run code by replacing the USRP Sink with an RFNoC Radio TX >>> block, however the FPGA image is missing the DMAFifo and DUC RFNoC blocks >>> so I directly connected my flowchart to a FIFO buffer -> RFNoC:Radio >>> TXblock. This produced a signal with a desired frequency response, but I >>> was unable to decode the signal when I ran it over the air and via a >>> coaxial cable. I tried many different configurations (over the air and via >>> coaxial cable) including an E312 TX -> E312 (another one) RX, E312 TX -> >>> B205 RX. I also tried B205 TX -> E312 RX and this worked perfectly. B205 TX >>> -> B205 RX with the same code also works well. This is why I think the >>> issue is due to the RFNoC Radio TX block. I am also unable to use the >>> Channel B TX/RX antennas or the GPSDO timing source as the images provided >>> in "uhd-images_4.0.0.rfnoc-devel-238-g39a41476 <+6141476>" and >>> "uhd-images_4.0.0.rfnoc-devel-409-gec9138eb" do not support these >>> options (I can send more specifics about this if it helps, otherwise I will >>> create a new thread in the near future). >>> >>> >>> Lastly, I have been following [3]. At the top of this document it does >>> state " >>> *However*, this document only covers using RFNoC for the USRP >>> X300/X310. Using RFNoC with the E310/E312 will be covered in another >>> document. >>> " which is why I did not initially follow the instructions on this >>> document. Having read that now I found that there are several references to >>> the E310 throughout the document, which was very confusing. The document >>> states that the non-RFNOC fpga images should have DMAFifo and DUC blocks, >>> however whenever I tried loading these images via "uhd_usrp_probe >>> --args='fpga=...'" it always gave me same output as that in Paul's message >>> with always the following blocks included: >>> >>> >>> |* | / >>> *|* | | RFNoC blocks on this device: >>> *|* | | >>> *|* | | * Radio_0 >>> *|* | | * FIFO_0 >>> *|* | | * Window_0 >>> *|* | | * FFT_0 >>> *|* | | * fosphor_0 >>> *|* | | * FIFO_1 >>> *|* | | * FIR_0* >>> >>> >>> My next strategy is to create a custom FPGA image and try this by >>> following the instructions in [3]. Is this the only way to install the >>> DMAFifo, DUC RFNoC blocks to transmit on my E312? I may have made a >>> mistake in my understanding/diagnosis somewhere and would appreciate any >>> help that you may be able to give me. Thank you for your time in advance. >>> >>> >>> Ronakraj >>> >>> >>> >>> References: >>> >>> >>> [1] https://kb.ettus.com/Software_Development_on_the_E310_and_E312 >>> >>> [2] <https://kb.ettus.com/Software_Development_on_the_E310_and_E312> >>> https://kb.ettus.com/Software_Development_on_the_E3xx_ >>> USRP_-_Building_RFNoC_UHD_/_GNU_Radio_/_gr-ettus_from_Source >>> >>> [3] >>> <https://kb.ettus.com/Software_Development_on_the_E3xx_USRP_-_Building_RFNoC_UHD_/_GNU_Radio_/_gr-ettus_from_Source> >>> https://kb.ettus.com/Getting_Started_with_RFNoC_Development >>> Getting Started with RFNoC Development - Ettus Knowledge Base >>> <https://kb.ettus.com/Getting_Started_with_RFNoC_Development> >>> kb.ettus.com >>> Abstract. This application note guides a user through basic information >>> on the RFNoC architecture, installing necessary software to develop custom >>> RFNoC blocks, also ... >>> >>> Software Development on the E3xx USRP - Ettus >>> <https://kb.ettus.com/Software_Development_on_the_E3xx_USRP_-_Building_RFNoC_UHD_/_GNU_Radio_/_gr-ettus_from_Source> >>> kb.ettus.com >>> Abstract. This application note is one of a multi-part series which will >>> cover the software development process on the USRP E310, E312 and E313. >>> >>> Software Development on the E310 and E312 - Ettus ... >>> <https://kb.ettus.com/Software_Development_on_the_E310_and_E312> >>> kb.ettus.com >>> Abstract. This application note covers the software development process >>> on the USRP E310 and E312. Overview. Note: Linux only. When developing >>> software for the ... >>> >>> >>> _______________________________________________ >>> 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 >> >> > > > -- > > [image: logo_170x100px.png] <http://www.gradiant.org/> > > Brais Ares Fernández > Investigador - Desarrollador | Área de Comunicaciones Avanzadas > Researcher - Developer | Advanced Communications Department > > Ph. (+34) 986 120 430 <+34%20986%2012%2004%2030> Ext. 3030 > ba...@gradiant.org | www.gradiant.org > > [image: Iconos Redes Sociales GRD Firma email-01] > <https://www.facebook.com/GradiantNews/> [image: Iconos Redes Sociales > GRD Firma email-02] <https://twitter.com/Gradiant> [image: Iconos Redes > Sociales GRD Firma email-03] > <https://www.linkedin.com/company-beta/769728> [image: Iconos Redes > Sociales GRD Firma email-04] > <https://www.youtube.com/user/ComunicacionGRD> > Take care of the environment. Try not to print this email. > The information contained in this email message may be confidential > information, and may also be the subject of legal professional privilege. > If you are not the intended recipient, any use, interference with, > disclosure or copying of this material is unauthorized and prohibited. > Please inform us immediately and destroy the email. Thank you for your > cooperation. >
_______________________________________________ USRP-users mailing list USRP-users@lists.ettus.com http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
