[Discuss-gnuradio] Receiving signal from a signal generator
Hi, I've got 2 units of USRP1 and DBSRX dboards. The two USRP are synchronized for master and slave. the uhd_fft.py is responding correctly. Now I want to use a signal generator to provide 900 MHz. signal level is -20 dBm. From the gnuradio-companion, I created a flow graph using UHD-USRP Source connected to WX-GUI-FFT Sink. The setup are as follow: For USRP source: ID: uhd_usrp_source_0 Device Addr: fpga=usrp1_fpga_4rx.rbf Sync: Don'y sink Clock rate: default Num Mboards:1 Mbo Clock source: default Mbo Time source:default Mbo Subdevice Spec: Num Channel: 1 Sample rate (sps): 32K Cho Center freq: 900M Cho Gain:30 dB Cho Antenna: RXA Cho Bandwidth:10M For FFT Sink: Sample rate:32k Baseband freq:900M With this setup, only noise is plotted in the FFT. I don't see the signal at 900MHz. And even if I remove the daughterboard from the usrp, the result is unchanged: Noise only. Can you please tell me what is wrong with the setup, and what to do if I want to use the side B. Also which USRP must I use: the master, the slave or both. Please help. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] FSK using VCO
Anju, Try connecting these data_src(0,1)==>chunk to symbol(-1,1)==>fm modulator(sensitivity=(2*pi*(freq_sep/2.0))/samp_rate)) where freq_sep = symb_rate (for non-coherent detection) On receiver side u can use quadrature demoulator -Adeel On Fri, Feb 17, 2012 at 12:42 AM, anju babu wrote: > > HI all, > > I'm developing an underwater modem which uses acoustic signal > for transmission and reception .for that i need to have a FSK > modulator.since CPFSk is not practically possible in underwater ,i decided > to use VCO.I have to modulate data from a file sourc(output type byte) > using 10khz carrier.i don't know how to do this.when i connected a file > source -uchar to float- vco -scopesink and observed output i couldn't see > what i was expecting.can't i input the vco with a file source?please help > me. > > thanks in advance > ANJU > -- > ** > > ___ > 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] Sampling Rate
Hi, I'm getting confused with the concept of "Sampling rate" to set the UHD:USRP Source and other blocks from the gnuradio-companion. If I'm still right, the sampling rate must be at least the double of the operating frequency. But I can see some working applications when this Nyquist theory is not respected. How come? ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] About how to write c++ based signal processing block
Hi Martin,
i have used gr_modtool.py to create custom blocks and all these new blocks
are working fine. Thanks to u for this good utility.
I have python/gnuradio installed on two machines. Same version of
gr_modtool.py (downloaded yesterday) works fine on one but on second
machine, it creates new module but when we try to add some block, it exits
with following error.
adeel@adeel-desktop:~/Desktop/blocks$ gr_modtool.py newmod mydsp
Module directory is "./gr-mydsp".
Creating directory...
Copying howto example...
Unpacking...
Replacing occurences of 'howto' to 'mydsp'...
Done.
Use 'gr_modtool add' to add a new block to this currently empty module.
adeel@adeel-desktop:~/Desktop/blocks$ cd gr-mydsp/
adeel@adeel-desktop:~/Desktop/blocks/gr-mydsp$ gr_modtool.py add
Operating in directory .
GNU Radio module name identified: mydsp
Enter code type: sync
Code is of type: sync
Enter name of block/code (without module name prefix): algorithm1_ff
Block/code identifier: algorithm1_ff
Full block/code identifier is: mydsp_algorithm1_ff
Enter valid argument list, including default arguments: int x
Add Python QA code? [Y/n] y
Add C++ QA code? [Y/n] n
Traversing lib...
Adding file 'mydsp_algorithm1_ff.h'...
Adding file 'mydsp_algorithm1_ff.cc'...
Traceback (most recent call last):
File "/usr/local/bin/gr_modtool.py", line 2315, in
main()
File "/usr/local/bin/gr_modtool.py", line 2312, in main
modtool.run()
File "/usr/local/bin/gr_modtool.py", line 748, in run
self._run_lib()
File "/usr/local/bin/gr_modtool.py", line 787, in _run_lib
ed.append_value('add_library', fname_cc)
File "/usr/local/bin/gr_modtool.py", line 503, in append_value
count=1, flags=re.MULTILINE)
TypeError: sub() got an unexpected keyword argument 'flags'
adeel@adeel-desktop:~/Desktop/blocks/gr-mydsp$
Thanks,
Adeel
On Wed, Feb 15, 2012 at 12:29 PM, Martin Braun wrote:
> On Wed, Feb 15, 2012 at 11:15:55AM -0600, Alex Zhang wrote:
> > Hi Gurus,
> >
> > To learn how to write the signal processing block over C++, I downloaded
> the
> > gr-how-to-write-a-block and successfully build the block and passed the
> test.
> >
> > But my question is, for a block writer who is not familiar with the
> complex
> > building tree, like the makefile writing, can the future block writing
> just be
> > simply based on the building framework provided by the
> > gr-how-to-write-a-block example? I mean, I do not want to dig too much
> the
> > makefile, but just reuse the current example with minor modification, to
> meet
> > all the requirements from the new block generating.
>
> Sure that's OK.
> You can also use gr_modtool.py (available at
> https://cgran.org/wiki/devtools)
> which does all the Makefile editing for you.
>
> If you're using the autotools version of howto-write-a-block (which
> apparently you are), you need the older version.
>
> MB
>
> --
> Karlsruhe Institute of Technology (KIT)
> Communications Engineering Lab (CEL)
>
> Dipl.-Ing. Martin Braun
> Research Associate
>
> Kaiserstraße 12
> Building 05.01
> 76131 Karlsruhe
>
> Phone: +49 721 608-43790
> Fax: +49 721 608-46071
> www.cel.kit.edu
>
> KIT -- University of the State of Baden-Württemberg and
> National Laboratory of the Helmholtz Association
>
>
> ___
> 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] FSK using VCO
HI all, I'm developing an underwater modem which uses acoustic signal for transmission and reception .for that i need to have a FSK modulator.since CPFSk is not practically possible in underwater ,i decided to use VCO.I have to modulate data from a file sourc(output type byte) using 10khz carrier.i don't know how to do this.when i connected a file source -uchar to float- vco -scopesink and observed output i couldn't see what i was expecting.can't i input the vco with a file source?please help me. thanks in advance ANJU -- ** ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] UHD on USRP1 v < 500
Great, I'll tar the latest *we have* traditional GR and exec $./build-gnuradio Thanks, Patrik - Original Message - From: Marcus D. Leech To: discuss-gnuradio@gnu.org Sent: Friday, February 17, 2012 2:00 Subject: Re: [Discuss-gnuradio] UHD on USRP1 v < 500 On 02/16/2012 06:48 PM, Patrik Tast wrote: Hi all, Thanks for the latest developers call. Q1: will an usrp1 < 500 run using uhd? Yup, I do that all the time. I have a very-early USRP1 and I use it frequently with all the latest UHD goop. Q2: if so, will I then be able to use 8bit samples ie 16 msps? I believe it does, yes. But perhaps Josh can confirm. Q3: If it *doesn't work*, to wich url do I point to get the *traditional GR*? Patrik ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio -- 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 ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] problem building gr-howto-write-a-block-cmake
Tom, Can you also email me the result of a fresh cmake ../ on the gr-howto-write-a-block-cmake/build directory (after removing the CMakeCache.txt file) thanks Achilleas On Thu, Feb 16, 2012 at 4:27 PM, Achilleas Anastasopoulos wrote: > I also noticed the following in the cmake ../ > > -- Found SWIG: /usr/bin/swig (found version "2.0.4") > -- Could NOT find PythonLibs (missing: PYTHON_LIBRARIES) > -- Found PythonInterp: /usr/bin/python2.7 > > > what is the significance of not founding the PythonLibs? > when i build gnuradio it says that it found them > > > -- Configuring python-support support... > -- Dependency PYTHONLIBS_FOUND = TRUE > -- Dependency SWIG_FOUND = TRUE > -- Dependency SWIG_VERSION_CHECK = TRUE > -- Enabling python-support support. > -- Override with -DENABLE_PYTHON=ON/OFF > > > > > Achilleas > > > > On Thu, Feb 16, 2012 at 4:03 PM, Achilleas Anastasopoulos > wrote: >> yes i did that and get the same problem (the swig-related files are not >> built). >> >> BTW, how can using git rm the entire directory gr-howto-cmake >> and download it from the trunk? >> >> thanks >> Achilleas >> >> >> >> On Thu, Feb 16, 2012 at 3:53 PM, Tom Rondeau wrote: >>> On Thu, Feb 16, 2012 at 11:57 AM, Achilleas Anastasopoulos >>> wrote: BTW, I forgot to say that I am building from the latest master branch and I have already built/installed the latest gnuradio from the master branch. Achilleas On Thu, Feb 16, 2012 at 11:49 AM, Achilleas Anastasopoulos wrote: > OK, I am having a problem building the howto module with CMake. > > Here is the output of all the steps: > > > [anastas@jefe build]$ cmake ../ > -- The CXX compiler identification is GNU > -- Check for working CXX compiler: /usr/lib64/ccache/c++ > -- Check for working CXX compiler: /usr/lib64/ccache/c++ -- works > -- Detecting CXX compiler ABI info > -- Detecting CXX compiler ABI info - done > -- Build type not specified: defaulting to release. > -- Boost version: 1.46.0 > -- checking for module 'gruel' > -- found gruel, version 3.5.2git > -- Found GRUEL: /usr/local/lib64/libgruel.so > -- checking for module 'gnuradio-core' > -- found gnuradio-core, version 3.5.2git > -- Found GNURADIO_CORE: /usr/local/lib64/libgnuradio-core.so > -- Boost version: 1.46.0 > -- Found the following Boost libraries: > -- unit_test_framework > -- Found SWIG: /usr/bin/swig (found version "2.0.4") > -- Could NOT find PythonLibs (missing: PYTHON_LIBRARIES) > -- Found PythonInterp: /usr/bin/python2.7 > -- Found Doxygen: /usr/bin/doxygen > -- Configuring done > -- Generating done > -- Build files have been written to: > > /n/harrisville/x/anastas/gnuradio_trunk/gr-howto-write-a-block-cmake/build > > > Then > > > > [anastas@jefe build]$ make > [ 12%] Building CXX object > lib/CMakeFiles/gnuradio-howto.dir/howto_square_ff.cc.o > [ 25%] Building CXX object > lib/CMakeFiles/gnuradio-howto.dir/howto_square2_ff.cc.o > [ 37%] Building CXX object > lib/CMakeFiles/gnuradio-howto.dir/howto_demod_filterbank_ccvc.cc.o > Linking CXX shared library libgnuradio-howto.so > [ 37%] Built target gnuradio-howto > [ 50%] Building CXX object > lib/CMakeFiles/qa_howto_square2_ff.dir/qa_howto_square2_ff.cc.o > Linking CXX executable qa_howto_square2_ff > [ 50%] Built target qa_howto_square2_ff > [ 62%] Building CXX object > lib/CMakeFiles/qa_howto_square_ff.dir/qa_howto_square_ff.cc.o > Linking CXX executable qa_howto_square_ff > [ 62%] Built target qa_howto_square_ff > [ 62%] Generating __init__.pyc > [ 62%] Generating __init__.pyo > [ 87%] Built target pygen_python_6b399 > [ 87%] Shebangin howto_square.py > [100%] Built target pygen_apps_19307 > > > Then > > > [anastas@jefe build]$ sudo make install > Built target gnuradio-howto > Built target qa_howto_square2_ff > Built target qa_howto_square_ff > Built target pygen_python_6b399 > Built target pygen_apps_19307 > Install the project... > -- Install configuration: "Release" > -- Installing: /usr/local/include/howto/howto_api.h > -- Installing: /usr/local/include/howto/howto_square_ff.h > -- Installing: /usr/local/include/howto/howto_square2_ff.h > -- Installing: /usr/local/lib64/libgnuradio-howto.so > -- Removed runtime path from "/usr/local/lib64/libgnuradio-howto.so" > -- Installing: > /usr/local/lib64/python2.7/site-packages/howto/__init__.py > -- Installing: > /usr/local/lib64/python2.7/site-packages/howto/__init__.pyc > -- Installing: > /usr/local/lib64/python2.7/site-packages/howto/__init__.pyo > -- Installing: /usr/local/share/gnuradio/grc/blocks/howto_square_ff.xml
Re: [Discuss-gnuradio] UHD on USRP1 v < 500
On 02/16/2012 06:48 PM, Patrik Tast wrote: Hi all, Thanks for the latest developers call. Q1: will an usrp1 < 500 run using uhd? Yup, I do that all the time. I have a very-early USRP1 and I use it frequently with all the latest UHD goop. Q2: if so, will I then be able to use 8bit samples ie 16 msps? I believe it does, yes. But perhaps Josh can confirm. Q3: If it *doesn't work*, to wich url do I point to get the *traditional GR*? Patrik ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio -- 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
[Discuss-gnuradio] UHD on USRP1 v < 500
Hi all, Thanks for the latest developers call. Q1: will an usrp1 < 500 run using uhd? Q2: if so, will I then be able to use 8bit samples ie 16 msps? Q3: If it *doesn't work*, to wich url do I point to get the *traditional GR*? Patrik___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] E100 compile error: trondeau safe_align branch
On 02/16/2012 02:10 PM, Nowlan, Sean wrote:
> Actually, what's the difference between "-march=armv7-a -mtune=cortex-a8" and
> "-mcpu=cortex-a8"?
I think the second is a deprecated way to say the first.
-Josh
>
> -Original Message-
> From: discuss-gnuradio-bounces+sean.nowlan=gtri.gatech@gnu.org
> [mailto:discuss-gnuradio-bounces+sean.nowlan=gtri.gatech@gnu.org] On
> Behalf Of Nowlan, Sean
> Sent: Thursday, February 16, 2012 4:39 PM
> To: Philip Balister; GNURadio Discussion List
> Subject: Re: [Discuss-gnuradio] E100 compile error: trondeau safe_align branch
>
> That was the next thing I did and now (4 hours later :-P) it appears to have
> worked. I'm not sure why it didn't pick up CMAKE_TOOLCHAIN_FILE.
>
> Thanks,
> Sean
>
> -Original Message-
> From: Philip Balister [mailto:phi...@balister.org]
> Sent: Thursday, February 16, 2012 1:16 PM
> To: Nowlan, Sean; GNURadio Discussion List
> Subject: Re: [Discuss-gnuradio] E100 compile error: trondeau safe_align branch
>
> On 02/16/2012 09:39 AM, Nowlan, Sean wrote:
>> Hi all,
>>
>> I'm trying to build Tom's branch with the recent changes to use Volk, but
>> I'm getting an error. I ran this command:
>>
>> cmake -DCMAKE_INSTALL_PREFIX=/usr
>> -DCMAKE_TOOLCHAIN_FILE=../cmake/Toolchains/arm_cortex_a8_native.cmake
>> -DENABLE_GR_QTGUI=OFF -DCMAKE_BUILD_TYPE=release ../
>>
>> And got this error:
>>
>> [ 18%] generating filter files
>> [ 18%] Building CXX object
>> gnuradio-core/src/lib/CMakeFiles/gnuradio-core.dir/filter/sysconfig_ar
>> mv7_a.cc.o [ 18%] Building CXX object
>> gnuradio-core/src/lib/CMakeFiles/gnuradio-core.dir/filter/gr_fir_sysco
>> nfig_armv7_a.cc.o [ 18%] Building CXX object
>> gnuradio-core/src/lib/CMakeFiles/gnuradio-core.dir/filter/gr_cpu_armv7
>> _a.cc.o [ 18%] Building CXX object
>> gnuradio-core/src/lib/CMakeFiles/gnuradio-core.dir/filter/gr_fir_fff_a
>> rmv7_a.cc.o [ 18%] Building C object
>> gnuradio-core/src/lib/CMakeFiles/gnuradio-core.dir/filter/dotprod_fff_
>> armv7_a.c.o
>> /tmp/cct93Ve1.s: Assembler messages:
>> /tmp/cct93Ve1.s:27: Error: bad instruction `vmov.f32 q8,#0.0'
>> /tmp/cct93Ve1.s:28: Error: bad instruction `vmov.f32 q9,#0.0'
>> /tmp/cct93Ve1.s:31: Error: bad instruction `vld1.32 {d0,d1,d2,d3},[r3]!'
>> /tmp/cct93Ve1.s:32: Error: bad instruction `vld1.32 {d4,d5,d6,d7},[r1]!'
>> /tmp/cct93Ve1.s:33: Error: bad instruction `vmla.f32 q8,q0,q2'
>> /tmp/cct93Ve1.s:34: Error: bad instruction `vmla.f32 q9,q1,q3'
>> /tmp/cct93Ve1.s:36: Error: bad instruction `vadd.f32 q8,q8,q9'
>> /tmp/cct93Ve1.s:37: Error: bad instruction `vpadd.f32 d0,d16,d17'
>> /tmp/cct93Ve1.s:38: Error: bad instruction `vadd.f32 s16,s0,s1'
>> make[2]: ***
>> [gnuradio-core/src/lib/CMakeFiles/gnuradio-core.dir/filter/dotprod_fff
>> _armv7_a.c.o] Error 1
>> make[1]: *** [gnuradio-core/src/lib/CMakeFiles/gnuradio-core.dir/all]
>> Error 2
>> make: *** [all] Error 2
>>
>> Any hints/ideas? Thanks!
>
> I feel like the flags from the toolchain file are not getting through to gcc,
> try passing the compiler flags via the command line.
>
> Philip
>
>>
>> Sean
>>
>>
>>
>>
>> ___
>> 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 mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] E100 compile error: trondeau safe_align branch
Actually, what's the difference between "-march=armv7-a -mtune=cortex-a8" and
"-mcpu=cortex-a8"?
-Original Message-
From: discuss-gnuradio-bounces+sean.nowlan=gtri.gatech@gnu.org
[mailto:discuss-gnuradio-bounces+sean.nowlan=gtri.gatech@gnu.org] On Behalf
Of Nowlan, Sean
Sent: Thursday, February 16, 2012 4:39 PM
To: Philip Balister; GNURadio Discussion List
Subject: Re: [Discuss-gnuradio] E100 compile error: trondeau safe_align branch
That was the next thing I did and now (4 hours later :-P) it appears to have
worked. I'm not sure why it didn't pick up CMAKE_TOOLCHAIN_FILE.
Thanks,
Sean
-Original Message-
From: Philip Balister [mailto:phi...@balister.org]
Sent: Thursday, February 16, 2012 1:16 PM
To: Nowlan, Sean; GNURadio Discussion List
Subject: Re: [Discuss-gnuradio] E100 compile error: trondeau safe_align branch
On 02/16/2012 09:39 AM, Nowlan, Sean wrote:
> Hi all,
>
> I'm trying to build Tom's branch with the recent changes to use Volk, but I'm
> getting an error. I ran this command:
>
> cmake -DCMAKE_INSTALL_PREFIX=/usr
> -DCMAKE_TOOLCHAIN_FILE=../cmake/Toolchains/arm_cortex_a8_native.cmake
> -DENABLE_GR_QTGUI=OFF -DCMAKE_BUILD_TYPE=release ../
>
> And got this error:
>
> [ 18%] generating filter files
> [ 18%] Building CXX object
> gnuradio-core/src/lib/CMakeFiles/gnuradio-core.dir/filter/sysconfig_ar
> mv7_a.cc.o [ 18%] Building CXX object
> gnuradio-core/src/lib/CMakeFiles/gnuradio-core.dir/filter/gr_fir_sysco
> nfig_armv7_a.cc.o [ 18%] Building CXX object
> gnuradio-core/src/lib/CMakeFiles/gnuradio-core.dir/filter/gr_cpu_armv7
> _a.cc.o [ 18%] Building CXX object
> gnuradio-core/src/lib/CMakeFiles/gnuradio-core.dir/filter/gr_fir_fff_a
> rmv7_a.cc.o [ 18%] Building C object
> gnuradio-core/src/lib/CMakeFiles/gnuradio-core.dir/filter/dotprod_fff_
> armv7_a.c.o
> /tmp/cct93Ve1.s: Assembler messages:
> /tmp/cct93Ve1.s:27: Error: bad instruction `vmov.f32 q8,#0.0'
> /tmp/cct93Ve1.s:28: Error: bad instruction `vmov.f32 q9,#0.0'
> /tmp/cct93Ve1.s:31: Error: bad instruction `vld1.32 {d0,d1,d2,d3},[r3]!'
> /tmp/cct93Ve1.s:32: Error: bad instruction `vld1.32 {d4,d5,d6,d7},[r1]!'
> /tmp/cct93Ve1.s:33: Error: bad instruction `vmla.f32 q8,q0,q2'
> /tmp/cct93Ve1.s:34: Error: bad instruction `vmla.f32 q9,q1,q3'
> /tmp/cct93Ve1.s:36: Error: bad instruction `vadd.f32 q8,q8,q9'
> /tmp/cct93Ve1.s:37: Error: bad instruction `vpadd.f32 d0,d16,d17'
> /tmp/cct93Ve1.s:38: Error: bad instruction `vadd.f32 s16,s0,s1'
> make[2]: ***
> [gnuradio-core/src/lib/CMakeFiles/gnuradio-core.dir/filter/dotprod_fff
> _armv7_a.c.o] Error 1
> make[1]: *** [gnuradio-core/src/lib/CMakeFiles/gnuradio-core.dir/all]
> Error 2
> make: *** [all] Error 2
>
> Any hints/ideas? Thanks!
I feel like the flags from the toolchain file are not getting through to gcc,
try passing the compiler flags via the command line.
Philip
>
> Sean
>
>
>
>
> ___
> 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 mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Volk branch on github
On Thu, Feb 16, 2012 at 1:47 PM, Josh Blum wrote: > > > On 02/16/2012 01:30 PM, Douglas Geiger wrote: > > On Thu, Feb 16, 2012 at 2:08 PM, Josh Blum wrote: > >> > >> Perhaps this is because you have a processor that doesn't penalize you > >> for unaligned loads/stores. > >> > >> -Josh > > > > Which suggests this decision may need to be made on a > > per-arch/processor basis, and therefore it may be most appropriate for > > Volk to figure it out rather than the scheduler. > > > > There was some talk about making volk handle head cases (most kernels > already handle tail cases). > > This would mean writing a volk_32f_x2_multiply_32f that calls > volk_32f_x2_multiply_32f_a and volk_32f_x2_multiply_32f_u based on the > boundary conditions. > > Such a thing could be generated, so long as we have a way to convey to > the generator something about the parameters. Maybe we just need the > framework... and every time someone wants a volk kernel that handles > head and tail cases, they just fill in a few lines to the generator. > The side benefit to this approach is it lets us get rid of the tacky _a/_u suffixes and just use a single function call without the user worrying about alignment. --n > > -Josh > > ___ > Discuss-gnuradio mailing list > Discuss-gnuradio@gnu.org > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio > ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Volk branch on github
On 02/16/2012 01:30 PM, Douglas Geiger wrote: > On Thu, Feb 16, 2012 at 2:08 PM, Josh Blum wrote: >> >> Perhaps this is because you have a processor that doesn't penalize you >> for unaligned loads/stores. >> >> -Josh > > Which suggests this decision may need to be made on a > per-arch/processor basis, and therefore it may be most appropriate for > Volk to figure it out rather than the scheduler. > There was some talk about making volk handle head cases (most kernels already handle tail cases). This would mean writing a volk_32f_x2_multiply_32f that calls volk_32f_x2_multiply_32f_a and volk_32f_x2_multiply_32f_u based on the boundary conditions. Such a thing could be generated, so long as we have a way to convey to the generator something about the parameters. Maybe we just need the framework... and every time someone wants a volk kernel that handles head and tail cases, they just fill in a few lines to the generator. -Josh ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] ATSC decoding - Now Working!
No, I don't know where that is... I can always take more data though. I'll post it on a Dropbox tonight or this weekend. I'm pretty sure the Gnuradio ATSC decoder is suffering from some massive bitrot though. If you do get it working for you, *please* post your changes for inclusion into Gnuradio! --n On Thu, Feb 16, 2012 at 1:31 PM, shea_watson wrote: > > Nick, > > I apologize if this is bringing back old ghosts but I am doing research > with > ATSC signals and gnuradio and would like that sample ATSC capture that you > posted. i cannot find where you posted it. Do you happen to still have > it? > > Thanks, > SW > > > Nick Foster-4 wrote: > > > > Achilleas, > > > > I live all of a half mile away from the local 10MW broadcast tower, so I > > can almost hear ATSC in my fillings at night. I'll get an ATSC capture > > and post it online tonight. > > > > --n > > > > On Fri, 2010-10-29 at 10:02 -0400, Achilleas Anastasopoulos wrote: > >> Bryce and others, > >> > >> is there any way someone can post captured sample atsc files for > >> downloading and testing. > >> > >> I have some ideas for improving the atsc implementation but need to test > >> some things before i propose something meaningful... > >> > >> Thanks > >> Achilleas > >> > >> ___ > >> 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 > > > > > > -- > View this message in context: > http://old.nabble.com/Re%3A-Re%3A-ATSC-decoding---Now-Working%21-tp30073408p1099.html > Sent from the GnuRadio mailing list archive at Nabble.com. > > > ___ > Discuss-gnuradio mailing list > Discuss-gnuradio@gnu.org > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio > ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] E100 compile error: trondeau safe_align branch
That was the next thing I did and now (4 hours later :-P) it appears to have
worked. I'm not sure why it didn't pick up CMAKE_TOOLCHAIN_FILE.
Thanks,
Sean
-Original Message-
From: Philip Balister [mailto:phi...@balister.org]
Sent: Thursday, February 16, 2012 1:16 PM
To: Nowlan, Sean; GNURadio Discussion List
Subject: Re: [Discuss-gnuradio] E100 compile error: trondeau safe_align branch
On 02/16/2012 09:39 AM, Nowlan, Sean wrote:
> Hi all,
>
> I'm trying to build Tom's branch with the recent changes to use Volk, but I'm
> getting an error. I ran this command:
>
> cmake -DCMAKE_INSTALL_PREFIX=/usr
> -DCMAKE_TOOLCHAIN_FILE=../cmake/Toolchains/arm_cortex_a8_native.cmake
> -DENABLE_GR_QTGUI=OFF -DCMAKE_BUILD_TYPE=release ../
>
> And got this error:
>
> [ 18%] generating filter files
> [ 18%] Building CXX object
> gnuradio-core/src/lib/CMakeFiles/gnuradio-core.dir/filter/sysconfig_ar
> mv7_a.cc.o [ 18%] Building CXX object
> gnuradio-core/src/lib/CMakeFiles/gnuradio-core.dir/filter/gr_fir_sysco
> nfig_armv7_a.cc.o [ 18%] Building CXX object
> gnuradio-core/src/lib/CMakeFiles/gnuradio-core.dir/filter/gr_cpu_armv7
> _a.cc.o [ 18%] Building CXX object
> gnuradio-core/src/lib/CMakeFiles/gnuradio-core.dir/filter/gr_fir_fff_a
> rmv7_a.cc.o [ 18%] Building C object
> gnuradio-core/src/lib/CMakeFiles/gnuradio-core.dir/filter/dotprod_fff_
> armv7_a.c.o
> /tmp/cct93Ve1.s: Assembler messages:
> /tmp/cct93Ve1.s:27: Error: bad instruction `vmov.f32 q8,#0.0'
> /tmp/cct93Ve1.s:28: Error: bad instruction `vmov.f32 q9,#0.0'
> /tmp/cct93Ve1.s:31: Error: bad instruction `vld1.32 {d0,d1,d2,d3},[r3]!'
> /tmp/cct93Ve1.s:32: Error: bad instruction `vld1.32 {d4,d5,d6,d7},[r1]!'
> /tmp/cct93Ve1.s:33: Error: bad instruction `vmla.f32 q8,q0,q2'
> /tmp/cct93Ve1.s:34: Error: bad instruction `vmla.f32 q9,q1,q3'
> /tmp/cct93Ve1.s:36: Error: bad instruction `vadd.f32 q8,q8,q9'
> /tmp/cct93Ve1.s:37: Error: bad instruction `vpadd.f32 d0,d16,d17'
> /tmp/cct93Ve1.s:38: Error: bad instruction `vadd.f32 s16,s0,s1'
> make[2]: ***
> [gnuradio-core/src/lib/CMakeFiles/gnuradio-core.dir/filter/dotprod_fff
> _armv7_a.c.o] Error 1
> make[1]: *** [gnuradio-core/src/lib/CMakeFiles/gnuradio-core.dir/all]
> Error 2
> make: *** [all] Error 2
>
> Any hints/ideas? Thanks!
I feel like the flags from the toolchain file are not getting through to gcc,
try passing the compiler flags via the command line.
Philip
>
> Sean
>
>
>
>
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] ATSC decoding - Now Working!
Nick, I apologize if this is bringing back old ghosts but I am doing research with ATSC signals and gnuradio and would like that sample ATSC capture that you posted. i cannot find where you posted it. Do you happen to still have it? Thanks, SW Nick Foster-4 wrote: > > Achilleas, > > I live all of a half mile away from the local 10MW broadcast tower, so I > can almost hear ATSC in my fillings at night. I'll get an ATSC capture > and post it online tonight. > > --n > > On Fri, 2010-10-29 at 10:02 -0400, Achilleas Anastasopoulos wrote: >> Bryce and others, >> >> is there any way someone can post captured sample atsc files for >> downloading and testing. >> >> I have some ideas for improving the atsc implementation but need to test >> some things before i propose something meaningful... >> >> Thanks >> Achilleas >> >> ___ >> 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 > > -- View this message in context: http://old.nabble.com/Re%3A-Re%3A-ATSC-decoding---Now-Working%21-tp30073408p1099.html Sent from the GnuRadio mailing list archive at Nabble.com. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Volk branch on github
On Thu, Feb 16, 2012 at 2:08 PM, Josh Blum wrote: > > Perhaps this is because you have a processor that doesn't penalize you > for unaligned loads/stores. > > -Josh Which suggests this decision may need to be made on a per-arch/processor basis, and therefore it may be most appropriate for Volk to figure it out rather than the scheduler. -- Doug Geiger doug.gei...@bioradiation.net ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] problem building gr-howto-write-a-block-cmake
I also noticed the following in the cmake ../ -- Found SWIG: /usr/bin/swig (found version "2.0.4") -- Could NOT find PythonLibs (missing: PYTHON_LIBRARIES) -- Found PythonInterp: /usr/bin/python2.7 what is the significance of not founding the PythonLibs? when i build gnuradio it says that it found them -- Configuring python-support support... -- Dependency PYTHONLIBS_FOUND = TRUE -- Dependency SWIG_FOUND = TRUE -- Dependency SWIG_VERSION_CHECK = TRUE -- Enabling python-support support. -- Override with -DENABLE_PYTHON=ON/OFF Achilleas On Thu, Feb 16, 2012 at 4:03 PM, Achilleas Anastasopoulos wrote: > yes i did that and get the same problem (the swig-related files are not > built). > > BTW, how can using git rm the entire directory gr-howto-cmake > and download it from the trunk? > > thanks > Achilleas > > > > On Thu, Feb 16, 2012 at 3:53 PM, Tom Rondeau wrote: >> On Thu, Feb 16, 2012 at 11:57 AM, Achilleas Anastasopoulos >> wrote: >>> >>> BTW, I forgot to say that I am building from the latest master branch >>> and I have already built/installed the latest gnuradio from >>> the master branch. >>> >>> Achilleas >>> >>> On Thu, Feb 16, 2012 at 11:49 AM, Achilleas Anastasopoulos >>> wrote: >>> > OK, I am having a problem building the howto module with CMake. >>> > >>> > Here is the output of all the steps: >>> > >>> > >>> > [anastas@jefe build]$ cmake ../ >>> > -- The CXX compiler identification is GNU >>> > -- Check for working CXX compiler: /usr/lib64/ccache/c++ >>> > -- Check for working CXX compiler: /usr/lib64/ccache/c++ -- works >>> > -- Detecting CXX compiler ABI info >>> > -- Detecting CXX compiler ABI info - done >>> > -- Build type not specified: defaulting to release. >>> > -- Boost version: 1.46.0 >>> > -- checking for module 'gruel' >>> > -- found gruel, version 3.5.2git >>> > -- Found GRUEL: /usr/local/lib64/libgruel.so >>> > -- checking for module 'gnuradio-core' >>> > -- found gnuradio-core, version 3.5.2git >>> > -- Found GNURADIO_CORE: /usr/local/lib64/libgnuradio-core.so >>> > -- Boost version: 1.46.0 >>> > -- Found the following Boost libraries: >>> > -- unit_test_framework >>> > -- Found SWIG: /usr/bin/swig (found version "2.0.4") >>> > -- Could NOT find PythonLibs (missing: PYTHON_LIBRARIES) >>> > -- Found PythonInterp: /usr/bin/python2.7 >>> > -- Found Doxygen: /usr/bin/doxygen >>> > -- Configuring done >>> > -- Generating done >>> > -- Build files have been written to: >>> > >>> > /n/harrisville/x/anastas/gnuradio_trunk/gr-howto-write-a-block-cmake/build >>> > >>> > >>> > Then >>> > >>> > >>> > >>> > [anastas@jefe build]$ make >>> > [ 12%] Building CXX object >>> > lib/CMakeFiles/gnuradio-howto.dir/howto_square_ff.cc.o >>> > [ 25%] Building CXX object >>> > lib/CMakeFiles/gnuradio-howto.dir/howto_square2_ff.cc.o >>> > [ 37%] Building CXX object >>> > lib/CMakeFiles/gnuradio-howto.dir/howto_demod_filterbank_ccvc.cc.o >>> > Linking CXX shared library libgnuradio-howto.so >>> > [ 37%] Built target gnuradio-howto >>> > [ 50%] Building CXX object >>> > lib/CMakeFiles/qa_howto_square2_ff.dir/qa_howto_square2_ff.cc.o >>> > Linking CXX executable qa_howto_square2_ff >>> > [ 50%] Built target qa_howto_square2_ff >>> > [ 62%] Building CXX object >>> > lib/CMakeFiles/qa_howto_square_ff.dir/qa_howto_square_ff.cc.o >>> > Linking CXX executable qa_howto_square_ff >>> > [ 62%] Built target qa_howto_square_ff >>> > [ 62%] Generating __init__.pyc >>> > [ 62%] Generating __init__.pyo >>> > [ 87%] Built target pygen_python_6b399 >>> > [ 87%] Shebangin howto_square.py >>> > [100%] Built target pygen_apps_19307 >>> > >>> > >>> > Then >>> > >>> > >>> > [anastas@jefe build]$ sudo make install >>> > Built target gnuradio-howto >>> > Built target qa_howto_square2_ff >>> > Built target qa_howto_square_ff >>> > Built target pygen_python_6b399 >>> > Built target pygen_apps_19307 >>> > Install the project... >>> > -- Install configuration: "Release" >>> > -- Installing: /usr/local/include/howto/howto_api.h >>> > -- Installing: /usr/local/include/howto/howto_square_ff.h >>> > -- Installing: /usr/local/include/howto/howto_square2_ff.h >>> > -- Installing: /usr/local/lib64/libgnuradio-howto.so >>> > -- Removed runtime path from "/usr/local/lib64/libgnuradio-howto.so" >>> > -- Installing: >>> > /usr/local/lib64/python2.7/site-packages/howto/__init__.py >>> > -- Installing: >>> > /usr/local/lib64/python2.7/site-packages/howto/__init__.pyc >>> > -- Installing: >>> > /usr/local/lib64/python2.7/site-packages/howto/__init__.pyo >>> > -- Installing: /usr/local/share/gnuradio/grc/blocks/howto_square_ff.xml >>> > -- Installing: /usr/local/share/gnuradio/grc/blocks/howto_square2_ff.xml >>> > -- Installing: /usr/local/bin/howto_square.py >>> > >>> > >>> > Now in python I try: >>> > >>> > [anastas@jefe build]$ python >>> > Python 2.7.1 (r271:86832, Apr 12 2011, 16:15:16) >>> > [GCC 4.6.0 20110331 (Red Hat 4.6.0-2)] on linux2 >>> > Type "help", "copyright", "credits" or "license" for more in
[Discuss-gnuradio] Using volk in Mac: test report
Hi all,
We are using the volk library in a C++ program that uses
gnuradio-core and currently builds under Linux and MacOS X. In MacOS
1.6.8 (Snow Leopard, updated), I used macports for installing
gnuradio-core (which is in version 3.3, enough for my app). Since, in
my understanding (please correct me if I'm wrong), volk is a library
that can live independently from the gnuradio version, I did the
following:
$ git clone git://gnuradio.org/gnuradio
$ cd gnuradio/volk
$ cmake .
$ make
...
[100%] Built target volk_profile
$ sudo make install
Then I ran the tests:
$ lib/test_all
All test but one passed, and I see that in some functions the generic
architecture is the best one, which is beyond my understanding. The
test that failed is:
...
volk_32fc_32f_multiply_32fc_a: fail on arch sse
Best arch: sse
/Users/carlesfernandez/Documents/workspace/gnuradio/volk/lib/testqa.cc:25:
error in "volk_32fc_32f_multiply_32fc_a_test": check
run_volk_tests(volk_32fc_32f_multiply_32fc_a_get_func_desc(), (void
(*)())volk_32fc_32f_multiply_32fc_a_manual,
std::string("volk_32fc_32f_multiply_32fc_a"), 1e-4, 0, 20460, 1, 0) ==
0 failed [true != 0]
...
I'm quite happy because I see dramatic improvements in some functions
of my interest (basically I want to implement correlators and mixers,
so I'm sensible precisely to this function, bad luck), but this
"generic" superiority in some cases intrigues me. I would appreciate
if anyone can shed some light on the internals of volk, or if I have
to configure or install something else. Anyway, thanks to the
developers for releasing such interesting stuff :-)
This is the complete output, for the records:
volk carlesfernandez$ cmake .
-- The C compiler identification is GNU
-- The CXX compiler identification is GNU
-- Checking whether C compiler has -isysroot
-- Checking whether C compiler has -isysroot - yes
-- Checking whether C compiler supports OSX deployment target flag
-- Checking whether C compiler supports OSX deployment target flag - yes
-- Check for working C compiler: /usr/local/bin/gcc
-- Check for working C compiler: /usr/local/bin/gcc -- works
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Checking whether CXX compiler has -isysroot
-- Checking whether CXX compiler has -isysroot - yes
-- Checking whether CXX compiler supports OSX deployment target flag
-- Checking whether CXX compiler supports OSX deployment target flag - yes
-- Check for working CXX compiler: /usr/bin/c++
-- Check for working CXX compiler: /usr/bin/c++ -- works
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Found PythonInterp: /opt/local/bin/python (found version "2.6.7")
-- Boost version: 1.48.0
-- Found the following Boost libraries:
-- unit_test_framework
-- checking for module 'orc-0.4'
-- package 'orc-0.4' not found
-- orc files (missing: ORC_LIBRARY ORC_INCLUDE_DIR ORCC_EXECUTABLE)
-- Check size of void*
-- Check size of void* - done
-- Performing Test have_maltivec
-- Performing Test have_maltivec - Failed
-- Performing Test have_mfpu=neon
-- Performing Test have_mfpu=neon - Failed
-- Performing Test have_mfloat-abi=softfp
-- Performing Test have_mfloat-abi=softfp - Failed
-- Performing Test have_funsafe-math-optimizations
-- Performing Test have_funsafe-math-optimizations - Success
-- 32 overruled
-- Performing Test have_m64
-- Performing Test have_m64 - Success
-- Performing Test have_m3dnow
-- Performing Test have_m3dnow - Success
-- Performing Test have_msse4.2
-- Performing Test have_msse4.2 - Success
-- Performing Test have_mpopcnt
-- Performing Test have_mpopcnt - Failed
-- Performing Test have_mmmx
-- Performing Test have_mmmx - Success
-- Performing Test have_msse
-- Performing Test have_msse - Success
-- Performing Test have_msse2
-- Performing Test have_msse2 - Success
-- orc overruled
-- Performing Test have_msse3
-- Performing Test have_msse3 - Success
-- Performing Test have_mssse3
-- Performing Test have_mssse3 - Success
-- Performing Test have_msse4a
-- Performing Test have_msse4a - Success
-- Performing Test have_msse4.1
-- Performing Test have_msse4.1 - Success
-- Performing Test have_mavx
-- Performing Test have_mavx - Failed
-- Available arches:
generic;64;3dnow;abm;mmx;sse;sse2;sse3;ssse3;sse4_a;sse4_1;sse4_2
-- Available machines: generic;sse2_only;sse2_64;sse3_64;ssse3_64;sse4_1_64
-- Did not find liborc and orcc, disabling orc support...
-- Using install prefix: /usr/local
-- Configuring done
-- Generating done
Tests output:
Running 77 test cases...
Using Volk machine: sse4_1_64
RUN_VOLK_TESTS: volk_16ic_s32f_deinterleave_real_32f_a
sse4_1 completed in 1.5e-05s
sse completed in 5.5e-05s
generic completed in 1.4e-05s
Best arch: generic
RUN_VOLK_TESTS: volk_16ic_deinterleave_real_8i_a
ssse3 completed in 7e-06s
generic completed in 8e-06s
Best arch: ssse3
RUN_VOLK_TESTS: volk_16ic_deinterleave_16i_x2_a
ssse3 completed in 1.7e-05s
sse2 completed in 1.1e-05s
generic completed in 2.1e-05s
Best arch:
Re: [Discuss-gnuradio] problem building gr-howto-write-a-block-cmake
yes i did that and get the same problem (the swig-related files are not built). BTW, how can using git rm the entire directory gr-howto-cmake and download it from the trunk? thanks Achilleas On Thu, Feb 16, 2012 at 3:53 PM, Tom Rondeau wrote: > On Thu, Feb 16, 2012 at 11:57 AM, Achilleas Anastasopoulos > wrote: >> >> BTW, I forgot to say that I am building from the latest master branch >> and I have already built/installed the latest gnuradio from >> the master branch. >> >> Achilleas >> >> On Thu, Feb 16, 2012 at 11:49 AM, Achilleas Anastasopoulos >> wrote: >> > OK, I am having a problem building the howto module with CMake. >> > >> > Here is the output of all the steps: >> > >> > >> > [anastas@jefe build]$ cmake ../ >> > -- The CXX compiler identification is GNU >> > -- Check for working CXX compiler: /usr/lib64/ccache/c++ >> > -- Check for working CXX compiler: /usr/lib64/ccache/c++ -- works >> > -- Detecting CXX compiler ABI info >> > -- Detecting CXX compiler ABI info - done >> > -- Build type not specified: defaulting to release. >> > -- Boost version: 1.46.0 >> > -- checking for module 'gruel' >> > -- found gruel, version 3.5.2git >> > -- Found GRUEL: /usr/local/lib64/libgruel.so >> > -- checking for module 'gnuradio-core' >> > -- found gnuradio-core, version 3.5.2git >> > -- Found GNURADIO_CORE: /usr/local/lib64/libgnuradio-core.so >> > -- Boost version: 1.46.0 >> > -- Found the following Boost libraries: >> > -- unit_test_framework >> > -- Found SWIG: /usr/bin/swig (found version "2.0.4") >> > -- Could NOT find PythonLibs (missing: PYTHON_LIBRARIES) >> > -- Found PythonInterp: /usr/bin/python2.7 >> > -- Found Doxygen: /usr/bin/doxygen >> > -- Configuring done >> > -- Generating done >> > -- Build files have been written to: >> > >> > /n/harrisville/x/anastas/gnuradio_trunk/gr-howto-write-a-block-cmake/build >> > >> > >> > Then >> > >> > >> > >> > [anastas@jefe build]$ make >> > [ 12%] Building CXX object >> > lib/CMakeFiles/gnuradio-howto.dir/howto_square_ff.cc.o >> > [ 25%] Building CXX object >> > lib/CMakeFiles/gnuradio-howto.dir/howto_square2_ff.cc.o >> > [ 37%] Building CXX object >> > lib/CMakeFiles/gnuradio-howto.dir/howto_demod_filterbank_ccvc.cc.o >> > Linking CXX shared library libgnuradio-howto.so >> > [ 37%] Built target gnuradio-howto >> > [ 50%] Building CXX object >> > lib/CMakeFiles/qa_howto_square2_ff.dir/qa_howto_square2_ff.cc.o >> > Linking CXX executable qa_howto_square2_ff >> > [ 50%] Built target qa_howto_square2_ff >> > [ 62%] Building CXX object >> > lib/CMakeFiles/qa_howto_square_ff.dir/qa_howto_square_ff.cc.o >> > Linking CXX executable qa_howto_square_ff >> > [ 62%] Built target qa_howto_square_ff >> > [ 62%] Generating __init__.pyc >> > [ 62%] Generating __init__.pyo >> > [ 87%] Built target pygen_python_6b399 >> > [ 87%] Shebangin howto_square.py >> > [100%] Built target pygen_apps_19307 >> > >> > >> > Then >> > >> > >> > [anastas@jefe build]$ sudo make install >> > Built target gnuradio-howto >> > Built target qa_howto_square2_ff >> > Built target qa_howto_square_ff >> > Built target pygen_python_6b399 >> > Built target pygen_apps_19307 >> > Install the project... >> > -- Install configuration: "Release" >> > -- Installing: /usr/local/include/howto/howto_api.h >> > -- Installing: /usr/local/include/howto/howto_square_ff.h >> > -- Installing: /usr/local/include/howto/howto_square2_ff.h >> > -- Installing: /usr/local/lib64/libgnuradio-howto.so >> > -- Removed runtime path from "/usr/local/lib64/libgnuradio-howto.so" >> > -- Installing: >> > /usr/local/lib64/python2.7/site-packages/howto/__init__.py >> > -- Installing: >> > /usr/local/lib64/python2.7/site-packages/howto/__init__.pyc >> > -- Installing: >> > /usr/local/lib64/python2.7/site-packages/howto/__init__.pyo >> > -- Installing: /usr/local/share/gnuradio/grc/blocks/howto_square_ff.xml >> > -- Installing: /usr/local/share/gnuradio/grc/blocks/howto_square2_ff.xml >> > -- Installing: /usr/local/bin/howto_square.py >> > >> > >> > Now in python I try: >> > >> > [anastas@jefe build]$ python >> > Python 2.7.1 (r271:86832, Apr 12 2011, 16:15:16) >> > [GCC 4.6.0 20110331 (Red Hat 4.6.0-2)] on linux2 >> > Type "help", "copyright", "credits" or "license" for more information. >> import howto >> > Traceback (most recent call last): >> > File "", line 1, in >> > File "/usr/local/lib64/python2.7/site-packages/howto/__init__.py", >> > line 45, in >> > from howto_swig import * >> > ImportError: No module named howto_swig >> > >> > >> > The module howto_swig is missing >> > Any thoughts? >> > >> > thanks >> > Achilleas > > > Achilleas, > Something definitely looks off on your installation. Here's what I get when > I do a make install: > > howto $ sudo make install > [sudo] password for trondeau: > [ 10%] Built target gnuradio-howto > [ 15%] Built target qa_howto_square2_ff > [ 20%] Built target qa_howto_square_ff > [ 25%] Built target _howto_swig_doc_tag > [ 30%] Built target _howto_swig_swig_tag >
Re: [Discuss-gnuradio] problem building gr-howto-write-a-block-cmake
On Thu, Feb 16, 2012 at 11:57 AM, Achilleas Anastasopoulos < anas...@umich.edu> wrote: > BTW, I forgot to say that I am building from the latest master branch > and I have already built/installed the latest gnuradio from > the master branch. > > Achilleas > > On Thu, Feb 16, 2012 at 11:49 AM, Achilleas Anastasopoulos > wrote: > > OK, I am having a problem building the howto module with CMake. > > > > Here is the output of all the steps: > > > > > > [anastas@jefe build]$ cmake ../ > > -- The CXX compiler identification is GNU > > -- Check for working CXX compiler: /usr/lib64/ccache/c++ > > -- Check for working CXX compiler: /usr/lib64/ccache/c++ -- works > > -- Detecting CXX compiler ABI info > > -- Detecting CXX compiler ABI info - done > > -- Build type not specified: defaulting to release. > > -- Boost version: 1.46.0 > > -- checking for module 'gruel' > > -- found gruel, version 3.5.2git > > -- Found GRUEL: /usr/local/lib64/libgruel.so > > -- checking for module 'gnuradio-core' > > -- found gnuradio-core, version 3.5.2git > > -- Found GNURADIO_CORE: /usr/local/lib64/libgnuradio-core.so > > -- Boost version: 1.46.0 > > -- Found the following Boost libraries: > > -- unit_test_framework > > -- Found SWIG: /usr/bin/swig (found version "2.0.4") > > -- Could NOT find PythonLibs (missing: PYTHON_LIBRARIES) > > -- Found PythonInterp: /usr/bin/python2.7 > > -- Found Doxygen: /usr/bin/doxygen > > -- Configuring done > > -- Generating done > > -- Build files have been written to: > > > /n/harrisville/x/anastas/gnuradio_trunk/gr-howto-write-a-block-cmake/build > > > > > > Then > > > > > > > > [anastas@jefe build]$ make > > [ 12%] Building CXX object > > lib/CMakeFiles/gnuradio-howto.dir/howto_square_ff.cc.o > > [ 25%] Building CXX object > > lib/CMakeFiles/gnuradio-howto.dir/howto_square2_ff.cc.o > > [ 37%] Building CXX object > > lib/CMakeFiles/gnuradio-howto.dir/howto_demod_filterbank_ccvc.cc.o > > Linking CXX shared library libgnuradio-howto.so > > [ 37%] Built target gnuradio-howto > > [ 50%] Building CXX object > > lib/CMakeFiles/qa_howto_square2_ff.dir/qa_howto_square2_ff.cc.o > > Linking CXX executable qa_howto_square2_ff > > [ 50%] Built target qa_howto_square2_ff > > [ 62%] Building CXX object > > lib/CMakeFiles/qa_howto_square_ff.dir/qa_howto_square_ff.cc.o > > Linking CXX executable qa_howto_square_ff > > [ 62%] Built target qa_howto_square_ff > > [ 62%] Generating __init__.pyc > > [ 62%] Generating __init__.pyo > > [ 87%] Built target pygen_python_6b399 > > [ 87%] Shebangin howto_square.py > > [100%] Built target pygen_apps_19307 > > > > > > Then > > > > > > [anastas@jefe build]$ sudo make install > > Built target gnuradio-howto > > Built target qa_howto_square2_ff > > Built target qa_howto_square_ff > > Built target pygen_python_6b399 > > Built target pygen_apps_19307 > > Install the project... > > -- Install configuration: "Release" > > -- Installing: /usr/local/include/howto/howto_api.h > > -- Installing: /usr/local/include/howto/howto_square_ff.h > > -- Installing: /usr/local/include/howto/howto_square2_ff.h > > -- Installing: /usr/local/lib64/libgnuradio-howto.so > > -- Removed runtime path from "/usr/local/lib64/libgnuradio-howto.so" > > -- Installing: /usr/local/lib64/python2.7/site-packages/howto/__init__.py > > -- Installing: > /usr/local/lib64/python2.7/site-packages/howto/__init__.pyc > > -- Installing: > /usr/local/lib64/python2.7/site-packages/howto/__init__.pyo > > -- Installing: /usr/local/share/gnuradio/grc/blocks/howto_square_ff.xml > > -- Installing: /usr/local/share/gnuradio/grc/blocks/howto_square2_ff.xml > > -- Installing: /usr/local/bin/howto_square.py > > > > > > Now in python I try: > > > > [anastas@jefe build]$ python > > Python 2.7.1 (r271:86832, Apr 12 2011, 16:15:16) > > [GCC 4.6.0 20110331 (Red Hat 4.6.0-2)] on linux2 > > Type "help", "copyright", "credits" or "license" for more information. > import howto > > Traceback (most recent call last): > > File "", line 1, in > > File "/usr/local/lib64/python2.7/site-packages/howto/__init__.py", > > line 45, in > >from howto_swig import * > > ImportError: No module named howto_swig > > > > > > The module howto_swig is missing > > Any thoughts? > > > > thanks > > Achilleas > Achilleas, Something definitely looks off on your installation. Here's what I get when I do a make install: howto $ sudo make install [sudo] password for trondeau: [ 10%] Built target gnuradio-howto [ 15%] Built target qa_howto_square2_ff [ 20%] Built target qa_howto_square_ff [ 25%] Built target _howto_swig_doc_tag [ 30%] Built target _howto_swig_swig_tag [ 55%] Built target _howto_swig [ 85%] Built target pygen_swig_abbee [ 95%] Built target pygen_python_8d1a5 [100%] Built target pygen_apps_3fd98 Install the project... -- Install configuration: "Release" -- Installing: /opt/gr/include/howto/howto_api.h -- Installing: /opt/gr/include/howto/howto_square_ff.h -- Installing: /opt/gr/include/howto/howto_square2_ff.h -- Installing: /opt/g
Re: [Discuss-gnuradio] Seeks Information about GNURadio examples
Hello Selverine, Look at this ( http://gnuradio.org/redmine/projects/gnuradio/wiki/Tutorials ). Also, search for "Dawei Shen GNUradio tutorial" in google. Nazmul On Thu, Feb 16, 2012 at 2:56 PM, Selverine wrote: > > Hi everybody, > > I'm a beginner, I start working on GNU Radio. > I noted that there were many examples, but apart dial_tone I can't > understand the code. > > Does anyone can help me by giving me tutorials that explains the > examples? > Or any information that they could help me? > > Thank you a lot! > -- > View this message in context: > http://old.nabble.com/Seeks-Information-about-GNURadio-examples-tp7629p7629.html > Sent from the GnuRadio mailing list archive at Nabble.com. > > > ___ > Discuss-gnuradio mailing list > Discuss-gnuradio@gnu.org > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio > -- Muhammad Nazmul Islam Graduate Student Electrical & Computer Engineering Wireless Information & Networking Laboratory Rutgers, USA. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Reminder about call today
The easy button to interface to the AC plug would be to pick up some old power line telephone extenders from Radio Shack and cut them open. You could then use the basic RX and TX cards. _ From: discuss-gnuradio-bounces+evan=syndetix@gnu.org [mailto:discuss-gnuradio-bounces+evan=syndetix@gnu.org] On Behalf Of George Nychis Sent: Thursday, February 16, 2012 12:49 PM To: Tom Rondeau Cc: GNURadio Discussion List Subject: Re: [Discuss-gnuradio] Reminder about call today Interesting thought. Powerline communications have been discussed for quite a while, but they tend to be horrible channels (old copper, long distances, bad shielding, etc.). So yes, I'd expect OFDM for the equalization and multipath (or 'echos' in this case) issues and heavy channel coding are required. My main question regarding this topic is to figure out what would be necessary to create a test bed to try it out on? Obviously, we aren't going to stick the Rx/Tx port of the USRP into a wall socket :) Trust me, I am far from an EE person, so ignore any outrageous misunderstandings ;) I guess this will start as more of question: since we can't stick Rx/Tx directly in to a wall socket... what actually needs to happen to stick an Rx/Tx in to a wall socket? I'm guessing a bunch of filtering goes on with the actual power, but beyond that I have no clue. I guess part of this is I was wondering if it is feasible to develop a frontend to stick a USRP in to a wall socket. Then, due to the horrible channels you mention, I think it makes for an interesting/feasible 3 month project to get communication through to power line with those channels. Even measurement on what those channels are like would be interesting, and I know whatever might come out of this would really open up the ability for the academic community to directly research power line networks. Thanks, Tom! - George ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Reminder about call today
On Thu, Feb 16, 2012 at 11:49, George Nychis wrote: > Trust me, I am far from an EE person, so ignore any outrageous > misunderstandings ;) I guess this will start as more of question: since we > can't stick Rx/Tx directly in to a wall socket... what actually needs to > happen to stick an Rx/Tx in to a wall socket? The impedance of a power line varies a lot with frequency. Power couplers use capacitors and transformers to try to match the impedance the best they can, but it's hard to get anything broadband. Then there are all the safety issues when dealing with high voltage, and the protection circuitry for the 50-ohm side to deal with things like lightning induced spikes, etc. Johnathan ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Seeks Information about GNURadio examples
Hi everybody, I'm a beginner, I start working on GNU Radio. I noted that there were many examples, but apart dial_tone I can't understand the code. Does anyone can help me by giving me tutorials that explains the examples? Or any information that they could help me? Thank you a lot! -- View this message in context: http://old.nabble.com/Seeks-Information-about-GNURadio-examples-tp7629p7629.html Sent from the GnuRadio mailing list archive at Nabble.com. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Reminder about call today
On Thu, Feb 16, 2012 at 10:24, Tom Rondeau wrote: > Powerline communications have been discussed for quite > a while, but they tend to be horrible channels (old copper, long distances, > bad shielding, etc.). So yes, I'd expect OFDM for the equalization and > multipath (or 'echos' in this case) issues and heavy channel coding are > required. OFDM for the equalization and FEC for the channel errors has been a successful technique used in residential power-line communications. However, commercial buildings tend to have long and unpredictable power delay profiles, requiring long symbol times. In addition, there are enormous sources of interference (primarily impulse noise) from things like elevator motors and paper shredders (!), as well as strong shortwave RF induced signals. Finally, some installations use multiple transformers between floors, with their own very unpredictable channel response. As an alternative, one commercial R&D contract I did a while back was to use DSSS/CDMA with long codes to reduce the interference by the coding gain, then use additional delay correlators to receive and combine echos (a basic RAKE receiver). This worked extremely well for interference rejection, without FEC at the data level, but at the expense of a low bit rate and long synchronization times. Since the communication requirement was a unidirectional broadcast, this worked out well. The initial implementation was done in GNU Radio with a chipping rate of 2 Mcps, then ported to the USRP2 FPGA (minus the rake) for chipping rates up to 25 Mcps. I think this goes to the point that GNU Radio is an excellent tool for experimentation, R&D, prototyping, etc., and not so much for chasing existing standards. > My main question regarding this topic is to figure out what would be > necessary to create a test bed to try it out on? Obviously, we aren't going > to stick the Rx/Tx port of the USRP into a wall socket :) That company made some generic 50-ohm to wall socket power couplers for the project, but I don't know if they ever made them commercially. I still have a pair in my lab to play with :) Johnathan ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Reminder about call today
> > > Interesting thought. Powerline communications have been discussed for > quite a while, but they tend to be horrible channels (old copper, long > distances, bad shielding, etc.). So yes, I'd expect OFDM for the > equalization and multipath (or 'echos' in this case) issues and heavy > channel coding are required. > > My main question regarding this topic is to figure out what would be > necessary to create a test bed to try it out on? Obviously, we aren't going > to stick the Rx/Tx port of the USRP into a wall socket :) > > Trust me, I am far from an EE person, so ignore any outrageous misunderstandings ;) I guess this will start as more of question: since we can't stick Rx/Tx directly in to a wall socket... what actually needs to happen to stick an Rx/Tx in to a wall socket? I'm guessing a bunch of filtering goes on with the actual power, but beyond that I have no clue. I guess part of this is I was wondering if it is feasible to develop a frontend to stick a USRP in to a wall socket. Then, due to the horrible channels you mention, I think it makes for an interesting/feasible 3 month project to get communication through to power line with those channels. Even measurement on what those channels are like would be interesting, and I know whatever might come out of this would really open up the ability for the academic community to directly research power line networks. Thanks, Tom! - George ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Volk branch on github
On 02/16/2012 11:32 AM, Josh Blum wrote: > > > On 02/16/2012 11:24 AM, Tom Rondeau wrote: >> On Thu, Feb 16, 2012 at 2:08 PM, Josh Blum wrote: >> >>> Also, you never want to work on the smallest amount of memory possible. This is covered in my discussion on my blog. Making arbitrarily small >>> calls to work functions causes much more overhead than just running the >>> unaligned version of a Volk call. I found this out pretty quickly when I started looking into things. Better to process a large chunk to get back into alignment than try to handle calls to small amounts of data. >>> >>> Perhaps this is because you have a processor that doesn't penalize you >>> for unaligned loads/stores. >>> >>> -Josh >>> >> >> I tested this on a handful of different processors: Core2Due, QuadCore, i7 >> (first get), i7 (second gen) and they all told me the same thing. You are > > For most if not all recent x86 processors there is no unaligned penalty. > You should be able to always call the unaligned volk routine and see no > difference in performance. I'm wondering about neon for example, which > has a penalty. And I suppose to a lesser extent, older x86 processors. I > dont have numbers now, but I think the volk profiler can confirm this > about said processors. The answer for neon is probably a case of the "don't do that". In other words, keep your blocks fed with aligned multiples, regardless of how the scheduler handles things. -Josh ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Volk branch on github
On 02/16/2012 11:24 AM, Tom Rondeau wrote: > On Thu, Feb 16, 2012 at 2:08 PM, Josh Blum wrote: > >> >>> Also, you never want to work on the smallest amount of memory possible. >>> This is covered in my discussion on my blog. Making arbitrarily small >> calls >>> to work functions causes much more overhead than just running the >> unaligned >>> version of a Volk call. I found this out pretty quickly when I started >>> looking into things. Better to process a large chunk to get back into >>> alignment than try to handle calls to small amounts of data. >>> >> >> Perhaps this is because you have a processor that doesn't penalize you >> for unaligned loads/stores. >> >> -Josh >> > > I tested this on a handful of different processors: Core2Due, QuadCore, i7 > (first get), i7 (second gen) and they all told me the same thing. You are For most if not all recent x86 processors there is no unaligned penalty. You should be able to always call the unaligned volk routine and see no difference in performance. I'm wondering about neon for example, which has a penalty. And I suppose to a lesser extent, older x86 processors. I dont have numbers now, but I think the volk profiler can confirm this about said processors. -Josh ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] GRC: Just compile XML, no GUI
On Thu, Feb 16, 2012 at 10:19:31AM -0800, Josh Blum wrote: > > I was wondering if it's a big deal to give gnuradio-companion a switch > > to just compile a .grc file without firing up the GUI. > Give this a shot: https://github.com/jettero/grcc/blob/grcc/grcc > -Josh This is exactly why I wrote grcc. It should probably be a switch in the gnuradio-companion script, but grcc does the job for now. I'm open to forks and patches, I really just cobbled together something that works for me, suggestions welcome. -Paul -- If riding in an airplane is flying, then riding in a boat is swimming. 116 jumps, 48.6 minutes of freefall, 92.9 freefall miles. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Volk branch on github
On Thu, Feb 16, 2012 at 2:08 PM, Josh Blum wrote: > > > Also, you never want to work on the smallest amount of memory possible. > > This is covered in my discussion on my blog. Making arbitrarily small > calls > > to work functions causes much more overhead than just running the > unaligned > > version of a Volk call. I found this out pretty quickly when I started > > looking into things. Better to process a large chunk to get back into > > alignment than try to handle calls to small amounts of data. > > > > Perhaps this is because you have a processor that doesn't penalize you > for unaligned loads/stores. > > -Josh > I tested this on a handful of different processors: Core2Due, QuadCore, i7 (first get), i7 (second gen) and they all told me the same thing. You are still better doing unaligned loads in Volk than doing the generic loop. Also, the overhead of calling the scheduler functions for small data items is MUCH more costly than an unaligned load. Seriously, making these arbitrarily small calls to the work function for alignment reasons, which allowed me to always run aligned, made things run 4 - 5 times slower than the non-Volk version of the block. Tom ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Volk branch on github
> Also, you never want to work on the smallest amount of memory possible. > This is covered in my discussion on my blog. Making arbitrarily small calls > to work functions causes much more overhead than just running the unaligned > version of a Volk call. I found this out pretty quickly when I started > looking into things. Better to process a large chunk to get back into > alignment than try to handle calls to small amounts of data. > Perhaps this is because you have a processor that doesn't penalize you for unaligned loads/stores. -Josh ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] GRC: Just compile XML, no GUI
On Thu, Feb 16, 2012 at 1:47 PM, wrote: > ** > > On Thu, 16 Feb 2012 13:20:05 -0500, Tom Rondeau wrote: > > On Thu, Feb 16, 2012 at 11:39 AM, Martin Braun wrote: > >> Hi (most likely Josh), >> >> I was wondering if it's a big deal to give gnuradio-companion a switch >> to just compile a .grc file without firing up the GUI. >> >> Specifically, I was hoping to have unit tests for GRC files, so I wanted >> to automatically use the GRC checking features to test .grc files. >> However, I started digging in the code... and it seems to be very >> closely intertwined with the GUI. And, to be honest, I got a bit lost in >> there :) >> >> So, something like direct access to the Generator class would be >> great. Any hints? >> >> MB >> > Martin, > On the GRC page, open up the "Options" block. There is a drop-down box > for "Generate Options." Switch this to "No GUI." Now you can just compile > it into a Python file and run it either in GRC or from the command line. No > GUI involved. > Tom > > Tom: > > That's not what Martin was asking for. > > He's asking to be able to invoke the "compiler" part of GRC without going > into the actual UI of GRC and asking it to generate the corresponding .py > file. I've also wished for that capability, so that I can ship .grc files > only, and have a Makefile invoke the (non-existent) "--compile-only" form > of GRC > Oh, I see. Totally misread his post. Tom ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] GRC: Just compile XML, no GUI
On Thu, 16 Feb 2012 13:20:05 -0500, Tom Rondeau wrote: > On Thu, Feb 16, 2012 at 11:39 AM, Martin Braun wrote: > >> Hi (most likely Josh), >> >> I was wondering if it's a big deal to give gnuradio-companion a switch >> to just compile a .grc file without firing up the GUI. >> >> Specifically, I was hoping to have unit tests for GRC files, so I wanted >> to automatically use the GRC checking features to test .grc files. >> However, I started digging in the code... and it seems to be very >> closely intertwined with the GUI. And, to be honest, I got a bit lost in >> there :) >> >> So, something like direct access to the Generator class would be >> great. Any hints? >> >> MB > > Martin, > On the GRC page, open up the "Options" block. There is a drop-down box for "Generate Options." Switch this to "No GUI." Now you can just compile it into a Python file and run it either in GRC or from the command line. No GUI involved. > > Tom Tom: That's not what Martin was asking for. He's asking to be able to invoke the "compiler" part of GRC without going into the actual UI of GRC and asking it to generate the corresponding .py file. I've also wished for that capability, so that I can ship .grc files only, and have a Makefile invoke the (non-existent) "--compile-only" form of GRC. Links: -- [1] mailto:martin.br...@kit.edu ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Reminder about call today
On Thu, Feb 16, 2012 at 11:06 AM, George Nychis wrote: > Hey all, > > I actually really want to join the call, because I have a GSoC idea, but I > have a conflict with teaching assistant duties during that time. > Hi George, Sorry the timing won't work out this month. > So I thought I'd briefly share, and if it does become of interest then > maybe someone can get ahold of me and I could try to mentor or something. > I thought it might be cool to show that GNU Radio and the USRPP can be > more than just about wireless technology, pushing forward on a hot topic > recently: PowerLine networking. > > I've been trying to dig up details of PowerLine implementations, but I > think they are typically very "wireless PHY" oriented. I think they are in > general OFDM based with Turbo Convolutional Codes. I think that GNU Radio > already provides a lot of the blocks that would be necessary to build the > PHY. I am not sure of what the necessary frontend might be for this, but > maybe by the summer if Matt and GNU Radio folks are truly interested, a > prototype could be made. > > Some info i found on PowerLine details: > http://helpfromageek.com/2011/05/18/white-paper-powerline-networking/ > Interesting thought. Powerline communications have been discussed for quite a while, but they tend to be horrible channels (old copper, long distances, bad shielding, etc.). So yes, I'd expect OFDM for the equalization and multipath (or 'echos' in this case) issues and heavy channel coding are required. My main question regarding this topic is to figure out what would be necessary to create a test bed to try it out on? Obviously, we aren't going to stick the Rx/Tx port of the USRP into a wall socket :) Thanks for the idea! Tom > On Thu, Feb 16, 2012 at 10:50 AM, Tom Rondeau wrote: > >> This is just a reminder about today's Developers' Call. Due to other >> conflicts, the time has been changed from the normal time to 1600 EST or >> 2100 UTC. >> >> http://gnuradio.org/redmine/projects/gnuradio/wiki/Call20120216 >> >> We'll probably want to spend a significant amount of time on discussing >> the projects we want to put forward for the GSoC, so please join us if you >> are interested in participating. >> >> Thanks, >> Tom >> >> >> ___ >> Discuss-gnuradio mailing list >> Discuss-gnuradio@gnu.org >> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio >> >> > ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] GRC: Just compile XML, no GUI
On Thu, Feb 16, 2012 at 11:39 AM, Martin Braun wrote: > Hi (most likely Josh), > > I was wondering if it's a big deal to give gnuradio-companion a switch > to just compile a .grc file without firing up the GUI. > > Specifically, I was hoping to have unit tests for GRC files, so I wanted > to automatically use the GRC checking features to test .grc files. > However, I started digging in the code... and it seems to be very > closely intertwined with the GUI. And, to be honest, I got a bit lost in > there :) > > So, something like direct access to the Generator class would be > great. Any hints? > > MB > Martin, On the GRC page, open up the "Options" block. There is a drop-down box for "Generate Options." Switch this to "No GUI." Now you can just compile it into a Python file and run it either in GRC or from the command line. No GUI involved. Tom ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] GRC: Just compile XML, no GUI
On 02/16/2012 08:39 AM, Martin Braun wrote: > Hi (most likely Josh), > > I was wondering if it's a big deal to give gnuradio-companion a switch > to just compile a .grc file without firing up the GUI. > > Specifically, I was hoping to have unit tests for GRC files, so I wanted > to automatically use the GRC checking features to test .grc files. > However, I started digging in the code... and it seems to be very > closely intertwined with the GUI. And, to be honest, I got a bit lost in > there :) > > So, something like direct access to the Generator class would be > great. Any hints? > Give this a shot: https://github.com/jettero/grcc/blob/grcc/grcc -Josh ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] E100 compile error: trondeau safe_align branch
On 02/16/2012 09:39 AM, Nowlan, Sean wrote:
> Hi all,
>
> I'm trying to build Tom's branch with the recent changes to use Volk, but I'm
> getting an error. I ran this command:
>
> cmake -DCMAKE_INSTALL_PREFIX=/usr
> -DCMAKE_TOOLCHAIN_FILE=../cmake/Toolchains/arm_cortex_a8_native.cmake
> -DENABLE_GR_QTGUI=OFF -DCMAKE_BUILD_TYPE=release ../
>
> And got this error:
>
> [ 18%] generating filter files
> [ 18%] Building CXX object
> gnuradio-core/src/lib/CMakeFiles/gnuradio-core.dir/filter/sysconfig_armv7_a.cc.o
> [ 18%] Building CXX object
> gnuradio-core/src/lib/CMakeFiles/gnuradio-core.dir/filter/gr_fir_sysconfig_armv7_a.cc.o
> [ 18%] Building CXX object
> gnuradio-core/src/lib/CMakeFiles/gnuradio-core.dir/filter/gr_cpu_armv7_a.cc.o
> [ 18%] Building CXX object
> gnuradio-core/src/lib/CMakeFiles/gnuradio-core.dir/filter/gr_fir_fff_armv7_a.cc.o
> [ 18%] Building C object
> gnuradio-core/src/lib/CMakeFiles/gnuradio-core.dir/filter/dotprod_fff_armv7_a.c.o
> /tmp/cct93Ve1.s: Assembler messages:
> /tmp/cct93Ve1.s:27: Error: bad instruction `vmov.f32 q8,#0.0'
> /tmp/cct93Ve1.s:28: Error: bad instruction `vmov.f32 q9,#0.0'
> /tmp/cct93Ve1.s:31: Error: bad instruction `vld1.32 {d0,d1,d2,d3},[r3]!'
> /tmp/cct93Ve1.s:32: Error: bad instruction `vld1.32 {d4,d5,d6,d7},[r1]!'
> /tmp/cct93Ve1.s:33: Error: bad instruction `vmla.f32 q8,q0,q2'
> /tmp/cct93Ve1.s:34: Error: bad instruction `vmla.f32 q9,q1,q3'
> /tmp/cct93Ve1.s:36: Error: bad instruction `vadd.f32 q8,q8,q9'
> /tmp/cct93Ve1.s:37: Error: bad instruction `vpadd.f32 d0,d16,d17'
> /tmp/cct93Ve1.s:38: Error: bad instruction `vadd.f32 s16,s0,s1'
> make[2]: ***
> [gnuradio-core/src/lib/CMakeFiles/gnuradio-core.dir/filter/dotprod_fff_armv7_a.c.o]
> Error 1
> make[1]: *** [gnuradio-core/src/lib/CMakeFiles/gnuradio-core.dir/all] Error 2
> make: *** [all] Error 2
>
> Any hints/ideas? Thanks!
I feel like the flags from the toolchain file are not getting through to
gcc, try passing the compiler flags via the command line.
Philip
>
> Sean
>
>
>
>
> ___
> 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] E100 compile error: trondeau safe_align branch
Hi all,
I'm trying to build Tom's branch with the recent changes to use Volk, but I'm
getting an error. I ran this command:
cmake -DCMAKE_INSTALL_PREFIX=/usr
-DCMAKE_TOOLCHAIN_FILE=../cmake/Toolchains/arm_cortex_a8_native.cmake
-DENABLE_GR_QTGUI=OFF -DCMAKE_BUILD_TYPE=release ../
And got this error:
[ 18%] generating filter files
[ 18%] Building CXX object
gnuradio-core/src/lib/CMakeFiles/gnuradio-core.dir/filter/sysconfig_armv7_a.cc.o
[ 18%] Building CXX object
gnuradio-core/src/lib/CMakeFiles/gnuradio-core.dir/filter/gr_fir_sysconfig_armv7_a.cc.o
[ 18%] Building CXX object
gnuradio-core/src/lib/CMakeFiles/gnuradio-core.dir/filter/gr_cpu_armv7_a.cc.o
[ 18%] Building CXX object
gnuradio-core/src/lib/CMakeFiles/gnuradio-core.dir/filter/gr_fir_fff_armv7_a.cc.o
[ 18%] Building C object
gnuradio-core/src/lib/CMakeFiles/gnuradio-core.dir/filter/dotprod_fff_armv7_a.c.o
/tmp/cct93Ve1.s: Assembler messages:
/tmp/cct93Ve1.s:27: Error: bad instruction `vmov.f32 q8,#0.0'
/tmp/cct93Ve1.s:28: Error: bad instruction `vmov.f32 q9,#0.0'
/tmp/cct93Ve1.s:31: Error: bad instruction `vld1.32 {d0,d1,d2,d3},[r3]!'
/tmp/cct93Ve1.s:32: Error: bad instruction `vld1.32 {d4,d5,d6,d7},[r1]!'
/tmp/cct93Ve1.s:33: Error: bad instruction `vmla.f32 q8,q0,q2'
/tmp/cct93Ve1.s:34: Error: bad instruction `vmla.f32 q9,q1,q3'
/tmp/cct93Ve1.s:36: Error: bad instruction `vadd.f32 q8,q8,q9'
/tmp/cct93Ve1.s:37: Error: bad instruction `vpadd.f32 d0,d16,d17'
/tmp/cct93Ve1.s:38: Error: bad instruction `vadd.f32 s16,s0,s1'
make[2]: ***
[gnuradio-core/src/lib/CMakeFiles/gnuradio-core.dir/filter/dotprod_fff_armv7_a.c.o]
Error 1
make[1]: *** [gnuradio-core/src/lib/CMakeFiles/gnuradio-core.dir/all] Error 2
make: *** [all] Error 2
Any hints/ideas? Thanks!
Sean
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] problem building gr-howto-write-a-block-cmake
On Thu, Feb 16, 2012 at 11:49:10AM -0500, Achilleas Anastasopoulos wrote: > >>> import howto > Traceback (most recent call last): > File "", line 1, in > File "/usr/local/lib64/python2.7/site-packages/howto/__init__.py", > line 45, in > from howto_swig import * > ImportError: No module named howto_swig > Hi Achilleas, stupid question, but did you try 'sudo ldconfig'? MB -- Karlsruhe Institute of Technology (KIT) Communications Engineering Lab (CEL) Dipl.-Ing. Martin Braun Research Associate Kaiserstraße 12 Building 05.01 76131 Karlsruhe Phone: +49 721 608-43790 Fax: +49 721 608-46071 www.cel.kit.edu KIT -- University of the State of Baden-Württemberg and National Laboratory of the Helmholtz Association pgp6XN3UYvxdY.pgp Description: PGP signature ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] problem building gr-howto-write-a-block-cmake
BTW, I forgot to say that I am building from the latest master branch and I have already built/installed the latest gnuradio from the master branch. Achilleas On Thu, Feb 16, 2012 at 11:49 AM, Achilleas Anastasopoulos wrote: > OK, I am having a problem building the howto module with CMake. > > Here is the output of all the steps: > > > [anastas@jefe build]$ cmake ../ > -- The CXX compiler identification is GNU > -- Check for working CXX compiler: /usr/lib64/ccache/c++ > -- Check for working CXX compiler: /usr/lib64/ccache/c++ -- works > -- Detecting CXX compiler ABI info > -- Detecting CXX compiler ABI info - done > -- Build type not specified: defaulting to release. > -- Boost version: 1.46.0 > -- checking for module 'gruel' > -- found gruel, version 3.5.2git > -- Found GRUEL: /usr/local/lib64/libgruel.so > -- checking for module 'gnuradio-core' > -- found gnuradio-core, version 3.5.2git > -- Found GNURADIO_CORE: /usr/local/lib64/libgnuradio-core.so > -- Boost version: 1.46.0 > -- Found the following Boost libraries: > -- unit_test_framework > -- Found SWIG: /usr/bin/swig (found version "2.0.4") > -- Could NOT find PythonLibs (missing: PYTHON_LIBRARIES) > -- Found PythonInterp: /usr/bin/python2.7 > -- Found Doxygen: /usr/bin/doxygen > -- Configuring done > -- Generating done > -- Build files have been written to: > /n/harrisville/x/anastas/gnuradio_trunk/gr-howto-write-a-block-cmake/build > > > Then > > > > [anastas@jefe build]$ make > [ 12%] Building CXX object > lib/CMakeFiles/gnuradio-howto.dir/howto_square_ff.cc.o > [ 25%] Building CXX object > lib/CMakeFiles/gnuradio-howto.dir/howto_square2_ff.cc.o > [ 37%] Building CXX object > lib/CMakeFiles/gnuradio-howto.dir/howto_demod_filterbank_ccvc.cc.o > Linking CXX shared library libgnuradio-howto.so > [ 37%] Built target gnuradio-howto > [ 50%] Building CXX object > lib/CMakeFiles/qa_howto_square2_ff.dir/qa_howto_square2_ff.cc.o > Linking CXX executable qa_howto_square2_ff > [ 50%] Built target qa_howto_square2_ff > [ 62%] Building CXX object > lib/CMakeFiles/qa_howto_square_ff.dir/qa_howto_square_ff.cc.o > Linking CXX executable qa_howto_square_ff > [ 62%] Built target qa_howto_square_ff > [ 62%] Generating __init__.pyc > [ 62%] Generating __init__.pyo > [ 87%] Built target pygen_python_6b399 > [ 87%] Shebangin howto_square.py > [100%] Built target pygen_apps_19307 > > > Then > > > [anastas@jefe build]$ sudo make install > Built target gnuradio-howto > Built target qa_howto_square2_ff > Built target qa_howto_square_ff > Built target pygen_python_6b399 > Built target pygen_apps_19307 > Install the project... > -- Install configuration: "Release" > -- Installing: /usr/local/include/howto/howto_api.h > -- Installing: /usr/local/include/howto/howto_square_ff.h > -- Installing: /usr/local/include/howto/howto_square2_ff.h > -- Installing: /usr/local/lib64/libgnuradio-howto.so > -- Removed runtime path from "/usr/local/lib64/libgnuradio-howto.so" > -- Installing: /usr/local/lib64/python2.7/site-packages/howto/__init__.py > -- Installing: /usr/local/lib64/python2.7/site-packages/howto/__init__.pyc > -- Installing: /usr/local/lib64/python2.7/site-packages/howto/__init__.pyo > -- Installing: /usr/local/share/gnuradio/grc/blocks/howto_square_ff.xml > -- Installing: /usr/local/share/gnuradio/grc/blocks/howto_square2_ff.xml > -- Installing: /usr/local/bin/howto_square.py > > > Now in python I try: > > [anastas@jefe build]$ python > Python 2.7.1 (r271:86832, Apr 12 2011, 16:15:16) > [GCC 4.6.0 20110331 (Red Hat 4.6.0-2)] on linux2 > Type "help", "copyright", "credits" or "license" for more information. import howto > Traceback (most recent call last): > File "", line 1, in > File "/usr/local/lib64/python2.7/site-packages/howto/__init__.py", > line 45, in > from howto_swig import * > ImportError: No module named howto_swig > > > The module howto_swig is missing > Any thoughts? > > thanks > Achilleas ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] problem building gr-howto-write-a-block-cmake
OK, I am having a problem building the howto module with CMake. Here is the output of all the steps: [anastas@jefe build]$ cmake ../ -- The CXX compiler identification is GNU -- Check for working CXX compiler: /usr/lib64/ccache/c++ -- Check for working CXX compiler: /usr/lib64/ccache/c++ -- works -- Detecting CXX compiler ABI info -- Detecting CXX compiler ABI info - done -- Build type not specified: defaulting to release. -- Boost version: 1.46.0 -- checking for module 'gruel' -- found gruel, version 3.5.2git -- Found GRUEL: /usr/local/lib64/libgruel.so -- checking for module 'gnuradio-core' -- found gnuradio-core, version 3.5.2git -- Found GNURADIO_CORE: /usr/local/lib64/libgnuradio-core.so -- Boost version: 1.46.0 -- Found the following Boost libraries: -- unit_test_framework -- Found SWIG: /usr/bin/swig (found version "2.0.4") -- Could NOT find PythonLibs (missing: PYTHON_LIBRARIES) -- Found PythonInterp: /usr/bin/python2.7 -- Found Doxygen: /usr/bin/doxygen -- Configuring done -- Generating done -- Build files have been written to: /n/harrisville/x/anastas/gnuradio_trunk/gr-howto-write-a-block-cmake/build Then [anastas@jefe build]$ make [ 12%] Building CXX object lib/CMakeFiles/gnuradio-howto.dir/howto_square_ff.cc.o [ 25%] Building CXX object lib/CMakeFiles/gnuradio-howto.dir/howto_square2_ff.cc.o [ 37%] Building CXX object lib/CMakeFiles/gnuradio-howto.dir/howto_demod_filterbank_ccvc.cc.o Linking CXX shared library libgnuradio-howto.so [ 37%] Built target gnuradio-howto [ 50%] Building CXX object lib/CMakeFiles/qa_howto_square2_ff.dir/qa_howto_square2_ff.cc.o Linking CXX executable qa_howto_square2_ff [ 50%] Built target qa_howto_square2_ff [ 62%] Building CXX object lib/CMakeFiles/qa_howto_square_ff.dir/qa_howto_square_ff.cc.o Linking CXX executable qa_howto_square_ff [ 62%] Built target qa_howto_square_ff [ 62%] Generating __init__.pyc [ 62%] Generating __init__.pyo [ 87%] Built target pygen_python_6b399 [ 87%] Shebangin howto_square.py [100%] Built target pygen_apps_19307 Then [anastas@jefe build]$ sudo make install Built target gnuradio-howto Built target qa_howto_square2_ff Built target qa_howto_square_ff Built target pygen_python_6b399 Built target pygen_apps_19307 Install the project... -- Install configuration: "Release" -- Installing: /usr/local/include/howto/howto_api.h -- Installing: /usr/local/include/howto/howto_square_ff.h -- Installing: /usr/local/include/howto/howto_square2_ff.h -- Installing: /usr/local/lib64/libgnuradio-howto.so -- Removed runtime path from "/usr/local/lib64/libgnuradio-howto.so" -- Installing: /usr/local/lib64/python2.7/site-packages/howto/__init__.py -- Installing: /usr/local/lib64/python2.7/site-packages/howto/__init__.pyc -- Installing: /usr/local/lib64/python2.7/site-packages/howto/__init__.pyo -- Installing: /usr/local/share/gnuradio/grc/blocks/howto_square_ff.xml -- Installing: /usr/local/share/gnuradio/grc/blocks/howto_square2_ff.xml -- Installing: /usr/local/bin/howto_square.py Now in python I try: [anastas@jefe build]$ python Python 2.7.1 (r271:86832, Apr 12 2011, 16:15:16) [GCC 4.6.0 20110331 (Red Hat 4.6.0-2)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> import howto Traceback (most recent call last): File "", line 1, in File "/usr/local/lib64/python2.7/site-packages/howto/__init__.py", line 45, in from howto_swig import * ImportError: No module named howto_swig The module howto_swig is missing Any thoughts? thanks Achilleas ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] GRC: Just compile XML, no GUI
Hi (most likely Josh), I was wondering if it's a big deal to give gnuradio-companion a switch to just compile a .grc file without firing up the GUI. Specifically, I was hoping to have unit tests for GRC files, so I wanted to automatically use the GRC checking features to test .grc files. However, I started digging in the code... and it seems to be very closely intertwined with the GUI. And, to be honest, I got a bit lost in there :) So, something like direct access to the Generator class would be great. Any hints? MB -- Karlsruhe Institute of Technology (KIT) Communications Engineering Lab (CEL) Dipl.-Ing. Martin Braun Research Associate Kaiserstraße 12 Building 05.01 76131 Karlsruhe Phone: +49 721 608-43790 Fax: +49 721 608-46071 www.cel.kit.edu KIT -- University of the State of Baden-Württemberg and National Laboratory of the Helmholtz Association pgpFvI7ARsw9P.pgp Description: PGP signature ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Reminder about call today
Hey all, I actually really want to join the call, because I have a GSoC idea, but I have a conflict with teaching assistant duties during that time. So I thought I'd briefly share, and if it does become of interest then maybe someone can get ahold of me and I could try to mentor or something. I thought it might be cool to show that GNU Radio and the USRPP can be more than just about wireless technology, pushing forward on a hot topic recently: PowerLine networking. I've been trying to dig up details of PowerLine implementations, but I think they are typically very "wireless PHY" oriented. I think they are in general OFDM based with Turbo Convolutional Codes. I think that GNU Radio already provides a lot of the blocks that would be necessary to build the PHY. I am not sure of what the necessary frontend might be for this, but maybe by the summer if Matt and GNU Radio folks are truly interested, a prototype could be made. Some info i found on PowerLine details: http://helpfromageek.com/2011/05/18/white-paper-powerline-networking/ On Thu, Feb 16, 2012 at 10:50 AM, Tom Rondeau wrote: > This is just a reminder about today's Developers' Call. Due to other > conflicts, the time has been changed from the normal time to 1600 EST or > 2100 UTC. > > http://gnuradio.org/redmine/projects/gnuradio/wiki/Call20120216 > > We'll probably want to spend a significant amount of time on discussing > the projects we want to put forward for the GSoC, so please join us if you > are interested in participating. > > Thanks, > Tom > > > ___ > Discuss-gnuradio mailing list > Discuss-gnuradio@gnu.org > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio > > ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Reminder about call today
This is just a reminder about today's Developers' Call. Due to other conflicts, the time has been changed from the normal time to 1600 EST or 2100 UTC. http://gnuradio.org/redmine/projects/gnuradio/wiki/Call20120216 We'll probably want to spend a significant amount of time on discussing the projects we want to put forward for the GSoC, so please join us if you are interested in participating. Thanks, Tom ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] USRP Request
I started a new project involving GNURadio and USRP. I'm using Ubuntu 11.10 and GNU Radio Companion v3.5.1-9-g4beff39a. The hardwares I've got are: 2 units of USRP1 Rev 4.1 and DBSRX Rev2.1. I've got 2 questions: 1. These versions of USRP and daughter boards are still compatible with the version of the software above? 2. Could you please show me how to set the USRP-Source in the Gnuradio-companion so that to target each daughter boards. For your information, the 2 USRP's were long ago synchronized as master and slave. So I've got 4 units of DBSRX daughters boards. You help will be positively appreciated. Dominique___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] "GNU Radio is crap" and GSoc
>I don't agree. We'll hopefully settle the matter some day. :-) Me too, DREAM is an amazing SDR program that could benefit from GNURadio and show off GNURadio as-well. But this idea has been batted around before and never really develops, possibly due to the way GNURadio is currently setup. When I get some free time i'll continue getting some of the python examples ported to C++, so that potential developers who prefer C over python can see how things can be done from C world. I think this will get people who find GNURadio to start porting other C based programs to the GNURadio framework. On Thu, Feb 16, 2012 at 8:52 AM, Jens Elsner wrote: > Andrew, > > Am 15.02.2012 19:41, schrieb Andrew Davis: > >> Well some major GNUradio program would drive up sales of USRP's :) >> >> Back on topic, IMHO Gnuradio's problem with large apps stems from it >> trying to be the source to sink and everything in between of a radio. > > >> Lets take DREAM for example, they do transfer functions and digital >> AGC and the likes that GNUradio by design should not do. > > > If you could elaborate on this point - why should GNU Radio not implement > channel equalization (I assume that's what you mean?) or digital AGC? > > >> If you want >> to re-write DREAM with GNUradio you will end up writing about +200 >> blocks, not much fun. > > > Since I suggested this particular project, I obviously cannot agree. :-) > > Pulling the code base into GNU Radio might be a nice addition to > the available receivers and it can be useful for all amateur radio > operators world wide. > > Plus DRM is broadcasting so we don't need to worry about timing issues, > a real drawback of GNU Radio (and high level SDR in general). > > How fine the signal processing chain needs to be chopped up is a > matter of taste and performance, I believe. > > >> What people want is simple input to there >> program and a simple output API, not there entire program. They don't >> what to figure out how to write a GNURadio block or know anything >> about the complexities of GNURadio. They want to say "get me a signal >> at 100MHz, filter and interpolate to 1ksp with these cutoff >> frequencies then send me the data and let me do the rest", no need to >> know anything about GNURadio, what other API makes you learn as much >> about it? > > > I am not sure I understand your point here. That is not GNU Radio, I > see GNU Radio as a scheduler with a big collection of signal processing > blocks attached. > > [...] > > >> Back to DREAM, >> a lot of the filters, audio input/output, signal conditioning, etc >> could be in GNURadio, but a lot of the middle section cannot. GNURadio > > > Then it would be nice to find out what exactly is lacking to add this > to GNU Radio. > > >> can not be the whole program, just helper functions in big programs >> like this. Only about %20 of DREAM could be replaced with GNURadio API >> calls, but instead you will have to rewrite it %100 as GNURadio blocks >> with the current block to block only mentality > > > I don't agree. We'll hopefully settle the matter some day. :-) > > Jens > > > > ___ > Discuss-gnuradio mailing list > Discuss-gnuradio@gnu.org > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] "GNU Radio is crap" and GSoc
Andrew, Am 15.02.2012 19:41, schrieb Andrew Davis: Well some major GNUradio program would drive up sales of USRP's :) Back on topic, IMHO Gnuradio's problem with large apps stems from it trying to be the source to sink and everything in between of a radio. Lets take DREAM for example, they do transfer functions and digital AGC and the likes that GNUradio by design should not do. If you could elaborate on this point - why should GNU Radio not implement channel equalization (I assume that's what you mean?) or digital AGC? If you want to re-write DREAM with GNUradio you will end up writing about +200 blocks, not much fun. Since I suggested this particular project, I obviously cannot agree. :-) Pulling the code base into GNU Radio might be a nice addition to the available receivers and it can be useful for all amateur radio operators world wide. Plus DRM is broadcasting so we don't need to worry about timing issues, a real drawback of GNU Radio (and high level SDR in general). How fine the signal processing chain needs to be chopped up is a matter of taste and performance, I believe. What people want is simple input to there program and a simple output API, not there entire program. They don't what to figure out how to write a GNURadio block or know anything about the complexities of GNURadio. They want to say "get me a signal at 100MHz, filter and interpolate to 1ksp with these cutoff frequencies then send me the data and let me do the rest", no need to know anything about GNURadio, what other API makes you learn as much about it? I am not sure I understand your point here. That is not GNU Radio, I see GNU Radio as a scheduler with a big collection of signal processing blocks attached. [...] Back to DREAM, a lot of the filters, audio input/output, signal conditioning, etc could be in GNURadio, but a lot of the middle section cannot. GNURadio Then it would be nice to find out what exactly is lacking to add this to GNU Radio. can not be the whole program, just helper functions in big programs like this. Only about %20 of DREAM could be replaced with GNURadio API calls, but instead you will have to rewrite it %100 as GNURadio blocks with the current block to block only mentality I don't agree. We'll hopefully settle the matter some day. :-) Jens ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
