Re: [Discuss-gnuradio] Tuning problem - usrp_fft.py
Hi, I do not know if my problem is like your.But after installing Gnu Radio (3.1.3 tarball) I tested my USRP and Dbsrx daughterboard when usrp_fft.py and I could see gsm spectrum without problems. After that, I installed Tvoid to decode gsm channels and it worked. Now, I do not know what happend. When I type: ./usrp_fft.py -R A -d 64 -g 20 show me the sprectrum like noise ( I have seen the whole band - 800- 2400Mhz like noise at the same level). Besides, Tvoid does not work right now. My USRP does not receive from the RF. What could be happening? Thanks in advance. Sincerely, Jose 2009/2/3 Fabian Uehlin m...@fabian-uehlin.de Hello! I have a Gentoo Linux system with KDE and the current svn version of GNURadio and OpenBTS (revision 10370). Because tuning of my two daugtherboards (RFX-1800, USRP1) failed with OpenBTS, an user give me the hint to run usrp_fft.py. So I run usrp_fft.py -R A -f 1724.4e6 or usrp_fft.py -R B -f 1724.4e6 It returns Segmentation fault nothing more. Running usrp_siggen.py -T A -f 1819.4e6 or usrp_siggen.py -T B -f 1819.4e6 returns Using TX d'board A: Flex 1800 Tx MIMO B or Using TX d'board B: Flex 1800 Tx MIMO B nothing more. The main problem is, that OpenBTS occurs an error, that the daughterboard could not tune to the desired frequency. So I tried to fix it, but without success. But now it seems, there is a general problem with tuning my USRP/daughterboards?! What could be the problem? Does anyone have an idea? Thanks Regards -Fabian- OpenBTS warnings: openbts apps # ./OpenBTS1800 /home/openbts/current/fail.txt 1232538978.074960 3082876624: TRXManager.cpp:352: WARNING -- RXTUNE failed with status 1 1232538978.115613 3082876624: TRXManager.cpp:396: WARNING -- POWERON failed with status 1 openbts Transceiver # ./transceiver 1232538960.602767 3083904720: creating USRP device... 1232538960.602831 3083904720: making USRP device.. 1232538978.074243 3083762576: Transceiver.cpp:501: RX failed to tune Here are the last lines of my configure log: * The following components were skipped either because you asked not to build them or they didn't pass configuration checks: usrp2-firmware These components will not be built. * The following GNU Radio components have been successfully configured: config gruel omnithread gnuradio-core pmt mblock usrp usrp2 gr-usrp gr-usrp2 gr-msdd6000 gr-audio-alsa gr-audio-jack gr-audio-oss gr-audio-portaudio gr-atsc gr-cvsd-vocoder gr-gpio gr-gsm-fr-vocoder gr-pager gr-radar-mono gr-radio-astronomy gr-trellis gr-video-sdl gr-wxgui gr-qtgui gr-sounder gr-utils gnuradio-examples grc You my now run the make command to build these components. * The following components were skipped either because you asked not to build them or they didn't pass configuration checks: gcell gr-gcell gr-audio-osx gr-audio-windows gr-comedi These components will not be built. ___ 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] Re: Spectrum Sense - Convert FFT Data into dBm proportional values
TMob wrote: Is it correct to just subtract 20 times the log of the window power to remove the window processing gain from the data? Is subtracting the gain correct to get somewhat proportional values? Thank you very much in advance! TMob Eventhough, I am not clear about what you are doing(i am a new one),I know from FFT theories that the computed FFT should be normalized by 1/sqrt(N) to preserve the energy(where N is size of FFT u take). That means, 10*log(N) should be substracted from the computed FFT power to get same power as the one computed in time domain. Bruhtesfa -- Posted via http://www.ruby-forum.com/. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] FOSDEM
If anyone is going to FOSDEM, (www.fosdem.org) would you like together for a bit and say hi? Philip ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Ubuntu make error - Unable to open file gnuradio_swig_py_runtime.py
Hello! I'm testing GNURadio under Ubuntu (8.10), because of problems with Gentoo (Tuning problem - usrp_fft.py - segmentation fault). The installation of GNURadio works with the package gnuradio (3.0.4-2ubuntu2). usrp_fft.py -R A -f 1724.4e6 shows me the spectrum. Now, for building OpenBTS I want to have the current svn release version, but this does not compile without errors. Configure seems to be okay, but make fails: make[5]: Leaving directory `/home/openbts/Desktop/gnuradio/gnuradio- core/src/lib' Making all in swig make[5]: Entering directory `/home/openbts/Desktop/gnuradio/gnuradio- core/src/lib/swig' if /usr/bin/swig -c++ -fvirtual -python -modern -keyword -w511 - outdir -DOMNITHREAD_POSIX=1 -I/usr/include -I/home/openbts/Desktop/ gnuradio/omnithread -I/home/openbts/Desktop/gnuradio/gnuradio-core/src/ lib/runtime -I/home/openbts/Desktop/gnuradio/gnuradio-core/src/lib/ general -I/home/openbts/Desktop/gnuradio/gnuradio-core/src/lib/general -I/home/openbts/Desktop/gnuradio/gnuradio-core/src/lib/gengen -I/home/ openbts/Desktop/gnuradio/gnuradio-core/src/lib/gengen -I/home/openbts/ Desktop/gnuradio/gnuradio-core/src/lib/filter -I/home/openbts/Desktop/ gnuradio/gnuradio-core/src/lib/filter -I/home/openbts/Desktop/gnuradio/ gnuradio-core/src/lib/missing -I/home/openbts/Desktop/gnuradio/ gnuradio-core/src/lib/reed-solomon -I/home/openbts/Desktop/gnuradio/ gnuradio-core/src/lib/viterbi -I/home/openbts/Desktop/gnuradio/ gnuradio-core/src/lib/io -I/home/openbts/Desktop/gnuradio/gnuradio- core/src/lib/g72x -I/home/openbts/Desktop/gnuradio/gnuradio-core/src/ lib/swig -I/home/openbts/Desktop/gnuradio/gnuradio-core/src/lib/swig -I/home/openbts/Desktop/gnuradio/gruel/src/include -I/home/openbts/ Desktop/gnuradio/gruel/src/include-MMD -MF gnuradio_swig_py_runtime.Td -module gnuradio_swig_py_runtime -o gnuradio_swig_py_runtime.cc ./gnuradio.i ;\ then if test linux-gnu = mingw32; \ then sed 's,,/,g' gnuradio_swig_py_runtime.Td gnuradio_swig_py_runtime.d; rm -f gnuradio_swig_py_runtime.Td; \ else mv -f gnuradio_swig_py_runtime.Td gnuradio_swig_py_runtime.d; fi \ else rm -f gnuradio_swig_py_runtime.Td; exit 1; fi Unable to open file -DOMNITHREAD_POSIX=1/gnuradio_swig_py_runtime.py: No such file or directory make[5]: *** [gnuradio_swig_py_runtime.cc] Error 1 make[5]: Leaving directory `/home/openbts/Desktop/gnuradio/gnuradio- core/src/lib/swig' What's the problem? I have upgraded to swig version 1.3.38, the other packages are the normal Ubuntu versions of it. Thanks Regards -Fabian- ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Tuning problem - usrp_fft.py - segmentation fault
On Tue, Feb 03, 2009 at 10:19:44AM +0100, Fabian Uehlin wrote: Hello! I have a Gentoo Linux system with KDE and the current svn version of GNURadio and OpenBTS (revision 10370). Because tuning of my two daugtherboards (RFX-1800, USRP1) failed with OpenBTS, an user give me the hint to run usrp_fft.py. So I run usrp_fft.py -R A -f 1724.4e6 or usrp_fft.py -R B -f 1724.4e6 It returns Segmentation fault nothing more. Hi Fabian, Does GNU Radio pass make check? Eric ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Ubuntu make error - Unable to open file gnuradio_swig_py_runtime.py
On Tue, Feb 3, 2009 at 11:33 AM, Fabian Uehlin m...@fabian-uehlin.de wrote: I'm testing GNURadio under Ubuntu (8.10), because of problems with Gentoo (Tuning problem - usrp_fft.py - segmentation fault). The installation of GNURadio works with the package gnuradio (3.0.4-2ubuntu2). The version of GNU Radio in the official Ubuntu repositories is quite old. We have a packaged version of 3.1.3 on gnuradio.org; follow the instructions on the UbuntuInstall wiki page to update your software sources and install. However, it may also be the case that OpenBTS only supports the latest trunk version of GNU Radio (I don't recall immediately), so you're probably best of either using svn to check out the latest trunk, or downloading the 3.2rc0 release tarball. Johnathan ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Ubuntu make error - Unable to open file gnuradio_swig_py_runtime.py
On Feb 3, 2009, at 12:33 PM, Fabian Uehlin wrote: if /usr/bin/swig -c++ -fvirtual -python -modern -keyword -w511 - outdir -DOMNITHREAD_POSIX=1 -I/usr/include - [snip] Unable to open file -DOMNITHREAD_POSIX=1/ gnuradio_swig_py_runtime.py: No such file or directory make[5]: *** [gnuradio_swig_py_runtime.cc] Error 1 make[5]: Leaving directory `/home/openbts/Desktop/gnuradio/gnuradio- core/src/lib/swig' What's the problem? I have upgraded to swig version 1.3.38, the other packages are the normal Ubuntu versions of it. $(builddir) isn't being set (properly? not at all?) by autotools ... the SWIG arguments (including -outdir $(builddir)) are in the top- level Makefile.common:66 , so if you look in gnuradio-core/src/lib/ swig/Makefile , you should find the line builddir = . if autotools are working. If you go back to SWIG 1.3.36 (or whatever the OS provides by default), does compiling work? If not, try editing Makefile.common and changing that particular $ (builddir) to . (without the quotes, just the period). - MLD ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Ubuntu make error - Unable to open file gnuradio_swig_py_runtime.py
Yes, I test the the old Ubuntu version and this version works fine (running usrp_fft.py). Now I have the current svn revision 10378 (the current trunk). This version fails with error Unable to open file -DOMNITHREAD_POSIX=1/gnuradio_swig_py_runtime.py: No such file or directory And I do need the latest trunk, because of OpenBTS. -Fabian- Am 03.02.2009 um 18:39 schrieb Johnathan Corgan: On Tue, Feb 3, 2009 at 11:33 AM, Fabian Uehlin m...@fabian- uehlin.de wrote: I'm testing GNURadio under Ubuntu (8.10), because of problems with Gentoo (Tuning problem - usrp_fft.py - segmentation fault). The installation of GNURadio works with the package gnuradio (3.0.4-2ubuntu2). The version of GNU Radio in the official Ubuntu repositories is quite old. We have a packaged version of 3.1.3 on gnuradio.org; follow the instructions on the UbuntuInstall wiki page to update your software sources and install. However, it may also be the case that OpenBTS only supports the latest trunk version of GNU Radio (I don't recall immediately), so you're probably best of either using svn to check out the latest trunk, or downloading the 3.2rc0 release tarball. Johnathan ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Ubuntu make error - Unable to open file gnuradio_swig_py_runtime.py
On Tue, Feb 03, 2009 at 06:58:59PM +0100, Fabian Uehlin wrote: Yes, I test the the old Ubuntu version and this version works fine (running usrp_fft.py). Now I have the current svn revision 10378 (the current trunk). This version fails with error Unable to open file -DOMNITHREAD_POSIX=1/gnuradio_swig_py_runtime.py: No such file or directory Look at the line above. Something is hosed; there's nothing in front of /gnuradio_swig_py_runtime.py. Does the path to the your source or build directory contain any spaces? If so rename the path so there are no spaces. Eric ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Tuning problem - usrp_fft.py - segmentation fault
Hello Eric, I create a file with make check 21 | tee make_check.log - I can't see any error / problems. All tests passed. Regards -Fabian- Am 03.02.2009 um 18:31 schrieb Eric Blossom: On Tue, Feb 03, 2009 at 10:19:44AM +0100, Fabian Uehlin wrote: Hello! I have a Gentoo Linux system with KDE and the current svn version of GNURadio and OpenBTS (revision 10370). Because tuning of my two daugtherboards (RFX-1800, USRP1) failed with OpenBTS, an user give me the hint to run usrp_fft.py. So I run usrp_fft.py -R A -f 1724.4e6 or usrp_fft.py -R B -f 1724.4e6 It returns Segmentation fault nothing more. Hi Fabian, Does GNU Radio pass make check? Eric ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Re: Help to Test DBSRX and USRP
Hi all, Is it possible to do a reset at USRP? Thanks, Jose 2009/2/3 José Carlos Reyes jcreyesguerr...@gmail.com Hi all, As I posted before, after installing Gnu Radio (3.1.3 tarball) I tested my USRP and Dbsrx daughterboard when usrp_fft.py and I could see gsm spectrum without problems. After that, I installed Tvoid to decode gsm channels and it worked. Now, I do not know what happend. When I type something like: ./usrp_fft.py -R A -d 64 -g 20 show me the sprectrum like noise ( I have seen the whole band - 800- 2400Mhz like noise at the same level). My dbsrx is in slot A. Besides, Tvoid does not work right now. My USRP does not receive from the RF. What could be happening? Is there any way to test dbsrx? Was able to change the configuration of the FPGA? I do not think so. Thanks in advance. Sincerely, Jose ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Ubuntu make error - Unable to open file gnuradio_swig_py_runtime.py
Am 03.02.2009 um 18:54 schrieb Michael Dickens: On Feb 3, 2009, at 12:33 PM, Fabian Uehlin wrote: if /usr/bin/swig -c++ -fvirtual -python -modern -keyword -w511 - outdir -DOMNITHREAD_POSIX=1 -I/usr/include - [snip] Unable to open file -DOMNITHREAD_POSIX=1/ gnuradio_swig_py_runtime.py: No such file or directory make[5]: *** [gnuradio_swig_py_runtime.cc] Error 1 make[5]: Leaving directory `/home/openbts/Desktop/gnuradio/gnuradio- core/src/lib/swig' What's the problem? I have upgraded to swig version 1.3.38, the other packages are the normal Ubuntu versions of it. $(builddir) isn't being set (properly? not at all?) by autotools ... the SWIG arguments (including -outdir $(builddir)) are in the top- level Makefile.common:66 , so if you look in gnuradio-core/src/lib/ swig/Makefile , you should find the line builddir = . if autotools are working. In gnuradio-core/src/lib/swig/Makefile there is no line builddir = . I only found these lines which could be interesting? # swig flags # -w511 turns off keyword argument warning # -outdir $(builddir) writes all generated output files to # the local builddir (which should always be '.') SWIG_PYTHON_FLAGS = -fvirtual -python -modern -keyword \ -w511 -outdir $(builddir) If you go back to SWIG 1.3.36 (or whatever the OS provides by default), does compiling work? No, I had 1.3.35 and the same error occurs. If not, try editing Makefile.common and changing that particular $ (builddir) to . (without the quotes, just the period). - MLD In gnuradio/Makefile.common there is no line with builddir There is only: # swig flags # -w511 turns off keyword argument warning # -outdir $(builddir) writes all generated output files to # the local builddir (which should always be '.') SWIG_PYTHON_FLAGS = -fvirtual -python -modern -keyword \ -w511 -outdir $(builddir) Regards -Fabian- ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Hi guys,
-- View this message in context: http://www.nabble.com/Hi-guys%2C-tp21808281p21808281.html Sent from the GnuRadio mailing list archive at Nabble.com. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Ubuntu make error - Unable to open file gnuradio_swig_py_runtime.py
Hi Fabian - For some reason, your computer's autotools are not providing $ (builddir) ... do you know what version they are? Hence why you couldn't find reference to it in the Makefile, and why the compile errored out. SWIG_PYTHON_FLAGS = -fvirtual -python -modern -keyword \ -w511 -outdir $(builddir) Try changing the above line in Makefile.common to: SWIG_PYTHON_FLAGS = -fvirtual -python -modern -keyword \ -w511 -outdir . Then 'configure' again to rebuild all the Makefiles. Then compiling should work. - MLD ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Ubuntu make error - Unable to open file gnuradio_swig_py_runtime.py
Yes, there is no space character between =1 and /gnuradio_ No, I don't have any spaces. It is a standard Ubuntu installation (/ home/openbts/Desktop/gnuradio). Regards -Fabian- Am 03.02.2009 um 18:58 schrieb Eric Blossom: On Tue, Feb 03, 2009 at 06:58:59PM +0100, Fabian Uehlin wrote: Yes, I test the the old Ubuntu version and this version works fine (running usrp_fft.py). Now I have the current svn revision 10378 (the current trunk). This version fails with error Unable to open file -DOMNITHREAD_POSIX=1/ gnuradio_swig_py_runtime.py: No such file or directory Look at the line above. Something is hosed; there's nothing in front of /gnuradio_swig_py_runtime.py. Does the path to the your source or build directory contain any spaces? If so rename the path so there are no spaces. Eric ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Ubuntu make error - Unable to open file gnuradio_swig_py_runtime.py
Hi Fabian - What's the OS / version / compiler / tools you're working with for this? The autotools are new enough they should have generated $(builddir). The warnings are fine; could be a stricter GCC. Since you're working with the trunk, update it before trying anything further (svn up). The error you showed could have come from using revision 10371; the latest revision (10380) fixes that issue. - MLD ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] usrp_multi and the USRP2
Is there any code similar to usrp_multi.py to use multiple USRP2's already (or is it unnecessary)? As I understand it, with the USRP2, you either use the MIMO cable, or an external reference to synchronize the clocks - then on the host side you would still need to do the align_on_samplenumbers/deinterleaving, etc. business that usrp_multi.py took care of for the USRP1. If nobody has code available to do this, should I expect any major hurdles in trying to convert the usrp_multi.py for use with the USRP2 (besides converting the source create calls, removing the subdev calls, etc)? If I'm using the MIMO cable, do I need to make any additional settings (e.g. sync_to_pps(True) or similar) to synchronize the master to slave? http://gnuradio.org/trac/wiki/USRP2GenFAQ says the VCXO locks on to the external reference, if one exists - which implies this is also the case for the MIMO cable, just wanted to verify that was true. Looking at test_mimo_tx.cc in the u2-mimo-wip branch I see it is possible to setup one usrp2 interface, and send samples to different channels - is that accessible from python now - or is it still code that's in development? If that's the case, is it possible at all to get synchronized samples out of two usrp2's with a MIMO cable right now with python, or should I be writing something in C++ to do that for me? Perhaps Thanks, Doug -- Doug Geiger Research Assistant Communications and Signal Processing Lab Oklahoma State University http://cspl.okstate.edu douglas.gei...@okstate.edu doug.gei...@ieee.org ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Ubuntu make error - Unable to open file gnuradio_swig_py_runtime.py
Hi Michael, Am 03.02.2009 um 21:32 schrieb Michael Dickens: Hi Fabian - What's the OS / version / compiler / tools you're working with for this? The autotools are new enough they should have generated $(builddir). The warnings are fine; could be a stricter GCC. Ubuntu 8.10 autotools-dev 20080123.1 gcc 4:4.3.1-ubuntu2 make 3.81-5 automake 1.9.6+nogfdl-3ubuntu1 libtool 2.2.4-0ubuntu4 sdcc-nf 2.8.0-1 guile 1.8.5+1-3ubuntu1 ccache 2.4-15 What tools do you also wanna know? Since you're working with the trunk, update it before trying anything further (svn up). The error you showed could have come from using revision 10371; the latest revision (10380) fixes that issue. - MLD I already build it with 10380 when the error in make check occurs. I always do: make uninstall make distclean svn update ./bootstrap ./configure make make check make install Regards -Fabian- ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] some hardware parameters of the USRP board
Hello, all! I have a question about some hardware parameters of the USRP board. What is the antenna temperature and what is the amplifier gain after the antenna when the board we are using is RFX2400 and the antenna is the VERT2450 ? Thanks a lot! Bill ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Re: Python 2.6 and Python 3.0
Instead, python3 is included in both 8.10 and 9.04. Is the plan to port gnuradio to python3? There's no plan yet. This needs to be investigated. Fedora 10 is 2.5.2. Not sure what they are planning. Anyone know of a mainstream distro that uses python 2.6? Python 2.6 missed the release window for F10. Fedora 11 plans to make Python 2.6 the default (Fedora is about pushing the boundaries, and having Python 2.6 as a transitional release on the path to Python 3000 is no exception.) The F11 Roadmap says they're 85% done so far (and have no fallback position, i.e. it's gonna happen even if some things break around the edges): https://fedoraproject.org/wiki/Releases/11/FeatureList https://fedoraproject.org/wiki/Features/Python_2.6 The F11 alpha is already frozen, it'll come out on Feb 5th. Feature freeze is March 3. Beta code and string freezes are March 10. Is there any chance that a GNU Radio release with Python 2.6 support is going to hit those dates? Python 3.x is going to be a much bigger deal for GNU Radio -- but 2.6 is designed as a compatible transition release so you can evolve your code forward, gradually. Guido van van Rossum's slides on Python 3000 and You are at the first URL below: http://www.artima.com/weblogs/viewpost.jsp?thread=227041 http://www.python.org/doc/2.6/whatsnew/2.6.html http://python.org/download/releases/3.0/ John ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Re: Python 2.6 and Python 3.0
On Tue, 2009-02-03 at 13:00 -0800, John Gilmore wrote: The F11 alpha is already frozen, it'll come out on Feb 5th. Feature freeze is March 3. Beta code and string freezes are March 10. Is there any chance that a GNU Radio release with Python 2.6 support is going to hit those dates? Our intent is that we'll roll any changes needed to work with 2.6 into the trunk and backport to the 3.2 stable release. It high on the list of things to work out during the release candidate series. Johnathan ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Interfacing to USRP2 with C++
Hi, I am currently trying to write a C++ program that interfaces to USRP2. I was able to successfully complete the tutorial found at http://www.gnuradio.org/trac/wiki/UsrpFAQ/CppInterface for interfacing to the USRP1 despite the example code being a little outdated. What changes with interfacing with USRP2? Is there a similar tutorial for the USRP2? Thanks in advance! Jon Peck ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Ring-buffer allocation
Eric Blossom wrote: OK. It may no longer be double buffering, so your throughput may be down. But, hey, if it's working :-) Eric OK, so I looked into this further. If I work backwards from the file-sink back to the USRP, I have a float vector of 16e6 items, which was costing 250e6, a complex vector of 16e6 items, which was costing 500e6, another 16e6 complex vector costing 500e6, and a complex stream of 32e6 items, costing 250e6 memory. I added logic to gr_flat_flowgraph::allocate_buffer so that if nitems = 4 and item_size = 12, then nitems /= 2. That reduced the memory footprint considerably, and still gives you double buffering between blocks. -- Marcus Leech Principal Investigator, Shirleys Bay Radio Astronomy Consortium http://www.sbrac.org ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Interfacing to USRP2 with C++
On Tue, Feb 03, 2009 at 04:29:12PM -0500, Jonathan Peck wrote: Hi, I am currently trying to write a C++ program that interfaces to USRP2. I was able to successfully complete the tutorial found at http://www.gnuradio.org/trac/wiki/UsrpFAQ/CppInterface for interfacing to the USRP1 despite the example code being a little outdated. What changes with interfacing with USRP2? Is there a similar tutorial for the USRP2? Thanks in advance! Jon Peck There's no tutorial. Have you looked at usrp2/host/include/usrp2/usrp2.h? Eric ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: Re[Discuss-gnuradio] quire USRP1 / USRP2 ASAP
On Tue, 2009-02-03 at 10:38 -0800, chitlas wrote: Hi, Please let me know from where I can purchase USRP1 / USRP2 as I see that USRP2 is due for release (beta is no longer available) and USRP1 is out of stock till Feb end or so from ETTUS's site. Thanks in advance. Regds/Sudhir. My company Olifantasia is the European USRP distributor. You can buy USRPs at my website: English site: http://www.olifantasia.com/cms/en#USRP Dutch site: http://www.olifantasia.com/cms/nl#USRP Olifantasia has still several USRPs and daughterboards in stock. Regards, Martin ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re[Discuss-gnuradio] quire USRP1 / USRP2 ASAP
Hi, Please let me know from where I can purchase USRP1 / USRP2 as I see that USRP2 is due for release (beta is no longer available) and USRP1 is out of stock till Feb end or so from ETTUS's site. Thanks in advance. Regds/Sudhir. -- View this message in context: http://www.nabble.com/Require-USRP1---USRP2-ASAP-tp21816118p21816118.html Sent from the GnuRadio mailing list archive at Nabble.com. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Any implementation of Spread Spectrum
Johnathan, So your DSSS code is not yet public? How did you manage waveform synchronization among multiple USRPs? Thanks. Mark On Jan 29, 2009, at 5:36 PM, Johnathan Corgan wrote: On Wed, Jan 28, 2009 at 9:31 AM, Mir Ali mirmurt...@gmail.com wrote: I want to know if ever any work was done on Spread Spectrum (DSSS) in Gnuradio? Yes. I have done both host code and FPGA code implementation of DSSS with the USRP1 and in progress with USRP2. These will eventually make into the public GNU Radio tree, but it might be some time before that happens. Johnathan ___ 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
Re: [Discuss-gnuradio] usrp_multi and the USRP2
On Tue, Feb 03, 2009 at 02:33:15PM -0600, Douglas Geiger wrote: Is there any code similar to usrp_multi.py to use multiple USRP2's already (or is it unnecessary)? As I understand it, with the USRP2, you either use the MIMO cable, or an external reference to synchronize the clocks - then on the host side you would still need to do the align_on_samplenumbers/deinterleaving, etc. business that usrp_multi.py took care of for the USRP1. If nobody has code available to do this, should I expect any major hurdles in trying to convert the usrp_multi.py for use with the USRP2 (besides converting the source create calls, removing the subdev calls, etc)? If I'm using the MIMO cable, do I need to make any additional settings (e.g. sync_to_pps(True) or similar) to synchronize the master to slave? http://gnuradio.org/trac/wiki/USRP2GenFAQ says the VCXO locks on to the external reference, if one exists - which implies this is also the case for the MIMO cable, just wanted to verify that was true. Looking at test_mimo_tx.cc in the u2-mimo-wip branch I see it is possible to setup one usrp2 interface, and send samples to different channels - is that accessible from python now - or is it still code that's in development? If that's the case, is it possible at all to get synchronized samples out of two usrp2's with a MIMO cable right now with python, or should I be writing something in C++ to do that for me? Perhaps Thanks, Doug Doug, There's currently no production code that supports using the USRP2 and the MIMO cable. We have test code that confirms that the h/w works as we expect, but we're not going to sort this out until after the great reworking of the host, firmware and on-the-wire spec as part of our move toward VITA-49 (VITA Radio Transport), an emerging standard for digital IF. In the meanwhile, you can make this work by providing your own star-distributed 10 MHz reference and PPS. All USRP2's will be coherent and will share the same timestamps. You will have to invoke config_mimo(MC_WE_LOCK_TO_SMA) and sync_to_pps() on each USRP2. Eric ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Any implementation of Spread Spectrum
On Tue, Feb 3, 2009 at 4:28 PM, Mark Kuhr kuhr...@auburn.edu wrote: So your DSSS code is not yet public? How did you manage waveform synchronization among multiple USRPs? Not sure I understand your question. My DSSS implementation is a unidirectional continuous transmitter and separate receiver, implementing m-sequence based chipping. The receiver performs code phase synchronization using early/prompt/late correlation power and frequency synchronization using a Costas loop on the despread BPSK signal. Or perhaps you're asking about multiple, simultaneous transmitter/receiver pairs. Right now, this is not optimal, as m-sequences have poor cross-correlation properties, but I'll eventually put in Gold code generators. While this system was designed with a completely different purpose in mind, one goal I have is to eventually be able to use the receiver part of the code as a GPS L1 demodulator. Johnathan ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] USRP2 missing Quadrature samples
I was able to compile the firmware with Eric's suggestion but it made no difference on the performance. I tested this out on another USRP2 to see if it was a hardware issue but again got the same results. I noticed something interesting though: Using a RFX 2400 board if I try to tune to 2.45G (my original freq), 2.4G or 2.5G I get similar behaviour (Q samples are 0). If I tune away from them I start to receive Q samples! I sampled at 2.425G and compared it to the USRP1. I noticed 2 things: 1. The IQ samples at 2.425G seem like complete noise compared to the USRP1 samples. 2. The Amplitude of the USRP2 IQ samples is much lower than the USRP1 I have posted these results at: http://www.cs.ucla.edu/~septikus/usrp2.html Am I setting something up wrong? Why are the IQ samples I'm getting just noise? This is using my own compiled firmware and the latest FPGA image off the GNURadio website. Any further help or comments would be great! Thanks again for all your help! -Leslie On Fri, Jan 30, 2009 at 4:41 PM, Eric Blossom e...@comsec.com wrote: On Fri, Jan 30, 2009 at 04:24:55PM -0800, Leslie Choong wrote: So I've pulled down the most recent trunk and re-built gnuradio. One thing I noticed that I forgot about was that running make in gnuradio/usrp2 does not produce a txrx.bin under usrp2/firmware/apps. I must have copied the latest one sitting in the trunk which is dated Dec 31st (same date as the FPGA binary blob). I looked into it and it seems like ./configure did not find mb-gcc (the microblaze toolchain). I installed the pre-compiled binary from instructions here: http://gnuradio.org/trac/wiki/USRP2UserFAQ And then after configuring and running make I get this error: make[3]: Entering directory `/home/leslie/gnuradio/usrp2/firmware/lib' if gcc -DHAVE_CONFIG_H -I. -I. -I.. -DHAL_IO_USES_UART -I../include -I../lib --std=gnu99 -Wall -Werror-implicit-function-declaration -mxl-soft-div -msoft-float -mxl-soft-mul -mxl-barrel-shift -g -O2 -MT abort.o -MD -MP -MF .deps/abort.Tpo -c -o abort.o abort.c; \ then mv -f .deps/abort.Tpo .deps/abort.Po; else rm -f .deps/abort.Tpo; exit 1; fi cc1: error: unrecognized command line option -mxl-soft-div cc1: error: unrecognized command line option -mxl-soft-mul cc1: error: unrecognized command line option -mxl-barrel-shift make[3]: *** [abort.o] Error 1 Run ./configure from top directory. Otherwise you get gcc instead of mb-gcc. Eric ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] extending gr-trellis to perform Viterbi, MLSD on GMSK
Nick, there is no change required in the modules that perform viterbi decoding in order to implement either MLSD in ISI or (coherent) GMSK demod. The whole idea around gr-trellis was to disentangle the trellis aspect of a modulation scheme from the details of the modulation/channel. So, if you want to implement general (coherent) CPM demodulation, all you have to do is to represent the CPM signal as a FSM followed by a memoryless modulator. Look up the paper by Bixio Rimoldi: A decomposition approach to CPM, or take a look at my notes on this at http://www.eecs.umich.edu/~anastas/docs/cpm.pdf You will only need to write an additional constructor for the fsm class that takes the CPM parameters and produces the appropriate FSM. Similarly, you'll need to write a piece of code that takes the incoming waveform and does the metrics calculations (eithar as a separate block as in trellis-metrics or inside the viterbi block as in trellis-viterbi-combined). If you want to work on this general problem for a generic CPM modulation I can help you. Adding ISI to this is a piece of cake: you need to combine the two trellises into either a combined trellis or to use hard/soft decisions from one to feed the other detector. Achilleas --- Date: Tue, 3 Feb 2009 02:43:01 + From: Nick Foster bistro...@hotmail.com Subject: [Discuss-gnuradio] extending gr-trellis to perform Viterbi MLSD on GMSK To: gnuradio discuss-gnuradio@gnu.org Message-ID: col104-w83311cfd96ff650fd0de58a6...@phx.gbl Content-Type: text/plain; charset=windows-1252 Hi all, I've spent a few days familiarizing myself with gr-trellis as best as I can, and I'm interested in extending the gr-trellis module to handle Viterbi equalization of ISI channels for GMSK demodulation. I saw Toby Oliver's thread in Sept. '06 (http://www.mail-archive.com/discuss-gnuradio@gnu.org/msg05615.html) discussing a possible modification with Achilleas Anastasopoulos but never saw anything checked in as a result. I'm just looking to use the trellis code to demodulate low-BT GMSK in a more optimal way than the current Gnuradio implementation, and I have similar questions to Toby's: * How should I go about modifying make_isi_lookup() to add support for two-dimensional modulations? What format is trellis expecting? * I see the test_viterbi_equalization1.py file, which appears to do MLSD on an ISI channel for 4-PAM (and other one-dimensional modulations). Am I correct that if make_isi_lookup() is modified to support quadrature modulations, simply changing the modulation type in this example would be enough to make it work? I guess I'm asking more specifically if trellis.viterbi_combined_X will support an ISI lookup table for PSK modulations without modification. * Is there a good reason I should avoid tackling this problem? I'd hate to be duplicating someone else's work in this area, or barking up the wrong tree. For further information, I've written a packet-based AIS decoder for Gnuradio, and I'm disappointed at the quality of the data coming out of the GMSK demodulator. It's 9600 symbols per second @ BT=0.3, so there's enough ISI that I think MLSD would provide significant reduction in observed BER. Besides, it seems like it would be a useful capability to have added to Gnuradio. Any other tips anyone has that might help me in doing this would certainly be welcome! Nick ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] usrp_multi and the USRP2
Eric Blossom wrote: There's currently no production code that supports using the USRP2 and the MIMO cable. We have test code that confirms that the h/w works as we expect, but we're not going to sort this out until after the great reworking of the host, firmware and on-the-wire spec as part of our move toward VITA-49 (VITA Radio Transport), an emerging standard for digital IF. In the meanwhile, you can make this work by providing your own star-distributed 10 MHz reference and PPS. All USRP2's will be coherent and will share the same timestamps. You will have to invoke config_mimo(MC_WE_LOCK_TO_SMA) and sync_to_pps() on each USRP2. Eric Understood. Looking around at code that uses config_mimo (which looks like it's only available to C++ apps right now) - I see rx_samples.cc uses it, but it looks like that's fallen out of use, and is a bit crufty now. Any reason I couldn't modify rx_streaming_samples.cc to call config_mimo? Thanks, Doug -- Doug Geiger Research Assistant Communications and Signal Processing Lab Oklahoma State University http://cspl.okstate.edu douglas.gei...@okstate.edu doug.gei...@ieee.org ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] AM modulated signal
Hi when I applied AM modulated signal to USRP from Signal Generator. I can not getting the same modulating frequency. Parameters are as. RF Frequency = 900 MHz Modulation Frequency=80KHz Modulatio Rate=50% I am using DBRX daughterboard: The code is attached. can any body check this code. Thanks #!/usr/bin/env python from gnuradio import gr, gru, eng_notation, optfir from gnuradio import audio from gnuradio import usrp from gnuradio import blks2 from gnuradio.eng_option import eng_option from gnuradio.wxgui import slider, powermate from gnuradio.wxgui import stdgui, fftsink, form,scopesink from optparse import OptionParser from usrpm import usrp_dbid import sys import math import wx def pick_subdevice(u): return usrp.pick_subdev(u, (usrp_dbid.TV_RX_REV_2, usrp_dbid.DBS_RX, usrp_dbid.DBS_RX_REV_2_1, usrp_dbid.BASIC_RX)) class rf_frontEnd(stdgui.gui_flow_graph): def __init__(self,frame,panel,vbox,argv): #stdgui2.std_top_block.__init__ (self,frame,panel,vbox,argv) stdgui.gui_flow_graph.__init__(self,frame,panel,vbox,argv) # # User selects Target frequency # parser=OptionParser(option_class=eng_option) parser.add_option(-f, --freq, type=eng_float, default=2205e6, help=set frequency to FREQ, metavar=FREQ) (options, args) = parser.parse_args() if len(args) != 0: parser.print_help() sys.exit(1) #-- self.frame = frame self.panel = panel self.freq = options.freq # build graph #self.connect(self.u,throttle) self.u = usrp.source_c()# usrp is data source in complex format - 8 bytes adc_rate = self.u.adc_rate()# ADC sampling rate- 64 MS/s usrp_decim = 200 # must be between 8-256 even number only self.u.set_decim_rate(usrp_decim) # set decimation rate of USRP usrp_rate = adc_rate / usrp_decim # usp output rate 320 kS/s chanfilt_decim = 1 rx_subdev_spec = pick_subdevice(self.u) # Autoselect Daughter Board self.u.set_mux(usrp.determine_rx_mux_value(self.u, rx_subdev_spec)) self.subdev = usrp.selected_subdev(self.u, rx_subdev_spec) print Using RX d'board %s % (self.subdev.side_and_name(),) # Displays side and name of DBSRX self.set_freq(self.freq) Covert complex to real op = gr.complex_to_float() self.connect(self.u,op) #---Display Recieved signal: TIME DOMAIN--- scope = scopesink.scope_sink_f(self, panel, title=RECEIVED SIGNAL (REAL): TIME DOMAIN, sample_rate= usrp_rate) vbox.Add(scope.win,4,wx.EXPAND) self.connect(op,scope)#real bandpass signal to oscilloscope # -RF front end tuning-- def set_freq(self, target_freq): r = usrp.tune(self.u, 0, self.subdev, target_freq) if r: print Tune to IF freq success %s % (target_freq) #RUN THE SOFTWARE if __name__ == '__main__': app = stdgui.stdapp (rf_frontEnd, ESEU Receiver) app.MainLoop () ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] AM modulated signal
On Tue, Feb 03, 2009 at 05:57:47PM -0800, abrar muhammad wrote: Hi when I applied AM modulated signal to USRP from Signal Generator. I can not getting the same modulating frequency. What are you getting? Have you tried looking at the signal using usrp_fft.py? Parameters are as. RF Frequency = 900 MHz Modulation Frequency=80KHz Modulatio Rate=50% I am using DBRX daughterboard: The code is attached. can any body check this code. Thanks ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Ubuntu make error - Unable to open file gnuradio_swig_py_runtime.py
Hi Fabian - I just created a fresh VM using Ubuntu 8.10 and followed the instructions on gnuradio.org for this distro. I get the gcc warnings, but otherwise everything works through make check. Hence I'm guessing you have some stale files in your checkout (ones which distclean does not know about, and aren't being overwritten properly on make). My advice now would be to create a fresh checkout of the trunk, then, from that directory do you usual routine. Mine is the somewhat modified neurotic vpath build (it's what make distcheck does FAPP): sh bootstrap mkdir build chmod -R a-w . chmod a+rwx build cd build ../configure make make check sudo make install Now, when there's a big update you can do: cd build sudo make uninstall cd .. rm -rf build chmod -R a+w . svn up and start anew, as guaranteed as possible to not end up with stale files. The above works well for me when I use it (which I don't always remember to). All built files are in a separate directory from the source code, and any command trying to write into the source code directories will fail hence making some issues easier to track down (this is how I found out that SWIG 1.3.37 had a bug in where it was writing output files). Good luck! - MLD ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re:[Discuss-gnuradio] AM modulated signal
I have tried the usrp_fft.py. it works on frequency only between 1.5G to 2.0 G. otherwise shows failed: what its means. From: abrar muhammad abrar_...@yahoo.com Date: 2009/2/4 Subject: Re: [Discuss-gnuradio] AM modulated signal To: Eric Blossom e...@comsec.com Cc: discuss-gnuradio@gnu.org Hi As I am getting only real one in time domain. the wave form shows modulating frequency of about 5 KHz. and when i Just applied carrier of 900 MHz it gives the wave form of about 71 KHz. --- On Tue, 2/3/09, Eric Blossom e...@comsec.com wrote: From: Eric Blossom e...@comsec.com Subject: Re: [Discuss-gnuradio] AM modulated signal To: abrar muhammad abrar_...@yahoo.com Cc: discuss-gnuradio@gnu.org Date: Tuesday, February 3, 2009, 7:58 PM On Tue, Feb 03, 2009 at 05:57:47PM -0800, abrar muhammad wrote: Hi when I applied AM modulated signal to USRP from Signal Generator. I can not getting the same modulating frequency. What are you getting? Have you tried looking at the signal using usrp_fft.py? Parameters are as. RF Frequency = 900 MHz Modulation Frequency=80KHz Modulatio Rate=50% I am using DBRX daughterboard: The code is attached. can any body check this code. Thanks ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio -- Engr. Muhammad Abrar Massey University Palmerston North NewZealand Mob: 0064211204202 Res: 006463586340 ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
