Re: [USRP-users] latest E310 tutorial
There were no issues with the siggen example, I meant to paste in the name of the host fosphor python program and grabbed the wrong name -- sorry!. Your changes to both parts of fosphor look right. I used fosphor a bunch today, it really is a very useful program. Speaking of gr-ettus and siggen, I applied part of the API puncturing outlined in https://corvid.io/2017/04/22/stupid-rfnoc-tricks-loopback/ to make the siggen example a lot more useful by feeding it straight to the radio (and then looked at the signal with another radio using fosphor, and another radio using my home-brew block). Since you've cracked open gr-ettus anyway, is there any reason to not include the virtual void set_tx_streamer(bool active, const size_t port) virtual void set_rx_streamer(bool active, const size_t port) virtual void issue_stream_cmd(const uhd::stream_cmd_t , const size_t chan=0) API additions to the baseline gr-ettus? They don't seem to break anything else and they make the E310 a lot more useful on the transmit side. If just wish I could figure out a way to get gnuradio-companion to add the self.uhd_rfnoc_streamer_radio_0.set_tx_streamer(True, chan) line to the generated python so I wouldn't have to re-add it every time I mess with the GUI version. Thanks again, Dave On Tue, 2019-08-13 at 16:42 -0700, Nate Temple wrote: > Hi, > > We've pushed updated flowgraphs into gr-ettus for the networked > fosphor example to fix the FIFO select and QT display issues. There > is a few more minor things fixed in them but can you please give them > and try on your system? I will try to replicate the siggen issue you > ran into. > > > Regards, > Nate Temple > > On Sun, Aug 11, 2019 at 1:38 PM d.des via USRP-users < > usrp-users@lists.ettus.com> wrote: > > Thanks, Royce, that fixed the usrp side of both fosphor and my > > block! > > > > I also made two minor tweaks to the host side to get fosphor > > working on > > my PC. These are probably things that a Gnuradio expert would see > > right > > away but in case there's anyone else out there who primarily uses > > the > > c++ uhd interface and is barely Gnuradio literate here goes: > > > > The first problem was a segfault whenever the host side program > > rfnoc_siggen_network_host.py was launched. That turned out to be a > > problem with fosphor_display_impl.cc. The method > > "bool fosphor_display_impl::start()" ended without returning > > anything > > and my Fedora 30 machine really hated that. I put in a "return > > true" > > line at the end of the function and that fixed the problem. (It > > doesn't > > seem to matter whether the function returns true or false, it just > > needs to return something.) > > > > The second issue with the examples in stock form was that when I > > opened > > rfnoc_fosphor_network_host at first all I saw were controls, no > > plot. I > > spent some time looking for QT issues but it turned out to be > > really > > simple: there were GUI hints set on the slider controls but not on > > on > > the fosphor display block. The quickest fix is to remove the hints > > on > > the controls and the display shows up. > > > > Fosphor is a really nice quick survey tool. It's great to see 56 > > MHz at > > once with just a laptop and battery-powered E310. > > > > > > ___ > > 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
Re: [USRP-users] latest E310 tutorial
Hi, We've pushed updated flowgraphs into gr-ettus for the networked fosphor example to fix the FIFO select and QT display issues. There is a few more minor things fixed in them but can you please give them and try on your system? I will try to replicate the siggen issue you ran into. Regards, Nate Temple On Sun, Aug 11, 2019 at 1:38 PM d.des via USRP-users < usrp-users@lists.ettus.com> wrote: > Thanks, Royce, that fixed the usrp side of both fosphor and my block! > > I also made two minor tweaks to the host side to get fosphor working on > my PC. These are probably things that a Gnuradio expert would see right > away but in case there's anyone else out there who primarily uses the > c++ uhd interface and is barely Gnuradio literate here goes: > > The first problem was a segfault whenever the host side program > rfnoc_siggen_network_host.py was launched. That turned out to be a > problem with fosphor_display_impl.cc. The method > "bool fosphor_display_impl::start()" ended without returning anything > and my Fedora 30 machine really hated that. I put in a "return true" > line at the end of the function and that fixed the problem. (It doesn't > seem to matter whether the function returns true or false, it just > needs to return something.) > > The second issue with the examples in stock form was that when I opened > rfnoc_fosphor_network_host at first all I saw were controls, no plot. I > spent some time looking for QT issues but it turned out to be really > simple: there were GUI hints set on the slider controls but not on on > the fosphor display block. The quickest fix is to remove the hints on > the controls and the display shows up. > > Fosphor is a really nice quick survey tool. It's great to see 56 MHz at > once with just a laptop and battery-powered E310. > > > ___ > 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
Re: [USRP-users] latest E310 tutorial
Thanks, Royce, that fixed the usrp side of both fosphor and my block! I also made two minor tweaks to the host side to get fosphor working on my PC. These are probably things that a Gnuradio expert would see right away but in case there's anyone else out there who primarily uses the c++ uhd interface and is barely Gnuradio literate here goes: The first problem was a segfault whenever the host side program rfnoc_siggen_network_host.py was launched. That turned out to be a problem with fosphor_display_impl.cc. The method "bool fosphor_display_impl::start()" ended without returning anything and my Fedora 30 machine really hated that. I put in a "return true" line at the end of the function and that fixed the problem. (It doesn't seem to matter whether the function returns true or false, it just needs to return something.) The second issue with the examples in stock form was that when I opened rfnoc_fosphor_network_host at first all I saw were controls, no plot. I spent some time looking for QT issues but it turned out to be really simple: there were GUI hints set on the slider controls but not on on the fosphor display block. The quickest fix is to remove the hints on the controls and the display shows up. Fosphor is a really nice quick survey tool. It's great to see 56 MHz at once with just a laptop and battery-powered E310. ___ USRP-users mailing list USRP-users@lists.ettus.com http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
Re: [USRP-users] latest E310 tutorial
Are there more than one FIFOs in the flowgraph? If so, you may need to set the FIFO Select on each FIFO to select which FIFO block to use. Royce > On Aug 9, 2019, at 2:36 PM, d.des via USRP-users > wrote: > > The latest version of AN-315 > https://kb.ettus.com/Software_Development_on_the_E3xx_USRP_-_Building_RFNoC_UHD_/_GNU_Radio_/_gr-ettus_from_Source > is a very nice update. It was great to be able to build a more-up-to- > date version of UHD error-free. There still seem to be issues getting > the example or my own blocks to run in Gnuradio, however. > > Following the instructions when I run rfnoc_fosphor_network_usrp.py > I get > RuntimeError: RuntimeError: On node 0/FIFO_0, input port 0 is already > connected. > > I suspect that there may be a difference in the version of gr-ettus > that the the author used and the one I get from git following the > instructions. One hint is that the file size for > rfnoc_fosphor_network_usrp.py in the document is slightly different > than my copy generated following the instructions. Alternatively, maybe > Nate left out a few steps in modifying the python generated by GRC > before running it. I'm also having trouble running my own blocks and > examples such as addsub and gain with fresh-build FPGA images. These > images run fine in rfnoc_rx_to_file, but they segfault when gnuradio > attempts to connect the output of my blocks to anything else. I'm > hoping that it's all related and the fosphor is a good example case to > help a user such as myself get running. > > I Googled the port connection error and found some threads that > indicated that it was a known issue back in 2017. Since Nate had it > working so rececently when he updated the Application Note I hope that > he can share the last few pieces of the puzzle. > > > ___ > 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
