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

Reply via email to