Hi Marcus, Thanks for your advice.
Here are all the messages from gnu radio companion. The symptoms are very easy to reproduce. The block I tested is simply a connection between Signal Source (1KHz) and Audio sink, selecting the wxgui Generating: '/Users/glenlangston/Desktop/Research/watch/top_block.py' Executing: /opt/local/Library/Frameworks/Python.framework/Versions/2.7/Resources/Python.app/Contents/MacOS/Python -u /Users/glenlangston/Desktop/Research/watch/top_block.py Traceback (most recent call last): File "/Users/glenlangston/Desktop/Research/watch/top_block.py", line 25, in <module> from grc_gnuradio import wxgui as grc_wxgui ImportError: cannot import name wxgui I’ve done a gnuradio uninstall sudo port uninstall gnuradio Then a re-install using brew, following a trail of googled suggestions. brew install gnuradio More suggestions? Thanks Glen > On Nov 20, 2017, at 3:45 PM, Marcus D. Leech <mle...@ripnet.com> wrote: > > On 11/20/2017 03:07 PM, Glen Langston wrote: >> Hello >> >> I’m wondering if anyone else is having the same trouble with wxgui in >> Gnuradio. >> >> I’ve installed gnu radio on several MacBooks and ubuntu systems. >> I’ve got an application we’ve been using for years that uses >> >> wxgui >> >> Now I’ve tried to upgrade to get access to a new SDR but the software is >> refusing to run as is shown by the same message for gnu radio companion: >> >> File "/Users/glenlangston/Desktop/Research/watch/top_block.py", line 25, in >> <module> >> from grc_gnuradio import wxgui as grc_wxgui >> >> Suggestions? >> >> Thanks >> > There's probably more lines of error message there, and they would be helpful > in helping you. > > Also, I changed the subject to be more closely related to the topic at hand. > > Keep in mind that WXGUI is *going away* some time soon. The underlying > libraries haven't been supported in years, and WXGUI suffers significant > performance penalties compared to Qt GUI, which is what prompted me to > start work on spectro_radiometer as a replacement for > simple_ra. > > >> Glen >> >> our application is noted at www.opensourceradiotelescopes.org >> <http://www.opensourceradiotelescopes.org/> >> >> >>> On Nov 20, 2017, at 2:14 PM, Bakshi, Arjun <bakshi...@buckeyemail.osu.edu >>> <mailto:bakshi...@buckeyemail.osu.edu>> wrote: >>> >>> That was it. I overlooked that setting your setup. >>> >>> Hopefully the last issue. I'm still getting a lot of under flow errors when >>> I use the same radio (A/B ) for a rx and tx block. I have a WBX daughter >>> board in there so simultaneous rx-tx should not be a >>> problem. As mentioned earlier, I was able to get 2rx-tx links running at >>> 5Msps previously with N210s. >>> >>> Changing the buffer size, file size, or the sampling rate (not the 200e6 >>> one) doesn't help. >>> >>> Thank you, >>> >>> AB >>> From: Michael Carosino <m.caros...@gmail.com <mailto:m.caros...@gmail.com>> >>> Sent: Monday, November 20, 2017 1:24:17 PM >>> To: Bakshi, Arjun >>> Cc: discuss-gnuradio@gnu.org <mailto:discuss-gnuradio@gnu.org> >>> Subject: Re: [Discuss-gnuradio] X310 with 2 WBX in full duplex >>> >>> I've had this error before, can't recall the solution however one thing to >>> try is setting the DDC block select parameters. On the upper DDC block set >>> block select to 0 and on the lower DDC set the block select to 1. >>> (sometimes the auto-select function fails to work correctly I think). >>> >>> On Mon, Nov 20, 2017 at 10:14 AM, Bakshi, Arjun >>> <bakshi...@buckeyemail.osu.edu <mailto:bakshi...@buckeyemail.osu.edu>> >>> wrote: >>> Hi, >>> >>> Thanks for the info about the sampling rates. That was the source of the >>> issue. >>> >>> The issue was with the output rate of the DUC block, which should be set >>> to 200MHz. Changing that to 200e6 fixes the underflow issues. I guess that >>> the input rate is the sampling rate that I'm used to setting in the N210. I >>> can now run 2 TXblocks without a problem. >>> >>> The sampling rate in the RFNoC-radio(tx) block can be set to what you want, >>> but it'll get reset to 200e6 along with a warning saying so. >>> >>> I am still having trouble with the RX blocks. >>> -- When I add an RX flow to a graph with 2 TX flows in it, I get underflows >>> again. The application does not hang though. >>> >>> -- When I have 2 RX flows to the graph, I get the following error: >>> self.device3.connect(self.uhd_rfnoc_streamer_radio_2.get_block_id(), 0, >>> self.uhd_rfnoc_streamer_ddc_1.get_block_id(), 0) >>> File "/usr/local/lib/python2.7/dist-packages/ettus/ettus_swig.py", line >>> 1670, in connect >>> return _ettus_swig.device3_sptr_connect(self, *args) >>> RuntimeError: RuntimeError: On node 0/DDC_0, input port 0 is already >>> connected. >>> terminate called after throwing an instance of 'uhd::assertion_error' >>> what(): AssertionError: [0/DDC_0] Attempting to disconnect input port 0, >>> which is not registered as connected! >>> >>> It seems to have an issue with the lower DDC block. I changed the setup to >>> have only 1 DDC block with 2 channels, but that resulted in an overrun >>> error like "Ooverrun on chan 0". >>> >>> How can I fix these issues? >>> >>> Image of error prompt, and grc file attached. >>> >>> Thanks, >>> >>> AB >>> >>> From: Michael Carosino <m.caros...@gmail.com <mailto:m.caros...@gmail.com>> >>> Sent: Monday, November 20, 2017 12:31:52 AM >>> >>> To: Bakshi, Arjun >>> Cc: discuss-gnuradio@gnu.org <mailto:discuss-gnuradio@gnu.org> >>> Subject: Re: [Discuss-gnuradio] X310 with 2 WBX in full duplex >>> >>> Hi, >>> >>> looks like gnuradio is freezing due to the massive amount of underflows >>> ocurring. First try replacing the constant source with two separate analog >>> fast noise sources connected to the dma fifo - this might help if indeed >>> the problem is that the PC is being too slow to generate samples. Secondly, >>> revert the dma fifo depths to the default 32M and see if it has any effect >>> but I suspect the first option should fix your issues. Also it's definitely >>> helpful to test each single tx chain on its own to make sure it works as >>> expected before trying both together! >>> >>> Assuming you are using an x310, the sampling rate on the radio block should >>> be set to 200 megasamples/per sec, similarly the DUC output rate should >>> also be 200 megasamples/per sec. On the receive side, the radio block's >>> sampling rate should again be set to 200megasamp/sec with the DDC input >>> rate being set to the same as well. Also the analog bandwidth in the >>> context of the tx side just adjusts some filters I believe - so I'd leave >>> it at the default of 56Mhz. On the rx side I'd also leave it at the default >>> of 56Mhz unless you have some interferer in that range that you'd want to >>> avoid. >>> >>> On Sat, Nov 18, 2017 at 4:53 PM, Bakshi, Arjun >>> <bakshi...@buckeyemail.osu.edu <mailto:bakshi...@buckeyemail.osu.edu>> >>> wrote: >>> Hi, >>> >>> I've installed the correct uhd/gnuradio/gr-ettus packages now, and >>> constructed the attached flow graph. However, the application hangs up >>> after a second or so. Underflow warnings also appear almost immediately >>> after the flow starts. >>> >>> Image of flow graph and error attached. GRC file also attached. >>> >>> An earlier email mentioned: >>> ==== >>> Also you may get underflows depending on your >>> sample rate, in my case these were solved by moving the bpsk transmit >>> chain to fabric (RFNoC) as the host was not fast enough to generate >>> samples otherwise. >>> ==== >>> >>> However my sampling rate is pretty low. 1Msps. With 2xN210 I can support >>> ~5Msps tx+rx on this PC. >>> >>> Any ideas on whats going on, and how to fix it? >>> >>> Also, what are DUC input/out rates? What should the "analog bandwidth" be >>> set to? Same as sampling rate or 0, or something else? >>> >>> Thank you, >>> >>> AB >>> From: Bakshi, Arjun >>> Sent: Monday, November 6, 2017 2:01:16 PM >>> To: Michael Carosino >>> >>> Cc: discuss-gnuradio@gnu.org <mailto:discuss-gnuradio@gnu.org> >>> Subject: Re: [Discuss-gnuradio] X310 with 2 WBX in full duplex >>> >>> Thanks for the pointers. I'll look into them soon. I've temporarily moved >>> to another setup. Will report back when I come back the this one. >>> >>> Thanks, >>> >>> AB >>> From: Michael Carosino <m.caros...@gmail.com <mailto:m.caros...@gmail.com>> >>> Sent: Friday, November 3, 2017 3:38:37 PM >>> To: Bakshi, Arjun >>> Cc: discuss-gnuradio@gnu.org <mailto:discuss-gnuradio@gnu.org> >>> Subject: Re: [Discuss-gnuradio] X310 with 2 WBX in full duplex >>> >>> Hi, >>> >>> I don't believe you need to install Xilinx/vivado/etc - that's only needed >>> if you want to create your own rfnoc blocks (like I did for the >>> transmitter, but ideally you avoid this as its a lot of work!). >>> >>> You should simply need the UHD rfnoc_devel branch installed w/gnuradio and >>> use the image downloader to download the precompiled image for >>> usrp_x310_fpga_HG and flash it to the x310. (usrp_x310_fpga_HG contains 2x >>> DDC, 2x DUC, 2x Radios, and 1x DMAFIFO which is all you should need per my >>> previous pictures). >>> >>> For instructions, see >>> https://kb.ettus.com/Getting_Started_with_RFNoC_Development#Testing_the_default_FPGA_image_and_building_from_existing_blocks >>> >>> <https://kb.ettus.com/Getting_Started_with_RFNoC_Development#Testing_the_default_FPGA_image_and_building_from_existing_blocks> >>> and also flashing instructions here >>> http://files.ettus.com/manual/page_usrp_x3x0.html#x3x0_load_fpga_imgs >>> <http://files.ettus.com/manual/page_usrp_x3x0.html#x3x0_load_fpga_imgs> >>> >>> On Fri, Nov 3, 2017 at 8:42 AM, Bakshi, Arjun >>> <bakshi...@buckeyemail.osu.edu <mailto:bakshi...@buckeyemail.osu.edu>> >>> wrote: >>> Thanks for the quick reply, Michael. I looked into installing RFNoC and >>> thats going to need vivado/xilinx, and a bunch of other stuff. >>> >>> Trouble is that I don't have +20GB to spare needed for its installation. Is >>> there any way around it? What are the bare minimum options required? I >>> tried installing the Vivado Lab Solutions instead, but I guess thats not >>> enough as I couldn't get ettus's fpga software to build after just that. >>> >>> Install options image attached. >>> >>> Thanks, >>> >>> AB >>> From: Michael Carosino <m.caros...@gmail.com <mailto:m.caros...@gmail.com>> >>> Sent: Thursday, November 2, 2017 10:21:52 PM >>> To: Bakshi, Arjun >>> Cc: discuss-gnuradio@gnu.org <mailto:discuss-gnuradio@gnu.org> >>> Subject: Re: [Discuss-gnuradio] X310 with 2 WBX in full duplex >>> >>> Hi, >>> >>> I've successfully gotten the two tx-rx setup on an x310 you've >>> described but I did it somewhat differently. Instead of using the usrp >>> source/sink blocks I ended up using the RFNoC blocks - the main reason >>> for this is because a USRP Sink block is made up of the following >>> RFNoC blocks: RFNoC DMAFIFO -> RFNoC DUC -> RFNoC Radio. It turns out >>> that the DMAFIFO included by the USRP Sink block has a default depth >>> size of 32MB and this results in multiple seconds of delays for the >>> sample rates I was using (Ettus includes this fifo due to some flow >>> control latencies in their protocol that they use for transport >>> between the USRP and host over ethernet). >>> >>> Anyways, by manually creating the radio chain in RFNoC as described >>> above, you can adjust the default depth size of the DMAFIFO. By >>> playing around I found that a depth of 2^20 = 1.04MB worked well. It >>> is also of note that if you do this method you need four total radio >>> blocks - 2 for transmit and 2 for receive (for some reason the >>> multi-channel selection in the rfnoc radio block did not work, this >>> method does however). >>> >>> I would also run 'ethtool -G eth0 rx 4096' to ensure packets aren't >>> dropped in your NIC. Also you may get underflows depending on your >>> sample rate, in my case these were solved by moving the bpsk transmit >>> chain to fabric (RFNoC) as the host was not fast enough to generate >>> samples otherwise. >>> >>> Finally, you will probably experience occasional errors on flow graph >>> startup about synchronization errors (timeout waiting for PLL to lock, >>> backend sync failed, unexpected fifo depth), retrying to run the >>> flowgraph (sometimes it takes a few tries) will usually get it >>> running. I've spoken to Ettus about this and they are tracking this >>> issue so hopefully its solved soon. >>> >>> Attached a picture of transmit/receive configuration in RFNoC. >>> >>> regards, >>> Michael >>> >>> >>> >>> On Thu, Nov 2, 2017 at 7:12 PM, Bakshi, Arjun >>> <bakshi...@buckeyemail.osu.edu <mailto:bakshi...@buckeyemail.osu.edu>> >>> wrote: >>> > Few mistakes I caught after sending it. Center frequencies I had chosen >>> > were >>> > out of range for WBX. Fixed now. Also, image file now has proper >>> > extension. >>> > >>> > >>> > Thank you, >>> > >>> > >>> > AB >>> > >>> > ________________________________ >>> > From: Bakshi, Arjun >>> > Sent: Thursday, November 2, 2017 9:38:48 PM >>> > To: discuss-gnuradio@gnu.org <mailto:discuss-gnuradio@gnu.org> >>> > Subject: X310 with 2 WBX in full duplex >>> > >>> > >>> > Hi, >>> > >>> > >>> > I'm trying to get two Tx-Rx links running with an X310 with two WBX >>> > daughterboards in it. I've used multi-channel USRP source/sink blocks, but >>> > I'm experiencing latency (L) errors with the connection, and then the >>> > application (GRC) hangs. I've attached an image of my USRP source/sink >>> > blocks. I'm connected to the X310 with a 1GB ethernet connection. >>> > >>> > >>> > Can anyone point out the reason/mistake? Also, is the sub-device spec >>> > correct? Followed instructions for WBX from here: >>> > https://www.ettus.com/content/files/kb/application_note_frontends_subdevices_antenna_ports.pdf >>> > >>> > <https://www.ettus.com/content/files/kb/application_note_frontends_subdevices_antenna_ports.pdf> >>> RX DSP Chain 1 Logic DDC ADC SMA RXB - Ettus Research >>> <https://www.ettus.com/content/files/kb/application_note_frontends_subdevices_antenna_ports.pdf> >>> www.ettus.com <http://www.ettus.com/> >>> Default Sub-Device and Antenna Specifications UHD will automatically select >>> a sub-device and antenna specification if they are not specified by you. >>> >>> > >>> > My goal: >>> > >>> > I want to have a Tx-Rx link in freq F1 and another in freq F2 at the same >>> > time. One daughterboard TXes in F1 and RXes in F2, while other TXes in F2 >>> > and RXes in F1. Is this possible with the equipment I have? >>> > >>> > >>> > Thank you, >>> > >>> > >>> > AB >>> > >>> > >>> > _______________________________________________ >>> > Discuss-gnuradio mailing list >>> > Discuss-gnuradio@gnu.org <mailto:Discuss-gnuradio@gnu.org> >>> > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio >>> > <https://lists.gnu.org/mailman/listinfo/discuss-gnuradio> >>> Discuss-gnuradio -- GNU Radio, a free software radio toolkit >>> <https://lists.gnu.org/mailman/listinfo/discuss-gnuradio> >>> lists.gnu.org <http://lists.gnu.org/> >>> To see the collection of prior postings to the list, visit the >>> Discuss-gnuradio Archives. Using Discuss-gnuradio: To post a message to all >>> the list ... >>> >>> > >>> >>> >>> >>> _______________________________________________ >>> Discuss-gnuradio mailing list >>> Discuss-gnuradio@gnu.org <mailto:Discuss-gnuradio@gnu.org> >>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio >>> <https://lists.gnu.org/mailman/listinfo/discuss-gnuradio> >> >> >> _______________________________________________ >> Discuss-gnuradio mailing list >> Discuss-gnuradio@gnu.org <mailto:Discuss-gnuradio@gnu.org> >> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio >> <https://lists.gnu.org/mailman/listinfo/discuss-gnuradio> > > _______________________________________________ > Discuss-gnuradio mailing list > Discuss-gnuradio@gnu.org > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
_______________________________________________ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio