Re: [Discuss-gnuradio] BER vs SNR graph
Take a look at my thesis research in the academic papers section : https://app.box.com/s/5b8f1335df54af91b9cf Emulation of a radio link by means of software radio. It might help you understanding the used approach to the problem. Arturo ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Compiling GNURadio on BananaPI
Instead of building on the board itself, wouldn't be better to compile the source code on your working machine by exporting the toolchain compilers by means of a simple script ? 2015-01-09 22:52 GMT+01:00 Andreas Ladanyi andreas.lada...@gmx.net: On Fri, Jan 9, 2015 at 1:37 PM, Andreas Ladanyi andreas.lada...@gmx.net wrote: I must correct a detail. The datasheet tells me that bananapi has a Cortex-A7. cat /proc/cpuinfo: Processor: ARMv7 Processor rev 4 (v7l) processor: 0 BogoMIPS: 1431.55 processor: 1 BogoMIPS: 1436.46 Features: swp half thumb fastmult vfp edsp neon vfpv3 tls vfpv4 idiva idivt CPU implementer: 0x41 CPU architecture: 7 CPU variant: 0x0 CPU part: 0xc07 CPU revision: 4 Hardware: sun7i Revision: Serial: 0481019f5254484880485783165166d2 Hi, iam trying to compile GNURadio with the build-gnuradio script. Iam running a BananaPi (armv7 / cortex-a9) with the last raspian image for the Pi. The building process showed me two error messages. One message was that cmake is below 2.8.10. So i compiled and installed the last cmake 3.1 from source. The message is gone. When gnuradio is building i get this message: Scanning dependencies of target volk [ 2%] Building ASM object volk/lib/CMakeFiles/volk.dir/__/kernels/volk/asm/neon/volk_ 32fc_32f_dot_prod_32fc_a_neonasmpipeline.s.o [ 2%] Building ASM object volk/lib/CMakeFiles/volk.dir/__/kernels/volk/asm/neon/volk_ 32fc_x2_dot_prod_32fc_neonasm.s.o [ 2%] Building ASM object volk/lib/CMakeFiles/volk.dir/__/kernels/volk/asm/neon/volk_ 32fc_x2_dot_prod_32fc_neonasm_opttests.s.o [ 2%] Building ASM object volk/lib/CMakeFiles/volk.dir/__/kernels/volk/asm/neon/volk_ 32fc_32f_dot_prod_32fc_a_neonasm.s.o [ 2%] Building ASM object volk/lib/CMakeFiles/volk.dir/__/kernels/volk/asm/neon/volk_ 32f_s32f_multiply_32f_neonasm.s.o [ 2%] Building ASM object volk/lib/CMakeFiles/volk.dir/__/kernels/volk/asm/neon/volk_ 32fc_32f_dot_prod_32fc_unrollasm.s.o [ 2%] Building ASM object volk/lib/CMakeFiles/volk.dir/__/kernels/volk/asm/neon/volk_ 16i_max_star_horizontal_16i.s.o [ 2%] Building ASM object volk/lib/CMakeFiles/volk.dir/__/kernels/volk/asm/neon/volk_ 32f_x2_add_32f_a_neonasm.s.o [ 2%] Building ASM object volk/lib/CMakeFiles/volk.dir/__/kernels/volk/asm/neon/volk_ 32fc_32f_dot_prod_32fc_a_neonasmvmla.s.o [ 2%] Building ASM object volk/lib/CMakeFiles/volk.dir/__/kernels/volk/asm/neon/volk_ 32f_x2_add_32f_a_neonpipeline.s.o [ 3%] Building ASM object volk/lib/CMakeFiles/volk.dir/__/kernels/volk/asm/neon/volk_ 32f_x2_dot_prod_32f_neonasm_opts.s.o /home/bananapi/gnuradio/gnuradio/volk/kernels/volk/ asm/neon/volk_32f_x2_dot_prod_32f_neonasm_opts.s: Assembler messages: /home/bananapi/gnuradio/gnuradio/volk/kernels/volk/ asm/neon/volk_32f_x2_dot_prod_32f_neonasm_opts.s:46: Error: selected processor does not support ARM mode `sbfx r11,r1,#2,#1' volk/lib/CMakeFiles/volk.dir/build.make:1519: recipe for target 'volk/lib/CMakeFiles/volk.dir/__/kernels/volk/asm/neon/volk_ 32f_x2_dot_prod_32f_neonasm_opts.s.o' failed make[2]: *** [volk/lib/CMakeFiles/volk.dir/__/kernels/volk/asm/neon/volk_ 32f_x2_dot_prod_32f_neonasm_opts.s.o] Error 1 CMakeFiles/Makefile2:164: recipe for target 'volk/lib/CMakeFiles/volk.dir/all' failed make[1]: *** [volk/lib/CMakeFiles/volk.dir/all] Error 2 Makefile:147: recipe for target 'all' failed make: *** [all] Error 2 make failed I found the native compiling part at http://gnuradio.org/redmine/projects/gnuradio/wiki/Embedded and tried out: cmake [other options] -DCMAKE_C_FLAGS=-march=armv7-a -mthumb-interwork -mfloat-abi=hard -mfpu=neon -mtune=cortex-a9 -DCMAKE_ASM_FLAGS=-march=armv7-a -mthumb-interwork -mfloat-abi=hard -mfpu=neon source dir The result is: [ 1%] Building ASM object volk/lib/CMakeFiles/volk.dir/__/kernels/volk/asm/neon/volk_ 32f_x2_dot_prod_32f_neonasm_opts.s.o /home/bananapi/gnuradio/gnuradio/volk/kernels/volk/ asm/neon/volk_32f_x2_dot_prod_32f_neonasm_opts.s: Assembler messages: /home/bananapi/gnuradio/gnuradio/volk/kernels/volk/ asm/neon/volk_32f_x2_dot_prod_32f_neonasm_opts.s:46: Error: selected processor does not support ARM mode `sbfx r11,r1,#2,#1' volk/lib/CMakeFiles/volk.dir/build.make:1519: recipe for target 'volk/lib/CMakeFiles/volk.dir/__/kernels/volk/asm/neon/volk_ 32f_x2_dot_prod_32f_neonasm_opts.s.o' failed make[2]: *** [volk/lib/CMakeFiles/volk.dir/__/kernels/volk/asm/neon/volk_ 32f_x2_dot_prod_32f_neonasm_opts.s.o] Error 1 CMakeFiles/Makefile2:164: recipe for target 'volk/lib/CMakeFiles/volk.dir/all' failed make[1]: *** [volk/lib/CMakeFiles/volk.dir/all] Error 2 Makefile:147: recipe for target 'all' failed make: *** [all] Error 2 Any ideas ? cheers, Andreas I don't know that it's a definite fix for this, but I was going to suggest making sure the tune settings fit your processor. If that's not the case we can look around
Re: [Discuss-gnuradio] Status of GNU Radio with OSX 10.9
Nella citazione in data Wed Nov 20 00:50:52 2013, Michael Dickens ha
scritto:
Earlier today I pushed r113561 to MacPorts
https://trac.macports.org/changeset/113561 which should allow pretty much any
compiler should work on 10.8 or 10.9 (and, likely, any other OSX version) to build
any version of gnuradio (legacy, release, devel, next). If your build is broken,
please try:
{{{
sudo port clean gnuradio gnuradio-devel
sudo port -f -p uninstall gnuradio gnuradio-devel
sudo port selfupdate
sudo port install gnuradio-devel
}}}
and then see if the dial_tone works; see if gnuradio-companion works. Compared
with previous fixes, this one seems to work across the board. So please give
this change a try if you're using GNU Radio on OSX via MacPorts. Enjoy! - MLD
ps The issue, as has been the case before, comes down the compiling VOLK. This time,
the problem is that Apple's clang is some version of 3.3, which has issues with the
cvtpi32_ps intrinsic on ACX. Clang 3.4 has the fixes for this intrinsic. So ... long story
short is that in MacPorts only, I patch volk/lib/CMakeLists.txt to test for not just xgetbv
but also for cvtpi32_ps. I'm not sure it is important to include this patch within GNU
Radio proper, but it does specify if (APPLE) to it could be done.
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Hi folks, can you give some good news about the building from source of
the gnuradio tarball ? As I previously said, i need to work with
gnuradio 3.6.5.1 and above.
Kind Regards,
Arturo
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Status of GNU Radio with OSX 10.9
Nella citazione in data Mon Dec 2 19:42:56 2013, Michael Dickens ha scritto: Hi Arturo - GNU Radio 3.6.5.1 should now work within MacPorts; I've tested on 10.8 and 10.9, but the fixes should be backward compatible to at least 10.6, maybe 10.5. All of the GNU Radio ports should work right now within MacPorts. If you want to build these from source outside MacPorts, I'd advise to pretty much follow what the Portfile does including needed patches. For example, to get SWIG working on 10.9 you have to copy the whole swig/std directory to a place where SWIG files will be looked for, then patch the correct files in the copy. Hope this helps! - MLD On Dec 2, 2013, at 1:30 PM, Arturo Rinaldi arty.n...@gmail.com wrote: Hi folks, can you give some good news about the building from source of the gnuradio tarball ? As I previously said, i need to work with gnuradio 3.6.5.1 and above. Thank you again Michael, I was wondering If I could redirect the installation path of the port to /usr/local/lib/python2.7/site-packages instead of /opt/local/lib/python2.7/site-packages would this be possible or not ? Basically, it's what I really need to install custom gnuradio modules without messing with the /opt/local root path. This will totally cancel my need to perform a building from tarball. Regards again, Arturo ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Status of GNU Radio with OSX 10.9
Nella citazione in data Mon Dec 2 20:03:22 2013, Michael Dickens ha scritto: I think you should be able to have GNU Radio installed into /opt/local but then you create an OOT module which installs into /usr/local . I used to do this way back in the day; I would assume it still works. Maybe you can send me off-list more info on what you're trying to do and I can point you in the right directions? I think you could probably copy the files from /opt/local/lib/python2.7/site-packages into /usr/local/lib/python2.7/site-packages and they would probably work about right. No guarantees though, since some libraries might be linked against other libraries already in /opt/local somewhere. But, it's worth a try IMHO ... - MLD On Dec 2, 2013, at 1:52 PM, Arturo Rinaldi arty.n...@gmail.com wrote: Thank you again Michael, I was wondering If I could redirect the installation path of the port to /usr/local/lib/python2.7/site-packages instead of /opt/local/lib/python2.7/site-packages would this be possible or not ? Basically, it's what I really need to install custom gnuradio modules without messing with the /opt/local root path. This will totally cancel my need to perform a building from tarball. mmm I see.ok let's do it this way. Let's say that i untar the 3.6.5.1 tarball and write a script that patches all the needed files before running the usual steps of configuration. If I have understood well what I have to do I need to use all the 8 diff files you uploaded on the macports server, join them and apply the result to the extracted tarball directory. I can try that with patch --dry-run to find if the patching is properly perfromed and the files are not affected by patching. Now i have to figure out which are the right diff files to patch the legacy version and the new version since I'm noticing that the source path structure is different in the new tarball. Do I have to use all of them or not ? Can i write just one single diff file to apply before building from source as usual ? I was thinlking thah once the work is finished i could post it on the mailing list so it'd be available for everyone.let me know if you like the idea. Regards, Arturo ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Status of GNU Radio with OSX 10.9
Il 02/12/13 22:15, Michael Dickens ha scritto: Hi Arturo - You don't need all 8 diff files. If you read through the Portfile for GNU Radio, you'll find that you need just 5 of those patches to build 3.6.5.1 on 10.9; if you want to build on 10.8, you need just 3. Needed for 10.8 and 10.9 (and, likely, 10.7 or earlier): patch-path-order.diff patch-volk_lib_CMakeLists.txt.legacy.diff patch-volk_gen_archs.xml.legacy.diff Needed just for 10.9/libc++: patch-gnuradio-core_swig_std_std_container.i.diff patch-gnuradio-core_swig_include-std_string.i.diff If you use those patches on your OOT build of GNU Radio, you should be able to build it with minimal defines added to the cmake command line. - MLD On Dec 2, 2013, at 2:23 PM, Arturo Rinaldiarty.n...@gmail.com wrote: mmm I see.ok let's do it this way. Let's say that i untar the 3.6.5.1 tarball and write a script that patches all the needed files before running the usual steps of configuration. If I have understood well what I have to do I need to use all the 8 diff files you uploaded on the macports server, join them and apply the result to the extracted tarball directory. I can try that with patch --dry-run to find if the patching is properly perfromed and the files are not affected by patching. Now i have to figure out which are the right diff files to patch the legacy version and the new version since I'm noticing that the source path structure is different in the new tarball. Do I have to use all of them or not ? Can i write just one single diff file to apply before building from source as usual ? I was thinlking thah once the work is finished i could post it on the mailing list so it'd be available for everyone.let me know if you like the idea. ok let's sum up and see if i have understood what is coded in the Portfile. Let's examine it case by case : 10.7 *LEGACY (3.6.5.1 and lower) and * /cat/ of : patch-path-order.diff patch-volk_lib_CMakeLists.txt.legacy.diff patch-volk_gen_archs.xml.legacy.diff then apply resulting patch, then build as usual PS : I have always built from source any latest tarball of gnuradio legacy successfully, so I don't think I'll ever apply this modifications *NEW releases (3.7 and above) *nothing to patch or to modify 10.8 * LEGACY (3.6.5.1 and lower) and * /cat/ of : patch-path-order.diff patch-volk_lib_CMakeLists.txt.legacy.diff patch-volk_gen_archs.xml.legacy.diff then apply resulting patch, then build as usual *NEW releases (3.7 and above) *nothing to patch or to modify (at least applying the swig/std trick but it seems working without it as well) 10.9 first of all I have to perform the copy of the directory *std* of SWIG in my source directory according to : *LEGACY**(3.6.5.1 and lower)* cp -r /opt/local/share/swig/*/std to mygrsource/gnuradio-core/src/lib/swig /cat/ of : patch-path-order.diff patch-volk_lib_CMakeLists.txt.legacy.diff patch-volk_gen_archs.xml.legacy.diff patch-gnuradio-core_swig_std_std_container.i.diff patch-gnuradio-core_swig_include-std_string.i.diff then apply resulting patch, then build as usual *NEW releases (3.7 and above)* cp -r /opt/local/share/swig/*/std to mygrsource/gnuradio-runtime/src/lib/swig /cat/ of : patch-gnuradio-runtime_swig_std_std_container.i.diff patch-gnuradio-runtime_swig_include-std_string.i.diff then apply resulting patch, then build as usual Have I nailed it or not yet ? Let me know. Regards, ARturo ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Status of GNU Radio with OSX 10.9
Nella citazione in data Tue Dec 3 02:44:13 2013, Michael Dickens ha scritto: Hi Arturo - Yes, I think you've nailed it. - MLD On Dec 2, 2013, at 8:33 PM, Arturo Rinaldi arty.n...@gmail.com wrote: ok let's sum up and see if i have understood what is coded in the Portfile. Let's examine it case by case : 10.7 LEGACY (3.6.5.1 and lower) and cat of : patch-path-order.diff patch-volk_lib_CMakeLists.txt.legacy.diff patch-volk_gen_archs.xml.legacy.diff then apply resulting patch, then build as usual PS : I have always built from source any latest tarball of gnuradio legacy successfully, so I don't think I'll ever apply this modifications NEW releases (3.7 and above) nothing to patch or to modify 10.8 LEGACY (3.6.5.1 and lower) and cat of : patch-path-order.diff patch-volk_lib_CMakeLists.txt.legacy.diff patch-volk_gen_archs.xml.legacy.diff then apply resulting patch, then build as usual NEW releases (3.7 and above) nothing to patch or to modify (at least applying the swig/std trick but it seems working without it as well) 10.9 first of all I have to perform the copy of the directory std of SWIG in my source directory according to : LEGACY (3.6.5.1 and lower) cp -r /opt/local/share/swig/*/std to mygrsource/gnuradio-core/src/lib/swig cat of : patch-path-order.diff patch-volk_lib_CMakeLists.txt.legacy.diff patch-volk_gen_archs.xml.legacy.diff patch-gnuradio-core_swig_std_std_container.i.diff patch-gnuradio-core_swig_include-std_string.i.diff then apply resulting patch, then build as usual NEW releases (3.7 and above) cp -r /opt/local/share/swig/*/std to mygrsource/gnuradio-runtime/src/lib/swig cat of : patch-gnuradio-runtime_swig_std_std_container.i.diff patch-gnuradio-runtime_swig_include-std_string.i.diff then apply resulting patch, then build as usual Have I nailed it or not yet ? Let me know. Thank you very much again for your support. You're a priceless asset to me and the whole gnuradio mailing list of course. Keep doing this great work. Regards, Arturo ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] vector size instead of the regular size in class/object definition
Hi folks, is it possible to modify the input size at python level by using vectors ? What I specifically mean is that I want to build a hierachical block and giving it as input two vectors : */class error_rate_vector_iif(gr.hier_block2):/**/ /**/ /**/#init/**/ /**/gr.hier_block2.__init__(/**/ /**/self, 'error_rate_vector_iif',/**/ /**/gr.io_signature(2, 2, gr.sizeof_int,/**/ /**/gr.io_signature(1, 1, gr.sizeof_float),/**/ /**/)/* So my question is, is there a way to use a sort of fictional *gr.sizeofvector_int* instead of *gr.sizeof_int* size in the definition of my python class ? Basically, I need to compare two vectors and increase a counter while a difference between their elements is spotted..can anybody help me ? thank you in advance as always Kind Regards, Arturo ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] GR-RADAR-MONO module
Hi folks, I was wondering if I am currently able to use the latest revision of the GR module, the one from the 3.4.2 tarball, with the 3.6.4.1 source tarball and the UHD driver of course. I have browsed through python code and at a first glance it shouldn't be so difficult to update it by replacing the USRP objects with the UHD ones. However, I have some questions about it : 1) Can I use the included firmware to set up the FPGA of the usrp1 with the UHD driver (by which I mean the *fifo_1clk.v*, *radar_tb.v* and *usrp_radar_mono.v* fpga code) ? 2) Is the generated waveform the *CHIRP* one ? 3) Can I modify its frequency and amplitude according to my needs ? Thank you in advance. Kind Regards, Arturo ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] conversion from long integer to byte/char
thank you very much tom..piece of cake ! ! ! ^_^ 2013/10/7 Tom Rondeau t...@trondeau.com On Sun, Oct 6, 2013 at 6:45 PM, Arturo Rinaldi arty.n...@gmail.com wrote: Hi folks, i was wondering if it's possible to operate a type conversion from long integer (green color in GRC) to byte/char (purple color in GRC) with the existing gnuradio blocks. I'm running the 3.6.5.1 tarball, any suggestions ? Thanks in advance. Kind Regards, Arturo Right now, there is no direct conversion from int to char. To do it with current blocks, you'd have to do int_to_float followed by float_to_char. It should be easy for your to take these and create a single block out of them for your purposes. Tom ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] conversion from long integer to byte/char
Hi folks, i was wondering if it's possible to operate a type conversion from *long integer* *(green color in GRC)* to *byte/char* *(purple color in GRC)* with the existing gnuradio blocks. I'm running the 3.6.5.1 tarball, any suggestions ? Thanks in advance. Kind Regards, Arturo ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Flow graph issue with usrp1+RFX2400 daughter board and TX/RX antenna
Hi folks, I've recently bumped into an issue with two GRC flow graphs while running a rx/tx loop path interfacing with an external sensor : *T**X path - UHD Usrp1 Sink (sending data to the sensor)* http://img713.imageshack.us/img713/4540/gyz.png *RX path - UHD Usrp1 Source (receiving data from the sensor)* http://img822.imageshack.us/img822/521/dq8.png I'm using a USRP1 mainboard and a RFX2400 daughter board using the TX/RX section. I can run the TX flow graph, but when i launch the other one, the shell warns me about an UHD error. The uhd driver can't find the usrp1 card (specifically, the *uhd source object* can't be built because the uhd driver is not able find the usrp device), it's like the tx path had an exclusive possession of the A:0 subdevice (the *TX/RX* one on which I put my antenna). Do I have to pass some command line switches to the uhd driver to solve this issue ? Thanks in advance. Kind Regards, Arturo ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] building GNU Radio from tarball on Mac Os X with gcc-4.7
Hi folks, i was wondering if i might be able to build the gnuradio tarball (specifically the 3.6.4.2 version) on Mac Os X by using the gcc-4.7 compiler installed with macports. I usually launch these commands from shell : /$ CC=gcc-mp-4.7 CXX=g++-mp-4.7 cmake -DPYTHON_EXECUTABLE=/opt/local/bin/python -DPYTHON_INCLUDE_DIR=/opt/local/Library/Frameworks/Python.framework/Versions/2.7/include/python2.7 -DPYTHON_LIBRARY=/opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/libpython2.7.dylib -DENABLE_BAD_BOOST=ON ..// /$ make/ but the building process breaks at 12% warning me about a tag error in the swig directory.maybe it concerns a doxygen issue. However since i need a fully functional gnuradio installation I am now turning back to the llvm-gcc-42 compiler so to take advantage of the volk cpu capabilities. Has anyone ever succedeed in building the tarball with gcc-47 or gcc-46 ? Please let me know. Regards, Arturo ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Cannot import gnuradio
Il 15/06/13 13:02, Tanaga Biru ha scritto: Dear Helper, I had installed GNU Radio, but when I run gnuradio-companion in Ubuntu Terminal, I received the following message: *Cannot import gnuradio.* *Is the python path environment variable set correctly? * *All OS: PYTHONPATH* * * *Is the library path environment variable set correctly?* *Linux: LD_LIBRARY_PATH* *Windows: PATH* *MacOSX: DYLD_LIBRARY_PATH* I had set the path in .bashrc and .profile export PYTHONPATH=$PYTHONPATH:/usr/local/lib/python2.7/dist-packages export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:/usr/local/lib Thank you. Regards, Tanaga Biru ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio Hi Tanaga, follow these steps : *1.* Uninstall gnuradio with sudo make uninstall *2.* Remove all the export(s) in the .profile and .bashrc files or better leave only : /export PYTHONPATH=$PYTHONPATH:/usr/local/lib/python2.7/dist-packages/ in the .bashrc file *3.* go back in the root folder of the gnuradio source and remove the build folder you used to compile gnuradio. /rm -rf build// *4.* Edit the *CMakeLists.txt* file in the gnuradio root folder in the following way as described here : https://bbs.archlinux.org/viewtopic.php?id=147452 replace : // /find_package(PythonLibs)/ with : /find_package(PythonLibs your-python-version)/ you'll get the python version from your shell *5.* rebuiild and install gnuradio in the usual way. All the issues should be fixed nowLet me know Kind Regards, Arturo ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Cannot import gnuradio
Nella citazione in data sab 15 giu 2013 17:36:52 CEST, swrangsar basumatary ha scritto: hi, this can happen if you forget to do: sudo ldconfig On Sat, Jun 15, 2013 at 4:32 PM, Tanaga Biru tanagab...@gmail.com mailto:tanagab...@gmail.com wrote: Dear Helper, I had installed GNU Radio, but when I run gnuradio-companion in Ubuntu Terminal, I received the following message: *Cannot import gnuradio.* *Is the python path environment variable set correctly? * *All OS: PYTHONPATH* * * *Is the library path environment variable set correctly?* *Linux: LD_LIBRARY_PATH* *Windows: PATH* *MacOSX: DYLD_LIBRARY_PATH* I had set the path in .bashrc and .profile export PYTHONPATH=$PYTHONPATH:/usr/local/lib/python2.7/dist-packages export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:/usr/local/lib Thank you. Regards, Tanaga Biru ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org mailto: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 I took for granted that Tanaka did sudo ldconfig as last step of the building process. The Ubuntu derivatives (such as Kubuntu) suffer from this issue. Regards, Arturo ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] GNU Radio Companion isn't aware of custom pythonpath(s)
i was thinking about it but i can't find the right argument to pass to the config file. I looked up on the internet and there's no proper way to do in a simple thing as : [path] mypath=path1:path2 so i decided to make my own script *!# /bin/bash * * export PYTHONPATH=$PYTHONPATH:my-**custom-path \ gnuradio-companion* and link it to the .desktop file in my app menu in KDE. Gnuradio documentation lacks this information, so i really don't know where to search for. Regards 2013/6/7 Gregory Warnes g...@warnes.net Perhaps something to add to the [grc] section of ~/.gnuradio/config.conf? -Greg On Thu, Jun 6, 2013 at 5:14 PM, Marcus D. Leech mle...@ripnet.com wrote: On 06/06/2013 02:54 PM, Arturo Rinaldi wrote: I bumped into a strange issue in the past few days. When i launch GRC by the desktop link generated, the program itself isn't aware of my custom pythonpath set in the .bashrc settings file. I tried to modify the desktop link also by checking the option to *launch the program in a terminal* and putting into the blank space : /export PYTHONPATH=$PYTHONPATH:my-custom-path \ gnuradio-companion/ but without any results. I have never experienced this issue with the past versions of gnuradio. I'm running Kubuntu 13.04 with gnuradio 3.6.4.1. The only way it works is by making a script and launch it from my desktop. No issues if i launch GRC from shell, after all the pythonpath is embedded in the launched shell. thanks in advance for helping me. I can confirm that this is an issue. There may need to be a helper gnuradio-companion script that sets the env vars and then calls the actual python script. The gnuradio-grc.desktop would call this script instead. Not sure of a better way to do that. -josh In Ubuntu, terminals aren't automatically login terminals, and so don't run your .bashrc, although for terminals at least, you can configure them to pretend to be login terminals, and thus run your .bashrc. -- 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 -- Whereas true religion and good morals are the only solid foundations of public liberty and happiness . . . it is hereby earnestly recommended to the several States to take the most effectual measures for the encouragement thereof. Continental Congress, 1778 ___ 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] GNU Radio Companion isn't aware of custom pythonpath(s)
I bumped into a strange issue in the past few days. When i launch GRC by the desktop link generated, the program itself isn't aware of my custom pythonpath set in the .bashrc settings file. I tried to modify the desktop link also by checking the option to *launch the program in a terminal* and putting into the blank space : /export PYTHONPATH=$PYTHONPATH:my-custom-path \ gnuradio-companion/ but without any results. I have never experienced this issue with the past versions of gnuradio. I'm running Kubuntu 13.04 with gnuradio 3.6.4.1. The only way it works is by making a script and launch it from my desktop. No issues if i launch GRC from shell, after all the pythonpath is embedded in the launched shell. thanks in advance for helping me. Kind Regards, Arturo ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Ucla Zigbee compiling issues on MacOs X and Ubuntu 12.04.2 LTS
Il 06/06/13 07:23, Bastian Bloessl ha scritto: Hello Arturo, On 06/06/2013 01:55 AM, Arturo Rinaldi wrote: I have recently bumped into some issues when building the ucla_zigbee platform both on macos and ubuntu 12.04.2. I'll shortly sum up my two setups : I think the UCLA blocks were not updated to work with GNU Radio 3.6.4. I made some 802.15.4 blocks based on the UCLA Phy. Maybe you want to give them a try. https://github.com/bastibl/gr-ieee802-15-4 The last commits port the blocks to v3.7 API. If you want to use 3.6.4 you should go back some commits git checkout v3.6 Best, Bastian Hi Sebastian, I've just successfully built the zigbee platform with gnuradio-3.6.4.1 on Kubuntu 13.04. I already found your zigbee port some time ago but I need the whole complete distro. I have done another tweak in the *Makefile.common* file I attached last night, to fine tuning the python installation directory of the files with : /grpythondir = /usr/lib/python2.7/dist-packages/gnuradio/ and all went smoothly. Tomorrow i'll test my 12.04 machine hoping that this is the reason why i couldn't install zigbee on it. MacOS X issues still persist. Regards, Arturo ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Ucla Zigbee compiling issues on MacOs X and Ubuntu 12.04.2 LTS
Hi folks, I have recently bumped into some issues when building the ucla_zigbee platform both on macos and ubuntu 12.04.2. I'll shortly sum up my two setups : *Setup 1* MacOs X 10.7.4 Macports 2.1.3 (It was used for getting the gnuradio dependencies) GNU Radio 3.6.4.2 installed from tarball (and not from macports) I attach the make log error file. So I tried to tweak the Makefile.common file this way : /# includes// //grincludedir = /usr/local/include/gnuradio/swig// // //# swig includes // //swigincludedir = /usr/local/include/gruel/swig/ but then then i the errors reported in the ucla_error_2.txt log file which is really strange since /usr/local/include/gnuradio should already be in the system path. P.S. : By using the tweak i didn't get any error if the installation of gnuradio is performed by macports. Is there to add the //usr/local/include/gruel/swig /includes to the Makefile.common file ? *Setup 2* Ubuntu 12.02.2 LTS GNU Radio 3.6.4.1 (Binary deb version from Ettus Research) Th built-in gcc compiler (the 4.6.3) returns build errors so I decided to install and set the alternatives to gcc, g++ and cpp 4.5 which are mantained in the 12.04 official repos. The building from source went smoothly but this time i have installation issues. In fact i experienced an installation error when the compiler enters the /*source/python* directory. I can't post the log file since i don't currently have this machine by my side but i'll post it in a few hours. Has anyone of you experienced similar issues at least on one of the setups ? Thanks in advance Kind Regards, Arturo make all-recursive Making all in config make[2]: Nothing to be done for `all'. Making all in src Making all in lib /opt/local/bin/swig -c++ -fvirtual -python -modern -I/opt/local/Library/Frameworks/Python.framework/Versions/2.7/include/python2.7 -I/usr/local/include/gnuradio/swig -I/usr/local/include/gnuradio -module ucla -o ucla.cc ucla.i /usr/local/include/gnuradio/swig/gnuradio.i:31: Error: Unable to find 'gruel_common.i' /usr/local/include/gnuradio/swig/gr_basic_block.i:26: Error: Unable to find 'pmt_swig.i' make[3]: *** [ucla.cc] Error 1 make[2]: *** [all-recursive] Error 1 make[1]: *** [all-recursive] Error 1 make: *** [all] Error 2 binWEfZJ3egHy.bin Description: application/applefile Makefile.common Description: Binary data make all-recursive Making all in config make[2]: Nothing to be done for `all'. Making all in src Making all in lib /opt/local/bin/swig -c++ -fvirtual -python -modern -I/opt/local/Library/Frameworks/Python.framework/Versions/2.7/include/python2.7 -I/usr/local/include/gruel/swig -I/usr/local/include/gnuradio/swig -module ucla -o ucla.cc ucla.i /usr/local/include/gnuradio/swig/gnuradio.i:47: Error: Unable to find 'gr_types.h' make[3]: *** [ucla.cc] Error 1 make[2]: *** [all-recursive] Error 1 make[1]: *** [all-recursive] Error 1 make: *** [all] Error 2 ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] issues with the GL scopesinks on KUBUNTU 13.04
Hi folks, I have just built the 3.6.4.1, 3.6.4.2 and 3.6.5 tarballs on the latest KUBUNTU (13.04 raring ringtail) with these sequence of shell commands : *$ ./build-gnuradio -v prereqs** ** **$ mkdir build** ** **$ cd build** ** **$ cmake -DENABLE_BAD_BOOST=ON -DPYTHON_EXECUTABLE=/usr/bin/python2.7 -DPYTHON_INCLUDE_DIR=/usr/include/python2.7 -DPYTHON_LIBRARY=/usr/lib/x86_64-linux-gnu/libpython2.7.so -DCMAKE_INSTALL_PREFIX=/usr -DCPACK_GENERATOR=DEB ../** ** **$make package -j5* and so making a custom deb package for my distro. I had to use cmake with a lot of command line arguments since the library linking is not taken for granted on the Ubuntu derivative distros (such as Kubuntu for instance). Maybe this was also the reason because my builds always failed on Kubuntu 12.10.it was just a matter of setting the correct paths in cmake (Sorry Tom and Josh for Bothering so much ) ! ! ! However i have just bumped in another issue, this time the blocks affected are the GL sinks. Let me show you with this screenshot : http://imageshack.us/photo/my-images/543/gnuradioissue.png/ I have never experienced this issue before. The scope part where the waveforms are usually showed is blank !. I tested the built *deb(s)* on a virtual machine running *Ubuntu 13.04* instead of Kubuntu and they all work fine.could be this issue a kde related bug which is bound to the GL manager/libraries of the distro or something similar ? P.S. *The 3.6.4.1 deb* works perfectly on Kubuntu, the problems apparently affects *the 3.6.4.2 and 3.6.5 deb packages*. Fortunately, I am able to work on my projects with the 3.6.4.1 at the very moment.I decided to switch to Kubuntu long time ago and now I got used to it. Thank you in advance. Kind Regards, Arturo ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Installing GNU Radio: Use binaries!
Il 19/04/13 11:21, Martin Braun (CEL) ha scritto: Hi all, one point of yesterday's developer's call was the available binaries. A while back, installing GNU Radio meant installing it from source. Anything else wasn't really an option, which is why Marcus wrote build-gnuradio to make that as painless as possible. Things have changed! I would like to point out the fantastic work that has been done by Maitland, who makes our Debian (and therefore Ubuntu) packages, as well as the guys from Ettus, who host binaries for Ubuntu, Fedora and Windows. Nowadays, you don't need to install from source. In fact, if you're new to all of this, we recommend you don't. If you install from binaries, you have a GNU Radio version that's just fine. There's only one caveat: On some systems, the distributed packages might be a bit too old. If it's older than 3.6.0, installing by hand is better. Of course, if you're a developer and need the latest and greatest features, you can still use our git or tarballs. But if you're just trying it all out, just make your own life easier by using the binaries. Hopefully we can get rid of the myth that GNU Radio is hard to install! MB ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio Hi Martin, sorry to bother you. I was wondering if there is a way to build the deb from the source tarball. I made some time an attemp with the following commands : $ mkdir build $ cd build $ cmake -DCPACK_GENERATOR=deb ../ $ make package and i almost was successful in doing that, however i had some issues with the control version and the correct naming of the file. I am asking this because binaries for ubuntu 13.04 are not still available and i'd like to build one on my own.are these ones I've listed all the correct steps to perform to build a binary file of gnuradio or not ? Thank you in advance Kind Regards, Arturo ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Issues estimating the BER of a 16-QAM modulation (and of M-QAM of course)
Il 06/04/13 15:33, Tom Rondeau ha scritto:
On Fri, Apr 5, 2013 at 1:41 PM, Arturo Rinaldi arty.n...@gmail.com wrote:
Hi folks, i have bumped into an error while updating my thesis research to
the latest version of gnuradio.
It is a simple tool to estimate the BER of the digital modulation. I had to
change some lines of code due to the
fact that now the block constellation_decoder_cb accepts as input a
constellation object and not a complex
point tuple (i.e. [1+1j,1-1j,-1-1j,-1+1j] and so on) so i modified my code
in the following way (only the
deconding part). By asking to the gnuradio mailing list i got the following
advice :
rot = (3.0/2.0)*sqrt((8.0/5.0)*bit_energy)
rotated_const = map(lambda pt: pt * rot,
qam.make_nondifferential_constellation(16,gray_coded=True)
constell = digital.constellation_calcdist(rotated_const,[],1,1).base() #
(1) to get the base points and constellation object
self.slicer = digital.constellation_decoder_cb(constell)
# if self._gray_code:
# self.symbol_mapper = gr.map_bb(qam.gray_to_binary[arity])
# else:
# self.symbol_mapper = gr.map_bb(qam.ungray_to_binary[arity])
# unpack the k bit vector into a stream of bits
self.unpack = gr.unpack_k_bits_bb(self.bits_per_symbol()) # (2)
self.connect(self,self.slicer, self.unpack,self)
which works fine for M-PSK modulation but since QAM is a mix of both phase
and amplitude modulation i can't
recover the exact position of the constellation points. I think the error
stays in a wrong calculation of the
euclidean distance. Any suggestions ? i really need help or otherwise the
functionality of my tool will be
dramatically reduced ! ! !
Thanks in advance,
Arturo
P.S. : The modulator block is shaped in the old way, by just only passing
as parameter the constellation
points to the block
self.chunks2symbols = gr.chunks_to_symbols_bc(rotated_const)
I also use (2) because of my way to compare original bit by decoded bit and
then calculating the BER. However
the main issue is the wrong decoding of the constellation points by (1)
Arturo,
Take a look at the constellation_decoder. This uses the constellation
objects and handles the symbol slicing for you. The slicers are
defined in constellation.{cc,h}, and if you come up with a
smarter/cheaper way of slicing, you can add it here. I think this
might help simplify things for you.
Tom
I still can't figure out which is the correct slicer to use. I can't use
*digital.constellation_calcdist* because it works only constellations
with a small number of points (and for M-PSK is fine). I usually build
the qam-16 constellation with the old source code of gnuradio (the 3.3.0
one, I really prefer it..) and when using
*digital.**constellation_rect**().points()* as slicer i get different
different points decoded instead of the ones i originally sent, this is
the code :
/arity = 16//
//
//rot = (3.0/2.0)*sqrt((8.0/5.0)*1.0)// # base point distance. See
Simon Haykin - Communication Sytems
//
//side = int(sqrt(arity))//
//width = 2.0/(side-1)//
//#//
//#//
//#//
//rotated_const = map(lambda pt: pt * rot, qam.constellation[arity])//
# from 3.3.0 qam.py source
//#//
//decoded_points =
digital.constellation_rect(rotated_const,[],4,side,side,width,width).points()//
//#//
//print ORIGINAL POINTS\n//
//print rotated_const//
//print //
//print DECODED POINTS\n//
//print decoded_points/
returning :
/ORIGINAL POINTS//
//
//[(-0.6324555320336758-0.6324555320336758j),
(-0.6324555320336758-1.8973665961010275j),
(-1.8973665961010275-0.6324555320336758j),
(-1.8973665961010275-1.8973665961010275j),
(-0.6324555320336758+0.6324555320336758j),
(-0.6324555320336758+1.8973665961010275j),
(-1.8973665961010275+0.6324555320336758j),
(-1.8973665961010275+1.8973665961010275j),
(0.6324555320336758-0.6324555320336758j),
(0.6324555320336758-1.8973665961010275j),
(1.8973665961010275-0.6324555320336758j),
(1.8973665961010275-1.8973665961010275j),
(0.6324555320336758+0.6324555320336758j),
(0.6324555320336758+1.8973665961010275j),
(1.8973665961010275+0.6324555320336758j),
(1.8973665961010275+1.8973665961010275j)]//
//DECODED POINTS//
//
//((-0.33385056257247925-0.33385056257247925j),
(-0.33385056257247925-1.0015517473220825j),
(-1.0015517473220825-0.33385056257247925j),
(-1.0015517473220825-1.0015517473220825j),
(-0.33385056257247925+0.33385056257247925j),
(-0.33385056257247925+1.0015517473220825j),
(-1.0015517473220825+0.33385056257247925j),
(-1.0015517473220825+1.0015517473220825j),
(0.33385056257247925-0.33385056257247925j),
(0.33385056257247925-1.0015517473220825j),
(1.0015517473220825-0.33385056257247925j),
(1.0015517473220825-1.0015517473220825j),
(0.33385056257247925+0.33385056257247925j),
(0.33385056257247925+1.0015517473220825j),
(1.0015517473220825+0.33385056257247925j),
(1.0015517473220825+1.0015517473220825j))/
This issue, generally speaking, also breaks the compatibility with my
ASK-based modulation code
Re: [Discuss-gnuradio] Issues estimating the BER of a 16-QAM modulation (and of M-QAM of course)
Il 10/04/13 00:45, Ben Reynwar ha scritto:
Hi Arturo,
The constellation object scales the provided constellation points so
that the average magnitude of the points is 1.0. This is causing the
difference between the two sets of points that you noticed.
To avoid the abstract class error, use
digital.digital_constellation(rotated_const.base(), [], 1, 1), where
the base method is casting the object to the base constellation
class.
Ben
On Tue, Apr 9, 2013 at 3:19 PM, Arturo Rinaldi arty.n...@gmail.com wrote:
Il 06/04/13 15:33, Tom Rondeau ha scritto:
On Fri, Apr 5, 2013 at 1:41 PM, Arturo Rinaldi arty.n...@gmail.com wrote:
Hi folks, i have bumped into an error while updating my thesis research to
the latest version of gnuradio.
It is a simple tool to estimate the BER of the digital modulation. I had to
change some lines of code due to the
fact that now the block constellation_decoder_cb accepts as input a
constellation object and not a complex
point tuple (i.e. [1+1j,1-1j,-1-1j,-1+1j] and so on) so i modified my code
in the following way (only the
deconding part). By asking to the gnuradio mailing list i got the following
advice :
rot = (3.0/2.0)*sqrt((8.0/5.0)*bit_energy)
rotated_const = map(lambda pt: pt * rot,
qam.make_nondifferential_constellation(16,gray_coded=True)
constell = digital.constellation_calcdist(rotated_const,[],1,1).base() #
(1) to get the base points and constellation object
self.slicer = digital.constellation_decoder_cb(constell)
# if self._gray_code:
# self.symbol_mapper = gr.map_bb(qam.gray_to_binary[arity])
# else:
# self.symbol_mapper = gr.map_bb(qam.ungray_to_binary[arity])
# unpack the k bit vector into a stream of bits
self.unpack = gr.unpack_k_bits_bb(self.bits_per_symbol()) # (2)
self.connect(self,self.slicer, self.unpack,self)
which works fine for M-PSK modulation but since QAM is a mix of both phase
and amplitude modulation i can't
recover the exact position of the constellation points. I think the error
stays in a wrong calculation of the
euclidean distance. Any suggestions ? i really need help or otherwise the
functionality of my tool will be
dramatically reduced ! ! !
Thanks in advance,
Arturo
P.S. : The modulator block is shaped in the old way, by just only passing
as parameter the constellation
points to the block
self.chunks2symbols = gr.chunks_to_symbols_bc(rotated_const)
I also use (2) because of my way to compare original bit by decoded bit and
then calculating the BER. However
the main issue is the wrong decoding of the constellation points by (1)
Arturo,
Take a look at the constellation_decoder. This uses the constellation
objects and handles the symbol slicing for you. The slicers are
defined in constellation.{cc,h}, and if you come up with a
smarter/cheaper way of slicing, you can add it here. I think this
might help simplify things for you.
Tom
I still can't figure out which is the correct slicer to use. I can't use
digital.constellation_calcdist because it works only constellations with a
small number of points (and for M-PSK is fine). I usually build the qam-16
constellation with the old source code of gnuradio (the 3.3.0 one, I really
prefer it..) and when using digital.constellation_rect().points() as
slicer i get different different points decoded instead of the ones i
originally sent, this is the code :
arity = 16
rot = (3.0/2.0)*sqrt((8.0/5.0)*1.0) # base point distance. See Simon
Haykin - Communication Sytems
side = int(sqrt(arity))
width = 2.0/(side-1)
#
#
#
rotated_const = map(lambda pt: pt * rot, qam.constellation[arity]) # from
3.3.0 qam.py source
#
decoded_points =
digital.constellation_rect(rotated_const,[],4,side,side,width,width).points()
#
print ORIGINAL POINTS\n
print rotated_const
print
print DECODED POINTS\n
print decoded_points
returning :
ORIGINAL POINTS
[(-0.6324555320336758-0.6324555320336758j),
(-0.6324555320336758-1.8973665961010275j),
(-1.8973665961010275-0.6324555320336758j),
(-1.8973665961010275-1.8973665961010275j),
(-0.6324555320336758+0.6324555320336758j),
(-0.6324555320336758+1.8973665961010275j),
(-1.8973665961010275+0.6324555320336758j),
(-1.8973665961010275+1.8973665961010275j),
(0.6324555320336758-0.6324555320336758j),
(0.6324555320336758-1.8973665961010275j),
(1.8973665961010275-0.6324555320336758j),
(1.8973665961010275-1.8973665961010275j),
(0.6324555320336758+0.6324555320336758j),
(0.6324555320336758+1.8973665961010275j),
(1.8973665961010275+0.6324555320336758j),
(1.8973665961010275+1.8973665961010275j)]
DECODED POINTS
((-0.33385056257247925-0.33385056257247925j),
(-0.33385056257247925-1.0015517473220825j),
(-1.0015517473220825-0.33385056257247925j),
(-1.0015517473220825-1.0015517473220825j),
(-0.33385056257247925+0.33385056257247925j),
(-0.33385056257247925+1.0015517473220825j),
(-1.0015517473220825+0.33385056257247925j),
(-1.0015517473220825+1.0015517473220825j),
(0.33385056257247925-0.33385056257247925j),
(0.33385056257247925
[Discuss-gnuradio] Issues estimating the BER of a 16-QAM modulation (and of M-QAM of course)
Hi folks, i have bumped into an error while updating my thesis research to the latest version of gnuradio. It is a simple tool to estimate the BER of the digital modulation. I had to change some lines of code due to the fact that now the block constellation_decoder_cb accepts as input a constellation object and not a complex point tuple (i.e. [1+1j,1-1j,-1-1j,-1+1j] and so on) so i modified my code in the following way (only the deconding part). By asking to the gnuradio mailing list i got the following advice : *rot = (3.0/2.0)*sqrt((8.0/5.0)*bit_energy)** ** **rotated_const = map(lambda pt: pt * rot, qam.make_nondifferential_constellation(16,gray_coded=True)** **constell = digital.constellation_calcdist(rotated_const,[],1,1).base() # (1) to get the base points and constellation object** **self.slicer = digital.constellation_decoder_cb(constell)** ** **# if self._gray_code:** **# self.symbol_mapper = gr.map_bb(qam.gray_to_binary[arity])** **# else:** **# self.symbol_mapper = gr.map_bb(qam.ungray_to_binary[arity])** ** ** **# unpack the k bit vector into a stream of bits** ** **self.unpack = gr.unpack_k_bits_bb(self.bits_per_symbol()) # (2)** ** **self.connect(self,self.slicer, self.unpack,self)* which works fine for M-PSK modulation but since QAM is a mix of both phase and amplitude modulation i can't recover the exact position of the constellation points. I think the error stays in a wrong calculation of the euclidean distance. Any suggestions ? i really need help or otherwise the functionality of my tool will be dramatically reduced ! ! ! Thanks in advance, Arturo P.S. : The modulator block is shaped in the old way, by just only passing as parameter the constellation points to the block *self.chunks2symbols = gr.chunks_to_symbols_bc(rotated_const)* I also use (2) because of my way to compare original bit by decoded bit and then calculating the BER. However the main issue is the wrong decoding of the constellation points by (1) ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] GNU Radio releases 3.6.3.1 and 3.6.4 available for download
Il 26/02/13 23:59, Johnathan Corgan ha scritto: GNU Radio releases 3.6.3.1 and 3.6.4 are now available for download. Release 3.6.3.1 is a bug-fix only update to 3.6.3, and has no new features. Release 3.6.4 has both bug fixes and new features. http://gnuradio.org/releases/gnuradio/gnuradio-3.6.3.1.tar.gz http://gnuradio.org/releases/gnuradio/gnuradio-3.6.4.tar.gz MD5 sums: c05a20a380532b7bce45465ba247f2d6 gnuradio-3.6.3.1.tar.gz 320a7f18593ec493e1061141f23c9a86 gnuradio-3.6.4.tar.gz Enjoy! Johnathan Corgan Corgan Labs Contributors: Balint Seeber balint.see...@ettus.com mailto:balint.see...@ettus.com Ben Reynwar b...@reynwar.net mailto:b...@reynwar.net Johnathan Corgan johnat...@corganlabs.com mailto:johnat...@corganlabs.com Josh Blum j...@ettus.com mailto:j...@ettus.com Julien Olivain julien.oliv...@lacime.etsmtl.ca mailto:julien.oliv...@lacime.etsmtl.ca Martin Braun martin.br...@kit.edu mailto:martin.br...@kit.edu Mike Jameson mikej...@gmail.com mailto:mikej...@gmail.com Nicholas Corgan nick.cor...@ettus.com mailto:nick.cor...@ettus.com Roy Thompson rthom...@gmail.com mailto:rthom...@gmail.com Sylvain Munaut 246...@gmail.com mailto:246...@gmail.com Tim O'Shea tim.oshea...@gmail.com mailto:tim.oshea...@gmail.com Tom Rondeau t...@trondeau.com mailto:t...@trondeau.com Important new features (3.6.4): Ability to set processor affinity for GNU Radio blocks Tom Rondeau has implemented the ability to set processor affinity per block in a flowgraph. This allows the developer to limit the execution of a GNU Radio block thread to a set of one or more cores, helping optimize inter-core resources in a multicore system. See: http://www.trondeau.com/home/2013/2/7/block-core-affinity.html Inclusion of gr_modtool by Martin Braun Previously available as a stand-alone utility, the gr_modtool application for creating out-of-tree GNU Radio blocks has been integrated within the main GNU Radio software distribution. The features and functionality are the same, but it is now no longer necessary to download this separately. See: http://gnuradio.org/redmine/projects/gnuradio/wiki/OutOfTreeModules Use of GNU Radio preferences in native C++ applications Tom Rondeau has ported the GNU Radio preferences system to allow its use in GNU Radio applications implemented in C++. Prior to this, it was only possible to access the preferences file from Python. Until the new manual is updated on gnuradio.org http://gnuradio.org, you can see the raw commit here: http://gnuradio.org/cgit/gnuradio.git/commit/?id=3643a858 Addition of GNU Radio block performance counters Tom Rondeau has implemented a new capability to allow monitoring of peformance statistics of blocks inside a running flowgraph. This is an experimental feature that has not received a great deal of usage. For more details, see: http://gnuradio.org/redmine/projects/gnuradio/wiki/PerformanceCounters Minor features/changes (3.6.4): atsc: added single decode Python script (Ben Reynwar) atsc: made equalizer taps accessible in python. (Ben Reynwar) blocks: added 3.7 API versions of count_bits, threshold, strech, throttle (Tom Rondeau) blocks: added 3.7 API versions of peak_detector2, regenerate, transcendental (Tom Rondeau) cmake: added Fedora 18 packaging information (Nicholas Corgan) cmake: allow 64-bit systems to use Boost in non-standard locations (Nicholas Corgan) core: added min_noutput_items to gr_block API (Ben Reynwar) core: added operator == for tags (Martin Braun) core: added remove_tag_item() (Martin Braun) core: enabled msg_connect within python blocks (Roy Thompson) core: added gr_random_pdu message passing block (Tim O'Shea) core: added gr_fastnoise_source, default for gr_channel_model (Tim O'Shea) core: added GRC callback for gr_throttle sample_rate (Tim O'Shea) core: added a mutex to gr_block to sync setters and work function (Tom Rondeau) digital: improved constellation_receiver_cv documentation (Ben Reynwar) digital: made the demod examples clearer (Martin Braun) digital: added simple_correlator (inverse of simple_framer) to gr-digital. gruel: changed scoped_lock mutex to account for Boost deprecation (Johnathan Corgan) grc: pull in documentation for blocks from other GR modules. (Julien Olivain) howto: added example for Python blocks (Martin Braun) pmt: added python converters (Martin Braun) uhd: added click to change freq for uhd_fft (Mike Jameson) wxgui: dead code removal and formatting cleanup (Sylvain Munaut) wxgui: implemented persistence without using glAccum (Sylvain Munaut) Bug fixes (3.6.3.1, 3.6.4): analog: fixed floating point
[Discuss-gnuradio] can't build on a fresh installation of Ubuntu 12.10
Here we go again.after a fresh installation of *kubuntu 12.10 x64* on my brand new laptop, i get a build error at the 94% of the entire process both of the stable tarball and of the git version. The permormed steps are always the same : + satisfy the required dependencies with the build-gnuradio script then : + mkdir build | cmake ../ | make -j5 and i get an error about the TRELLIS section. My first choice was obviously to install the pre-compiled x64 binary but since i also need Skype and Wine on my laptop the gnuradio deb conflicts with the ia32-libsfrom here my need to build from source and make a deb package within cmake itself. any suggesions about it ? thank you in advance as always Kind Regards, Arturo ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] GNU Radio Using MacPorts
Nella citazione in data Thu Nov 29 02:24:03 2012, Michael Dickens ha scritto: Hi Arturo - Can you load up the GRC example provided by GR: gnuradio/examples/grc/simple/variable_config.grc ? This file works just fine for me, no GL issues or anything, and it looks about the same as your figure (or, maybe I'm doing something wrong?). I'm running from the latest GIT master (as installed by MacPorts gnuradio-devel +full; just updated this morning!). If this gives you the same error, then either email me off-list and we can work on resolving it; or, create a ticket in MacPorts and assign me as the owner and I'll work with you there. - MLD On Nov 26, 2012, at 8:57 PM, Arturo Rinaldi arty.n...@gmail.com wrote: Ok let's do just a simple flow graph. Here's the screenshot : http://img594.imageshack.us/img594/5670/testnz.png I'm trying to display a simple cosine waveform in a WXGUI Scopesink. This is the error I get when I run the flow graph : Traceback (most recent call last): File /opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/gnuradio/wxgui/plotter/plotter_base.py, line 187, in _on_paint for fcn in self._draw_fcns: fcn[1]() File /opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/gnuradio/wxgui/plotter/plotter_base.py, line 58, in draw GL.glNewList(self._grid_compiled_list_id, GL.GL_COMPILE) ctypes.ArgumentError: argument 1: type 'exceptions.TypeError': wrong type I get the controls part but not the plotting part of the sink : http://img842.imageshack.us/img842/2728/test2xm.png No issues apparently with QT SINKS. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio I need some details about your configuration. Mine is the following : iMac 21 with MacOs X Lion 10.7.5 and MacPorts 2.1.2 i was wondering if this issue is due to the fact that i can only install wxWidgets-devel an wxpython-devel, the 2.9.4.0 version, since Macports itself is unable to build the 2.8.12 version on Lion 10.7 and Xcode 4.4 by default..any ideas about it ?. I'll keep you updated as soon as i perform some tests on my setup. Regards, Arturo ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] GNU Radio Using MacPorts
Nella citazione in data Thu Nov 29 23:31:58 2012, Arturo Rinaldi ha scritto: Nella citazione in data Thu Nov 29 02:24:03 2012, Michael Dickens ha scritto: Hi Arturo - Can you load up the GRC example provided by GR: gnuradio/examples/grc/simple/variable_config.grc ? This file works just fine for me, no GL issues or anything, and it looks about the same as your figure (or, maybe I'm doing something wrong?). I'm running from the latest GIT master (as installed by MacPorts gnuradio-devel +full; just updated this morning!). If this gives you the same error, then either email me off-list and we can work on resolving it; or, create a ticket in MacPorts and assign me as the owner and I'll work with you there. - MLD On Nov 26, 2012, at 8:57 PM, Arturo Rinaldi arty.n...@gmail.com wrote: Ok let's do just a simple flow graph. Here's the screenshot : http://img594.imageshack.us/img594/5670/testnz.png I'm trying to display a simple cosine waveform in a WXGUI Scopesink. This is the error I get when I run the flow graph : Traceback (most recent call last): File /opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/gnuradio/wxgui/plotter/plotter_base.py, line 187, in _on_paint for fcn in self._draw_fcns: fcn[1]() File /opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/gnuradio/wxgui/plotter/plotter_base.py, line 58, in draw GL.glNewList(self._grid_compiled_list_id, GL.GL_COMPILE) ctypes.ArgumentError: argument 1: type 'exceptions.TypeError': wrong type I get the controls part but not the plotting part of the sink : http://img842.imageshack.us/img842/2728/test2xm.png No issues apparently with QT SINKS. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio I need some details about your configuration. Mine is the following : iMac 21 with MacOs X Lion 10.7.5 and MacPorts 2.1.2 i was wondering if this issue is due to the fact that i can only install wxWidgets-devel an wxpython-devel, the 2.9.4.0 version, since Macports itself is unable to build the 2.8.12 version on Lion 10.7 and Xcode 4.4 by default..any ideas about it ?. I'll keep you updated as soon as i perform some tests on my setup. Regards, Arturo I am currently testing two installations : sudo port install gnuradio +full +python27 configure.compiler=llvm-gcc-4.2 -v and sudo port install gnuradio-devel +full +python27 configure.compiler=llvm-gcc-4.2 -v you're totally right about variable_config.grc, it's pretty much the same flow graph as mine Arturo ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] WX Gui Scope Sink, odd appearance in Windows vs. Ubuntu
Nella citazione in data Tue Nov 27 16:35:52 2012, Seth Hollar ha scritto: Hi Arturo, I did two things: 1) I changed the config file located in c:\users\USERNAME\config.conf per your suggestion 2) I installed PyOpenGL When I ran BER Simulation, I got a couple of errors dealing with the GUI: Traceback (most recent call last): File C:\gnuradio\install\lib\site-packages\gnuradio\wxgui\forms\forms.py, line 100, in lambda widget.Bind(EVT_DATA, lambda x: self._update(x.data)) File C:\gnuradio\install\lib\site-packages\gnuradio\wxgui\forms\forms.py, line 503, in _update def _update(self, i): self._notebook.SetSelection(i, 0) File C:\Python27\lib\site-packages\wx-2.8-msw-unicode\wx\_controls.py, line 3021, in SetSelection return _controls_.BookCtrlBase_SetSelection(*args, **kwargs) TypeError: BookCtrlBase_SetSelection() takes at most 2 arguments (3 given) As best as I can tell, the function for the widget, SetSelection, cannot handle receiving a -1. I'm guessing that what works under some OS's doesn't necessarily work under others with native controls. In the end, I reverted back to not using OpenGL. I, too, would be curious if anyone got the OpenGl version of the Scope working. Thanks for your help. -Seth On 11/26/2012 5:37 PM, Arturo Rinaldi wrote: Nella citazione in data Mon Nov 26 19:02:33 2012, Seth Hollar ha scritto: In looking at the GRC example, BER Simulation, I noticed that the WX Gui Scope Sink window looks very different depending on whether it is Windows or Ubuntu. The Windows version looks a bit odd. I was wondering if anyone else is seeing the same thing, or if it is something that I'm doing wrong. A screen shot of the two side by side can be see here: http://www.sethhollar.com/BERSimulationWindowsVsUbuntu.png Thanks, Seth ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio the windows version is the non-GL version of the Scope Sink. I'm experiencing this issue also on MacOs Xyou can try editing your config.conf file (i don't know where it is on windows based systems. In unix like systems is in the hidden folder gnuradio placed in your HOME : .gnuradio/config.conf - if it doesn't exist you can create it and so override the default settings) and then add the following lines [wxgui] style=gl Please let me know if it works because I'm really interested too. Regards, Arturo If you don't mind, could you list me your installation steps of gnuradio under windows ? Firstly I installed python, then gnuradio, then other libraries such as wxpython qt and so on but i can't set the right PATH in the windows environment variables panel to start gnuradio-companion or import the libraries into python itself. would you be so kind to help me set the PATH so i can work on this issue ? I look forward to hear from you. Regards, Arturo. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] GNU Radio Using MacPorts
Nella citazione in data Fri Nov 23 17:35:38 2012, Michael Dickens ha scritto: On Nov 22, 2012, at 4:00 AM, Ian Buckley i...@ianbuckley.net wrote: I have Xcode4.5 installed so I gave the configure.compiler=apple-gcc-4.2 idea a go. Well, that was my bad: apple-gcc-4.2 is MacPorts' install of GCC 4.2 with Apple modifications. Not generally what you want to be using. Since you're using Xcode 4.5, I'd recommend instead using configure.compiler=llvm-gcc-4.2, which uses /usr/bin/llvm-gcc-4.2. For those folks using older Xcode, I'd recommend using configure.compiler=gcc-4.2 which (IIRC) uses /usr/bin/gcc-4.2. Sorry for the mix-up; I think the MacPorts names for the various compiler suites could use a little work and/or better description, but that's not up to me. - MLD ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio I smoothly installed the port version with sudo port install gnuradio +docs +grc +python27 +qtgui +wxgui +uhd +volk +wavelet +jack +portaudio +swig +sdl configure.compiler=llvm-gcc-4.2 performing a full installation. Now my question is, is there a way to use the GL sinks (scopesink, fftsink and so on) ? Every time i run a flow graph containing one of these elements, i get a OpenGL error and its pyton bindingany hint to solve this issue ? ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] WX Gui Scope Sink, odd appearance in Windows vs. Ubuntu
Nella citazione in data Mon Nov 26 19:02:33 2012, Seth Hollar ha scritto: In looking at the GRC example, BER Simulation, I noticed that the WX Gui Scope Sink window looks very different depending on whether it is Windows or Ubuntu. The Windows version looks a bit odd. I was wondering if anyone else is seeing the same thing, or if it is something that I'm doing wrong. A screen shot of the two side by side can be see here: http://www.sethhollar.com/BERSimulationWindowsVsUbuntu.png Thanks, Seth ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio the windows version is the non-GL version of the Scope Sink. I'm experiencing this issue also on MacOs Xyou can try editing your config.conf file (i don't know where it is on windows based systems. In unix like systems is in the hidden folder gnuradio placed in your HOME : .gnuradio/config.conf - if it doesn't exist you can create it and so override the default settings) and then add the following lines [wxgui] style=gl Please let me know if it works because I'm really interested too. Regards, Arturo ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] GNU Radio Using MacPorts
Nella citazione in data Tue Nov 27 00:36:33 2012, Michael Dickens ha scritto: On Nov 26, 2012, at 5:30 PM, Arturo Rinaldi arty.n...@gmail.com wrote: I smoothly installed the port version with sudo port install gnuradio +docs +grc +python27 +qtgui +wxgui +uhd +volk +wavelet +jack +portaudio +swig +sdl configure.compiler=llvm-gcc-4.2 performing a full installation. Great! Now my question is, is there a way to use the GL sinks (scopesink, fftsink and so on) ? Every time i run a flow graph containing one of these elements, i get a OpenGL error and its pyton bindingany hint to solve this issue ? Can you post the console error message so that we can see what's going on, as well as what you were trying to do when you got the error? - MLD Ok let's do just a simple flow graph. Here's the screenshot : http://img594.imageshack.us/img594/5670/testnz.png I'm trying to display a simple cosine waveform in a WXGUI Scopesink. This is the error I get when I run the flow graph : Traceback (most recent call last): File /opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/gnuradio/wxgui/plotter/plotter_base.py, line 187, in _on_paint for fcn in self._draw_fcns: fcn[1]() File /opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/gnuradio/wxgui/plotter/plotter_base.py, line 58, in draw GL.glNewList(self._grid_compiled_list_id, GL.GL_COMPILE) ctypes.ArgumentError: argument 1: type 'exceptions.TypeError': wrong type I get the controls part but not the plotting part of the sink : http://img842.imageshack.us/img842/2728/test2xm.png No issues apparently with QT SINKS. Regards, Arturo ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] GNU Radio Using MacPorts
Nella citazione in data Tue Nov 20 20:35:14 2012, Michael Dickens ha
scritto:
I just updated the GNU Radio ports in MacPorts to the latest release (3.6.2),
GIT master (commit afea463f07), and GIT Next branch (commit c0b35b4ec7). By
using a single Portfile for all 3 versions, I should be able to maintain the
ports more easily and keep the more up to date as releases and GIT commits
happen.
If you're using OSX, any version though MacPorts targets 10.5 and newer, I
would appreciate your feedback as to whether these ports work for you or not.
Well, OK, the Next port won't yet due to some issue with Boost and the real
time clock; but, this is known to GR developers and they're working on it
(right?). The other ports should work, with GCC or Clang as you like.
Along the way, I came upon 3 issues:
1) Clang and ASM don't play nice with .version commands. Tom has already
addressed this in a patch, but it's not yet in the GIT master or next branch. I am using
that patch in my port until it is no longer necessary.
2) If GNU Radio is already installed (e.g., by MacPorts), then gruel/*.h will be picked
up as dependencies from the already-installed files rather than from the current build. I work
around this (at least partially) by modifying the CMake build.make dependencies to
be the correct files (those in the current build). I've looked at the build debug output, and
it seems OK -- so, I'm thinking this is more of a CMake internal issue (in the way it
determines dependencies) rather than a GNU Radio CMake build script issue (in the ordering of
dependency directories). But, maybe not? Anyway, thought folks might want to know. I know
I've encountered this issue before; it requires that one uninstall GNU Radio, re-do the CMake
command, and then the build works.
3) Python scripts are installed into ${prefix}/lib/pythonX.Y/site-packages .
Always. And I cannot change this setting to the best of my reading. I use a
post-destroot hook that moves the whole site-packages directory into the
appropriate Python MacPorts framework directory. It would be good to be able
to control where these files are placed via some CMake command-line option.
Enjoy! - MLD
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
FIRST ERROR on Lion 10.7.5 and MacPorts 2.1.2, can't fetch teh patch
file :
Error: org.macports.fetch for port gnuradio returned: fetch failed
Please see the log file for port gnuradio for details:
/opt/local/var/macports/logs/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_science_gnuradio/gnuradio/main.log
To report a bug, follow the instructions in the guide:
http://guide.macports.org/#project.tickets
Error: Processing of port gnuradio failed
any ideas ? do i have to wait some time beacuse of server side issues ?
Thanks in advance, Arturo
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] GNU Radio Using MacPorts
Nella citazione in data Wed Nov 21 01:44:00 2012, Michael Dickens ha scritto: That would be my bad. I just checked in that file, so it will appear when you do a selfupdate within 30 minutes from this email. Things will work a LOT better when that file is available. :) - MLD FIRST ERROR on Lion 10.7.5 and MacPorts 2.1.2, can't fetch teh patch file : Error: org.macports.fetch for port gnuradio returned: fetch failed Please see the log file for port gnuradio for details: /opt/local/var/macports/logs/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_science_gnuradio/gnuradio/main.log To report a bug, follow the instructions in the guide: http://guide.macports.org/#project.tickets Error: Processing of port gnuradio failed any ideas ? do i have to wait some time beacuse of server side issues ? Sorry Michael, you're totally right. I thought it was all ready to install when you sent the email to the mailing list. Apologies again and keep up with the great work :D. Regards, Arturo. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] issue with GRC on ubuntu 12.10 - Segmentation Fault when launching the tool
Nella citazione in data Fri Oct 19 03:47:41 2012, Josh Blum ha scritto: On 10/18/2012 05:49 PM, Arturo Rinaldi wrote: After successfully building gnuradio 3.6.2 on *ubuntu quantal quetzal 12.10* i get this error when launching gnuradio-companion : /* *//*artynet@artynet-VirtualBox:/usr/local/bin$ gnuradio-companion */ /*Traceback (most recent call last):*//* *//* File /usr/local/bin/gnuradio-companion, line 58, in module*//* *//*from gnuradio.grc.python.Platform import Platform*//* *//* File /usr/local/lib/python2.7/dist-packages/gnuradio/grc/python/Platform.py, line 22, in module*//* *//*from .. base.Platform import Platform as _Platform*//* *//* File /usr/local/lib/python2.7/dist-packages/gnuradio/grc/base/Platform.py, line 22, in module*//* *//*from .. base import ParseXML, odict*//* *//* File /usr/local/lib/python2.7/dist-packages/gnuradio/grc/base/ParseXML.py, line 20, in module*//* *//*from lxml import etree*//* *//* File lxml.etree.pyx, line 67, in init lxml.etree (src/lxml/lxml.etree.c:160085)*//* *//* File /usr/lib/python2.7/io.py, line 51, in module*//* *//*import _io*//* *//*TypeError: type '_io._IOBase' participates in gc and is a base type but has inappropriate tp_free slot*//* *//*Segmentation Fault (core dump created) The error seems to be entirely from lxml. So I would guess that this is an lxml issue not gnuradio related. Can you try to run python -c from lxml import etree and see if the error happens? -josh */I satisfied all the required dependencies with the build-gnuradio script by SBRAC. Any ideas to solve this issue, it never happened to me in any build of GNURadio from stable tarball. Do I have to install some other python package ? Thank you in advance Kind Regards Arturo ___ 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 the python importing process (python -c from lxml import etree) exits without any error. I decided to switch to the 3.6.1 version from quantal repos until the problem is solved. I tried to install different versions of lxml from pipy but without any success. Regards, Arturo ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] issue with GRC on ubuntu 12.10 - Segmentation Fault when launching the tool
After successfully building gnuradio 3.6.2 on *ubuntu quantal quetzal 12.10* i get this error when launching gnuradio-companion : /* *//*artynet@artynet-VirtualBox:/usr/local/bin$ gnuradio-companion */ /*Traceback (most recent call last):*//* *//* File /usr/local/bin/gnuradio-companion, line 58, in module*//* *//*from gnuradio.grc.python.Platform import Platform*//* *//* File /usr/local/lib/python2.7/dist-packages/gnuradio/grc/python/Platform.py, line 22, in module*//* *//*from .. base.Platform import Platform as _Platform*//* *//* File /usr/local/lib/python2.7/dist-packages/gnuradio/grc/base/Platform.py, line 22, in module*//* *//*from .. base import ParseXML, odict*//* *//* File /usr/local/lib/python2.7/dist-packages/gnuradio/grc/base/ParseXML.py, line 20, in module*//* *//*from lxml import etree*//* *//* File lxml.etree.pyx, line 67, in init lxml.etree (src/lxml/lxml.etree.c:160085)*//* *//* File /usr/lib/python2.7/io.py, line 51, in module*//* *//*import _io*//* *//*TypeError: type '_io._IOBase' participates in gc and is a base type but has inappropriate tp_free slot*//* *//*Segmentation Fault (core dump created) */I satisfied all the required dependencies with the build-gnuradio script by SBRAC. Any ideas to solve this issue, it never happened to me in any build of GNURadio from stable tarball. Do I have to install some other python package ? Thank you in advance Kind Regards Arturo ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Building on Mac OS X 10.7.4 the latest tarball (3.6.2) - I finally did it but just a pair of issues left.....
I have finally succedeed in building from source the latest gnuradio stable tarball, the 3.6.2. My sistem is the following : Mac OS X 10.7.4 Macports 2.1.2 Xcode 4.4.1 i satisfied the dependencies with : */sudo port install boost cmake icu cppunit fftw-3-single gawk \readline gsl texinfo guile python27 py27-numpy py27-nose \ py27-distribute /**/libsndfile portaudio py27-opengl py27-opengl-accelerate py27-pil lcms py27-tkinter \/**/ /**/py27-wxpython-devel mesa makedepend xorg-dri2proto xorg-glproto xorg-libXmu \/**/ /**/py27-cheetah py27-gtk libglade2 py27-cairo py27-py py27-gobject py27-lxml doxygen \/**/ /**/libusb-legacy sdcc29 gputils py27-pyqt4 py27-sip py27-pyqwt qt4-mac dbus libmng qt4-mac qwtplot3d qwt52 libsdl/* and then i build from source with : /cmake LDFLAGS=-L/opt/local/lib CPPFLAGS=-I/opt/local/include ..// the configuration steps validates all the gnuradio modules except for *uhd*, *comedi* and *shd* but at the moment i am not interested in working with them so it's fine for me. After building and installing i set this two paths in my /.profile/ settings file : */export PYTHONPATH=/usr/local/lib/python2.7/site-packages:$PYTHONPATH/**/ /**/ /**/export DYLD_LIBRARY_PATH=/usr/local/lib/python2.7/site-packages/:$DYLD_LIBRARY_PATH/* when i try to start /gnuradio-companion/ or even import the /gnuradio/ package in my IDE i get this error (Python crashes :P): */Fatal Python error: Interpreter not initialized (version mismatch?)/**/ /**/Abort trap: 6/* i'm obviusly working with the python27 installed by macports (i.e. the 2.7.3 version) and set with the shell command : /sudo port select python python27/ any suggestion to solve the problem and finally working with gnuradio on a native OS system ? Kind Regards, Arturo ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] wxGUIs and threads
I can't solve a little issue with wxgui and threads. Before the explanation i link my pastebin code : (1) http://pastebin.com/sqbKTJG7 (2) http://pastebin.com/TemTW7cZ the first link is the code to a simple gui with one c*ombobox* and three *textboxes*. My goal is to collect this data in a buffer and then pass it with a thread to a flow graph with gui object (i.e. line 149 of code (1)). So an instance of that object is called (code (2)) and a flow graph for the real time estimation of BER is called and run as well. I however experience an error which I reported on Daniweb : http://www.daniweb.com/software-development/python/threads/417510/calling-threads-between-wxgtkguis the called object (i.e. *ber_rician_bpsk* ) is a *stdgui2.std_top_block* object and *stdframe4* (code (1)) is a lightly modified version of *stdgui2.stdframe* by me to accept more parameters. is someone able to help me ? Regards, Arturo ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] GR 3.5.1 OSX
Nella citazione in data Thu Mar 22 23:43:29 2012, Arturo Rinaldi ha scritto: Nella citazione in data Thu Mar 22 15:17:03 2012, Michael Dickens ha scritto: On Mar 22, 2012, at 9:55 AM, Arturo Rinaldi wrote: I think i've sorted out the dependencies for building gnuradio on Lion 10.7.3 sudo port install boost icu cppunit fftw-3-single gawk \ readline gsl texinfo guile python27 py27-numpy py27-nose py27-distribute \ libsndfile portaudio py27-opengl py27-opengl-accelerate py27-pil lcms py27-tkinter \ py27-wxpython wxWidgets mesa makedepend xorg-dri2proto xorg-glproto xorg-libXmu \ py27-cheetah py27-gtk libglade2 py27-cairo py27-py py27-gobject py27-lxml doxygen \ libusb-legacy sdcc29 gputils py27-pyqt4 py27-sip py27-pyqwt qt4-mac dbus libmng qt4-mac qwtplot3d qwt52 libsdl Yeah; I'd believe that. Nothing like a few background dependencies as added by MacPorts to those top-level ones. I tried creating a stand-alone .app for GRC, and it turned out to be something like 600 MB when all of these dependencies were included. Many of them are spurious -- not directly relevant -- but include as options or whatever. MP folks have had a discussion about this issue recently, since it's a real problem. However : First py27-wxpython doesn't install on macports. I'll post it on the macports mailing list then we aren't able to use the wxgui module There's are a few discussions about py27-wxpython on various MP lists right now. Seems like maybe you're not alone. Please do search for a ticket for: https://trac.macports.org/search. I have no issue with this port on 10.6.8, and it works correctly with 64-bit Wx! Second by using autotools with ./configure LDFLAGS=-L/opt/local/lib CPPFLAGS=-I/opt/local/include CC=clang --disable-gr-qtgui --disable-docs builds the latest tarball (3.5.2.1) and i need some help for the DYLD_LIBRARY_PATH because gnuradio-companion start with an error message though PYTHONPATH is correctly set You should be able to compile GR without LDFLAGS or CPPFLAGS, if you've set the PKG_CONFIG_PATH to include /opt/local/lib/pkgconfig. You'll probably want to set CXX to clang++ (or, whatever that is called) along with CC; I don't think CC is actually used, but it can't hurt to set it. Once installed, you should be able to execute GR scripts and GRC without resorting to the DYLD_LIBRARY_PATH -- the PATH and PYTHONPATH should be sufficient. Third downloaded the git version and after the usual steps with cmake, the building crashes at the 3% with the error cc1: error: unrecognized command line option -mpopcnt make[2]: *** [volk/lib/CMakeFiles/volk.dir/volk_machine_sse4_a_64.c.o] Error 1 make[1]: *** [volk/lib/CMakeFiles/volk.dir/all] Error 2 make: *** [all] Error 2 No idea, but using CMake is the way to go to get Volk working. Could be an OSX 10.7 issue; I'm still using 10.6 though I do do testing using an OSX 10.7 boot disk. I haven't tried this in a while, so I'll give it a whirl later today or tomorrow, as time allows. Good luck! - MLD ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio ok i'll do other experiments and report news.thx very much :D downloaded the latest git version and made a little progress in the third case. I set : export CXX=clang++ export CC=clang and the cmake building worked ! ! !. Now i have to set the python path correctly. GRC still doesn't run but the python interpreter import the gnuradio module correctly. i removed the documentantion from building because it seems to stuck at a certain point, and cpu(s) load is at full ! ! ! The py27-wxpython issue still remains, i'll post a ticket on macports Regards, Arturo ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] GR 3.5.1 OSX
Il 04/03/12 00:18, Carles Fernandez ha scritto: Hi guys, On OSX 10.6.8 I did the following: $ git clone git://code.ettus.com/ettus/uhd.git $ cd uhd $ mkdir build $ cd build $ cmake ../ $ make $ sudo make install $ cd.. $ git clone git://gnuradio.org/gnuradio $ cd gnuradio $ mkdir build $ cd build cmake ../ ... -- ## -- # Gnuradio enabled components -- ## -- * python-support -- * testing-support -- * volk -- * doxygen -- * gruel -- * gnuradio-core -- * gr-atsc -- * gr-audio -- * gr-digital -- * gr-noaa -- * gr-pager -- * gr-qtgui -- * gr-trellis -- * gr-uhd -- * gr-utils -- * gr-video-sdl -- * gr-vocoder -- -- ## -- # Gnuradio disabled components -- ## -- * gnuradio-companion -- * gr-comedi -- * gr-shd -- * gr-wxgui -- -- Using install prefix: /usr/local -- Building for version: v3.5.1-196-g4f0add17 / 3.5.2git -- Configuring done -- Generating done ... $ make $ sudo make install It seems that worked! :-) Best regards, Carles On Fri, Mar 2, 2012 at 3:45 PM, Michael Dickensm...@alum.mit.edu wrote: On Mar 2, 2012, at 9:39 AM, Arturo Rinaldi wrote: can i build the master git branch on macos X 10.7.3 with cmake ? have i to satisfy the build pre-requisites with macports as usual ? Hi Arturo - I believe that if you use MacPorts to install the background dependencies -- just do sudo port install gnuradio, and then, hours later, you can remove the installed GNU Radio / usrp ports, if any actually got installed. You'll need to install CMake too, since the current GR ports still use GNU Autotools. You should then be able to use CMake to build GNU Radio from the GIT master on OSX 10.7.3. I'm still using 10.6.8, but I know others who've used 10.7 and had success. Getting the dependencies to install is the tricky part, as always :) Give it a whirl, good luck, and please do let me/the list know if you have issues. - 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 I think i've sorted out the dependencies for building gnuradio on Lion 10.7.3 /sudo port install boost icu cppunit fftw-3-single gawk \ readline gsl texinfo guile python27 py27-numpy py27-nose py27-distribute \ libsndfile portaudio py27-opengl py27-opengl-accelerate py27-pil lcms py27-tkinter \ py27-wxpython wxWidgets mesa makedepend xorg-dri2proto xorg-glproto xorg-libXmu \ py27-cheetah py27-gtk libglade2 py27-cairo py27-py py27-gobject py27-lxml doxygen \ libusb-legacy sdcc29 gputils py27-pyqt4 py27-sip py27-pyqwt qt4-mac dbus libmng qt4-mac qwtplot3d qwt52 libsdl/ However : *First * /py27-wxpython/ doesn't install on macports. I'll post it on the macports mailing list then we aren't able to use the wxgui module *Second* by using autotools with / ./configure LDFLAGS=-L/opt/local/lib CPPFLAGS=-I/opt/local/include CC=clang --disable-gr-qtgui --disable-docs/ builds the latest tarball (3.5.2.1) and i need some help for the *DYLD_LIBRARY_PATH* because gnuradio-companion start with an error message though *PYTHONPATH* is correctly set *Third* downloaded the git version and after the usual steps with cmake, the building crashes at the 3% with the error /cc1: error: unrecognized command line option -mpopcnt make[2]: *** [volk/lib/CMakeFiles/volk.dir/volk_machine_sse4_a_64.c.o] Error 1 make[1]: *** [volk/lib/CMakeFiles/volk.dir/all] Error 2 make: *** [all] Error 2/ any suggest for all the three scenarios ? Best Regards, Arturo Rinaldi ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] GR 3.5.1 OSX
Nella citazione in data Thu Mar 22 15:17:03 2012, Michael Dickens ha scritto: On Mar 22, 2012, at 9:55 AM, Arturo Rinaldi wrote: I think i've sorted out the dependencies for building gnuradio on Lion 10.7.3 sudo port install boost icu cppunit fftw-3-single gawk \ readline gsl texinfo guile python27 py27-numpy py27-nose py27-distribute \ libsndfile portaudio py27-opengl py27-opengl-accelerate py27-pil lcms py27-tkinter \ py27-wxpython wxWidgets mesa makedepend xorg-dri2proto xorg-glproto xorg-libXmu \ py27-cheetah py27-gtk libglade2 py27-cairo py27-py py27-gobject py27-lxml doxygen \ libusb-legacy sdcc29 gputils py27-pyqt4 py27-sip py27-pyqwt qt4-mac dbus libmng qt4-mac qwtplot3d qwt52 libsdl Yeah; I'd believe that. Nothing like a few background dependencies as added by MacPorts to those top-level ones. I tried creating a stand-alone .app for GRC, and it turned out to be something like 600 MB when all of these dependencies were included. Many of them are spurious -- not directly relevant -- but include as options or whatever. MP folks have had a discussion about this issue recently, since it's a real problem. However : First py27-wxpython doesn't install on macports. I'll post it on the macports mailing list then we aren't able to use the wxgui module There's are a few discussions about py27-wxpython on various MP lists right now. Seems like maybe you're not alone. Please do search for a ticket for: https://trac.macports.org/search. I have no issue with this port on 10.6.8, and it works correctly with 64-bit Wx! Second by using autotools with ./configure LDFLAGS=-L/opt/local/lib CPPFLAGS=-I/opt/local/include CC=clang --disable-gr-qtgui --disable-docs builds the latest tarball (3.5.2.1) and i need some help for the DYLD_LIBRARY_PATH because gnuradio-companion start with an error message though PYTHONPATH is correctly set You should be able to compile GR without LDFLAGS or CPPFLAGS, if you've set the PKG_CONFIG_PATH to include /opt/local/lib/pkgconfig. You'll probably want to set CXX to clang++ (or, whatever that is called) along with CC; I don't think CC is actually used, but it can't hurt to set it. Once installed, you should be able to execute GR scripts and GRC without resorting to the DYLD_LIBRARY_PATH -- the PATH and PYTHONPATH should be sufficient. Third downloaded the git version and after the usual steps with cmake, the building crashes at the 3% with the error cc1: error: unrecognized command line option -mpopcnt make[2]: *** [volk/lib/CMakeFiles/volk.dir/volk_machine_sse4_a_64.c.o] Error 1 make[1]: *** [volk/lib/CMakeFiles/volk.dir/all] Error 2 make: *** [all] Error 2 No idea, but using CMake is the way to go to get Volk working. Could be an OSX 10.7 issue; I'm still using 10.6 though I do do testing using an OSX 10.7 boot disk. I haven't tried this in a while, so I'll give it a whirl later today or tomorrow, as time allows. Good luck! - MLD ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio ok i'll do other experiments and report news.thx very much :D ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] build gnuradio without volk module
Nella citazione in data Thu Mar 15 03:07:49 2012, Tom Rondeau ha scritto: On Wed, Mar 14, 2012 at 8:49 PM, Johnathan Corgan jcor...@corganenterprises.com mailto:jcor...@corganenterprises.com wrote: On Wed, Mar 14, 2012 at 17:41, Josh Blum j...@joshknows.com mailto:j...@joshknows.com wrote: Is this the official github for gnuradio? https://github.com/gnuradio/gnuradio/tags Any chance we could get tags pushed there as well (maybe automated)? It would be super easy to link to source tarballs that way. Tom is setting up this github repo to automatically mirror the contents of gnuradio.org http://gnuradio.org's repo, but the work isn't complete, and the repo itself doesn't have everything in it (like the tags, as you noticed.) He and I are working out some security issues with the automation, but maybe we can do a manual push of the tags there. Johnathan Yes, we should definitely push the tags. Have done that manually for now. Arturo, My suggestion would be to use either the github gnuradio account or gnuradio.org http://gnuradio.org's git repo. Clone the repo and then checkout tag v3.5.2. This tag is equivalent to the tarball release except that it will contain the cmake files to build that way. Here's the link to the tarball for the v3.5.2 tag on github: https://github.com/gnuradio/gnuradio/zipball/v3.5.2 One thing to note, though, is that with this, you a) get everything in the repo and b) don't have some generated stuff that normally goes into the release tarballs. Issue a shouldn't affect you. For issue b, you will just have to remember to run ./bootstrap before running ./configure. As of 3.5.2, we've started using Volk inside of gnuradio-core blocks, so it has become a requirement, not just an option, so disabling volk should disable gnuradio-core, too. If that's not happening, I'll fix it. We will be releasing a 3.5.3 (possibly soon) to fix some other issues that have recently come up. Due to the autotools issue with volk, we will try to include the cmake build files in this release, though. Tom ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio thx very much to all of you. I look forward to work with the 3.5.3 official tarball. Regards, Arturo ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] build gnuradio without volk module
i'd like to build the latest tarball of gnuradio without the *volk* module. However i get the following errors (you can see them in the attached log). can i at least disable the module itself when running python sources ? Best Regards, Arturo make all-recursive make[1]: ingresso nella directory /home/artynet/Scaricati/gnuradio-3.5.2 Making all in config make[2]: ingresso nella directory /home/artynet/Scaricati/gnuradio-3.5.2/config make all-am make[3]: ingresso nella directory /home/artynet/Scaricati/gnuradio-3.5.2/config make[3]: Nessuna operazione da eseguire per all-am. make[3]: uscita dalla directory /home/artynet/Scaricati/gnuradio-3.5.2/config make[2]: uscita dalla directory /home/artynet/Scaricati/gnuradio-3.5.2/config Making all in gruel make[2]: ingresso nella directory /home/artynet/Scaricati/gnuradio-3.5.2/gruel make all-recursive make[3]: ingresso nella directory /home/artynet/Scaricati/gnuradio-3.5.2/gruel Making all in src make[4]: ingresso nella directory /home/artynet/Scaricati/gnuradio-3.5.2/gruel/src Making all in lib make[5]: ingresso nella directory /home/artynet/Scaricati/gnuradio-3.5.2/gruel/src/lib make all-recursive make[6]: ingresso nella directory /home/artynet/Scaricati/gnuradio-3.5.2/gruel/src/lib Making all in pmt make[7]: ingresso nella directory /home/artynet/Scaricati/gnuradio-3.5.2/gruel/src/lib/pmt make all-am make[8]: ingresso nella directory /home/artynet/Scaricati/gnuradio-3.5.2/gruel/src/lib/pmt make[8]: Nessuna operazione da eseguire per all-am. make[8]: uscita dalla directory /home/artynet/Scaricati/gnuradio-3.5.2/gruel/src/lib/pmt make[7]: uscita dalla directory /home/artynet/Scaricati/gnuradio-3.5.2/gruel/src/lib/pmt Making all in msg make[7]: ingresso nella directory /home/artynet/Scaricati/gnuradio-3.5.2/gruel/src/lib/msg make all-am make[8]: ingresso nella directory /home/artynet/Scaricati/gnuradio-3.5.2/gruel/src/lib/msg make[8]: Nessuna operazione da eseguire per all-am. make[8]: uscita dalla directory /home/artynet/Scaricati/gnuradio-3.5.2/gruel/src/lib/msg make[7]: uscita dalla directory /home/artynet/Scaricati/gnuradio-3.5.2/gruel/src/lib/msg make[7]: ingresso nella directory /home/artynet/Scaricati/gnuradio-3.5.2/gruel/src/lib make[7]: Nessuna operazione da eseguire per all-am. make[7]: uscita dalla directory /home/artynet/Scaricati/gnuradio-3.5.2/gruel/src/lib make[6]: uscita dalla directory /home/artynet/Scaricati/gnuradio-3.5.2/gruel/src/lib make[5]: uscita dalla directory /home/artynet/Scaricati/gnuradio-3.5.2/gruel/src/lib Making all in include make[5]: ingresso nella directory /home/artynet/Scaricati/gnuradio-3.5.2/gruel/src/include Making all in gruel make[6]: ingresso nella directory /home/artynet/Scaricati/gnuradio-3.5.2/gruel/src/include/gruel make all-am make[7]: ingresso nella directory /home/artynet/Scaricati/gnuradio-3.5.2/gruel/src/include/gruel make[7]: Nessuna operazione da eseguire per all-am. make[7]: uscita dalla directory /home/artynet/Scaricati/gnuradio-3.5.2/gruel/src/include/gruel make[6]: uscita dalla directory /home/artynet/Scaricati/gnuradio-3.5.2/gruel/src/include/gruel make[6]: ingresso nella directory /home/artynet/Scaricati/gnuradio-3.5.2/gruel/src/include make[6]: Nessuna operazione da eseguire per all-am. make[6]: uscita dalla directory /home/artynet/Scaricati/gnuradio-3.5.2/gruel/src/include make[5]: uscita dalla directory /home/artynet/Scaricati/gnuradio-3.5.2/gruel/src/include Making all in scheme make[5]: ingresso nella directory /home/artynet/Scaricati/gnuradio-3.5.2/gruel/src/scheme Making all in gnuradio make[6]: ingresso nella directory /home/artynet/Scaricati/gnuradio-3.5.2/gruel/src/scheme/gnuradio make all-am make[7]: ingresso nella directory /home/artynet/Scaricati/gnuradio-3.5.2/gruel/src/scheme/gnuradio make[7]: Nessuna operazione da eseguire per all-am. make[7]: uscita dalla directory /home/artynet/Scaricati/gnuradio-3.5.2/gruel/src/scheme/gnuradio make[6]: uscita dalla directory /home/artynet/Scaricati/gnuradio-3.5.2/gruel/src/scheme/gnuradio make[6]: ingresso nella directory /home/artynet/Scaricati/gnuradio-3.5.2/gruel/src/scheme make[6]: Nessuna operazione da eseguire per all-am. make[6]: uscita dalla directory /home/artynet/Scaricati/gnuradio-3.5.2/gruel/src/scheme make[5]: uscita dalla directory /home/artynet/Scaricati/gnuradio-3.5.2/gruel/src/scheme Making all in . make[5]: ingresso nella directory /home/artynet/Scaricati/gnuradio-3.5.2/gruel/src make[5]: Nessuna operazione da eseguire per all-am. make[5]: uscita dalla directory /home/artynet/Scaricati/gnuradio-3.5.2/gruel/src Making all in swig make[5]: ingresso nella directory /home/artynet/Scaricati/gnuradio-3.5.2/gruel/src/swig make all-am make[6]: ingresso nella directory /home/artynet/Scaricati/gnuradio-3.5.2/gruel/src/swig make[6]: Nessuna operazione da eseguire per all-am. make[6]: uscita dalla directory /home/artynet/Scaricati/gnuradio-3.5.2/gruel/src/swig make[5]: uscita
Re: [Discuss-gnuradio] build gnuradio without volk module
Nella citazione in data Thu Mar 15 00:10:01 2012, Andrew Davis ha scritto: Use CMake. I don't think anyone wants to maintain autotools and it really should be removed. On Wed, Mar 14, 2012 at 11:36 AM, Arturo Rinaldiarty.n...@gmail.com wrote: i'd like to build the latest tarball of gnuradio without the volk module. However i get the following errors (you can see them in the attached log). can i at least disable the module itself when running python sources ? Best Regards, Arturo ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio i want to build a stable tarball...not a git version. any chances to do it ? Regards ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] build gnuradio without volk module
Nella citazione in data Thu Mar 15 00:32:47 2012, Josh Blum ha scritto: i want to build a stable tarball...not a git version. any chances to do it ? Here you go: https://github.com/trondeau/gnuradio/tarball/57ad294b333d185cfd6952f01ea03f88370d2b8d If the tags were pushed, i would give you a link to the tag and not the commit id. -josh ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio ok thank you very much Joshany chance to build the 3.5.2 tarball without volk ? i need it for my work ;) Regards ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] build gnuradio without volk module
Nella citazione in data Thu Mar 15 01:00:58 2012, Josh Blum ha scritto: On 03/14/2012 04:39 PM, Arturo Rinaldi wrote: Nella citazione in data Thu Mar 15 00:32:47 2012, Josh Blum ha scritto: i want to build a stable tarball...not a git version. any chances to do it ? Here you go: https://github.com/trondeau/gnuradio/tarball/57ad294b333d185cfd6952f01ea03f88370d2b8d If the tags were pushed, i would give you a link to the tag and not the commit id. -josh ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio ok thank you very much Joshany chance to build the 3.5.2 tarball without volk ? i need it for my work ;) Regards Sorry, I should clarify. 1) You should build volk; it will become a serious gnuradio requirement. Now, there is a autotools + multilib volk build bug. The solution is to build gnuradio with cmake. 1.1) Perhaps you can pass --disable-volk to configure (when building with autotools) 2) Building with cmake is supported in the latest releases. 3) There are *no* source tarballs uploaded for releases. The available tarballs are generated by autotools and are missing files in the source tree (like the CMakeLists.txt). 4) But, you can get a source tarball from github like so: https://github.com/trondeau/gnuradio/tarball/commit identifier Wherecommit identifier is the hash of a commit, branch name, or tag name. Unfortunately, I dont know of a github with the tags pushed, but you can use the git hash of the 3.5.2 tag. -Josh i didn't explain myself very well...i'm very sorry about that. in the configure step i did ./configure --disable volk then i tried to build but i got that error. i need to verify if the volk module is responsible for the crash of one part of my project. Sorry to bother you againthx very much again ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] build gnuradio without volk module
Nella citazione in data Thu Mar 15 01:23:09 2012, Ben Hilburn ha scritto: Arturo - Is there a reason you cannot use CMake? Cheers, Ben On Wed, Mar 14, 2012 at 5:20 PM, Arturo Rinaldi arty.n...@gmail.com mailto:arty.n...@gmail.com wrote: Nella citazione in data Thu Mar 15 01:00:58 2012, Josh Blum ha scritto: On 03/14/2012 04:39 PM, Arturo Rinaldi wrote: Nella citazione in data Thu Mar 15 00:32:47 2012, Josh Blum ha scritto: i want to build a stable tarball...not a git version. any chances to do it ? Here you go: https://github.com/trondeau/__gnuradio/tarball/__57ad294b333d185cfd6952f01ea03f__88370d2b8d https://github.com/trondeau/gnuradio/tarball/57ad294b333d185cfd6952f01ea03f88370d2b8d If the tags were pushed, i would give you a link to the tag and not the commit id. -josh _ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org mailto:Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/__listinfo/discuss-gnuradio https://lists.gnu.org/mailman/listinfo/discuss-gnuradio ok thank you very much Joshany chance to build the 3.5.2 tarball without volk ? i need it for my work ;) Regards Sorry, I should clarify. 1) You should build volk; it will become a serious gnuradio requirement. Now, there is a autotools + multilib volk build bug. The solution is to build gnuradio with cmake. 1.1) Perhaps you can pass --disable-volk to configure (when building with autotools) 2) Building with cmake is supported in the latest releases. 3) There are *no* source tarballs uploaded for releases. The available tarballs are generated by autotools and are missing files in the source tree (like the CMakeLists.txt). 4) But, you can get a source tarball from github like so: https://github.com/trondeau/__gnuradio/tarball/ https://github.com/trondeau/gnuradio/tarball/commit identifier Wherecommit identifier is the hash of a commit, branch name, or tag name. Unfortunately, I dont know of a github with the tags pushed, but you can use the git hash of the 3.5.2 tag. -Josh i didn't explain myself very well...i'm very sorry about that. in the configure step i did ./configure --disable volk then i tried to build but i got that error. i need to verify if the volk module is responsible for the crash of one part of my project. Sorry to bother you againthx very much again _ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org mailto:Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/__listinfo/discuss-gnuradio https://lists.gnu.org/mailman/listinfo/discuss-gnuradio no there isn't :D. the only one is thati I just needed the 3.5.2 stable.i'll move to the git branch thx you very much to all ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] need help for digital.constellation_decoder_cb in release 3.5.0
Nella citazione in data Mon Mar 12 03:36:20 2012, Ben Reynwar ha scritto: On Sun, Mar 11, 2012 at 4:25 PM, Arturo Rinaldiarty.n...@gmail.com wrote: Nella citazione in data Sun Mar 11 02:30:43 2012, Arturo Rinaldi ha scritto: Nella citazione in data Fri Mar 9 19:50:05 2012, Ben Reynwar ha scritto: On Thu, Mar 8, 2012 at 8:19 PM, Arturo Rinaldiarty.n...@gmail.com wrote: Nella citazione in data ven 09 dic 2011 05:55:57 CET, Ben Reynwar ha scritto: On Thu, Dec 8, 2011 at 5:33 PM, Arturo Rinaldiarty.n...@gmail.com wrote: I noticed dramatic changes in the 3.5.0 release in the generation of the constellation points of digital modulations. So, if the easy part is to again modify the source code to match my needs, i need some help in using the new block : digital.constellation_decoder_cb(arg1) instead of gr.constellation_decoder(arg1,arg2) I usually used the last one where arg1 is a list containing the complex values of a generic digital modulation and arg2 is the symbol mapping (Gray Coding for instance). Which blocks do i need to put together to get the same result ? Regards, Arturo ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio Simplest solution is probably: constell = digital.digital_constellation(list_of_complex_points, [], 1, 1) decoder = digital.constellation_decoder_cb(constell) To get the symbol mapping you want, just choose the appropriate order of the complex points in the list. The 2nd, 3rd and 4th arguments to the constellation constructor while not relevant to this example are: - a mapping to be applied before differential encoding. - the rotational-symmetry of the constellation - the dimensionality of the constellation (i.e. number of complex points that together map to one symbol) Functions to simplify the creation of commonly used constellations can be found in digital.bpsk, digital.qpsk, digital.psk, and digital.qam. Ben i made some progress in simplyfing the creation of the constellations but i still need help in the decoding part. I'm trying to calculate the modulation BER by using this flow graph : http://imageshack.us/photo/my-images/819/bersimgrchomeartynetscr.png/ i removed all the unnecessary parameters to my study (excess bw , differential coding etc.) because i need only gray coding. and the decoding part is this one http://pastebin.com/wADRx7Hj could you please help me ? the grc blocks are made by invoking only the psk_new.py source http://pastebin.com/kawSfuPg modified by me. please help me. thx in advance Regards, Arturo. I'd be happy to help but I'm not quite sure what exactly your problem/question is. Maybe you could post the python generated by grc, along with the issue you're having? here it is http://pastebin.com/hQsPXbjJ my goal is to perform a baseband simulation for a simple BER estimation (modulator-channel-demodulator). when i posted the issue some time ago i used the block decoder = gr.constellation_decoder_cb($constellation_points,$symbol_value) i.e. for a qpsk modulation - constellation_points=[1+1j,-1+1j,-1-1j,1-1j] , symbol_value=[0,1,2,3] after that i un-grayed the symbols by connecting the map block gr.map_bb([0,1,3,2]) Since i'm usign the 3.5.2 tarball, the new block digital_swig.constellation_decoder_cb($constellation) (and not digital.constellation_decoder_cb) that you suggested me takes as argument a constellation object and not a constellation_bpsk, constellation_qpsk object and so on. So i think i'm unable to assign the right symbols to the decoded constellation and perform a correct BER estimation. I tried to use also with the object digital.constellation($constellation_points) as you suggested to build my own constellation but the log file says that it is an abstract class so it can't be used. I hope I explained myself well this time. Please help me because i need to update my work to the 3.5.x gnuradio version. PS : I also thought that I could take the old block gr.constellation_decoder_cb from the 3.4.2 tarball (.h , .i and .cc files) and build it with gr-how-to-make-a-block-3.5.2...would it be possible ? Best Regards, Arturo i forgot to mention that i deleted any block for RRC filtering and recovery. my goal is a simple baseband simulation. I attach again my new version (v2) of the source file generic_mod_demod and the grc image of the flow graph : http://imageshack.us/photo/my-images/838/bersimulationgrchomeart.png/ http://pastebin.com/i3nxY6u0 Regards, Arturo Hi Arturo, To generate a generic constellation use: constellation = digital.constellation_calcdist(complex_points, [], 1, 1).base() In my earlier email I forgot about the '_calcdist' and the '.base()'. Hopefully the above will work better for you. I'm also including an simple example that works for me, in case that doesn't fix your problem. Cheers, Ben import random from gnuradio import gr, digital def get_BER
Re: [Discuss-gnuradio] need help for digital.constellation_decoder_cb in release 3.5.0
Nella citazione in data Fri Mar 9 19:50:05 2012, Ben Reynwar ha scritto: On Thu, Mar 8, 2012 at 8:19 PM, Arturo Rinaldiarty.n...@gmail.com wrote: Nella citazione in data ven 09 dic 2011 05:55:57 CET, Ben Reynwar ha scritto: On Thu, Dec 8, 2011 at 5:33 PM, Arturo Rinaldiarty.n...@gmail.com wrote: I noticed dramatic changes in the 3.5.0 release in the generation of the constellation points of digital modulations. So, if the easy part is to again modify the source code to match my needs, i need some help in using the new block : digital.constellation_decoder_cb(arg1) instead of gr.constellation_decoder(arg1,arg2) I usually used the last one where arg1 is a list containing the complex values of a generic digital modulation and arg2 is the symbol mapping (Gray Coding for instance). Which blocks do i need to put together to get the same result ? Regards, Arturo ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio Simplest solution is probably: constell = digital.digital_constellation(list_of_complex_points, [], 1, 1) decoder = digital.constellation_decoder_cb(constell) To get the symbol mapping you want, just choose the appropriate order of the complex points in the list. The 2nd, 3rd and 4th arguments to the constellation constructor while not relevant to this example are: - a mapping to be applied before differential encoding. - the rotational-symmetry of the constellation - the dimensionality of the constellation (i.e. number of complex points that together map to one symbol) Functions to simplify the creation of commonly used constellations can be found in digital.bpsk, digital.qpsk, digital.psk, and digital.qam. Ben i made some progress in simplyfing the creation of the constellations but i still need help in the decoding part. I'm trying to calculate the modulation BER by using this flow graph : http://imageshack.us/photo/my-images/819/bersimgrchomeartynetscr.png/ i removed all the unnecessary parameters to my study (excess bw , differential coding etc.) because i need only gray coding. and the decoding part is this one http://pastebin.com/wADRx7Hj could you please help me ? the grc blocks are made by invoking only the psk_new.py source http://pastebin.com/kawSfuPg modified by me. please help me. thx in advance Regards, Arturo. I'd be happy to help but I'm not quite sure what exactly your problem/question is. Maybe you could post the python generated by grc, along with the issue you're having? here it is http://pastebin.com/hQsPXbjJ my goal is to perform a baseband simulation for a simple BER estimation (modulator-channel-demodulator). when i posted the issue some time ago i used the block decoder = gr.constellation_decoder_cb($constellation_points,$symbol_value) i.e. for a qpsk modulation - constellation_points=[1+1j,-1+1j,-1-1j,1-1j] , symbol_value=[0,1,2,3] after that i un-grayed the symbols by connecting the map block gr.map_bb([0,1,3,2]) Since i'm usign the 3.5.2 tarball, the new block digital_swig.constellation_decoder_cb($constellation) (and not digital.constellation_decoder_cb) that you suggested me takes as argument a constellation object and not a constellation_bpsk, constellation_qpsk object and so on. So i think i'm unable to assign the right symbols to the decoded constellation and perform a correct BER estimation. I tried to use also with the object digital.constellation($constellation_points) as you suggested to build my own constellation but the log file says that it is an abstract class so it can't be used. I hope I explained myself well this time. Please help me because i need to update my work to the 3.5.x gnuradio version. PS : I also thought that I could take the old block gr.constellation_decoder_cb from the 3.4.2 tarball (.h , .i and .cc files) and build it with gr-how-to-make-a-block-3.5.2...would it be possible ? Best Regards, Arturo ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] need help for digital.constellation_decoder_cb in release 3.5.0
Nella citazione in data ven 09 dic 2011 05:55:57 CET, Ben Reynwar ha scritto: On Thu, Dec 8, 2011 at 5:33 PM, Arturo Rinaldiarty.n...@gmail.com wrote: I noticed dramatic changes in the 3.5.0 release in the generation of the constellation points of digital modulations. So, if the easy part is to again modify the source code to match my needs, i need some help in using the new block : digital.constellation_decoder_cb(arg1) instead of gr.constellation_decoder(arg1,arg2) I usually used the last one where arg1 is a list containing the complex values of a generic digital modulation and arg2 is the symbol mapping (Gray Coding for instance). Which blocks do i need to put together to get the same result ? Regards, Arturo ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio Simplest solution is probably: constell = digital.digital_constellation(list_of_complex_points, [], 1, 1) decoder = digital.constellation_decoder_cb(constell) To get the symbol mapping you want, just choose the appropriate order of the complex points in the list. The 2nd, 3rd and 4th arguments to the constellation constructor while not relevant to this example are: - a mapping to be applied before differential encoding. - the rotational-symmetry of the constellation - the dimensionality of the constellation (i.e. number of complex points that together map to one symbol) Functions to simplify the creation of commonly used constellations can be found in digital.bpsk, digital.qpsk, digital.psk, and digital.qam. Ben i made some progress in simplyfing the creation of the constellations but i still need help in the decoding part. I'm trying to calculate the modulation BER by using this flow graph : http://imageshack.us/photo/my-images/819/bersimgrchomeartynetscr.png/ i removed all the unnecessary parameters to my study (excess bw , differential coding etc.) because i need only gray coding. and the decoding part is this one http://pastebin.com/wADRx7Hj could you please help me ? the grc blocks are made by invoking only the psk_new.py source http://pastebin.com/kawSfuPg modified by me. please help me. thx in advance Regards, Arturo. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] GR 3.5.1 OSX
Nella citazione in data mer 11 gen 2012 20:28:43 CET, Michael Dickens ha scritto: Hi Ed - I build from their respective GIT masters, not from those specific releases; but, yes, they seem to work for me. I use CMake for both, since (1) GNU autotools is on the way out; and (2) it works better (e.g., I don't have to disable Volk). - MLD On Jan 11, 2012, at 2:25 PM, Ed Criscuolo wrote: Has anyone built 3.5.1 release and UHD 3.3.2 on OSX 10.6 (Snow Leopard) yet? ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio can i build the master git branch on macos X 10.7.3 with cmake ? have i to satisfy the build pre-requisites with macports as usual ? ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] GR 3.5.1 OSX
Nella citazione in data ven 02 mar 2012 15:45:45 CET, Michael Dickens ha scritto: On Mar 2, 2012, at 9:39 AM, Arturo Rinaldi wrote: can i build the master git branch on macos X 10.7.3 with cmake ? have i to satisfy the build pre-requisites with macports as usual ? Hi Arturo - I believe that if you use MacPorts to install the background dependencies -- just do sudo port install gnuradio, and then, hours later, you can remove the installed GNU Radio / usrp ports, if any actually got installed. You'll need to install CMake too, since the current GR ports still use GNU Autotools. You should then be able to use CMake to build GNU Radio from the GIT master on OSX 10.7.3. I'm still using 10.6.8, but I know others who've used 10.7 and had success. Getting the dependencies to install is the tricky part, as always :) Give it a whirl, good luck, and please do let me/the list know if you have issues. - MLD ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio ok i'll try to satisfy the dependencies and build with cmake :D. wish me luck ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Submission to academic papers : Emulation of a Radio Link by means of Software Radio
Just to inform the mailing list that I uploaded the PDF slides of my degree thesis in the academic papers section. Here's a little description as reported in the page : Title : *Emulation of a Radio Link by means of Software Radio * /The goal of my degree thesis was to build an open source tool, the *gr-bertool*, for the estimation (computational and real-time) of the digital modulations *Bit Error Rate (BER)* both in the wired and wireless channels. It also provides complementary tools to show how the most common audio and video file formats are affected by digital modulations over the simulated transmission channels./ I'd like very much to have feedback from all the community for my work, so I can eventually improve it. Thanks in advance. Best Regards, Arturo Rinaldi ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Building on Mac OSX
Il 06/01/12 01:58, Michael Dickens ha scritto:
On Jan 5, 2012, at 6:32 PM, Arturo Rinaldi wrote:
could you list the dependencies to install trough macports to build gnuradio
from source on OS X Lion ? the gnuradio port of macports fails to build.
port rdeps gnuradio | sed -e 1d | awk '{ print $1 '} | sort | uniq | grep -v
gnuradio
results in the long appended list. Many of these are already available on OSX
(10.5 / 6 / 7), but MacPorts generally does not use those. Some are build
dependencies, but not runtime. Some are for documentation only. All of that
said, GNU Radio still has a bunch of dependencies, which in turn have their own
dependencies. If you have all of the below installed, then the 'cmake' port
has just a single added dependency (libidn). I don't know how many of the below
ports are removed by not including the GNU autotools.
BTW real soon now I'll be bumping the MacPorts ports for GNU Radio to 3.5.0
(or 3.5.1, or .2 -- the latest formal release). Could be a few weeks, or could be a few
months depending on how my work queue goes.
Xft2
atk
autoconf
automake
bison
boost
bzip2
cairo
cppunit
db46
dbus
docbook-xml
docbook-xml-4.1.2
docbook-xml-4.2
docbook-xml-4.3
docbook-xml-4.4
docbook-xml-4.5
docbook-xml-5.0
docbook-xsl
expat
fftw-3
fftw-3-single
flac
fontconfig
freetype
gawk
gdbm
gdk-pixbuf2
getopt
gettext
glib2
gmp
gnome-common
gnome-doc-utils
gperf
gputils
gsed
gsl
gtk-doc
gtk2
guile
help2man
hicolor-icon-theme
icu
intltool
iso-codes
jack
jasper
jpeg
lcms
libedit
libffi
libglade2
libiconv
libmng
libogg
libpixman
libpng
libsamplerate
libsdl
libsndfile
libtool
libusb-legacy
libvorbis
libxml2
libxslt
m4
makedepend
mesa
ncurses
ncursesw
openssl
p5.12-getopt-long
p5.12-locale-gettext
p5.12-pathtools
p5.12-scalar-list-utils
p5.12-xml-parser
pango
pcre
perl5
perl5.12
pkgconfig
portaudio
py26-cairo
py26-cheetah
py26-distribute
py26-gobject
py26-gtk
py26-lxml
py26-nose
py26-numpy
py26-opengl
py26-opengl-accelerate
py26-pil
py26-py
py26-pyqt4
py26-sip
py26-tkinter
py26-wxpython
py27-libxml2
python26
python27
python_select
qt4-mac
qwt52
qwtplot3d
rarian
readline
sdcc29
shared-mime-info
sqlite3
swig
swig-python
tcl
texinfo
tiff
tk
unzip
usrp
wxWidgets-python
xmlcatmgr
xorg-bigreqsproto
xorg-compositeproto
xorg-damageproto
xorg-dri2proto
xorg-fixesproto
xorg-glproto
xorg-inputproto
xorg-kbproto
xorg-libX11
xorg-libXScrnSaver
xorg-libXau
xorg-libXcomposite
xorg-libXcursor
xorg-libXdamage
xorg-libXdmcp
xorg-libXext
xorg-libXfixes
xorg-libXi
xorg-libXinerama
xorg-libXmu
xorg-libXrandr
xorg-libXt
xorg-libice
xorg-libpthread-stubs
xorg-libsm
xorg-libxcb
xorg-randrproto
xorg-renderproto
xorg-scrnsaverproto
xorg-util-macros
xorg-xcb-proto
xorg-xcb-util
xorg-xcmiscproto
xorg-xextproto
xorg-xf86bigfontproto
xorg-xineramaproto
xorg-xproto
xorg-xtrans
xrender
xz
zlib
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
thank you very much :D. I', lloking forward to the 3.5.0 port ;)
Regards, Arturo
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Building on Mac OSX
Il 26/10/11 21:54, Josh Blum ha scritto: On 10/26/2011 12:52 PM, Jeff Scaparra wrote: Alternatively it may be using the wrong python. Is there a way to specify which python to use. If it uses the same path as the normal terminal then it will work however if it sets the standard /usr/bin/python it will fail. pass -DPYTHON_EXECUTABLE=path to python to override -josh Thanks, Jeff On Wed, Oct 26, 2011 at 3:50 PM, Jeff Scaparraj...@scaparra.com wrote: I think I have everything figured out now I have pyqt pygtk and pywx installed however cmake still isn't finding pygtk even though the version is correct (running 2.24.0) and python -c import gtk has no output. Anyone know what the specific check actually is? Jeff On Wed, Oct 26, 2011 at 1:18 PM, Jeff Scaparraj...@scaparra.com wrote: I was just having an issue with the python path. gr_wxgui is enabled now. I have the qt stuff installed but will look at manually pointing cmake in the right direction. I think I can make this work. I hate to give up now. It would be nice to write up a brew formula for gnuradio but I have no idea how I would get my system back to a default state for testing after all I have done (without reinstalling). Jeff On Wed, Oct 26, 2011 at 12:47 PM, Ben Reynwarb...@reynwar.net wrote: On Wed, Oct 26, 2011 at 8:44 AM, Jeff Scaparraj...@scaparra.com wrote: Hello, I have almost gotten all the dependencies needed for gnuradio recognized however I have qt qwt and wx installed but they aren't being recognized by cmake. I have also tried to manually enable them with the -DENABLE_GR_QTGUI AND -DENABLE_GR_WXGUI options with no luck. I have used homebrew to install almost all of the dependencies and it has been a great help. If anyone have any experience building gnuradio on OSX I would appreciate any input. Thanks, Jeff (KK4EPP) ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio If you're not using homebrew for anything else, it's probably easier just to switch to using macports. I had a good crack at getting gnuradio installed via homebrew but switched to macports in the end because I couldn't get the gui stuff working. Cheers, Ben ___ 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 could you list the dependencies to install trough macports to build gnuradio from source on OS X Lion ? the gnuradio port of macports fails to build. Regards, Arturo ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] need help for digital.constellation_decoder_cb in release 3.5.0
I noticed dramatic changes in the 3.5.0 release in the generation of the constellation points of digital modulations. So, if the easy part is to again modify the source code to match my needs, i need some help in using the new block : /digital.constellation_decoder_cb(arg1)/ instead of / gr.constellation_decoder(arg1,arg2)/ I usually used the last one where /arg1/ is a list containing the complex values of a generic digital modulation and /arg2/ is the symbol mapping (Gray Coding for instance). Which blocks do i need to put together to get the same result ? Regards, Arturo ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] need help for digital.constellation_decoder_cb in release 3.5.0
I noticed dramatic changes in the 3.5.0 release in the generation of the constellation points of digital modulations. So, if the easy part is to again modify the source code to match my needs, i need some help in using the new block : /digital.constellation_decoder_cb(arg1)/ instead of / gr.constellation_decoder(arg1,arg2)/ I usually used the last one where /arg1/ is a list containing the complex values of a generic digital modulation and /arg2/ is the symbol mapping (Gray Coding for instance). Which blocks do i need to put together to get the same result ? Regards, Arturo ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] submission to academic paper section
I'd like to submit my own graduation thesis to the academic section of the gnuradio wiki. Which is the right way to do it ? Regards, Arturo ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] GNU Radio release candidate 3.5.0rc0 available for download
Nella citazione in data mar 01 nov 2011 22:22:06 CET, Ben Hilburn ha scritto: Svante - You say see below, but I'm not seeing any error messages or attached files in your e-mail. Tell me if they are there and I'm just not seeing them, as it might be my mail client. Regardless, yes, please join the USRP-Users list, and post your questions there. We will be happy to field any issues you may have while using UHD. I think we have de-railed Johnathan's 3.5.0 RC announcement enough at this point ;) Cheers, Ben On Tue, Nov 1, 2011 at 1:42 PM, Svante Signell s...@kth.se mailto:s...@kth.se wrote: On Tue, 2011-11-01 at 12:00 -0700, Ben Hilburn wrote: Svante - UHD is an entirely different project from GNURadio. UHD provides the firmware API for Ettus Research SDRs. GNURadio has support for UHD-compatible devices, through gr-uhd, but they are different projects. You can, in fact, install GNURadio without UHD, and use GNURadio with SDRs that are not USRPs, or without any actual hardware at all. If you have questions about using UHD with USRPs, you can get help from us on the USRP-Users list! http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com If you want to build GNURadio with the gr-uhd component, you will need to build and install UHD prior to building installing GNURadio. You didn't say what was keeping you from building UHD in your last e-mail, so I don't really have any information to help you yet. If you still need help, send your error messages to the USRP-Users list, linked above, and we will do what we can to help you =) I used git to download the uhd code and tried to build it. But I did not succeed with autotools or cmake, se below. Additionally there does not seem to be any Debian packages available. So building from source would be the only option for now. I'll subscribe to USRP-Users mailing list if needed. Thanks! Looking at the ettus webpage, http://code.ettus.com/redmine/ettus/projects/uhd/wiki there seems to be a separate git directory for the driver: git clone git://code.ettus.com/ettus/uhd.git http://code.ettus.com/ettus/uhd.git ... However, I did not manage to build the driver either with cmake or the autotools yet. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio i can't find the bug tracker to post the cmake -build-package errorcan you link me to it ? Regards, Arturo ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] GNU Radio release candidate 3.5.0rc0 available for download
Il 29/10/2011 22:03, Johnathan Corgan ha scritto: GNU Radio release candidate 3.5.0rc0 has been tagged on the master branch and made available as a tarball: http://gnuradio.org/redmine/attachments/download/281/gnuradio-3.5.0rc0.tar.gz As a release candidate, this tarball represents what will be in the 3.5.0 release, absent bug fixes discovered in testing. To avoid issues with multiple versions of GNU Radio being installed, it is important to uninstall an existing installation using the make uninstall command from your source tree. Also, please remember that when building GNU Radio from a tarball, one does not need to run the bootstrap step. Johnathan ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio i expected to find the /CMakelists.txt/ file inside to rc0 tarball to build with cmakebut there is no trace at allwill it be inserted in the final release of 3.5.0 ? Regards, Arturo ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] build-gnuradio under Ubuntu 11.10
Nella citazione in data gio 20 ott 2011 14:10:10 CEST, Marcus D. Leech ha scritto: On 20/10/11 01:51 AM, Dan CaJacob wrote: It worked for me on Ubuntu 11.10 x64 Thanks! On Oct 17, 2011, at 1:31 PM, Marcus D. Leechmle...@ripnet.com wrote: Could somebody try build-gnuradio under Ubuntu 11.10 and give me feedback about work/not-work. There's currently a pre-reqs paragraph for 11.*, which may or may not work under 11.10. does the new 3.4.2 tarball build without any problem on ubuntu 11.10 ? can we expect an gr-how-to-write-a-block 3.4.2 ? Regards ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] New build structure! (Warning #2)
Il 20/10/2011 03:43, Tom Rondeau ha scritto: Another big change is happening today! Josh Blum has make GNU Radio build using cmake, and we are hoping to switch over to it completely. The 'next' branch has just pulled in his changes, and we now have parallel build systems, cmake and autofoo. We are trying to make cmake the default build system, so we need people to start using it and testing as much as possible. For people who have issues using cmake, the autofoo stuff will still be there. The parallel build system will be in place official from 3.5. As of 3.6, we will have made a decision to move to cmake or stay with autotools; the other will be removed. It is expected that we will move to cmake, so this is a Warning to everyone that autotools is being deprecated as our build method. Details about using cmake can be found here: http://gnuradio.org/redmine/projects/gnuradio/wiki/CMakeWork To summarizes: $ cd gnuradio $ git checkout next $ git pull $ mkdir build $ cd build $ cmake ../ $ make $ make test $ sudo make install Again, if that fails but you really need to use the current next branch, the same autotools build process will work. Please let us know if you find any issues. Thanks! Tom ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio does this mean that i could perform the steps /mkdir build cd build cmake -DCPACK_GENERATOR=DEB ../ make package/ and make deb(s) of the current git release ? which is the switch to disable one of the components ? Regards, Arturo ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Ubuntu 11.10
Il 17/10/2011 04:17, Tom Rondeau ha scritto: The maint, master, and next branches in git have all been fixed to work under Ubuntu 11.10 (new autotools and Qwt 6 were the main culprits). A bit more information can be found here: http://gnuradio.squarespace.com/home/2011/10/16/ubuntu-1110-troubles.html Tom ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio Do I need to install /swig/ or /swig2.0/ from the repos as dependencies to build from source ? Regards, Arturo ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] building issues of 3.4.1 on Ubuntu Oneiric 11.10 - 32 bit
I don't want to be the guy bothering you about building issues of gnuradio every time :D, but experienced again building problems from the 3.4.1 source tarball with the latest ubuntu distro. I installed the dependencies as reported in the SBRAC script : /sudo apt-get -y install libfontconfig1-dev libxrender-dev libpulse-dev swig g++ \ automake autoconf libtool python-dev libfftw3-dev \ libcppunit-dev libboost-all-dev libusb-dev libusb-1.0-0-dev fort77 sdcc sdcc-libraries \ libsdl1.2-dev python-wxgtk2.8 git-core guile-1.8-dev \ libqt4-dev python-numpy ccache python-opengl libgsl0-dev \ python-cheetah python-lxml doxygen qt4-dev-tools libusb-1.0-0-dev \ libqwt5-qt4-dev libqwtplot3d-qt4-dev pyqt4-dev-tools python-qwt5-qt4 \ cmake git-core wget sdcc libxi-dev/ then built from source the uhd images from the latest tar.gz from UHD website with /cmake -DCPACK_GENERATOR=DEB -DENABLE_USRP_E_UTILS=ON -DENABLE_E100=ON ..// then : /./configure make /as usual, the errors are reported in a text file thanks in advance ;) make[6]: uscita dalla directory /home/artynet/Scrivania/gnuradio-3.4.1/usrp2/firmware make[5]: uscita dalla directory /home/artynet/Scrivania/gnuradio-3.4.1/usrp2/firmware make[4]: uscita dalla directory /home/artynet/Scrivania/gnuradio-3.4.1/usrp2/firmware make[4]: ingresso nella directory /home/artynet/Scrivania/gnuradio-3.4.1/usrp2 make[4]: Nessuna operazione da eseguire per all-am. make[4]: uscita dalla directory /home/artynet/Scrivania/gnuradio-3.4.1/usrp2 make[3]: uscita dalla directory /home/artynet/Scrivania/gnuradio-3.4.1/usrp2 make[2]: uscita dalla directory /home/artynet/Scrivania/gnuradio-3.4.1/usrp2 Making all in gr-usrp make[2]: ingresso nella directory /home/artynet/Scrivania/gnuradio-3.4.1/gr-usrp make all-recursive make[3]: ingresso nella directory /home/artynet/Scrivania/gnuradio-3.4.1/gr-usrp Making all in src make[4]: ingresso nella directory /home/artynet/Scrivania/gnuradio-3.4.1/gr-usrp/src Compile .i to .py /usr/bin/swig -c++ -fvirtual -python -modern -keyword -w511 -outdir . -I/home/artynet/Scrivania/gnuradio-3.4.1/gnuradio-core/src/lib/runtime -I/home/artynet/Scrivania/gnuradio-3.4.1/gnuradio-core/src/lib/general -I/home/artynet/Scrivania/gnuradio-3.4.1/gnuradio-core/src/lib/general -I/home/artynet/Scrivania/gnuradio-3.4.1/gnuradio-core/src/lib/gengen -I/home/artynet/Scrivania/gnuradio-3.4.1/gnuradio-core/src/lib/gengen -I/home/artynet/Scrivania/gnuradio-3.4.1/gnuradio-core/src/lib/filter -I/home/artynet/Scrivania/gnuradio-3.4.1/gnuradio-core/src/lib/filter -I/home/artynet/Scrivania/gnuradio-3.4.1/gnuradio-core/src/lib/missing -I/home/artynet/Scrivania/gnuradio-3.4.1/gnuradio-core/src/lib/reed-solomon -I/home/artynet/Scrivania/gnuradio-3.4.1/gnuradio-core/src/lib/viterbi -I/home/artynet/Scrivania/gnuradio-3.4.1/gnuradio-core/src/lib/io -I/home/artynet/Scrivania/gnuradio-3.4.1/gnuradio-core/src/lib/g72x -I/home/artynet/Scrivania/gnuradio-3.4.1/gnuradio-core/src/lib/swig -I/home/artynet/Scrivania/gnuradio-3.4.1/gnuradio-core/src/lib/hier -I/home/artynet/Scrivania/gnuradio-3.4.1/gnuradio-core/src/lib/swig -I/home/artynet/Scrivania/gnuradio-3.4.1/gruel/src/include -I/home/artynet/Scrivania/gnuradio-3.4.1/gruel/src/include -I/usr/include -I. -I../.. -I/home/artynet/Scrivania/gnuradio-3.4.1/usrp/host/include -I/home/artynet/Scrivania/gnuradio-3.4.1/usrp/host/include -I/home/artynet/Scrivania/gnuradio-3.4.1/usrp/firmware/include \ -MD -MF python/usrp_swig.Std \ -module usrp_swig -o python/usrp_swig.cc -oh python/usrp_swig.h usrp_swig.i /bin/sed -e 's|python/\(.*\)\.cc:|\1.py:|' python/usrp_swig.Std python/usrp_swig.d /bin/rm -f python/usrp_swig.Std make all-am make[5]: ingresso nella directory /home/artynet/Scrivania/gnuradio-3.4.1/gr-usrp/src /bin/bash ../../libtool --tag=CXX --mode=compile g++ -DHAVE_CONFIG_H -I. -I../.. -I/home/artynet/Scrivania/gnuradio-3.4.1/usrp/host/include -I/home/artynet/Scrivania/gnuradio-3.4.1/usrp/host/include -I/home/artynet/Scrivania/gnuradio-3.4.1/usrp/firmware/include -I/home/artynet/Scrivania/gnuradio-3.4.1/gnuradio-core/src/lib/runtime -I/home/artynet/Scrivania/gnuradio-3.4.1/gnuradio-core/src/lib/general -I/home/artynet/Scrivania/gnuradio-3.4.1/gnuradio-core/src/lib/general -I/home/artynet/Scrivania/gnuradio-3.4.1/gnuradio-core/src/lib/gengen -I/home/artynet/Scrivania/gnuradio-3.4.1/gnuradio-core/src/lib/gengen -I/home/artynet/Scrivania/gnuradio-3.4.1/gnuradio-core/src/lib/filter -I/home/artynet/Scrivania/gnuradio-3.4.1/gnuradio-core/src/lib/filter -I/home/artynet/Scrivania/gnuradio-3.4.1/gnuradio-core/src/lib/missing -I/home/artynet/Scrivania/gnuradio-3.4.1/gnuradio-core/src/lib/reed-solomon -I/home/artynet/Scrivania/gnuradio-3.4.1/gnuradio-core/src/lib/viterbi -I/home/artynet/Scrivania/gnuradio-3.4.1/gnuradio-core/src/lib/io -I/home/artynet/Scrivania/gnuradio-3.4.1/gnuradio-core/src/lib/g72x
Re: [Discuss-gnuradio] building issues of 3.4.1 on Ubuntu Oneiric 11.10 - 32 bit
Nella citazione in data sab 15 ott 2011 01:46:48 CEST, Ben Hilburn ha scritto: Arturo - Looks like some boost errors. What version of boost is installed on your system? Also, will you make sure that the libboost_system and libboost_filesystem libraries are installed? A quick: $ sudo updatedb $ locate libboost | grep system ... ought to reveal the answer. If there are incompatibilities in the newest version of boost shipping on Ubuntu, we'll need to take care of that quickly. Cheers, Ben On Fri, Oct 14, 2011 at 4:35 PM, Arturo Rinaldi arty.n...@gmail.com mailto:arty.n...@gmail.com wrote: I don't want to be the guy bothering you about building issues of gnuradio every time :D, but experienced again building problems from the 3.4.1 source tarball with the latest ubuntu distro. I installed the dependencies as reported in the SBRAC script : /sudo apt-get -y install libfontconfig1-dev libxrender-dev libpulse-dev swig g++ \ automake autoconf libtool python-dev libfftw3-dev \ libcppunit-dev libboost-all-dev libusb-dev libusb-1.0-0-dev fort77 sdcc sdcc-libraries \ libsdl1.2-dev python-wxgtk2.8 git-core guile-1.8-dev \ libqt4-dev python-numpy ccache python-opengl libgsl0-dev \ python-cheetah python-lxml doxygen qt4-dev-tools libusb-1.0-0-dev \ libqwt5-qt4-dev libqwtplot3d-qt4-dev pyqt4-dev-tools python-qwt5-qt4 \ cmake git-core wget sdcc libxi-dev/ then built from source the uhd images from the latest tar.gz from UHD website with /cmake -DCPACK_GENERATOR=DEB -DENABLE_USRP_E_UTILS=ON -DENABLE_E100=ON ..// then : /./configure make /as usual, the errors are reported in a text file thanks in advance ;) ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org mailto:Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio i'll let you know as soon as possible.i'm doing a new virtual machine with amd64 architecture. Stay Tuned :D ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] building issues of 3.4.1 on Ubuntu Oneiric 11.10 - 32 bit
Nella citazione in data sab 15 ott 2011 01:56:04 CEST, Arturo Rinaldi ha scritto: Nella citazione in data sab 15 ott 2011 01:46:48 CEST, Ben Hilburn ha scritto: Arturo - Looks like some boost errors. What version of boost is installed on your system? Also, will you make sure that the libboost_system and libboost_filesystem libraries are installed? A quick: $ sudo updatedb $ locate libboost | grep system ... ought to reveal the answer. If there are incompatibilities in the newest version of boost shipping on Ubuntu, we'll need to take care of that quickly. Cheers, Ben On Fri, Oct 14, 2011 at 4:35 PM, Arturo Rinaldi arty.n...@gmail.com mailto:arty.n...@gmail.com wrote: I don't want to be the guy bothering you about building issues of gnuradio every time :D, but experienced again building problems from the 3.4.1 source tarball with the latest ubuntu distro. I installed the dependencies as reported in the SBRAC script : /sudo apt-get -y install libfontconfig1-dev libxrender-dev libpulse-dev swig g++ \ automake autoconf libtool python-dev libfftw3-dev \ libcppunit-dev libboost-all-dev libusb-dev libusb-1.0-0-dev fort77 sdcc sdcc-libraries \ libsdl1.2-dev python-wxgtk2.8 git-core guile-1.8-dev \ libqt4-dev python-numpy ccache python-opengl libgsl0-dev \ python-cheetah python-lxml doxygen qt4-dev-tools libusb-1.0-0-dev \ libqwt5-qt4-dev libqwtplot3d-qt4-dev pyqt4-dev-tools python-qwt5-qt4 \ cmake git-core wget sdcc libxi-dev/ then built from source the uhd images from the latest tar.gz from UHD website with /cmake -DCPACK_GENERATOR=DEB -DENABLE_USRP_E_UTILS=ON -DENABLE_E100=ON ..// then : /./configure make /as usual, the errors are reported in a text file thanks in advance ;) ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org mailto:Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio i'll let you know as soon as possible.i'm doing a new virtual machine with amd64 architecture. Stay Tuned :D here it is, the version is 1.46. the 1.42 version is also present in the repositories, but 11.10 installs 1.46 by default.. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] error compiling 3.4.1 on ubuntu maverick
i experienced this error while compiling on Ubuntu 10.10 i386 /make[6]: uscita dalla directory /home/artynet/Downloads/gnuradio-3.4.1/gruel/src/swig make[5]: uscita dalla directory /home/artynet/Downloads/gnuradio-3.4.1/gruel/src/swig Making all in python make[5]: ingresso nella directory /home/artynet/Downloads/gnuradio-3.4.1/gruel/src/python make all-am make[6]: ingresso nella directory /home/artynet/Downloads/gnuradio-3.4.1/gruel/src/python make[6]: Nessuna operazione da eseguire per all-am. make[6]: uscita dalla directory /home/artynet/Downloads/gnuradio-3.4.1/gruel/src/python make[5]: uscita dalla directory /home/artynet/Downloads/gnuradio-3.4.1/gruel/src/python make[4]: uscita dalla directory /home/artynet/Downloads/gnuradio-3.4.1/gruel/src make[4]: ingresso nella directory /home/artynet/Downloads/gnuradio-3.4.1/gruel make[4]: Nessuna operazione da eseguire per all-am. make[4]: uscita dalla directory /home/artynet/Downloads/gnuradio-3.4.1/gruel make[3]: uscita dalla directory /home/artynet/Downloads/gnuradio-3.4.1/gruel make[2]: uscita dalla directory /home/artynet/Downloads/gnuradio-3.4.1/gruel Making all in volk make[2]: ingresso nella directory /home/artynet/Downloads/gnuradio-3.4.1/volk make[2]: *** Nessuna regola per generare l'obiettivo all. Arresto. make[2]: uscita dalla directory /home/artynet/Downloads/gnuradio-3.4.1/volk make[1]: *** [all-recursive] Errore 1 make[1]: uscita dalla directory /home/artynet/Downloads/gnuradio-3.4.1 make: *** [all] Errore 2/* *where is the issue ? I always compiled the gnuradio tarball without any problems. thx in advance, Arturo ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Building gnuradio 3.3.0 on Fedora 15 (issue with SDCC)
Il 26/05/2011 13:05, Robert McGwier ha scritto: On either my Ubuntu box or my Fedora box, 2.9.0 fails. I used 2.8.0 and all is well. I get it from sdcc sourceforge site and was done in a few minutes. Bob On May 26, 2011 6:15 AM, Tom Rondeau trondeau1...@gmail.com mailto:trondeau1...@gmail.com wrote: On Thu, May 26, 2011 at 3:08 AM, Marcus D. Leech mle...@ripnet.com mailto:mle...@ripnet.com wrote: On 05/25/2011 09:01 PM, Arturo Rinaldi wrote: i have an issue regarding the SDCC executable in the building of gnuradio 3.3.0 on Fedora 15. I set up the PATH in my *.bashrc* file as : *export PATH=/usr/libexec/sdcc:$PATH *as written in the build guide but I still get the error in the configure process : *USRP requires sdcc. sdcc not found. See http://sdcc.sf.net Unable to find firmware compiler SDCC. Not building component usrp.* Where am i wrong ? If I launch from terminal *$ sdcc -v * it returns : *$ SDCC : mcs51/gbz80/z80/ds390/pic16/pic14/TININative/ds400/hc08 3.0.0 #6037 (Apr 13 2011) (Linux)* thx in advance. All the others pre-requisites are fully satisfied. Regards, Arturo. A few points: If you're using UHD, you don't need component USRP. Since Fedora 14, they have shipped SDCC version 3.0 which has different command names, and also some difference syntax for built-in variable-type intrinsics, so the USRP1 firmware won't build under SDCC-3.0 anyway. The configure script for Gnu Radio looks for SDCC using the SDCC version 2.X command names, and so for a system with SDCC 3.0, this will fail. But, once again, if you're using UHD (which I *strongly* recommend), you don't need the component usrp and gr-usrp to be built anyway. I haven't upgraded any of my systems to F15 yet, but when I do, expect the famous (almost!) build-gnuradio script to get updated to deal with F15. -- Principal Investigator Shirleys Bay Radio Astronomy Consortiumhttp://www.sbrac.org http://www.sbrac.org And if you do really want to get the usrp and gr-usrp components to build, you should be able to easily install a 2.9 version of SDCC. Tom ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio thank you very much to all of you. I'll do my test on my Fedora 15 system as soon as possible. I think the best solution is to build 2.9.0-7 from source and then install. @ Bob never experienced any issue on Ubuntu with sdcc 2.9.0-5. I also remember that building from source on a Fedora 14 worked well like described in the guide on the gnuradio website. Best Regards to all, Arturo ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] log scale on gnuradio wxgui scopesink Counts
is it possible to show in the *wxgui_scopesink* the Counts values in the form of a log scale, i.e. 10^(-1) 10^(-2), 10^(-3), 10^(-4) and so on ? do i have to modify some source python file ? thx in advance Regards, Arturo ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Building gnuradio 3.3.0 on Fedora 15 (issue with SDCC)
i have an issue regarding the SDCC executable in the building of gnuradio 3.3.0 on Fedora 15. I set up the PATH in my *.bashrc* file as : /export PATH=/usr/libexec/sdcc:$PATH /as written in the build guide but I still get the error in the configure process : /USRP requires sdcc. sdcc not found. See http://sdcc.sf.net Unable to find firmware compiler SDCC. Not building component usrp./ Where am i wrong ? If I launch from terminal /$ sdcc -v / it returns : /$ SDCC : mcs51/gbz80/z80/ds390/pic16/pic14/TININative/ds400/hc08 3.0.0 #6037 (Apr 13 2011) (Linux)/ thx in advance. All the others pre-requisites are fully satisfied. Regards, Arturo. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Gnuradio Compilation error
Il 09/05/2011 11:00, HW Wong ha scritto: yes, Ubuntu 11.04 then I ignore the error and make install, and get error on benchmark.py HP-Compaq-6535s:~/gnuradio/gnuradio-examples/python/usrp$ ./usrp_benchmark_usb.py Testing 2MB/sec... /home/howie/.gnuradio/prefs/gr_vmcircbuf_default_factory: No such file or directory gr_vmcircbuf_createfilemapping: createfilemapping is not available uUuOuUuOuUuOuUuOuUuOuUuOuOuUuOuUuOuUuOuUuOuUuOuUuOuUuOuUuOuOuUuUuUuUuUuUusb_throughput = 2M ntotal= 100 nright= 953366 runlength = 37404 delta = 962596 FAILED Testing 4MB/sec... uOuUuOuUuOuUuOuUuOuUuOuUuOuUuOuUuOuUuOuUuOuUuOuUuOuUuOuUuOuUuOuUuOuUuOuUuOuUuOuUuUuUuUuUuU^Cusb_throughput = 4M ntotal= 200 nright= 1907110 runlength = 75805 delta = 1924195 FAILED Testing 8MB/sec... uUuOuUuOuUuOuUuOuUuOuUuOuUuOuUuOuUuOuUuOuUuOuUuOuUuOuUuOuUuOuUuOuUuOuUuOuUuOuUuUuUuUuUuUuUuUuUuUuUuUuUuUuUuUuUuUusb_throughput = 8M ntotal= 400 nright= 3883563 runlength = 38818 delta = 3961182 FAILED On Mon, May 9, 2011 at 4:52 PM, Tom Rondeau trondeau1...@gmail.com mailto:trondeau1...@gmail.com wrote: On Mon, May 9, 2011 at 9:49 AM, HW Wong ffp.how...@gmail.com mailto:ffp.how...@gmail.com wrote: Hi, I get the gnuradio from git and make it. get the following error. Could anyone please kindly advice. Thanks! /lib/i386-linux-gnu/gcc/i686-linux-gnu/4.5.2/crtendS.o /usr/lib/i386-linux-gnu/gcc/i686-linux-gnu/4.5.2/../../../crtn.o -pthread -pthread -pthread -Wl,-soname -Wl,libgnuradio-qtgui-3.4.0git.so.0 -o .libs/libgnuradio-qtgui-3.4.0git.so.0.0.0 /usr/bin/ld: cannot find -lXi collect2: ld returned 1 exit status make[5]: *** [libgnuradio-qtgui.la http://libgnuradio-qtgui.la] Error 1 I'm assuming you are running Ubuntu 11.04? I addressed this problem in the build guide (http://gnuradio.org/redmine/wiki/gnuradio/UbuntuInstall): sudo apt-get -y install libxi-dev Tom ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio FYI i had the same error long time ago compiling from git on *Ubuntu 10.10*. I recently compiled on Ubuntu 11.04 (both the stable and the git version) like Tom well knows, my step were : +sudo apt-get build-dep gnuradio +install all the dependencies on the gnuradio build guide page ( i got installed other stuff) +then the usual steps of building from source no problems experienced :D. Never ignore the errors when building, at least you disable the modules Regards, Arturo ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] grc: cannot import gnuradio error when launching from Applications menu
Il 09/05/2011 20:21, Elvis Dowson ha scritto: Hi, I just performed a clean install of gnuradio (3.4.0 from the current master branch). The installation and tests all worked out fine with my USRP2. However, when I try to launch GRC from the Applications Programming GRC, it gives me a grc: cannot import gnuradio error. I have set my PYTHONPATH in my .profile, and .bashrc. However, it doesn't affect the graphical login. I have read that one possible solution is to make it system wide using /etc/profile, but I was wondering if there was another way to do this. Launching gnuradio_companion from a console works, but launching it from the Gnome Desktop panel doesn't work. Elvis Dowson ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio try $/sudo ldconfig/ and then $//usr/local/libexec/gnuradio/grc_setup_freedesktop install / which creates the links in the menu and the associations for *.grc files. However the command in the link is /gnuradio-companion %F/ never problems experienced in that :D Regards, Arturo ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] UHD Failed to Install: build-gnuradio script not working properly for Ubuntu 9.04 (Fresh Install) + USRP1 + WBX?
Il 07/05/2011 14:32, Tom Rondeau ha scritto: On Tue, May 3, 2011 at 4:39 PM, turbovectorz turbovectorz turbovect...@gmail.com mailto:turbovect...@gmail.com wrote: Hello ALL! I setup a fresh install of Ubuntu 9.04 on a very old Toughbook 512MB RAM, Intel Pentium M 1.6GHz, 80GB HDD. My hardware is an USRP1 with a WBX on slot A. I downloaded and ran the build-gnuradio script with the proper security permissions (sudo access) on my /home/user directory. I ran the build script but I eventually get the messageUHD Failed to Install and the script exits. Newbie questions? Do I have to have the USRP1 connected to the unit? Do I need to remove the libusb-0.1 from the Synaptic Package Manager? Do I need to upgrade the OS to Ubuntu 9.,10? Any help will be Greatly appreaciated! Thanks, TVZ Instead of running the build-gnuradio script, can you follow the instructions (http://gnuradio.org/redmine/wiki/gnuradio/UbuntuInstall) for 9.04 as well as the UHD (http://code.ettus.com/redmine/ettus/projects/uhd/wiki) separately and make sure there are no problems doing that? Thanks, Tom ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio i just did the UHD compiling today. you can also make a *.deb file of the uhd libraries. Check out the readme in the /uhd/host directory after downloading it from gitTom Any news about my issue ? Regards, Arturo ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Issues on Build/install on Ubuntu x32 (version 3.3.0)
i have some issue in building gnuradio-3.3.0 on ubuntu 11.04 x32. In particular I get errors in the building of the gr-usrp2 module, so i'm temporarily disabling the modules gr-usrp and gr-usrp through the ./ configure process.any suggestions ? Regards , Arturo PS: if i build the unstable version from git i don't experience any problem at all ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Build/install on Ubuntu x64 10.10 today
Il 12/04/2011 15:27, Andrew Hofmaier ha scritto:
I got the same error today as Marcus did last week in a fresh install
from next on Ubuntu 10.04 x64. Everything worked fine through the UHD
install, ./bootstrap, ./configure, make, make check, sudo make install
routine. However, attempting to run gnuradio companion reports:
Cannot import gnuradio. Are your PYTHONPATH and LD_LIBRARY_PATH set
correctly?
I have the following in my .bashrc file:
# GNU Radio installation
export PATH=$PATH:/usr/local/bin
export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:/usr/local/lib
export PKG_CONFIG_PATH=$PKG_CONFIG_PATH:/usr/local/lib/pkgconfig
export PYTHONPATH=$PYTHONPATH:/usr/local/lib/python2.6/site-packages
Also, attempting to from gnuradio import gr in a python prompt returns:
from gnuradio import gr
Traceback (most recent call last):
File stdin, line 1, in module
File
/usr/local/lib/python2.6/dist-packages/gnuradio/gr/__init__.py, line
43, in module
from gnuradio_core import *
File
/usr/local/lib/python2.6/dist-packages/gnuradio/gr/gnuradio_core.py,
line 23, in module
from gnuradio_core_runtime import *
File
/usr/local/lib/python2.6/dist-packages/gnuradio/gr/gnuradio_core_runtime.py,
line 24, in module
_gnuradio_core_runtime = swig_import_helper()
File
/usr/local/lib/python2.6/dist-packages/gnuradio/gr/gnuradio_core_runtime.py,
line 20, in swig_import_helper
_mod = imp.load_module('_gnuradio_core_runtime', fp, pathname,
description)
ImportError: /usr/local/lib/libgnuradio-core-3.4.0git.so.0: undefined
symbol: _ZTIN5gruel12msg_accepterE
Any advice?
On Mon, Apr 4, 2011 at 6:19 PM, Marcus D. Leech mle...@ripnet.com
mailto:mle...@ripnet.com wrote:
From today's GIT, fresh build
./bootstrap
./configure
make
sudo make install
Then when I try to use gnuradio stuff:
from gnuradio import gr
Traceback (most recent call last):
File stdin, line 1, in module
File
/usr/local/lib/python2.6/dist-packages/gnuradio/gr/__init__.py,
line 43, in module
from gnuradio_core import *
File
/usr/local/lib/python2.6/dist-packages/gnuradio/gr/gnuradio_core.py,
line 23, in module
from gnuradio_core_runtime import *
File
/usr/local/lib/python2.6/dist-packages/gnuradio/gr/gnuradio_core_runtime.py,
line 24, in module
_gnuradio_core_runtime = swig_import_helper()
File
/usr/local/lib/python2.6/dist-packages/gnuradio/gr/gnuradio_core_runtime.py,
line 20, in swig_import_helper
_mod = imp.load_module('_gnuradio_core_runtime', fp, pathname,
description)
ImportError: /usr/local/lib/libgnuradio-core-3.4.0git.so.0:
undefined symbol: _ZTIN5gruel12msg_accepterE
Re-did the build a coupla of times, including make clean and
make distclean. Still the same results.
Did a sudo ldconfig just in case it was the LD cache. No dice,
still same problem.
System is Ubuntu 10.10 x86_64
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org mailto: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
pay attention ! on debian based distribution the local pythonpath is
*export PYTHONPATH=$PYTHONPATH:/usr/local/lib/python2.6/dist-packages*
not the one you put in the .bashrc ! I compiled the source tarball
(stable 3.3.0) without any problems in this way
sudo apt-get build-dep gnuradio
./configure
make
and then using the checkinstall utility
sudo checkinstall (instead of make install)
after the generated *.deb is installed digit :
sudo ldconfig
my hypothesis of the wrong pythonpath could be confirmed by your
errorsLet me know
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Build/install on Ubuntu x64 10.10 today
Il 12/04/2011 15:27, Andrew Hofmaier ha scritto:
I got the same error today as Marcus did last week in a fresh install
from next on Ubuntu 10.04 x64. Everything worked fine through the UHD
install, ./bootstrap, ./configure, make, make check, sudo make install
routine. However, attempting to run gnuradio companion reports:
Cannot import gnuradio. Are your PYTHONPATH and LD_LIBRARY_PATH set
correctly?
I have the following in my .bashrc file:
# GNU Radio installation
export PATH=$PATH:/usr/local/bin
export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:/usr/local/lib
export PKG_CONFIG_PATH=$PKG_CONFIG_PATH:/usr/local/lib/pkgconfig
export PYTHONPATH=$PYTHONPATH:/usr/local/lib/python2.6/site-packages
Also, attempting to from gnuradio import gr in a python prompt returns:
from gnuradio import gr
Traceback (most recent call last):
File stdin, line 1, in module
File
/usr/local/lib/python2.6/dist-packages/gnuradio/gr/__init__.py, line
43, in module
from gnuradio_core import *
File
/usr/local/lib/python2.6/dist-packages/gnuradio/gr/gnuradio_core.py,
line 23, in module
from gnuradio_core_runtime import *
File
/usr/local/lib/python2.6/dist-packages/gnuradio/gr/gnuradio_core_runtime.py,
line 24, in module
_gnuradio_core_runtime = swig_import_helper()
File
/usr/local/lib/python2.6/dist-packages/gnuradio/gr/gnuradio_core_runtime.py,
line 20, in swig_import_helper
_mod = imp.load_module('_gnuradio_core_runtime', fp, pathname,
description)
ImportError: /usr/local/lib/libgnuradio-core-3.4.0git.so.0: undefined
symbol: _ZTIN5gruel12msg_accepterE
Any advice?
On Mon, Apr 4, 2011 at 6:19 PM, Marcus D. Leech mle...@ripnet.com
mailto:mle...@ripnet.com wrote:
From today's GIT, fresh build
./bootstrap
./configure
make
sudo make install
Then when I try to use gnuradio stuff:
from gnuradio import gr
Traceback (most recent call last):
File stdin, line 1, in module
File
/usr/local/lib/python2.6/dist-packages/gnuradio/gr/__init__.py,
line 43, in module
from gnuradio_core import *
File
/usr/local/lib/python2.6/dist-packages/gnuradio/gr/gnuradio_core.py,
line 23, in module
from gnuradio_core_runtime import *
File
/usr/local/lib/python2.6/dist-packages/gnuradio/gr/gnuradio_core_runtime.py,
line 24, in module
_gnuradio_core_runtime = swig_import_helper()
File
/usr/local/lib/python2.6/dist-packages/gnuradio/gr/gnuradio_core_runtime.py,
line 20, in swig_import_helper
_mod = imp.load_module('_gnuradio_core_runtime', fp, pathname,
description)
ImportError: /usr/local/lib/libgnuradio-core-3.4.0git.so.0:
undefined symbol: _ZTIN5gruel12msg_accepterE
Re-did the build a coupla of times, including make clean and
make distclean. Still the same results.
Did a sudo ldconfig just in case it was the LD cache. No dice,
still same problem.
System is Ubuntu 10.10 x86_64
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org mailto: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
just forgetting a little thingyou can also don't put any paths in
your .bashrc, sudo ldconfig will take care of all the necessary stuff.
If you use paths you have to logout and then to login again so the OS
is aware of them (every time you add a new one to .bashrc). if you
decide to use checkinstall, after installation edit the configuration file.
/etc/checkinstallrc
and put the TRANSLATE entry from 1 to 0.
Best Regards, Arturo
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Build/install on Ubuntu x64 10.10 today
removing all the paths exported and digit in the terminal sudo ldconfig i'll try with the git version later and post any comment ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Build/install on Ubuntu x64 10.10 today
Il 12/04/2011 20:58, Andrew Hofmaier ha scritto: Performed the following routine: commented all path lines from .bashrc. (I had previously tested it with both dist-packages and site-packages). ran sudo ldconfig restarted ran sudo ldconfig again recieved the same error message (ImportError: /usr/local/lib/libgnuradio-core-3.4.0git.so.0: undefined symbol: _ZTIN5gruel12msg_accepterE) Went back to the source (fresh git download this AM) and: make uninstall ./bootstrap ./configure --enable-gr-uhd make make check sudo make install sudo ldconfig logged out / logged in (just for kicks) I got the same errors (cannot find Gnuradio and the import errors) Then, I tried arturo's method. make uninstall ./configure make sudo checkinstall This gave me the error: dpkg-db: parse error, in file '/var/tmp/tmp.hX5IvZ8xr3/package/DEBIAN/control' near line 10 package 'gnuradio': empty value for version Any further comments? ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio i downloaded the latest git snap this afternoon and the installation was quite smooth. I'll list my procedure step by step : +sudo apt-get build-dep gnuradio +sudo apt-get install libboost1.42-all-dev python-qwt5-qt4 +download and install the following file (the uhd driver) http://www.ettus.com/downloads/uhd_releases/003_000_001/UHD-003.000.001-Ubuntu-10.10-x86_64.deb then +git clone http://gnuradio.org/git/gnuradio.git +./bootstrap +./configure +make +sudo make install (or checkinstall) about the checkinstall error you have to change the value version which is empty. So when asked digit 3 and insert just for example 1:3.4.0-git. +sudo ldconfig +/usr/local/libexec/gnuradio/gcr_setup_freedesktop install (for shortcuts in the start menu and the file associations) you can add this latest directory in your path as export PATH=$PATH:/usr/local/libexec/gnuradio for the gcr_setup_freedesktop script, then logout and login. It worked very fine for me. No problems at all. Please ask me again if you have troubles...follow also Marcus suggestion by purging any other gnuradio installation if existing. Regards, Arturo ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] opengl persistence error
Il 01/04/2011 17:21, Josh Blum ha scritto: On 04/01/2011 07:43 AM, Arturo Rinaldi wrote: Every time I tick the Persistence box in one of the scopes i get this error : Traceback (most recent call last): File /usr/local/lib/python2.6/dist-packages/gnuradio/wxgui/plotter/plotter_base.py, line 192, in _on_paint GL.glAccum(GL.GL_LOAD, 1.0) File /usr/lib/pymodules/python2.6/OpenGL/error.py, line 208, in glCheckError baseOperation = baseOperation, OpenGL.error.GLError: GLError( err = 1282, description = 'invalid operation', baseOperation = glAccum, cArguments = (GL_LOAD, 1.0) ) It happens on all of my computers too. I think the persistence uses a hardware feature that is not widely implemented. -Josh i have correctly installed my ati catalyst drivers on my laptop (latest version). My laptop GPU is a Radeon HD4570 and my OS Ubuntu 10.10. I compiled and installed from source gnuradio v. 3.3.0. Regards Arturo Rinaldi ___ 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 In fact on my nvidia GF 6800GT i have never experienced such an error. Maybe an nVidia cards hardware feature ? ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] GNU Radio release 3.3.0-rc1 tarballs available for download
Il 22/05/2010 01:34, Johnathan Corgan ha scritto: GNU Radio release 3.3.0-rc1 tarballs are available for download: http://gnuradio.org/releases/gnuradio/gnuradio-3.3.0-rc1.tar.gz http://gnuradio.org/releases/gnuradio/gr-howto-write-a-block-3.3.0-rc1.tar.gz md5sums: b936f27cf106b15be0ad7e2066b023be gnuradio-3.3.0-rc1.tar.gz 8d6ea3d7604dba4d920ce4721b76ceae gr-howto-write-a-block-3.3.0-rc1.tar.gz Changelog: Release 3.3.0-rc1 Don Ward (1): howto: fix make check for win32, darwin (untested) Eric Blossom (1): Remove bogus check for existence of prefix directory. John Orlando (8): Update incorrectly checked in Makefile.am Add support for the Bitshark USRP RX (BURX) daughterboard for the USRP1. Add support for the Bitshark USRP RX (BURX) daughterboard for the USRP2. Fixed issue with with wrong Makefile.am files being copied Including bitshark_rx.h header file for USRP2 build Updated db_bitshark_rx.c to the proper version that includes the Once and for all, here is the properly updated Makefile.am for the apps -Updated to allow BURX support to be built into standard txrx.bin Johnathan Corgan (17): usrp: Cleanup for merge of bitshark daughterboard code Change default bandwidth to 25 MHz to match maximum USRP2 bandwidth Merge branch 'master' into wip/burx_support Merge remote branch 'nldudok1/gr-wxgui_emulate_analog' into master gr-wxgui: Renamed emulate analog feature to use persistence gr-wxgui: update copyrights gnuradio-core: Disable (temporarily) interpolator tap calculation build: force use of ltmain.sh from libtool 2.2.6b build: use correct comment delimiter build: distribute version controlled ltmain.sh in tarball Merge remote branch 'bitshark/burx_support' into wip/burx_support Revert build: force use of ltmain.sh from libtool 2.2.6b Revert build: distribute version controlled ltmain.sh in tarball Merge branch 'wip/burx_support' gnuradio-core: removed gr.dd_mpsk_sync_cc block as obsolete grc: rename execution binary from 'grc' to 'gnuradio-companion' Update revision to release 3.3.0-rc1, update autotools Martin Dudok van Heel (1): Add analog CRT screen afterglow emulation for gr-wxgui Regards, Johnathan Corgan Corgan Enterprises LLC ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio i'm experiencing this problem in building on *ubuntu 9.10* the *3.3 RC1 * */usr/include/qwt-qt4/qwt_plot_picker.h:106: warning: 'virtual void QwtPlotPicker::move(const QPoint)' was hidden /usr/include/qwt-qt4/qwt_plot_zoomer.h:88: warning: by 'virtual void QwtPlotZoomer::move(double, double)' In file included from ./plot_waterfall.h:5, from ./WaterfallDisplayPlot.h:9, from WaterfallDisplayPlot.cc:4: ./waterfallGlobalData.h:12: error: ISO C++ forbids declaration of 'uint64_t' with no type ./waterfallGlobalData.h:18: error: ISO C++ forbids declaration of 'uint64_t' with no type ./waterfallGlobalData.h:26: error: 'uint64_t' does not name a type ./waterfallGlobalData.h:27: error: ISO C++ forbids declaration of 'uint64_t' with no type ./waterfallGlobalData.h:39: error: 'uint64_t' does not name a type ./waterfallGlobalData.h:40: error: 'uint64_t' does not name a type ./waterfallGlobalData.h:51: error: ISO C++ forbids declaration of 'uint64_t' with no type ./waterfallGlobalData.h:54: error: ISO C++ forbids declaration of 'uint64_t' with no type /usr/include/qwtplot3d-qt4/qwt3d_function.h:30: warning: 'virtual bool Qwt3D::Function::create(Qwt3D::SurfacePlot)' was hidden ./waterfallGlobalData.h:56: warning: by 'virtual bool Waterfall3DData::create()' /usr/include/qwt-qt4/qwt_plot_picker.h:103: warning: 'virtual QwtText QwtPlotPicker::trackerText(const QPoint) const' was hidden WaterfallDisplayPlot.cc:189: warning: by 'virtual QwtText WaterfallZoomer::trackerText(const QwtDoublePoint) const' make[5]: *** [WaterfallDisplayPlot.lo] Errore 1 make[4]: *** [all] Errore 2 make[3]: *** [all-recursive] Errore 1 make[2]: *** [all-recursive] Errore 1 make[1]: *** [all-recursive] Errore 1 make: *** [all] Errore 2 make[5]: uscita dalla directory «/home/artynet/Scrivania/gnuradio-3.3.0-rc1/gr-qtgui/src/lib» make[4]: uscita dalla directory «/home/artynet/Scrivania/gnuradio-3.3.0-rc1/gr-qtgui/src/lib» make[3]: uscita dalla directory «/home/artynet/Scrivania/gnuradio-3.3.0-rc1/gr-qtgui/src» make[2]: uscita dalla directory «/home/artynet/Scrivania/gnuradio-3.3.0-rc1/gr-qtgui» make[1]: uscita dalla directory «/home/artynet/Scrivania/gnuradio-3.3.0-rc1»* an error in the waterfall sink.where am i wrong ? I installed all the dependencies required fot the 9.10, the configure goes like a charm without any error and then i have this error in building the source hope you can help me :D thx
Re: [Discuss-gnuradio] GNU Radio release 3.3.0-rc1 tarballs available for download
Il 22/05/2010 01:34, Johnathan Corgan ha scritto: GNU Radio release 3.3.0-rc1 tarballs are available for download: http://gnuradio.org/releases/gnuradio/gnuradio-3.3.0-rc1.tar.gz http://gnuradio.org/releases/gnuradio/gr-howto-write-a-block-3.3.0-rc1.tar.gz md5sums: b936f27cf106b15be0ad7e2066b023be gnuradio-3.3.0-rc1.tar.gz 8d6ea3d7604dba4d920ce4721b76ceae gr-howto-write-a-block-3.3.0-rc1.tar.gz Changelog: Release 3.3.0-rc1 Don Ward (1): howto: fix make check for win32, darwin (untested) Eric Blossom (1): Remove bogus check for existence of prefix directory. John Orlando (8): Update incorrectly checked in Makefile.am Add support for the Bitshark USRP RX (BURX) daughterboard for the USRP1. Add support for the Bitshark USRP RX (BURX) daughterboard for the USRP2. Fixed issue with with wrong Makefile.am files being copied Including bitshark_rx.h header file for USRP2 build Updated db_bitshark_rx.c to the proper version that includes the Once and for all, here is the properly updated Makefile.am for the apps -Updated to allow BURX support to be built into standard txrx.bin Johnathan Corgan (17): usrp: Cleanup for merge of bitshark daughterboard code Change default bandwidth to 25 MHz to match maximum USRP2 bandwidth Merge branch 'master' into wip/burx_support Merge remote branch 'nldudok1/gr-wxgui_emulate_analog' into master gr-wxgui: Renamed emulate analog feature to use persistence gr-wxgui: update copyrights gnuradio-core: Disable (temporarily) interpolator tap calculation build: force use of ltmain.sh from libtool 2.2.6b build: use correct comment delimiter build: distribute version controlled ltmain.sh in tarball Merge remote branch 'bitshark/burx_support' into wip/burx_support Revert build: force use of ltmain.sh from libtool 2.2.6b Revert build: distribute version controlled ltmain.sh in tarball Merge branch 'wip/burx_support' gnuradio-core: removed gr.dd_mpsk_sync_cc block as obsolete grc: rename execution binary from 'grc' to 'gnuradio-companion' Update revision to release 3.3.0-rc1, update autotools Martin Dudok van Heel (1): Add analog CRT screen afterglow emulation for gr-wxgui Regards, Johnathan Corgan Corgan Enterprises LLC ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio is it necessary to use the *./boostrap* command before the* ./configure* one with these tarballs ? thx ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] GNU Radio release 3.3.0-rc1 tarballs available for download
Il 22/05/2010 01:34, Johnathan Corgan ha scritto: GNU Radio release 3.3.0-rc1 tarballs are available for download: http://gnuradio.org/releases/gnuradio/gnuradio-3.3.0-rc1.tar.gz http://gnuradio.org/releases/gnuradio/gr-howto-write-a-block-3.3.0-rc1.tar.gz md5sums: b936f27cf106b15be0ad7e2066b023be gnuradio-3.3.0-rc1.tar.gz 8d6ea3d7604dba4d920ce4721b76ceae gr-howto-write-a-block-3.3.0-rc1.tar.gz Changelog: Release 3.3.0-rc1 Don Ward (1): howto: fix make check for win32, darwin (untested) Eric Blossom (1): Remove bogus check for existence of prefix directory. John Orlando (8): Update incorrectly checked in Makefile.am Add support for the Bitshark USRP RX (BURX) daughterboard for the USRP1. Add support for the Bitshark USRP RX (BURX) daughterboard for the USRP2. Fixed issue with with wrong Makefile.am files being copied Including bitshark_rx.h header file for USRP2 build Updated db_bitshark_rx.c to the proper version that includes the Once and for all, here is the properly updated Makefile.am for the apps -Updated to allow BURX support to be built into standard txrx.bin Johnathan Corgan (17): usrp: Cleanup for merge of bitshark daughterboard code Change default bandwidth to 25 MHz to match maximum USRP2 bandwidth Merge branch 'master' into wip/burx_support Merge remote branch 'nldudok1/gr-wxgui_emulate_analog' into master gr-wxgui: Renamed emulate analog feature to use persistence gr-wxgui: update copyrights gnuradio-core: Disable (temporarily) interpolator tap calculation build: force use of ltmain.sh from libtool 2.2.6b build: use correct comment delimiter build: distribute version controlled ltmain.sh in tarball Merge remote branch 'bitshark/burx_support' into wip/burx_support Revert build: force use of ltmain.sh from libtool 2.2.6b Revert build: distribute version controlled ltmain.sh in tarball Merge branch 'wip/burx_support' gnuradio-core: removed gr.dd_mpsk_sync_cc block as obsolete grc: rename execution binary from 'grc' to 'gnuradio-companion' Update revision to release 3.3.0-rc1, update autotools Martin Dudok van Heel (1): Add analog CRT screen afterglow emulation for gr-wxgui Regards, Johnathan Corgan Corgan Enterprises LLC ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio is the *./bootstrap* command needed for these for these tarball or only the *./configure* one ? I mean the sequence : *./boostrap ./configure make make install* or : *./configure make make install* thx in advance :D ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] ploting gnucap simulation data with gnuradio.
Il 15/05/2010 01:02, Eric Blossom ha scritto: On Fri, May 14, 2010 at 06:41:09PM +0200, Josef Vukovic wrote: Hi, I have some data from a gnucap charging capacitor simulation and want to plot it with gnuradio.wxgui.plot. Has someone a python example code How to read the data produced from gnucap in to make gnuradio.wxgui.plot plotting it out? So I think I have to use something like PolyLine(data1, legend= 'charging capacitor', colour = 'red') but how can I fill a python sequence,array,tuple or list with my gnucap data? My data from gnucap looks like this: #Timev(C1) 0. 0. 0.010.46406 0.020.92923 0.031.3717 0.041.7926 . . . . 0.989.9254 0.999.9291 1.9.9325 e 0.0. 0.01 0.04768 . . . . Is there something ready for use in gnuradio which do the task? Or do I have to read the data in with the python file functions (open, read, readline) mfg Josef Vukovic How about just using matplotlib? Eric ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio i used matplotlib with my ber experiment and it is a very powerful libraryi really incourage you using it ;) ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] How to install GnuRadio Notes:
Il 09/05/2010 01:36, William Pretty Security Inc ha scritto: Everyone on the list has been REALLY helpful, so here is my contribution to the list. While I was installing Gnuradio on Ubuntu 9.10, I took careful notes of everything I did. This should be complete instructions. Starting from scratch, with a new install of Ubuntu. Much of this document is cut and pasted from the wiki. What I have done is save you the trouble of searching all over for the information that you need. Hopefully this will be of help to the non-Linux Guru's on the list. Hopefully someone will edit and add to this document to make it even better ... Bill ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio worked perfectly also on ubuntu 10.04. Obviously the requisites are the ones for Lucid ;). I'd also like to add a suggestion. Install *checkinstall* *sudo apt-get install checkinstall* and at the end run *sudo checkinstall* instead of *sudo make install* a deb package will be created to uninstall it easily if desired ;) ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] perform installation by source code got from git
I tried to perform an installation of gnuradio from the source code got from git on ubuntu 10.04. So my steps are : ./bootstrap ./configure ./make ./sudo make install all the processes are fine without problems, however i want to install gnuradio in the path: /usr/lib... not in /usr/local/lib. Which is the file to edit to make my desired path work in the gnuradio install ? Is it the configure or the makefile or both ? thx in advance, Arturo. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] MSK constellation : make and decode
i'd like to make an MSK constellation (1+j,-1+j,-1-j,1-j) and decode it. so i put the code this way modulator : file_source(byte) gr_packed_to_unpacked_(1,MSB) gr_chunks_to_symbols((1+j,-1+j,-1-j,1-j),2) file_sink(complex) demodulator: file_source(complex) gr_constellation_decoder_cb((1+j,-1+j,-1-j,1-j),(0,1,0,1)) gr_unpacked_to_packed(1,MSB) file_sink(byte) i found that the size of the demodulated file is twice the original source file (and not correctly demodulated) due obviously to the value of dimension D=2 in *gr.chunks_to_symbols*. Any hint on how decode the constellation in the correct way or to built it in such 1-D way preserving the orginal size of the file after demodulation ? thx in advance, Arturo ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] how to set the bit time ?
Is it possible to set the *bit time* (i.e. the time of 0 and 1) arbitrarily in gnuradio, so to have an integer multiple of the default one used by gnuradio itself ? thx in advance, Arturo ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] amplitude of gaussian noise (complex) - which one ?
given a gaussian distribution such as: with *zero mean*, which parameter of the function does the amplitude of this block represent ? sigma, sigma^2 , or the whole amplitude before the exponential term (so the variance is always 1) ? I ask you because i didn't find any hint in the documentation. thx in advance for the answer ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Test tarballs for 3.3git
Il 17/01/2010 19:32, Johnathan Corgan ha scritto: Test tarball distribution files have been created for the current 3.3git release under development: http://gnuradio.org/releases/gnuradio/gnuradio-3.3git-594-g02616cf8.tar.gz http://gnuradio.org/releases/gnuradio/gr-howto-write-a-block-3.3git-594-g02616cf8.tar.gz These distribution files should compile and install using the same configure, make, make install process as the current 3.2.2 release files do. The purpose of providing these is to test the distribution tarball creation process, which can fail in ways that wouldn't affect building from a repository checkout. The full set of features for 3.3 release is not in them, nor are there release notes. However, the resulting build should be identical to what you would get if you were to build from our current git master. A word on naming--pre-release tarballs will have 3.3git, followed by the number of revisions since the last tag in the repository, followed by the shortened git commit id they are based on. In this case, we put in a 3.3git tag in the repo when we did the conversion from Subversion, so there have been 594 commits along the master branch since then. (This naming is derived from the output of 'git describe'). For USRP2 users, the associated image files for the firmware and FPGA, respectively, are: http://gnuradio.org/releases/usrp2-bin/trunk/txrx_edk10.1_3.3git-594-g02616cf8.bin http://gnuradio.org/releases/usrp2-bin/trunk/u2_rev3_ise10.1sp3_3.3git-594-g02616cf8.bin Remember, this is not a stable release, but a snapshot of our current development for 3.3. If this turns out to be useful (as measured by feedback on the list or the wiki), we may automate this. Finally, pending further testing, binary packages for Ubuntu 9.10 for this version will be created; those tracking 'unstable' in their package manager will get these automatically when they are ready. Thank you, Johnathan Corgan Corgan Enterprises LLC ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio will these new *.deb binaries be good for updating on ubuntu 9.04 too ? or are they for ubuntu 9.10 specific only? thx in advance for the answer Bye ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] gray code in D8PSK
just a simple questionwhy in D8PSK is the gray coding and decoding
the following ?
*# ---
# Do Gray code
# ---
# binary to gray coding -- constellation does Gray coding
binary_to_gray = {
2 : range(2),
4 : [0,1,3,2],
8 : [0, 1, 3, 2, 7, 6, 4, 5]
#8 : [0, 1, 3, 2, 6, 7, 5, 4] - why not this way in coding ?
}
# gray to binary
gray_to_binary = {
2 : range(2),
4 : [0,1,3,2],
8 : [0, 1, 3, 2, 6, 7, 5, 4]
}*
i was surprised to find a difference in *bynary_to_gray* and*
gray_to_binary* in mapping the eight symbols ! ! ! could you please
explain me the reason ?
thx in advance
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Test tarballs for 3.3git
Il 19/01/2010 19:10, Johnathan Corgan ha scritto: On Tue, Jan 19, 2010 at 05:57, Arturo Rinaldiarty.n...@yahoo.it wrote: will these new *.deb binaries be good for updating on ubuntu 9.04 too ? or are they for ubuntu 9.10 specific only? Right now they will be for Ubuntu 9.10. Unfortunately, 9.04 and 9.10 do not ship with a common version of Boost, so I would have to build a separate set of .debs for 9.04. I may do that if I get the time. Johnathan thank you very much. it would be appreciated (i think) not only by myself ;) Bye, Arturo ;) ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] boost-1.37.0 dependency in 3.2.2 debian packages
Il 19/01/2010 20:06, Johnathan Corgan ha scritto: 2010/1/19 Pedro Lobopjl...@sec.upm.es: I've just tried to install the gnuradio debian packages in Ubuntu 9.10 (Karmic), as per the instructions in http://gnuradio.org/redmine/wiki/gnuradio/DebianPackages, and they don't work. The problem is that the packages depend on boost version = 1.37.0 (as opposed to= 1.37.0) and Karmic ships with 1.38.0. Is there any possibility of having this dependency fixed? I know that I can build from source or even add deb http://mirrors.kernel.org/ubuntu jaunty main universe to the sources.list and get the boost 1.37.0 packages, but it would be very nice to have a working Karmic package. Unfortunately, the Boost ABI changes from release to release, so it is not possible to build GNU Radio binary packages that are dependent on a= version of Boost. Rather, they have to be tied to a specific Boost version. Jaunty ships with 1.35 and 1.37 available. Karmic ships with 1.38 and 1.40 available. So it isn't possible to build binary packages that depend on a common version of Boost for both releases. Right now I am testing the deb file creation process with 3.3git on Karmic (9.10), using Boost 1.40, and these will get posted on gnuradio.org in the unstable repository. Depending on time (and feedback), I will also build binary packages for 3.3git based on Boost 1.37, but it is unclear how to name them or publish them so as to not conflict with the 9.10 ones. Johnathan ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio i've just got the idea that maybe you can publish the patch (the **.orig.tar*, the **.dsc*, the **.diff.gz*) in the folder http://gnuradio.org/ubuntu/dists/unstable/main/source/ as you did for release 472 and 473 so we can eventually build the binary deb packages by ourselves on ubuntu 9.04 or 9.10. Would it be possible or is too difficult to make ? thx ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Audio Overrun ( aOaOaO problem) - how to solve ?
i've got a strange audio overrun (aOaOaO) problem. My scheme is the following : audio_source FFT_graphical sink *signal = audio.source(32000,'plughw:0,0', True) fft = fftsink2.fft_sink_f(panel,title=Spettro Segnale Vocale, sample_rate=64e3,y_per_div=20,ref_level=-70) self.connect(signal,fft)* it happens to get in random way these cases : case 1 : i get it fully working with no errors in the terminal case 2 : it works displaying the FFT with the terminal showing repeatedly the aO error case 3 : it shows the blank display of the FFT with the terminal showing repeatedly the aO error i edited in my home the *config.con*f file in *~./gnuradio* in this way to override the settings: *[DEFAULT] verbose = False [audio] audio_module = audio_alsa # specify which audio module to load, or use auto to have the system # select one. Valid choices depend on your OS and which modules # you've installed, but typically include: auto, audio_alsa, # audio_oss, audio_portaudio, audio_jack, audio_osx, audio_windows [audio_alsa] default_input_device = plughw:0,0 default_output_device = plughw:0,0 period_time = 0.010 # in seconds nperiods = 4 # total buffering = period_time * nperiods verbose = false * i'm using ubuntu 9.04 with the last unstable deb version dated 10.22.2009. If i enter the terminal and digit */asoundconf set-default-card SB/* (SB is my first listed audio card) and reboot it seems to adjust by itself so i just decided to put it in the start commands of the OS. The strange thing is that my laptop is a dual-core laptop and i read that a fast computer could usually help to solve this overrun problem (my previous laptop was not a good one :D). Did i maybe need an update of the alsa drivers ? I hope you can help me thx in advance, Arturo ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] demodulate a CPFSK modulated file - how to
i'm trying to demodulate a *cpfsk* modulation implemented through the block *gr.cpfsk_bc( )* my scheme is : *bytes_source (a byte vector_source with one byte of stuffing inserted as first element of the vector) gr.packed_to_unpacked_bb(1, gr./GR_MSB_FIRST/ ) gr.cpfsk_bc(10,1,200) file_sink (complex type)* then after different un-succeeded attempts to demodulate the modulated file through the quadrature demodulator and converting the float output to byte i was wondering a different approach to demodulate the file by using the block *gr.constellation_decoder_bc( )* and then removing the stuffing byte to obtain the original file. My question so is which are , if possible, the parameters to pass to the constellation decoder in order to demodulate the CPFSK. thx in advance Arturo ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Help to build a loop modulating / de-modulating system
I'm trying to build this kinda of system for my degree thesis. It is a loop system in the sense its structure could be described in this way file source (byte) --- Digital modulator (QAM , PSK , MSK etc) Digital de-modulator - File sink (byte) file source is a text file or a jpeg photo just for example. I read the de-modulator loses the first 5 bits due to the clock recovery, so i wrote a few lines in python, my steps were : *1)* I made a function to read a text file and put its content after converting the single *chars* in *int* with the type converter *ord( )*. Then i put the intS i got in an array with also adding a byte of empty stuffing as the first one ( a single zero). And putting the content in a byte file source. *2)*I connected this byte file source to the modulator (GMSK for example) to get a complex file sink. Then i try to put this last one like *complex* *file source *for my de-modulator. *3)*The output of the de-modulator is a *byte file sink*. but i don't get the data i transmitted ! ! ! ! (i.e. the text file doesn't open) *4)*I tried a different approach by scanning the complex sink output of *2)*, converting the contents to *int* and then putting it in a *complex vector* to feed the de-modulator. the resulting *byte* *file sink *is a text file i can open but i only see the bytes in the text file ! ! ! (the little squares with 1,0 etc) *5)*I tried another approach by converting the complex content of the modulator output to* int* and feeding the intS into a* byte* file sink. The file is then scanned and its contents are put as the array arguments of a *complex vector*. The de-modulator is fed with this complex vector and its output its a byte file sink ( the demodulated one). in all these cases i don't succeed in get any good de-modulated data (i.e. the original text file or a jpeg photo). where am i wrong ? can i get some hints from anyone of you ? thx in advance *@ Richard Clarke* Regarding GNUradio installation on Ubuntu 9.10 i used a little cheat :D. I added the 9.04 repositories to the 9.10 ones and then i was able to install smoothly the DEBs from the gnuradio repository,both the stable and the un-stable ones. So you also get full dependencies if you want to compile from the git code. Bye Arturo ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] gnuradio deb(S) and ubuntu 9.10
hi, i just wanted to know if a new update of gnuradio *debs* is planned, so to ensure the compatibility of the *stable branch* with Ubuntu 9.10. Otherwise, is the unstable branch fully installable through synaptic with the Karmic Koala ? thx in advance Arturo ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Re: GNU Radio release 3.2.1 source and binaries available for download
Johnathan Corgan wrote: On Mon, Jul 6, 2009 at 12:01, Alexandru Cseteoz9...@googlemail.com wrote: Grc in version 3.2 was running fine yesterday. I have also successfully built the 3.2.1 source code earlier today on a different machine running Ubuntu 8.10 64bit where I had no problems executing grc. Any hints appreciated. This may be a problem with the custom grc.conf installed in /etc/gnuradio in the binary packages. Thanks for the report; we're looking into it. Johnathan i experienced the same problem on my ubuntu-9.04 machine (32bit) here's my error log: arty...@artynet-laptop:~$ grc Welcome to GNU Radio Companion 3.2.1 Loading: /home/artynet/Scrivania/grc_work/SIN_WAVES.grc 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' Loading: /home/artynet/Scrivania/grc_work/mod_demod_AM.grc 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' Loading: /home/artynet/Scrivania/grc_work/mod_demod_AM+.grc 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' Loading: /home/artynet/Scrivania/grc_work/mod_demod_AM+.grc 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
[Discuss-gnuradio] Re: Re: GNU Radio release 3.2.1 source and binaries available for download
Johnathan Corgan wrote: On Mon, Jul 6, 2009 at 14:35, Arturo Rinaldili...@ruby-forum.com wrote: i experienced the same problem on my ubuntu-9.04 machine (32bit) here's my error log: We've figured it out and will be updating the binary packages soon. More in another email. Johnathan Great ! It's very kind of youkeep up with this great work ;) bye, Arturo -- Posted via http://www.ruby-forum.com/. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
