Re: [Discuss-gnuradio] GRC running on Mac OS X 10.6.4 using GTK+ Quartz 32bit Carbon backend
Hi Alex, On Sep 21, 2010, at 3:26 AM, Alexandru Csete wrote: Since the menubar is still in the application window, I'm wondering if it uses http://gtk-osx.sourceforge.net/ ? Yes, I used GTK+ with the quartz backend from the sources available at that site. I tried building using the jhbuild script and the build process that they suggested but that resulted in a couple of failures for some packages, probably because it was blindly compiling for x86_64, when there were 32-bit Carbon dependencies in the packages. So, I ran the jhbuild anyway, looked at the build log, noted down the build order, and manually compiled all the required files and patched the GTK+ sources for Mac OS X 10.6.4. After that, GNU Radio's configure was able to pick up the GTK+ installation. Here is the procedure for replicating this for the GTK+ part and using Quartz backend. I didn't use libpng,libjpeg and libtiff for this build. I also ignored the doc generation utilities. I did some basic dial tone tests, using GRC and it worked fine. I still have to test out the main GNU Radio stuff with the UHD driver. Step 45.00: Install GTK+, which is required for GRC. GTK+ additionally requires the following libraries: libpng gtk-osx-docbook gnome-doc-utils gtk-doc libjpeg libtiff expat perl-xml-parser perl-xml-simple hicolor-icon-theme gnome-common intltool glib pixman freetype fontconfig cairo pango atk gtk+ Step 45.01: Install expat-2.0.1. $ cd expat-2.0.1 $ ./configure CC='/usr/bin/gcc-4.0' CPP='/usr/bin/cpp-4.0' CXX='/usr/bin/g++-4.0' CXXCPP='/usr/bin/cpp-4.0' CFLAGS='-arch i386 -arch x86_64' CPPFLAGS='-arch i386 -arch x86_64' CXXFLAGS='-arch i386 -arch x86_64' LDFLAGS='-arch i386 -arch x86_64' --disable-dependency-tracking $ make -j 6 $ sudo make install Check the file architecture. $ file /usr/local/lib/libexpat.dylib /usr/local/lib/libexpat.dylib: Mach-O universal binary with 2 architectures /usr/local/lib/libexpat.dylib (for architecture i386): Mach-O dynamically linked shared library i386 /usr/local/lib/libexpat.dylib (for architecture x86_64): Mach-O 64-bit dynamically linked shared library x86_64 Step 45.02: Install hicolor-icon-theme-0.11. $ cd hicolor-icon-theme-0.11 $ ./configure $ make $ sudo make install Step 45.03: Install glib-2.24.1. (32-bit only, need to create a universal binary later on). GLib is the low-level core library that forms the basis for projects such as GTK+ and GNOME. It provides data structure handling for C, portability wrappers, and interfaces for such runtime functionality as an event loop, threads, dynamic loading, and an object system. $ cd glib-2.24.1 $ ./configure CC='/usr/bin/gcc-4.0' CPP='/usr/bin/cpp-4.0' CXX='/usr/bin/g++-4.0' CXXCPP='/usr/bin/cpp-4.0' CFLAGS='-arch i386' CPPFLAGS='-arch i386' CXXFLAGS='-arch i386' LDFLAGS='-arch i386' $ make -j 6 $ sudo make install Check the file architecture. $ file /usr/local/lib/libglib-2.0.dylib /usr/local/lib/libglib-2.0.dylib: Mach-O dynamically linked shared library i386 Step 45.04: Install pixman-0.16.0. Pixman is a library that provides low-level pixel manipulation features such as image compositing and trapezoid rasterization. $ cd pixman-0.16.0 $ ./configure CC='/usr/bin/gcc-4.0' CPP='/usr/bin/cpp-4.0' CXX='/usr/bin/g++-4.0' CXXCPP='/usr/bin/cpp-4.0' CFLAGS='-arch i386 -arch x86_64' CPPFLAGS='-arch i386 -arch x86_64' CXXFLAGS='-arch i386 -arch x86_64' LDFLAGS='-arch i386 -arch x86_64' --disable-dependency-tracking $ make -j 6 $ sudo make install Check the file architecture. $ file /usr/local/lib/libpixman-1.dylib /usr/local/lib/libpixman-1.dylib: Mach-O universal binary with 2 architectures /usr/local/lib/libpixman-1.dylib (for architecture i386): Mach-O dynamically linked shared library i386 /usr/local/lib/libpixman-1.dylib (for architecture x86_64): Mach-O 64-bit dynamically linked shared library x86_64 Step 45.05: Install freetype-2.3.11. $ cd freetype-2.3.11 $ ./configure CC='/usr/bin/gcc-4.0' CPP='/usr/bin/cpp-4.0' CFLAGS='-arch i386 -arch x86_64' CPPFLAGS='-arch i386 -arch x86_64' LDFLAGS='-arch i386 -arch x86_64' --disable-dependency-tracking $ make -j 6 $ sudo make install Check the file architecture. $ file /usr/local/lib/libfreetype.dylib /usr/local/lib/libfreetype.dylib: Mach-O universal binary with 2 architectures /usr/local/lib/libfreetype.dylib (for architecture i386): Mach-O dynamically linked shared library i386 /usr/local/lib/libfreetype.dylib (for architecture x86_64): Mach-O 64-bit dynamically linked shared library x86_64 Step 45.06: Install fontconfig-2.7.3. $ cd fontconfig-2.7.3 $ ./configure CC='/usr/bin/gcc-4.0' CPP='/usr/bin/cpp-4.0' CFLAGS='-arch i386 -arch x86_64' CPPFLAGS='-arch i386 -arch x86_64' LDFLAGS='-arch i386 -arch x86_64' --disable-dependency-tracking $ make -j 6 $ sudo make install Check the file architecture. $ file /usr/local/lib/libfontconfig.dylib /usr/local/lib/libfontconfig.dylib: Mach-O universal binary with 2
[Discuss-gnuradio] Is WUBI (Lucid) a viable environment for GNU-Radio (3.2.2) ?
I recently purchased a USRP and have a fresh install of WUBI (HP Pavillion DV5 , Windows Home Vista) and used gnuradio.org/redmine/wiki/gnuradio/UbuntuInstall to install things. I passed 'make check' correctly I have my username in the group usrp j...@ubuntu:~/gnuradio$ ls -lR /dev/bus/usb | grep usrp crw-rw 1 root usrp 189, 132 2010-09-21 11:14 005 when I execute ./usrp_benchmark_usb.py I get: Testing 2MB/sec... gr_vmcircbuf_createfilemapping: createfilemapping is not available /home/john/.gnuradio/prefs/gr_vmcircbuf_default_factory: Permission denied uUuOuUuOuUuOuUuOuUuOuUuOuUuOuUuOuUuOuUuOuUuOuOuUuOuUuOuUuOuUuOuUuOuUuOuU^Z and it hangs so I kill it [1]+ Stopped ./usrp_benchmark_usb.py I cannot repeat this operation as I get Testing 2MB/sec... usrp_open_interface:usb_set_alt_interface: failed could not set alt intf 0/0: Connection timed out open_nth_cmd_interface: open_cmd_interface failed usrp: failed to load firmware /usr/share/usrp/rev4/std.ihx. Traceback (most recent call last): File ./usrp_benchmark_usb.py, line 106, in module main () snip. unless I move the USRP to a new USB port in which case I get the first symptom again I have seen similar posts elsewhere re: issues with USB ports, Python and VirtualBox so my question is has anyone been able to run GNURADIO on WUBI? Kind Regards, Slainte, John ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Setting buffer size when using UHD
I read the page you refer to but I don't understand. Is this correct ? uhd::device_addr_t dev_addr; dev_addr[addr] = 192.168.10.11 192.168.20.11; dev_addr[addr] = 192.168.10.11 192.168.20.11; dev_addr[recv_buff_size] = 1e4; d_mdev=uhd::usrp::mimo_usrp::make(dev_addr); If this is linux, I recommend setting sysctl and letting UHD automatically pick the size. sudo sysctl -w net.core.rmem_max=5000 Yes. But then I need to do change this value when depending on which application I about to run or ... ? BR/ Per On Mon, 2010-09-20 at 08:07 -0700, Josh Blum wrote: The buffer size setting is used across all motherboards in the mimo setup. So, if specified, its only specified once: http://www.ettus.com/uhd_docs/manual/html/usrp2.html#resize-the-send-and-receive-buffers If this is linux, I recommend setting sysctl and letting UHD automatically pick the size. sudo sysctl -w net.core.rmem_max=5000 -Josh On 09/20/2010 03:36 AM, Per Zetterberg wrote: Hi All, How do I set the buffer size when using uhd::usrp::mimo_usrp ? BR/ Per ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] UHD and General purpose pins
Hi All, Is there any support for setting general purpose pins in UHD ? Or even better, to be able to set them on every sample transmitted to the USRP (for precise antenna selection). BR/ Per ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Patch to fix crash on Mac OS X, when calling MemoryDC.GetMultiLineTextExtent with no associated bitmap
Hi, Here is a patch to fix an issue with gr-wxgui running on Mac OS X, where calls to MemoryDC.GetMultiLineTextExtent fails if there is no bitmap associated with the MemoryDC, prior to calls to GetMultiLineTextExtent. The workaround is to create a 1x1 bitmap, get the text extent, and then delete the old bitmap and create a new bitmap with the newly computed text extent. It doesn't seem like a good solution from a performance stand-point, but the wxWidgets guys say that its the only way to do this. It doesn't crash on Linux, but on Mac OS X. Here is the link to the issue tracker: http://trac.wxwidgets.org/ticket/12486 diff --git a/gr-wxgui/src/python/plotter/gltext.py b/gr-wxgui/src/python/plotter/gltext.py index 1b3c047..65d6da0 100644 --- a/gr-wxgui/src/python/plotter/gltext.py +++ b/gr-wxgui/src/python/plotter/gltext.py @@ -146,8 +146,12 @@ class TextElement(object): DRAWBACK of the whole conversion thing is a really long time for creating the texture. If you see any optimizations that could save time PLEASE CREATE A PATCH!!! -# get a memory dc -dc = wx.MemoryDC() +# get a memory dc +# Remark: We need to ensure that a bitmap is associated with the MemoryDC before + # making calls to GetMultiLineTextExtent or GetTextExtent. +dc = wx.MemoryDC() + bmp = wx.EmptyBitmap(1,1) + dc.SelectObject(bmp) # set our font dc.SetFont(self._font) @@ -157,11 +161,18 @@ class TextElement(object): # sucker gains compared to sizes not of the power of 2. It's like # 500ms -- 0.5ms (on my ATI-GPU powered Notebook). On Sams nvidia # machine there don't seem to occur any losses...bad drivers? -ow, oh = dc.GetMultiLineTextExtent(self._text)[:2] +ow, oh = dc.GetMultiLineTextExtent(self._text)[:2] + + # Delete the temporary 1x1 bitmap. + del bmp + + # Compute the width and height of the display text w, h = self._getUpper2Base(ow), self._getUpper2Base(oh) self._text_size = wx.Size(ow,oh) -self._texture_size = wx.Size(w,h) +self._texture_size = wx.Size(w,h) + + # Create a new bitmap with the computed width and height of the display text. bmp = wx.EmptyBitmap(w,h) Best regards, Elvis ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Problem with installation - grc does not start
Hi, I've installed gnuradio following this guide: http://www.mail-archive.com/discuss-gnuradio@gnu.org/msg26238.html While installing everything was fine and I had no error messages. After the installation I tried to start grc and got the error messages posted below. In http://www.ruby-forum.com/topic/190977 the following work-around was descried: Johnathan Corgan wrote: It looks like we're having some sort of problem with the GNU Radio prefs system. We've at least established that you can get this working by copying the /etc/gnuradio/conf.d/grc.conf contents into your local ~/.gnuradio/config.conf: $ touch ~/.gnuradio/config.conf $ cat /etc/gnuradio/conf.d/grc.conf ~/.gnuradio/config.conf Johnathan Unfortunately this doesn't work because I have no /etc/gnuradio/ . Is this folder normally created automatically when you install gnuradio? Can anybody help me? OS: Kubuntu 10.04 gnuradio from git, branch next. Thanks, Thorsten Error messages: gnura...@nb-gnuradio:~/gnuradio-uhd/gnuradio$ grc Welcome to GNU Radio Companion 3.2.2 Error: 'options' Failue Traceback (most recent call last): File /usr/lib/python2.6/dist-packages/gnuradio/grc/gui/MainWindow.py, line 174, in new_page flow_graph = self._platform.get_new_flow_graph() File /usr/lib/python2.6/dist-packages/gnuradio/grc/base/Platform.py, line 149, in get_new_flow_graph def get_new_flow_graph(self): return self.FlowGraph(self) File string, line 4, in __init__ File /usr/lib/python2.6/dist-packages/gnuradio/grc/base/FlowGraph.py, line 37, in __init__ self.import_data() File /usr/lib/python2.6/dist-packages/gnuradio/grc/base/FlowGraph.py, line 192, in import_data self._options_block = self.get_parent().get_new_block(self, 'options') File /usr/lib/python2.6/dist-packages/gnuradio/grc/base/Platform.py, line 159, in get_new_block def get_new_block(self, flow_graph, key): return self.Block(flow_graph, n=self._blocks_n[key]) File /usr/lib/python2.6/dist-packages/gnuradio/grc/base/odict.py, line 34, in __getitem__ return self._data[key] KeyError: 'options' Error: 'options' Failue Traceback (most recent call last): File /usr/lib/python2.6/dist-packages/gnuradio/grc/gui/MainWindow.py, line 174, in new_page flow_graph = self._platform.get_new_flow_graph() File /usr/lib/python2.6/dist-packages/gnuradio/grc/base/Platform.py, line 149, in get_new_flow_graph def get_new_flow_graph(self): return self.FlowGraph(self) File string, line 4, in __init__ File /usr/lib/python2.6/dist-packages/gnuradio/grc/base/FlowGraph.py, line 37, in __init__ self.import_data() File /usr/lib/python2.6/dist-packages/gnuradio/grc/base/FlowGraph.py, line 192, in import_data self._options_block = self.get_parent().get_new_block(self, 'options') File /usr/lib/python2.6/dist-packages/gnuradio/grc/base/Platform.py, line 159, in get_new_block def get_new_block(self, flow_graph, key): return self.Block(flow_graph, n=self._blocks_n[key]) File /usr/lib/python2.6/dist-packages/gnuradio/grc/base/odict.py, line 34, in __getitem__ return self._data[key] KeyError: 'options' Traceback (most recent call last): File /usr/bin/grc, line 53, in module ActionHandler(args, Platform()) File /usr/lib/python2.6/dist-packages/gnuradio/grc/gui/ActionHandler.py, line 70, in __init__ self.handle_states(Actions.APPLICATION_INITIALIZE) File /usr/lib/python2.6/dist-packages/gnuradio/grc/gui/ActionHandler.py, line 332, in handle_states Actions.get_action_from_name(Actions.ELEMENT_DELETE).set_sensitive(bool(self.get_flow_graph().get_selected_elements())) File /usr/lib/python2.6/dist-packages/gnuradio/grc/gui/MainWindow.py, line 281, in get_flow_graph return self.get_page().get_flow_graph() AttributeError: 'NoneType' object has no attribute 'get_flow_graph' ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] General question concerning usrp audio
On Tue, Sep 21, 2010 at 5:09 AM, Thomas Seidel tomseid...@web.de wrote: hHey! I am just playing around with gnuradio and the usrp stuff and want to achieve the following: file1.py [...] self.u = usrp.sink_c(0, 64) self.src gr.sig_source_c(48000, gr.GR_SIN_WAVE, 400, 1) self.connect(self.src, self.u) [...] file2.py [...] self.u = usrp.source_c(0, self.decim_rate) self.sndsink = audio.sink(48000, 'plughw:0,0') self.blk = gr.complex_to_mag() self.connect(self.u, self.blk, (self.sndsink, 0)) [...] in words: file1.py should serve as the sender of sine signal with a frequency of 400Hz and file2.py should receive this signal and emit it on the soundcard. Both excerpts are implemented as a derived class from gr.top_block(). Running usrp_oscope.py, I can see that a sine is transmitted, however i can not here anything than noise(?). Actually I would have expected something like the output of dial_tone.py. Can somebody tell me why I am wrong and don't receive what i expect. One of the problems is that you connect the USRP to the audio sink without any downsampling. Even with max decimation, 256, the USRP will generate 250 ksps while your audio sink expects only 48 ksps. If you look at the receiver examples you'll see that all of them use a channel filter (usually low pass) which also does some downsampling. By the way, using a channel filter in a receiver is generally a good idea ;-) Other problems could be receiver settings (gain, frequency, antenna selection, etc.). Alex ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Regarding the UCLA Zigbee library
Hello all However i made my self successful in installing UCLA Zigbee library but now i am unable to execute the examples available in ucla_zigbee_phy/scr/examples The error which prompted is Traceback (most recent call last): Flile file name, line 47, in module from gnu radio import ucla ImportError: No module named ucla Please do help me with this thanks ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] GNU Radio and usrp_standard.h: No such file or directory
Dear All, I'd like to add a little piece of information about this problem. if I try to compile the previously mentioned code with: g++ usrp_test_c++.cpp -o testusrp `pkg-config --cflags usrp` `pkg-config --libs usrp` and I change: #include usrp_standard.h in: #include usrp/usrp_standard.h #include stdio.h the code from here: http://gnuradio.org/redmine/wiki/1/UsrpFAQCppInterface almost compile... The solution to this problem does however implies lots of modifications for the gcc line. Perhaps somebody who knows how the pkg-config works could comment on it. Also the source file that I am using is right in the gnuradio.org site, put there as first example for people who begin using the gnu radio package in C++. How come the stdio.h is not declared? also line: urx-read(bufr0, bufsize, overrun); seems to be wrong... Perhaps a better C++ example should be put there? Just my very humble opinion/suggestion. Best regards Fabrizio On Mon, Sep 20, 2010 at 9:27 AM, Fabrizio Tappero fabrizio.tapp...@gmail.com wrote: Dear Eric, thank you for your help. Yes I have done make install and defined the various path using a source .gnuradiorc inside by .bashrc and in fact: ~$ more .gnuradiorc export PATH=$PATH:/media/lin_sw/gnuradio/current/bin export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:/media/lin_sw/gnuradio/current/lib export PKG_CONFIG_PATH=$PKG_CONFIG_PATH:/media/lin_sw/gnuradio/current/lib/pkgconfig export PYTHONPATH=$PYTHONPATH:/media/lin_sw/gnuradio/current/lib/python2.6/site-packages if I check the PKG_CONFIG_PATH as you suggest, this is what I get: ~$ echo $PKG_CONFIG_PATH :/media/lin_sw/gnuradio/current/lib/pkgconfig ~$ pkg-config --cflags usrp -I/media/lin_sw/gnuradio/3.3.0/include ~$ pkg-config --libs usrp -L/media/lin_sw/gnuradio/3.3.0/lib -lusrp -lusb Everything seems correct to me but probably something is not. If you have any more ideas please let me know. Best Regards, Fabrizio PS just to clarify, I am on a 32bit linux ubuntu machine with gnuradio installed in /media/lin_sw/gnuradio/3.3.0 and with a symbolic link /media/lin_sw/gnuradio/current point at the 3.3.0 folder. On Fri, Sep 17, 2010 at 10:24 PM, Eric Blossom e...@comsec.com wrote: On Fri, Sep 17, 2010 at 05:02:00PM +0200, Fabrizio Tappero wrote: hello, I am trying to compile this C++ file: http://gnuradio.org/redmine/wiki/1/UsrpFAQCppInterface by doing: g++ usrp_test_c++.cpp -o testusrp -lusrp and I get the following error: test_usrp_standard_rx.cc:28:39: error: usrp_standard.h: No such file or directory I am on a ubuntu 10.4 (32bit) system with gnuradio 3.3.0 properly (I guess) installer (from git) in /media/lin_sw/gnuradio/current from env I see that: LD_LIBRARY_PATH=/usr/lib/:/media/lin_sw/gnuradio/current/lib I do not seem to figure out what I am missing, can anybody please help. thanks a lot fabrizio PS current is actually a symbolic link to the folder 3.3.0 in the same location as suggested in here: http://wiki.frednet.org/index.php/GNU_Radio_Installation_Guide Assuming you've done a make install, pkg-config will tell you the cflags and libs you need to use. You'll need to have your PKG_CONFIG_PATH set correctly for this to work. If you installed into the default prefix (/usr/local), the you'll need either: $ export PKG_CONFIG_PATH=/usr/local/lib64/pkgconfig or $ export PKG_CONFIG_PATH=/usr/local/lib/pkgconfig Depending on whether you're on a 64-bit machine and/or what OS and distribution you're using On my x86_64 machine running Fedora 13: $ echo $PKG_CONFIG_PATH /usr/local/lib64/pkgconfig $ pkg-config --cflags usrp -I/usr/local/include $ pkg-config --libs usrp -L/usr/local/lib64 -lusrp -lusb Eric ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Problem with installation - grc does not start
The default behavior is to install the blocks to prefix/share/gnuradio/grc/blocks/ GRC knows to look in that path, so you must have done something strange to your gnuradio installation. If you know where you installed the xml block files. You can set the path in the following two ways (copied from the wiki): Method 2: Configuration File Create or edit ~/.gnuradio/config.conf and add the following lines: [grc] local_blocks_path=/path/to/my/blocks The local_blocks_path can contain multiple paths separated by colons: local_blocks_path=/path/to/blocks1:/path/to/blocks2 Method 3: Environment Variable Set the GRC_BLOCKS_PATH environment variable to a path that contains your custom block wrapper. The GRC_BLOCKS_PATH can contain multiple paths separated by colons: GRC_BLOCKS_PATH=/path/to/blocks1:/path/to/blocks2 -josh On 09/21/2010 03:19 AM, Thorsten Laude wrote: Hi, I've installed gnuradio following this guide: http://www.mail-archive.com/discuss-gnuradio@gnu.org/msg26238.html While installing everything was fine and I had no error messages. After the installation I tried to start grc and got the error messages posted below. The default dehvior In http://www.ruby-forum.com/topic/190977 the following work-around was descried: Johnathan Corgan wrote: It looks like we're having some sort of problem with the GNU Radio prefs system. We've at least established that you can get this working by copying the /etc/gnuradio/conf.d/grc.conf contents into your local ~/.gnuradio/config.conf: $ touch ~/.gnuradio/config.conf $ cat /etc/gnuradio/conf.d/grc.conf ~/.gnuradio/config.conf Johnathan Unfortunately this doesn't work because I have no /etc/gnuradio/ . Is this folder normally created automatically when you install gnuradio? Can anybody help me? OS: Kubuntu 10.04 gnuradio from git, branch next. Thanks, Thorsten Error messages: gnura...@nb-gnuradio:~/gnuradio-uhd/gnuradio$ grc Welcome to GNU Radio Companion 3.2.2 Error: 'options' Failue Traceback (most recent call last): File /usr/lib/python2.6/dist-packages/gnuradio/grc/gui/MainWindow.py, line 174, in new_page flow_graph = self._platform.get_new_flow_graph() File /usr/lib/python2.6/dist-packages/gnuradio/grc/base/Platform.py, line 149, in get_new_flow_graph def get_new_flow_graph(self): return self.FlowGraph(self) File string, line 4, in __init__ File /usr/lib/python2.6/dist-packages/gnuradio/grc/base/FlowGraph.py, line 37, in __init__ self.import_data() File /usr/lib/python2.6/dist-packages/gnuradio/grc/base/FlowGraph.py, line 192, in import_data self._options_block = self.get_parent().get_new_block(self, 'options') File /usr/lib/python2.6/dist-packages/gnuradio/grc/base/Platform.py, line 159, in get_new_block def get_new_block(self, flow_graph, key): return self.Block(flow_graph, n=self._blocks_n[key]) File /usr/lib/python2.6/dist-packages/gnuradio/grc/base/odict.py, line 34, in __getitem__ return self._data[key] KeyError: 'options' Error: 'options' Failue Traceback (most recent call last): File /usr/lib/python2.6/dist-packages/gnuradio/grc/gui/MainWindow.py, line 174, in new_page flow_graph = self._platform.get_new_flow_graph() File /usr/lib/python2.6/dist-packages/gnuradio/grc/base/Platform.py, line 149, in get_new_flow_graph def get_new_flow_graph(self): return self.FlowGraph(self) File string, line 4, in __init__ File /usr/lib/python2.6/dist-packages/gnuradio/grc/base/FlowGraph.py, line 37, in __init__ self.import_data() File /usr/lib/python2.6/dist-packages/gnuradio/grc/base/FlowGraph.py, line 192, in import_data self._options_block = self.get_parent().get_new_block(self, 'options') File /usr/lib/python2.6/dist-packages/gnuradio/grc/base/Platform.py, line 159, in get_new_block def get_new_block(self, flow_graph, key): return self.Block(flow_graph, n=self._blocks_n[key]) File /usr/lib/python2.6/dist-packages/gnuradio/grc/base/odict.py, line 34, in __getitem__ return self._data[key] KeyError: 'options' Traceback (most recent call last): File /usr/bin/grc, line 53, inmodule ActionHandler(args, Platform()) File /usr/lib/python2.6/dist-packages/gnuradio/grc/gui/ActionHandler.py, line 70, in __init__ self.handle_states(Actions.APPLICATION_INITIALIZE) File /usr/lib/python2.6/dist-packages/gnuradio/grc/gui/ActionHandler.py, line 332, in handle_states Actions.get_action_from_name(Actions.ELEMENT_DELETE).set_sensitive(bool(self.get_flow_graph().get_selected_elements())) File /usr/lib/python2.6/dist-packages/gnuradio/grc/gui/MainWindow.py, line 281, in get_flow_graph return self.get_page().get_flow_graph() AttributeError: 'NoneType' object has no attribute 'get_flow_graph' ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Is WUBI (Lucid) a viable environment for GNU-Radio (3.2.2) ?
On Tue, Sep 21, 2010 at 08:24:53PM +1200, John Shields wrote: I recently purchased a USRP and have a fresh install of WUBI (HP Pavillion DV5 , Windows Home Vista) and used gnuradio.org/redmine/wiki/gnuradio/UbuntuInstall to install things. I passed 'make check' correctly I have my username in the group usrp j...@ubuntu:~/gnuradio$ ls -lR /dev/bus/usb | grep usrp crw-rw 1 root usrp 189, 132 2010-09-21 11:14 005 when I execute ./usrp_benchmark_usb.py I get: Testing 2MB/sec... gr_vmcircbuf_createfilemapping: createfilemapping is not available /home/john/.gnuradio/prefs/gr_vmcircbuf_default_factory: Permission denied uUuOuUuOuUuOuUuOuUuOuUuOuUuOuUuOuUuOuUuOuUuOuOuUuOuUuOuUuOuUuOuUuOuUuOuU^Z and it hangs so I kill it [1]+ Stopped ./usrp_benchmark_usb.py I cannot repeat this operation as I get Testing 2MB/sec... usrp_open_interface:usb_set_alt_interface: failed could not set alt intf 0/0: Connection timed out open_nth_cmd_interface: open_cmd_interface failed usrp: failed to load firmware /usr/share/usrp/rev4/std.ihx. Traceback (most recent call last): File ./usrp_benchmark_usb.py, line 106, in module main () snip. Just to rule out a flakey cable, can you try using a different USB 2 cable? Eric ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Setting buffer size when using UHD
On 09/21/2010 01:30 AM, Per Zetterberg wrote: I read the page you refer to but I don't understand. Is this correct ? uhd::device_addr_t dev_addr; dev_addr[addr] = 192.168.10.11 192.168.20.11; dev_addr[addr] = 192.168.10.11 192.168.20.11; dev_addr[recv_buff_size] = 1e4; d_mdev=uhd::usrp::mimo_usrp::make(dev_addr); That should work, however, that is a very small buffer. Expect overflow. If this is linux, I recommend setting sysctl and letting UHD automatically pick the size. sudo sysctl -w net.core.rmem_max=5000 Yes. But then I need to do change this value when depending on which application I about to run or ... ? 50MB is half a second of buffering at full rate. The default behavior of the UHD is to resize recv buffers to 50 MB. I think that is sufficient for most applications. -Josh ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] USRP2 FM TX and FM RX working together
Hello community! I initiated myself in GNU radio two weeks ago and I am learning as fast as I can. To begin with, I decided to play with GRC and my URSP2. I successfully built a FM modulator that works fine. I successfully built a FM demodulator that works fine. But there are still several things I do not understand. While building the FM modulator: 1)Wave file source 2)Rational resampler 3)LPF 4)Rational resampler 5)Frequency Mod 6)Multiply const 7)USRP2 sink Why is block 6 necessary? I tried with lots of values over 2 and all of them are ok. I realized that the smaller the number, the higher the noise in my receiver (my mobile phone). Is it related to the amplitude of the modulated signal? Another thing very strange is that if I create a GRC file with both, transmitter and receiver with exactly the same blocks and the same parameters I cannot hear any demodulated signal. I can see information with a FFT block connected to the receiver chain, and I am able to demodulate the signal with my mobile phone when the example is running but in my computer I do not hear anything else besides noise mixed with some sort of non-understandable signal. Thus, I guess I have to change something in the receiver chain although it works alone in my FM demodulator. I changed every single parameter but I cannot get any improvement. Any suggestions? Many thanks in advance, Jorge. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] UHD and General purpose pins
On 09/21/2010 01:33 AM, Per Zetterberg wrote: Hi All, Is there any support for setting general purpose pins in UHD ? Or even You can get access to the daughter board interface class which can control all of the daughter board peripherals: http://www.ettus.com/uhd_docs/doxygen/html/classuhd_1_1usrp_1_1simple__usrp.html#a05f24e338d576b889714667864bac193 http://www.ettus.com/uhd_docs/doxygen/html/classuhd_1_1usrp_1_1dboard__iface.html better, to be able to set them on every sample transmitted to the USRP (for precise antenna selection). There is no hardware support to change the GPIO's per sample. However, you can manipulate the ATR registers which are hardware controlled to change the GPIO state when the device transitions from from recv-only, send-only, full-duplex, idle. See RFX or WBX daughterboard code in lib/usrp/dboard/*db_*.cpp for an example. -Josh BR/ Per ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] UHD transmit issues solved
Recently, I've started two threads involving problems using UHD. http://www.ruby-forum.com/topic/217106 http://www.ruby-forum.com/topic/216320 It turns out they were both on the transmit side and I stumbled onto a solution for both: way smaller send_buff_size. Like 50,000 bytes instead of 500,000,000 bytes. The behavior with large buffers is strange. I altered my flowgraph to write one second's worth of data to a file instead of displaying on a scope sink and looked at it MATLAB. It turns out the transmit dropouts didn't happen at all until after about 20ms and then they were frequent. Suspecting something buffer-related, I started experimenting to see if the length of the period w/o dropouts was related to the buffer size. Strangely, the glitch-free time didn't seem to be affected much by cutting the size in 1/2 or 1/10, but if the buffer is small enough, the problem goes away entirely. Also, when the buffer is large, my simple flowgraph pegs one of the CPUs, but when small, all the CPUs fluctuate nicely below 50%. I suspect some sort of scheduling priority issue combined with contention for a lock. It turns out that I'm not the first to suspect this. I went looking for the default send buffer size and found this in udp_zero_copy_asio.cpp: //Large buffers cause more underflow at high rates. //Perhaps this is due to the kernel scheduling, //but may change with host-based flow control. static const size_t MIN_SEND_SOCK_BUFF_SIZE = size_t(10e3); I think the advice Josh gave for the receive buffer in another thread is good: Stick with the default buffer sizes. -Marc ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] USRP2 FM TX and FM RX working together
Hi Jorge, Can you copy the .grc file you created? Hello community! I initiated myself in GNU radio two weeks ago and I am learning as fast as I can. To begin with, I decided to play with GRC and my URSP2. I successfully built a FM modulator that works fine. I successfully built a FM demodulator that works fine. But there are still several things I do not understand. While building the FM modulator: 1)Wave file source 2)Rational resampler 3)LPF 4)Rational resampler 5)Frequency Mod 6)Multiply const 7)USRP2 sink Why is block 6 necessary? I tried with lots of values over 2 and all of them are ok. I realized that the smaller the number, the higher the noise in my receiver (my mobile phone). Is it related to the amplitude of the modulated signal? Another thing very strange is that if I create a GRC file with both, transmitter and receiver with exactly the same blocks and the same parameters I cannot hear any demodulated signal. I can see information with a FFT block connected to the receiver chain, and I am able to demodulate the signal with my mobile phone when the example is running but in my computer I do not hear anything else besides noise mixed with some sort of non-understandable signal. Thus, I guess I have to change something in the receiver chain although it works alone in my FM demodulator. I changed every single parameter but I cannot get any improvement. Any suggestions? Many thanks in advance, Jorge. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] GNU Radio and usrp_standard.h: No such file or directory
On Tue, Sep 21, 2010 at 10:20 AM, Fabrizio Tappero fabrizio.tapp...@gmail.com wrote: Dear All, I'd like to add a little piece of information about this problem. if I try to compile the previously mentioned code with: g++ usrp_test_c++.cpp -o testusrp `pkg-config --cflags usrp` `pkg-config --libs usrp` and I change: #include usrp_standard.h in: #include usrp/usrp_standard.h #include stdio.h the code from here: http://gnuradio.org/redmine/wiki/1/UsrpFAQCppInterface almost compile... As you discovered, there are a number of problems with the example code. I made some quick changes to the wiki page, which was quite dated. It should now compile with gnuradio 3.3 and recent Linux distributions. Thomas ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Is WUBI (Lucid) a viable environment for GNU-Radio (3.2.2) ?
Thanks Eric, will do though I used the sealed one given by Ettus but stranger things have happened. I had also wondered about whether the USB ports on my laptop were running fast enough and before I posted, have confirmed Enhanced in the Host Controller description. I wonder if U is underun and O is overrun? I briefly looked at the source but am not familiar with GNU_Radio and it's classes. Thanks again for your suggestion, Regards, John - Original Message - From: Eric Blossom e...@comsec.com To: John Shields john.shie...@xtra.co.nz Cc: discuss-gnuradio@gnu.org Sent: Wednesday, September 22, 2010 3:31 AM Subject: Re: [Discuss-gnuradio] Is WUBI (Lucid) a viable environment for GNU-Radio (3.2.2) ? On Tue, Sep 21, 2010 at 08:24:53PM +1200, John Shields wrote: I recently purchased a USRP and have a fresh install of WUBI (HP Pavillion DV5 , Windows Home Vista) and used gnuradio.org/redmine/wiki/gnuradio/UbuntuInstall to install things. I passed 'make check' correctly I have my username in the group usrp j...@ubuntu:~/gnuradio$ ls -lR /dev/bus/usb | grep usrp crw-rw 1 root usrp 189, 132 2010-09-21 11:14 005 when I execute ./usrp_benchmark_usb.py I get: Testing 2MB/sec... gr_vmcircbuf_createfilemapping: createfilemapping is not available /home/john/.gnuradio/prefs/gr_vmcircbuf_default_factory: Permission denied uUuOuUuOuUuOuUuOuUuOuUuOuUuOuUuOuUuOuUuOuUuOuOuUuOuUuOuUuOuUuOuUuOuUuOuU^Z and it hangs so I kill it [1]+ Stopped ./usrp_benchmark_usb.py I cannot repeat this operation as I get Testing 2MB/sec... usrp_open_interface:usb_set_alt_interface: failed could not set alt intf 0/0: Connection timed out open_nth_cmd_interface: open_cmd_interface failed usrp: failed to load firmware /usr/share/usrp/rev4/std.ihx. Traceback (most recent call last): File ./usrp_benchmark_usb.py, line 106, in module main () snip. Just to rule out a flakey cable, can you try using a different USB 2 cable? Eric ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] General question concerning usrp audio
Thanks a lot for your help! file2.py now looks like this: class soundcheck(gr.top_block): def __init__(self): gr.top_block.__init__(self) self.decim_rate = 256 self.u = usrp.source_c(0, self.decim_rate) self.rx_subdev_spec = usrp.pick_rx_subdevice(self.u) self.subdev = usrp.selected_subdev(self.u, self.rx_subdev_spec) self.input_rate = self.u.adc_freq() / self.decim_rate res = self.u.tune(0, self.subdev, 13.56e6) if res: print 'frequency successfully changed to 13.56Mhz' else: print 'tuning failed' sys.exit(1) interp = gru.lcm(self.input_rate, 48000) / self.input_rate decim = gru.lcm(self.input_rate, 48000) / 48000 interp = int(interp) decim = int(decim) print 'interp = %d, decim = %d' % (interp, decim) rr = blks2.rational_resampler_ccc(interp, decim) self.sndsink = audio.sink(48000, 'plughw:0,0') self.magblk = gr.complex_to_mag() self.connect(self.u, rr, self.magblk, (self.sndsink, 0)) As one can see I added the reational_resampler_ccc(), hoping that it does the magic work needed that I can hear a nice sine wave, but still there is only noise. On the transmitting side a gr.sig_source_c(48000, gr.GR_SIN_WAVE, 4000, 1000) is used with the interpolation of the USRP set to a factor of 32. Maybe I still lack of a proper understanding of the whole issue so that I would really appreciate your help. Tom -Ursprüngliche Nachricht- Von: Alexandru Csete oz9...@gmail.com Gesendet: Sep 21, 2010 12:32:17 PM An: discuss-gnuradio@gnu.org Betreff: Re: [Discuss-gnuradio] General question concerning usrp audio On Tue, Sep 21, 2010 at 5:09 AM, Thomas Seidel tomseid...@web.de wrote: hHey! I am just playing around with gnuradio and the usrp stuff and want to achieve the following: file1.py [...] self.u = usrp.sink_c(0, 64) self.src gr.sig_source_c(48000, gr.GR_SIN_WAVE, 400, 1) self.connect(self.src, self.u) [...] file2.py [...] self.u = usrp.source_c(0, self.decim_rate) self.sndsink = audio.sink(48000, 'plughw:0,0') self.blk = gr.complex_to_mag() self.connect(self.u, self.blk, (self.sndsink, 0)) [...] in words: file1.py should serve as the sender of sine signal with a frequency of 400Hz and file2.py should receive this signal and emit it on the soundcard. Both excerpts are implemented as a derived class from gr.top_block(). Running usrp_oscope.py, I can see that a sine is transmitted, however i can not here anything than noise(?). Actually I would have expected something like the output of dial_tone.py. Can somebody tell me why I am wrong and don't receive what i expect. One of the problems is that you connect the USRP to the audio sink without any downsampling. Even with max decimation, 256, the USRP will generate 250 ksps while your audio sink expects only 48 ksps. If you look at the receiver examples you'll see that all of them use a channel filter (usually low pass) which also does some downsampling. By the way, using a channel filter in a receiver is generally a good idea ;-) Other problems could be receiver settings (gain, frequency, antenna selection, etc.). Alex ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio ___ GRATIS: Spider-Man 1-3 sowie 300 weitere Videos! Jetzt kostenlose Movie-FLAT freischalten! http://movieflat.web.de ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] General question concerning usrp audio
Hi Tom, The magnitude of a complex sine wave is constant so you can not hear it. If you want to hear a tone you have to listen to either the real or the imaginary part, i.e. use complex_to_real or complex_to_float. You can easily test it by connecting a complex signal source to the audio sink via complex_to_mag (you wont hear anything) and complex_to_real/complex_to_imag (you will hear the tone). In terms of radio complex_to_mag corresponds to a simple AM demodulator but you don't have any AM modulator on the transmitter side. If you want to hear a tone with the AM receiver, you have to send a *real* sine wave through an AM modulator in the transmitter. Sending a complex tone to the USRP is pretty much the same as an unmodulated carrier. For the transmitter, you will have to use interpolation much higher than 32. The DAC rate is 128 Msps and the max interpolation you can use is 512 corresponding to 250 ksps (the same exercise as for the receiver but the other way around). Alex On Tue, Sep 21, 2010 at 11:36 PM, Thomas Seidel tomseid...@web.de wrote: Thanks a lot for your help! file2.py now looks like this: class soundcheck(gr.top_block): def __init__(self): gr.top_block.__init__(self) self.decim_rate = 256 self.u = usrp.source_c(0, self.decim_rate) self.rx_subdev_spec = usrp.pick_rx_subdevice(self.u) self.subdev = usrp.selected_subdev(self.u, self.rx_subdev_spec) self.input_rate = self.u.adc_freq() / self.decim_rate res = self.u.tune(0, self.subdev, 13.56e6) if res: print 'frequency successfully changed to 13.56Mhz' else: print 'tuning failed' sys.exit(1) interp = gru.lcm(self.input_rate, 48000) / self.input_rate decim = gru.lcm(self.input_rate, 48000) / 48000 interp = int(interp) decim = int(decim) print 'interp = %d, decim = %d' % (interp, decim) rr = blks2.rational_resampler_ccc(interp, decim) self.sndsink = audio.sink(48000, 'plughw:0,0') self.magblk = gr.complex_to_mag() self.connect(self.u, rr, self.magblk, (self.sndsink, 0)) As one can see I added the reational_resampler_ccc(), hoping that it does the magic work needed that I can hear a nice sine wave, but still there is only noise. On the transmitting side a gr.sig_source_c(48000, gr.GR_SIN_WAVE, 4000, 1000) is used with the interpolation of the USRP set to a factor of 32. Maybe I still lack of a proper understanding of the whole issue so that I would really appreciate your help. Tom -Ursprüngliche Nachricht- Von: Alexandru Csete oz9...@gmail.com Gesendet: Sep 21, 2010 12:32:17 PM An: discuss-gnuradio@gnu.org Betreff: Re: [Discuss-gnuradio] General question concerning usrp audio On Tue, Sep 21, 2010 at 5:09 AM, Thomas Seidel tomseid...@web.de wrote: hHey! I am just playing around with gnuradio and the usrp stuff and want to achieve the following: file1.py [...] self.u = usrp.sink_c(0, 64) self.src gr.sig_source_c(48000, gr.GR_SIN_WAVE, 400, 1) self.connect(self.src, self.u) [...] file2.py [...] self.u = usrp.source_c(0, self.decim_rate) self.sndsink = audio.sink(48000, 'plughw:0,0') self.blk = gr.complex_to_mag() self.connect(self.u, self.blk, (self.sndsink, 0)) [...] in words: file1.py should serve as the sender of sine signal with a frequency of 400Hz and file2.py should receive this signal and emit it on the soundcard. Both excerpts are implemented as a derived class from gr.top_block(). Running usrp_oscope.py, I can see that a sine is transmitted, however i can not here anything than noise(?). Actually I would have expected something like the output of dial_tone.py. Can somebody tell me why I am wrong and don't receive what i expect. One of the problems is that you connect the USRP to the audio sink without any downsampling. Even with max decimation, 256, the USRP will generate 250 ksps while your audio sink expects only 48 ksps. If you look at the receiver examples you'll see that all of them use a channel filter (usually low pass) which also does some downsampling. By the way, using a channel filter in a receiver is generally a good idea ;-) Other problems could be receiver settings (gain, frequency, antenna selection, etc.). Alex ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio ___ GRATIS: Spider-Man 1-3 sowie 300 weitere Videos! Jetzt kostenlose Movie-FLAT freischalten! http://movieflat.web.de ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
