Re: [Discuss-gnuradio] grc code generation issues with name confliction
On 10/09/2011, at 3:13 PM, Josh Blum wrote: > > If you wrote the xml files, you need to change them in such a way so > that they dont conflict. > > Ex: > from packa import modc as packa_modc > packa_modc.my_block() > > I bet there are many other ways to do this. Its just python :-) > > -josh > Great! I did not realize the codes generated are controlled by .xml file, in particular the tag. Thanks Josh Kyle ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] peak in fft of OFDM
when I ran benchmark_ofdm_tx.py I am getting a peak as shown in the attached figure. I used both usrp and usrp2 . with both RFX2400 and XCVR2450. http://old.nabble.com/file/p32438726/peak%2Bat%2Bofdm%2Bfrom%2Busrp.png http://old.nabble.com/file/p32438726/peak%2Bat%2Bofdm%2Bfrom%2Busrp2.png I took trace and hence I can see that there wasn't any peak there before the transmission. - Sumit Kr. Research Assistant Communication Research center IIIT Hyderabad India -- View this message in context: http://old.nabble.com/peak-in-fft-of-OFDM-tp32438726p32438726.html Sent from the GnuRadio mailing list archive at Nabble.com. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Confusion with uhd_fft.py with usrp2
Today I ran uhd_fft.py in two usrp and two usrp2.They were in the same room and placed at a distance of 2-3 meters from each other(approx) but there was much difference in the fft. Actually there was a peak at 2.432G . Both usrp detected well but there was some confusing display from usrp2 under uhd_fft.py. usrp2s also detected the peak but there was a significant rise on the left side in both the usrp2.I checked with RFX2400 and XCVR2450 both. Here is the fft for both usrp2 under uhd_fft.py http://old.nabble.com/file/p32438830/usrp2_1.png Also in the figure below its detecting two peaks. http://old.nabble.com/file/p32438830/usrp2_2.png Also sometimes it went like this http://old.nabble.com/file/p32438830/usrp2_2_1.png At the same time the display from usrp under usrp_fft.py was perfect. I am using RFX2400 as well as XCVR2450. Although there is some problem with the second usrp.Despite of elevating the gain and changing the positions the peak is not getting sharp and high. :) http://old.nabble.com/file/p32438830/usrp_1.png http://old.nabble.com/file/p32438830/usrp_1_2.png What may be the reason Placement of the usrp's or some hardware fault ? - Sumit Kr. Research Assistant Communication Research center IIIT Hyderabad India -- View this message in context: http://old.nabble.com/Confusion-with-uhd_fft.py-with-usrp2-tp32438830p32438830.html Sent from the GnuRadio mailing list archive at Nabble.com. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] RX and TX stuff
Hi All, I've been following closely the OFDM- and related TX/RX issues. If you TX sumthing, build/buy an (directive) antenna for your target frequency and point it at the RX usrp. I suggest a Yagi, helix or a parabola for TX:ing, cost ~$10 at your frequency. Apply to RX the same. Using a whip is trouble if you do not know An antenna sure can be *omni* to detect the signal, to demodulate it perfectly is another thing. Example: TX is a RHCP (right hand circular polarized) signal. RX it with a VP (vertical polarized) antenna, it wont demodulate properly. A user receiving 137 MHz RHCP satellite data posted *his ultimate antenna* image http://www.poes-weather.com/~patrik/tmp/RHCP-137.jpg It aint that complicated, trial and error does it. Regards, Patrik ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Problems regarding using UHD Digital-bert codes
Hi , I have been trying to use the examples given in /home/aravind/gnuradio/gnuradio-examples/python/digital-bert . esp the uhd_benchmark_tx.py . here are a few changes that i made to the existing code .. __- #setup usrp self._setup_usrp(options.ip, interp, options.gain, options.freq) self.connect(self._transmitter, self._usrp) def _setup_usrp(self, ip, interp, gain, freq): # Setup single usrp sink self._uhd = uhd.single_usrp_sink(device_addr="", io_type=uhd.io_type.COMPLEX_FLOAT32, num_channels=1 ) # Tune to center frequency tr = self._usrp.set_center_freq(freq,0) if not (tr): print "Failed to tune to center frequency!" else: print "Actual Intermediate frequency:", n2s(self._usrp.get_center_freq()) # Set Tx Gain self._uhd.set_gain(gain,1) print "Gain d'board: ",n2s(self._usrp.get_gain()), "dB" but i am getting error as mentioned : - Traceback (most recent call last): File "./uhd_benchmark_tx.py", line 113, in tb = tx_bpsk_block(options) File "./uhd_benchmark_tx.py", line 56, in __init__ options.freq) File "./uhd_benchmark_tx.py", line 70, in _setup_usrp tr = self._usrp.set_center_freq(freq,0) File "/usr/local/lib/python2.6/dist-packages/gnuradio/gr/top_block.py", line 94, in __getattr__ return getattr(self._tb, name) AttributeError: 'gr_top_block_sptr' object has no attribute '_usrp' aravind@COE-2X85V91:~/gnuradio/gnuradio-examples/python/uhd-digital-bert$ ___ i included an From gnuradio import uhd statement to top_block.py also . but i am still getting getting the same error . I waould like your guidance , because i have been trying to make this example work for weeks . Yours sincerely Bonee Soibam ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] cmake build
Just tested the cmake install on OS X 10.5.8, XCode 3.1.4, Homebrew for dependencies. Homebrew is not quite up to scratch for the dependencies since it's missing pyqwk and pygtk, and qt is there but the install script failed for me. Anyway there's enough working for gnuradio-core to install but not gnuradio-companion. The problem I'm running into appears to be caused by the installed version of python being 2.5. Cmake requests a version of 2.5 or later so it should be okay, however I get the following error. Serf:gnuradio-build ben$ make [ 0%] Generating ../include/volk/volk.h, volk.c, volk_init.h, ../include/volk/volk_typedefs.h, ../include/volk/volk_cpu.h, volk_cpu.c, ../include/volk/volk_config_fixed.h, volk_environment_init.c, volk_environment_init.h, volk_machines.h, volk_machines.c, volk_machine_generic.c, volk_machine_sse2_only.c, volk_machine_sse2_32.c, volk_machine_sse3_32.c, volk_machine_ssse3_32.c Unknown option: -B usage: /System/Library/Frameworks/Python.framework/Versions/2.5/Resources/Python.app/Contents/MacOS/Python [option] ... [-c cmd | -m mod | file | -] [arg] ... Try `python -h' for more information. make[2]: *** [volk/include/volk/volk.h] Error 2 make[1]: *** [volk/lib/CMakeFiles/volk.dir/all] Error 2 make: *** [all] Error 2 A google suggests that the -B option for python was added in 2.6. I'll install a newer version of python and see if I have more luck. Cheers, Ben On Thu, Aug 18, 2011 at 6:07 PM, Tom Rondeau wrote: > And another thing... > > We are looking at possibly moving from autotools to cmake. In many > ways, cmake looks like it will simply many of our build issues and > actually solve others. Josh Blum has been doing outstanding work in > converting the GNU Radio build system over to using cmake, and we > really need testers to chip away at any of the bugs. Specifically, we > have tested it on some modern OSes, but we want ot make sure that it > covers most (if not all) of our customer base (I'm sorry, but if it > come down to it, I'm willing to let the VAX users go...). > > Find the instructions to start working on it here: > http://gnuradio.org/redmine/projects/gnuradio/wiki/CMakeWork > > Please post both positive and negative experiences so that we know not > only what to fix, but it will also let us know what systems are > working. > > Thanks! > Tom > > ___ > 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
[Discuss-gnuradio] Fwd: Problems regarding using UHD Digital-bert codes
Attached here is a copy of my digital bert codes .. Sincerely Bonee soibam -- Forwarded message -- From: Bonee Soibam Date: Sat, Sep 10, 2011 at 5:16 PM Subject: Problems regarding using UHD Digital-bert codes To: discuss-gnuradio@gnu.org Hi , I have been trying to use the examples given in /home/aravind/gnuradio/gnuradio-examples/python/digital-bert . esp the uhd_benchmark_tx.py . here are a few changes that i made to the existing code .. __- #setup usrp self._setup_usrp(options.ip, interp, options.gain, options.freq) self.connect(self._transmitter, self._usrp) def _setup_usrp(self, ip, interp, gain, freq): # Setup single usrp sink self._uhd = uhd.single_usrp_sink(device_addr="", io_type=uhd.io_type.COMPLEX_FLOAT32, num_channels=1 ) # Tune to center frequency tr = self._usrp.set_center_freq(freq,0) if not (tr): print "Failed to tune to center frequency!" else: print "Actual Intermediate frequency:", n2s(self._usrp.get_center_freq()) # Set Tx Gain self._uhd.set_gain(gain,1) print "Gain d'board: ",n2s(self._usrp.get_gain()), "dB" but i am getting error as mentioned : - Traceback (most recent call last): File "./uhd_benchmark_tx.py", line 113, in tb = tx_bpsk_block(options) File "./uhd_benchmark_tx.py", line 56, in __init__ options.freq) File "./uhd_benchmark_tx.py", line 70, in _setup_usrp tr = self._usrp.set_center_freq(freq,0) File "/usr/local/lib/python2.6/dist-packages/gnuradio/gr/top_block.py", line 94, in __getattr__ return getattr(self._tb, name) AttributeError: 'gr_top_block_sptr' object has no attribute '_usrp' aravind@COE-2X85V91:~/gnuradio/gnuradio-examples/python/uhd-digital-bert$ ___ i included an From gnuradio import uhd statement to top_block.py also . but i am still getting getting the same error . I waould like your guidance , because i have been trying to make this example work for weeks . Yours sincerely Bonee Soibam #!/usr/bin/env python # # Copyright 2008 Free Software Foundation, Inc. # # This file is part of GNU Radio # # GNU Radio is free software; you can redistribute it and/or modify # it under the terms of the GNU General Public License as published by # the Free Software Foundation; either version 3, or (at your option) # any later version. # # GNU Radio is distributed in the hope that it will be useful, # but WITHOUT ANY WARRANTY; without even the implied warranty of # MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the # GNU General Public License for more details. # # You should have received a copy of the GNU General Public License # along with GNU Radio; see the file COPYING. If not, write to # the Free Software Foundation, Inc., 51 Franklin Street, # Boston, MA 02110-1301, USA. # from gnuradio import gr, eng_notation, uhd,usrp from gnuradio.eng_option import eng_option from optparse import OptionParser from transmit_path import transmit_path import sys import uhd_options _dac_rate = 128e6 n2s = eng_notation.num_to_str class tx_bpsk_block(gr.top_block): def __init__(self, options): gr.top_block.__init__(self, "tx_mpsk") self._transmitter = transmit_path(options.sps, options.excess_bw, options.amplitude) if_rate = options.rate*options.sps interp = int(_dac_rate/if_rate) print "Modulation:", n2s(options.rate), "bits/sec" print "TX IF rate:", n2s(if_rate), "samples/sec" print "USRP interpolation:", interp print "DAC amplitude:", options.amplitude #setup usrp self._setup_usrp(options.ip, interp, options.gain, options.freq) self.connect(self._transmitter, self._usrp) #COMPLEX_FLOAT32 def _setup_usrp(self, ip, interp, gain, freq): # Setup single usrp sink self._uhd = uhd.usrp_sink(device_addr="", io_type=uhd.io_type.COMPLEX_FLOAT32, num_channels=1 ) # Tune to center frequency tr = self._uhd.set_center_freq(freq) if not (tr): print "Failed to tune to center frequency!"
[Discuss-gnuradio] APCO 25 crack using GnuRadio
http://tech.slashdot.org/story/11/09/10/1539217/Security-Researchers-Crack-APCO-P25-Encryption ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] APCO 25 crack using GnuRadio
On 09/10/2011 06:48 PM, Robert McGwier wrote: http://tech.slashdot.org/story/11/09/10/1539217/Security-Researchers-Crack-APCO-P25-Encryption ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio Interesting. It was only a couple of weeks ago that Matt Blaze' group at Penn announced some of their results against P25. -- Marcus Leech Principal Investigator Shirleys Bay Radio Astronomy Consortium http://www.sbrac.org ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] cmake build
Hi Ben - I believe that Volk (in general, not just the Python version) doesn't play nicely with OSX (any version) yet. Use --disable-volk on the configure command line to disable it, and everything else should work. - MLD On Sep 10, 2011, at 5:24 PM, Ben Reynwar wrote: > Just tested the cmake install on OS X 10.5.8, XCode 3.1.4, Homebrew > for dependencies. Homebrew is not quite up to scratch for the > dependencies since it's missing pyqwk and pygtk, and qt is there but > the install script failed for me. Anyway there's enough working for > gnuradio-core to install but not gnuradio-companion. > > The problem I'm running into appears to be caused by the installed > version of python being 2.5. Cmake requests a version of 2.5 or later > so it should be okay, however I get the following error. > > Serf:gnuradio-build ben$ make > [ 0%] Generating ../include/volk/volk.h, volk.c, volk_init.h, > ../include/volk/volk_typedefs.h, ../include/volk/volk_cpu.h, > volk_cpu.c, ../include/volk/volk_config_fixed.h, > volk_environment_init.c, volk_environment_init.h, volk_machines.h, > volk_machines.c, volk_machine_generic.c, volk_machine_sse2_only.c, > volk_machine_sse2_32.c, volk_machine_sse3_32.c, > volk_machine_ssse3_32.c > Unknown option: -B > usage: > /System/Library/Frameworks/Python.framework/Versions/2.5/Resources/Python.app/Contents/MacOS/Python > [option] ... [-c cmd | -m mod | file | -] [arg] ... > Try `python -h' for more information. > make[2]: *** [volk/include/volk/volk.h] Error 2 > make[1]: *** [volk/lib/CMakeFiles/volk.dir/all] Error 2 > make: *** [all] Error 2 > > A google suggests that the -B option for python was added in 2.6. > I'll install a newer version of python and see if I have more luck. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] cmake build
> The problem I'm running into appears to be caused by the installed > version of python being 2.5. Cmake requests a version of 2.5 or later > so it should be okay, however I get the following error. > > Serf:gnuradio-build ben$ make > [ 0%] Generating ../include/volk/volk.h, volk.c, volk_init.h, > ../include/volk/volk_typedefs.h, ../include/volk/volk_cpu.h, > volk_cpu.c, ../include/volk/volk_config_fixed.h, > volk_environment_init.c, volk_environment_init.h, volk_machines.h, > volk_machines.c, volk_machine_generic.c, volk_machine_sse2_only.c, > volk_machine_sse2_32.c, volk_machine_sse3_32.c, > volk_machine_ssse3_32.c > Unknown option: -B > usage: > /System/Library/Frameworks/Python.framework/Versions/2.5/Resources/Python.app/Contents/MacOS/Python > [option] ... [-c cmd | -m mod | file | -] [arg] ... > Try `python -h' for more information. > make[2]: *** [volk/include/volk/volk.h] Error 2 > make[1]: *** [volk/lib/CMakeFiles/volk.dir/all] Error 2 > make: *** [all] Error 2 > > A google suggests that the -B option for python was added in 2.6. > I'll install a newer version of python and see if I have more luck. > The -B tells python not to generate .pyc files (to keep junk from being generated in tree). I didnt realize it was for 2.6 and up. For now, you can harmlessly remove it, or alternatively, disable volk -DENABLE_VOLK=ON/OFF -josh ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] cmake build
> Use --disable-volk on the configure command line to disable it, and > everything else should work. Right. CMake. Use what Josh said: -DENABLE_VOLK=OFF on the cmake command line. I'm still in GNU autotools mode. - MLD ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] cmake build
I got everything working in the end by upgrading python to 2.7 and by using the standard autotools installation with volk disabled (I didn't try in with volk enabled based on your advice). However, for the sake of completeness, here is the error that prevented me from using cmake with python 2.7 installed. [ 9%] Building C object gnuradio-core/src/lib/CMakeFiles/gnuradio-core.dir/filter/sse_debug.c.o [ 9%] Building C object gnuradio-core/src/lib/CMakeFiles/gnuradio-core.dir/filter/float_dotprod_sse64.S.o float_dotprod_sse64.S:66:bad register name `%rdx' float_dotprod_sse64.S:76:bad register name `%rax' float_dotprod_sse64.S:81:bad register name `%rsi)' float_dotprod_sse64.S:82:bad register name `%rdi)' float_dotprod_sse64.S:83:bad register name `%rdi' float_dotprod_sse64.S:84:bad register name `%rsi' float_dotprod_sse64.S:87:bad register name `%rax' float_dotprod_sse64.S:96:bad register name `%rdx' float_dotprod_sse64.S:101:bad register name `%rsi)' float_dotprod_sse64.S:103:bad register name `%rsi)' float_dotprod_sse64.S:111:bad register name `%rdi)' float_dotprod_sse64.S:113:bad register name `%rsi)' float_dotprod_sse64.S:115:bad register name `%rdi)' float_dotprod_sse64.S:117:bad register name `%rsi)' float_dotprod_sse64.S:119:bad register name `%rdi)' float_dotprod_sse64.S:121:bad register name `%rsi)' float_dotprod_sse64.S:123:bad register name `%rdi)' float_dotprod_sse64.S:125:bad register name `%rsi)' float_dotprod_sse64.S:127:bad register name `%rdi' float_dotprod_sse64.S:128:bad register name `%rsi' float_dotprod_sse64.S:129:bad register name `%rdx' float_dotprod_sse64.S:158:suffix or operands invalid for `ret' make[2]: *** [gnuradio-core/src/lib/CMakeFiles/gnuradio-core.dir/filter/float_dotprod_sse64.S.o] Error 1 make[1]: *** [gnuradio-core/src/lib/CMakeFiles/gnuradio-core.dir/all] Error 2 make: *** [all] Error 2 On Sat, Sep 10, 2011 at 7:40 PM, Michael Dickens wrote: >> Use --disable-volk on the configure command line to disable it, and >> everything else should work. > > Right. CMake. Use what Josh said: -DENABLE_VOLK=OFF on the cmake command > line. I'm still in GNU autotools mode. - MLD > > > ___ > 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
Re: [Discuss-gnuradio] cmake build
> float_dotprod_sse64.S:84:bad register name `%rsi' > float_dotprod_sse64.S:87:bad register name `%rax' > float_dotprod_sse64.S:96:bad register name `%rdx' > float_dotprod_sse64.S:101:bad register name `%rsi)' > float_dotprod_sse64.S:103:bad register name `%rsi)' > float_dotprod_sse64.S:111:bad register name `%rdi)' > float_dotprod_sse64.S:113:bad register name `%rsi)' > float_dotprod_sse64.S:115:bad register name `%rdi)' > float_dotprod_sse64.S:117:bad register name `%rsi)' > float_dotprod_sse64.S:119:bad register name `%rdi)' > float_dotprod_sse64.S:121:bad register name `%rsi)' > float_dotprod_sse64.S:123:bad register name `%rdi)' > float_dotprod_sse64.S:125:bad register name `%rsi)' > float_dotprod_sse64.S:127:bad register name `%rdi' > float_dotprod_sse64.S:128:bad register name `%rsi' > float_dotprod_sse64.S:129:bad register name `%rdx' > float_dotprod_sse64.S:158:suffix or operands invalid for `ret' > make[2]: *** > [gnuradio-core/src/lib/CMakeFiles/gnuradio-core.dir/filter/float_dotprod_sse64.S.o] > Error 1 > make[1]: *** [gnuradio-core/src/lib/CMakeFiles/gnuradio-core.dir/all] Error 2 > make: *** [all] Error 2 > Is the build correctly detecting your machine arch (you have a x86-64)? If so, gcc may also need to build those sources w/ -m64, here is my best guess for a correction: http://pastebin.com/gNrnG8kE -josh ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
