Re: [Discuss-gnuradio] How to integrate a specific number of vectors element-wise in gnuradio?
Hi again, I uninstalled what I had installed through PyBOMBS and installed Gnuradio 3.7 through the build_gnuradio script. Then I tried Jareds repo for specest with 3.7 (http://www.github.com/dfxx) and it seems to compile just fine, well done! I can also import specest in python without problems. Now: I would very much like to use the block moving_average_vff in Gnuradio Companion. Unfortunately it seems there are no xml files for that block, hence invisible to the GRC. I got a hint from Martin Braun that I could use the "gr_modtool makexml" command to generate this. Unfortunately it seems that I don't understand how to use it: gr_specest_jared$ ls apps AUTHORS build cmake CMakeLists.txt COPYING docs examples grc include lib python README swig gr_specest_jared$ gr_modtool makexml moving_average_vff GNU Radio module name identified: specest Warning: This is an experimental feature. Don't expect any magic. Searching for matching files in lib/: None found. - There is a file called moving_average_vff.cc in the lib directory, so I guess something more is needed here which I don't know about. I tried looking at the page http://gnuradio.org/redmine/projects/gnuradio/wiki/OutOfTreeModules?version=16#Making-your-blocks-available-in-GRCwhere there are links to example xml blocks to understand a bit more, but it seems these links are broken. Also the link to the gr_block documentation in the next section (There's more:...) is broken. I'm grateful for any hints on how to make the block moving_average_vff visible in the GRC. Best regards, Eskil 2013/10/4 Jared Clements > I updated gr-specest so it would compile with 3.7, see my repo on > www.github.com/dfxx if you want to try that route. The changes were > almost all namespace stuff and cmake stuff, i.e. I don't think I broke > anything. > > Jared > On Oct 4, 2013 7:33 AM, "Eskil Varenius" wrote: > >> Hi everyone, >> After a long break since June I am now back learning about Gnuradio. I >> asked in June for a way to average vectors elementwise and Martin Braun >> suggested the moving_average_Vff block in the gr-specest. He also said it >> would be available PyBOMBS. Now update: >> >> Since I had installed Gnuradio using the build-script I wanted to >> re-install it using pybombs. I uninstalled the old gnuradio by doing a >> "sudo make uninstall" in each build directory for the old release. Seems to >> work. Now I installed gnuradio 3.6 (since gr-specest is still only verified >> for 3.6, although I'm happy to see people working towards a 3.7 release). I >> did the install using the instructions on the pybombs quickstart page: >> >> git clone git://github.com/pybombs/pybombs >> cd pybombs >> git checkout gr-3.6 >> ./pybombs install gnuradio >> >> Gnuradio seemed to install without problems but: I realised I had >> path-problems since I could not start anything (gnuradio companion, import >> gnuradio etc. fails). Perhaps this was related to me using a custom target >> directory (/opt/gnuradio_pybombs). I looked around and found path >> instructions for custom directory installs at " >> http://gnuradio.org/redmine/projects/gnuradio/wiki/UbuntuInstall#Installing-in-a-custom-directory";, >> i.e. put the following in my .bashrc: >> >> # GNU Radio installation >> export PATH=$PATH:/opt/gnuradio_pybombs/bin >> export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:/opt/gnuradio_pybombs/lib >> export >> PKG_CONFIG_PATH=$PKG_CONFIG_PATH:/opt/gnuradio_pybombs/lib/pkgconfig >> export >> PYTHONPATH=$PYTHONPATH:/opt/gnuradio_pybombs/lib/python2.6/site-packages >> >> However, that didn't work completely - I still could not find the >> gnuradio python module. I realised two things: the 2.6 should probably be >> 2.7 for me, and also the pythonpath should end in dist-packages, not >> site-packages, since the site-packages folder was empty. After modifying >> the pythonpath with 2.7 and dist-packages everything runs, I can import >> gnuradio and also use gnuradio companion. So far so good! >> >> Now for gr-specest. I tried to install it using app store (cool stuff, >> you guys are amazing!) and also just command line which is equivalent, i.e. >> I run using "sudo ./pybombs install gr-specest" I get a lot of output, but >> the perhaps most interesting one before it ends abruptly is: >> -- checking for module 'gruel' >> -- package 'gruel' not found >> -- Could NOT find GRUEL (missing: GRUEL_LIBRARIES GRUEL_INCLUDE_DIRS) >> -- checking for module 'gnuradio-core' >> -- package 'gnuradio-core' not found >> -- Could NOT find GNURADIO_CORE (missing: GNURADIO_CORE_LIBRARIES >> GNURADIO_CORE_INCLUDE_DIRS) >> CMake Error at CMakeLists.txt:100 (message): >> Gruel required to compile specest >> >> I am lost here. Any ideas? I can give the rest of the output as well, but >> this is the showstopper as far as I can see. I have tried googling this, >> but it seems to me that the solution used is to use the build-gnuradio >> script instead o
[Discuss-gnuradio] Again bladerf / gqrx / gr-osmosdr
Hi, With latest versions of GR / bladerf / gqrx / gr-osmosdr again something is stuck. Gqrx does not work anymore, I get the following error during make: /usr/local/lib/libgnuradio-osmosdr.so: undefined reference to `bladerf_fpga_version' /usr/local/lib/libgnuradio-osmosdr.so: undefined reference to `bladerf_fw_version' collect2: ld returned 1 exit status make: *** [gqrx] Error 1 ras@ubuntu:~/gqrx$ make g++ -Wl,-O1 -o gqrx main.o mainwindow.o receiver.o cafsk12.o costabf.o agc_impl.o correct_iq_cc.o lpf.o resampler_xx.o rx_demod_am.o rx_demod_fm.o rx_fft.o rx_filter.o rx_meter.o rx_agc_xx.o rx_noise_blanker_cc.o sniffer_f.o stereo_demod.o afsk1200win.o agc_options.o audio_options.o demod_options.o dockinputctl.o dockaudio.o dockfft.o dockiqplayer.o dockrxopt.o freqctrl.o ioconfig.o meter.o nb_options.o plotter.o qtcolorpicker.o nbrx.o receiver_base.o wfmrx.o pa_device_list.o pa_sink.o pa_source.o moc_mainwindow.o moc_cafsk12.o moc_afsk1200win.o moc_agc_options.o moc_audio_options.o moc_demod_options.o moc_dockaudio.o moc_dockfft.o moc_dockinputctl.o moc_dockiqplayer.o moc_dockrxopt.o moc_freqctrl.o moc_ioconfig.o moc_meter.o moc_nb_options.o moc_plotter.o moc_qtcolorpicker.o qrc_icons.o-L/usr/lib/i386-linux-gnu -lboost_system -lboost_program_options -lrt -lpulse-simple -lpulse -L/usr/local/lib -lgnuradio-analog -lgnuradio-filter -lgnuradio-fft -lgnuradio-osmosdr -lgnuradio-blocks -lgnuradio-runtime -lgnuradio-pmt -lQtSvg -lQtGui -lQtCore -lpthread /usr/local/lib/libgnuradio-osmosdr.so: undefined reference to `bladerf_fpga_version' /usr/local/lib/libgnuradio-osmosdr.so: undefined reference to `bladerf_fw_version' collect2: ld returned 1 exit status make: *** [gqrx] Error 1 ras@ubuntu:~/gqrx$ When trying to run the previously built gqrx: gqrx linux; GNU C++ version 4.6.3; Boost_104800; UHD_003.005.003-164-g0c5099ab gr-osmosdr v0.1.0-13-g9b41c6aa (0.1.1git) gnuradio 3.7.2git-43-g9792b280 built-in source types: file fcd rtl rtl_tcp uhd bladerf Using Volk machine: avx_32_mmx_orc QLayout: Attempting to add QLayout "" to DockInputCtl "DockInputCtl", which already has a layout gr-osmosdr v0.1.0-13-g9b41c6aa (0.1.1git) gnuradio 3.7.2git-43-g9792b280 built-in source types: file fcd rtl rtl_tcp uhd bladerf [INFO] Instance: 0 [INFO] Found a bladeRF [INFO] Claimed all inferfaces successfully [INFO] Change to alternate interface 1 [INFO] Changed into RF link mode: LIBUSB_SUCCESS [WARNING] Could not extract serial number [WARNING] Could not extract VCTCXO trim value [WARNING] Could not extract FPGA size Using nuand LLC bladeRF #0 SN 8efd2b30699e61bec690a0b37cc5ad57gqrx: symbol lookup error: /usr/local/lib/libgnuradio-osmosdr-0.1.1git.so.0.0.0: undefined symbol: bladerf_fw_version ras@ubuntu:~/gqrx$ Any ideas out there? :) Ralph. -- Ralph A. Schmid Mondstr. 10 90762 Fürth +49-171-3631223 ra...@schmid.xxx http://www.bclog.de/ ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Again bladerf / gqrx / gr-osmosdr
On Tue, Oct 8, 2013 at 1:11 PM, Ralph A. Schmid, dk5ras wrote: > Hi, > > With latest versions of GR / bladerf / gqrx / gr-osmosdr again something is > stuck. Gqrx does not work anymore, I get the following error during make: > > > /usr/local/lib/libgnuradio-osmosdr.so: undefined reference to > `bladerf_fpga_version' > /usr/local/lib/libgnuradio-osmosdr.so: undefined reference to > `bladerf_fw_version' > collect2: ld returned 1 exit status > make: *** [gqrx] Error 1 > ras@ubuntu:~/gqrx$ make > g++ -Wl,-O1 -o gqrx main.o mainwindow.o receiver.o cafsk12.o costabf.o > agc_impl.o correct_iq_cc.o lpf.o resampler_xx.o rx_demod_am.o rx_demod_fm.o > rx_fft.o rx_filter.o rx_meter.o rx_agc_xx.o rx_noise_blanker_cc.o > sniffer_f.o stereo_demod.o afsk1200win.o agc_options.o audio_options.o > demod_options.o dockinputctl.o dockaudio.o dockfft.o dockiqplayer.o > dockrxopt.o freqctrl.o ioconfig.o meter.o nb_options.o plotter.o > qtcolorpicker.o nbrx.o receiver_base.o wfmrx.o pa_device_list.o pa_sink.o > pa_source.o moc_mainwindow.o moc_cafsk12.o moc_afsk1200win.o > moc_agc_options.o moc_audio_options.o moc_demod_options.o moc_dockaudio.o > moc_dockfft.o moc_dockinputctl.o moc_dockiqplayer.o moc_dockrxopt.o > moc_freqctrl.o moc_ioconfig.o moc_meter.o moc_nb_options.o moc_plotter.o > moc_qtcolorpicker.o qrc_icons.o-L/usr/lib/i386-linux-gnu -lboost_system > -lboost_program_options -lrt -lpulse-simple -lpulse -L/usr/local/lib > -lgnuradio-analog -lgnuradio-filter -lgnuradio-fft -lgnuradio-osmosdr > -lgnuradio-blocks -lgnuradio-runtime -lgnuradio-pmt -lQtSvg -lQtGui -lQtCore > -lpthread > /usr/local/lib/libgnuradio-osmosdr.so: undefined reference to > `bladerf_fpga_version' > /usr/local/lib/libgnuradio-osmosdr.so: undefined reference to > `bladerf_fw_version' > collect2: ld returned 1 exit status > make: *** [gqrx] Error 1 > ras@ubuntu:~/gqrx$ > > > When trying to run the previously built gqrx: > > gqrx > linux; GNU C++ version 4.6.3; Boost_104800; UHD_003.005.003-164-g0c5099ab > > gr-osmosdr v0.1.0-13-g9b41c6aa (0.1.1git) gnuradio 3.7.2git-43-g9792b280 > built-in source types: file fcd rtl rtl_tcp uhd bladerf > Using Volk machine: avx_32_mmx_orc > QLayout: Attempting to add QLayout "" to DockInputCtl "DockInputCtl", which > already has a layout > gr-osmosdr v0.1.0-13-g9b41c6aa (0.1.1git) gnuradio 3.7.2git-43-g9792b280 > built-in source types: file fcd rtl rtl_tcp uhd bladerf > [INFO] Instance: 0 > [INFO] Found a bladeRF > [INFO] Claimed all inferfaces successfully > [INFO] Change to alternate interface 1 > [INFO] Changed into RF link mode: LIBUSB_SUCCESS > [WARNING] Could not extract serial number > [WARNING] Could not extract VCTCXO trim value > [WARNING] Could not extract FPGA size > Using nuand LLC bladeRF #0 SN 8efd2b30699e61bec690a0b37cc5ad57gqrx: symbol > lookup error: /usr/local/lib/libgnuradio-osmosdr-0.1.1git.so.0.0.0: > undefined symbol: bladerf_fw_version > ras@ubuntu:~/gqrx$ > > Any ideas out there? :) I think it is because you don't use the latest bladerf library - or if you do, you probably still have an older version left. By the way, you should get this error while building gr-osmosdr and not while building gqrx unless you build gqrx before gr-osmosdr, which is the wrong order. I had the same build error few days ago when I tried to build gr-osmosdr in the gqrx/snapshots PPA against somebody elses bladerf debian package. I have then updated the bladerf library to the latest git where after everything built fine and is now avaialble through the gqrx PPA: https://launchpad.net/~gqrx/+archive/snapshots - though untested by me since I don't have the hardware. Alex ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Again bladerf / gqrx / gr-osmosdr
Hi, > I think it is because you don't use the latest bladerf library - or if you do, you > probably still have an older version left. Well, at least I made a git pull, make, sudo make install for bladerf. > By the way, you should get this error while building gr-osmosdr and not while > building gqrx unless you build gqrx before gr-osmosdr, which is the wrong > order. The order should have been bladerf, gr-osmosdr, gqrx, but I will clean everything and do it once again strictly by the book. > I had the same build error few days ago when I tried to build gr-osmosdr in > the gqrx/snapshots PPA against somebody elses bladerf debian package. I > have then updated the bladerf library to the latest git where after everything > built fine and is now avaialble through the gqrx PPA: > https://launchpad.net/~gqrx/+archive/snapshots > - though untested by me since I don't have the hardware. OK, I see. So maybe I really do a very thorough cleanup, not that there is hidden some quite old bladerf stuff somewhere :) Thanks a lot! Ralph. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] around empty subcarrier in 802.11n implementation
Hi list, I'm using gnuradio 3.6.0 together with USRPs N210 for implementing OFDM 802.11 n communications, just SISO for the moment (in the future it would be MIMO). I have properly modified parameters such as FFT size, number of occupied tones and so on. I have also included all preambles (STF, LTF...) and I have accordingly modified the "correlate" and "calculate_equalizer" functions in ofdm_frame_acquisition. FEC is also included in the chain. In the ofdm_frame_sink file I've added a function that computes SNR in a per-carrier basis. Everything is working fine, I obtain about 80% of correct packets, but I've noticed from the snr plotting, that the carriers around the central empty one (3 subcarriers before and 3 subcarriers after) have very poor snr values. So I've investigated about this effect, and I've realized that the all transmission errors are in those subcarriers and, in most cases, FEC is able to recover, but I would like to understand why this happens. I conducted some searches in the web but unfortunately I didn't find an answer. Let me know if you need some other information about my implementation. Thanks for your attention francesca ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Reconfigure FIR coefficients without stopping the sampling process
Hello Everyone, I have a quick question regarding the reconfiguration of blocks within a gnuradio "top block" application. I am working on a radar system that will occasionally attempt to switch transmission waveforms due to results of processed data. Consequently, the back end processing will have to adjust simultaneously, namely the FIR filter coefficients. Currently, I have a "top block" application working properly when the radar is operating for a fixed waveform. This application is initiated as a parallel process from a parent program, and continuously takes data until the parent program is terminated. Here is small portion of the code that is of interest: gr_matchfil = [gr.fir_filter_ccf(1, fr ) , gr.fir_filter_ccf(1, fr )] for i in range(numchan): fg.connect((u,i), (gr_decimation[i],0)) fg.connect((gr_decimation[i],0), (gr_matchfil[i],0)) fg.connect((gr_matchfil[i],0), (gr_interleave,i)) fg.connect((gr_interleave,0), (fsink,0)) fg.start() What I would like to do is alter the the coefficients "fr" in the variable "gr_matchfil" from the parent program without stopping the sampling process. I figure that this will have to do something with accessing the shared memory of the parallel process. Would this be possibly after "fg.start()" is executed. If anybody has any ideas on how to achieve this, it would be greatly appreciated. Thanks, Rob -- View this message in context: http://gnuradio.4.n7.nabble.com/Reconfigure-FIR-coefficients-without-stopping-the-sampling-process-tp44013.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] Reconfigure FIR coefficients without stopping the sampling process
The filters all have "set_taps()" methods that allow you to set the taps dynamically. on Oct 08, 2013, rmsrms1987 wrote: Hello Everyone, I have a quick question regarding the reconfiguration of blocks within agnuradio "top block" application. I am working on a radar system that willoccasionally attempt to switch transmission waveforms due to results ofprocessed data. Consequently, the back end processing will have to adjustsimultaneously, namely the FIR filter coefficients. Currently, I have a"top block" application working properly when the radar is operating for afixed waveform. This application is initiated as a parallel process from aparent program, and continuously takes data until the parent program isterminated. Here is small portion of the code that is of interest:gr_matchfil = [gr.fir_filter_ccf(1, fr ) , gr.fir_filter_ccf(1, fr )]for i in range(numchan): fg.connect((u,i), (gr_decimation[i],0)) fg.connect((gr_decimation[i],0), (gr_matchfil[i],0)) fg.connect((gr_matchfil[i],0), (gr_interleave,i)) fg.connect((gr_interleave,0), (fsink,0))fg.start()What I would like to do is alter the the coefficients "fr" in the variable"gr_matchfil" from the parent program without stopping the sampling process. I figure that this will have to do something with accessing the sharedmemory of the parallel process. Would this be possibly after "fg.start()"is executed. If anybody has any ideas on how to achieve this, it would begreatly appreciated. Thanks,Rob--View this message in context: http://gnuradio.4.n7.nabble.com/Reconfigure-FIR-coefficients-without-stopping-the-sampling-process-tp44013.htmlSent from the GnuRadio mailing list archive at Nabble.com.___Discuss-gnuradio mailing listDiscuss-gnuradio@gnu.orghttps://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] around empty subcarrier in 802.11n implementation
On Tue, Oct 8, 2013 at 9:52 AM, xe...@libero.it wrote: > Hi list, > > I'm using gnuradio 3.6.0 together with USRPs N210 for implementing OFDM 802.11 > n communications, just SISO for the moment (in the future it would be MIMO). I > have properly modified parameters such as FFT size, number of occupied tones > and so on. I have also included all preambles (STF, LTF...) and I have > accordingly modified the "correlate" and "calculate_equalizer" functions in > ofdm_frame_acquisition. FEC is also included in the chain. In the > ofdm_frame_sink file I've added a function that computes SNR in a per-carrier > basis. > > Everything is working fine, I obtain about 80% of correct packets, but I've > noticed from the snr plotting, that the carriers around the central empty one > (3 subcarriers before and 3 subcarriers after) have very poor snr values. So > I've investigated about this effect, and I've realized that the all > transmission errors are in those subcarriers and, in most cases, FEC is able > to > recover, but I would like to understand why this happens. > > I conducted some searches in the web but unfortunately I didn't find an > answer. > Let me know if you need some other information about my implementation. > > Thanks for your attention > francesca The USRPs do a good job at getting rid of the DC carrier, but there are still issues around DC that are probably affecting you. The crude but easy option is to try to make sure you are perfectly centered on DC by some hand-tuning. Tom ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] How to integrate a specific number of vectors element-wise in gnuradio?
I've been poking around in other GRC files to find examples. The ones in specest are a little tough around the edges, but I've found the ones in GNURadio/gr-fft and other sub blocks of GNURadio to be decent examples. Rgrep has been helpful... Jared On Oct 8, 2013 1:26 AM, "Eskil Varenius" wrote: > Hi again, > I uninstalled what I had installed through PyBOMBS and installed Gnuradio > 3.7 through the build_gnuradio script. Then I tried Jareds repo for specest > with 3.7 (http://www.github.com/dfxx) and it seems to compile just fine, > well done! I can also import specest in python without problems. > > Now: I would very much like to use the block moving_average_vff in > Gnuradio Companion. Unfortunately it seems there are no xml files for that > block, hence invisible to the GRC. I got a hint from Martin Braun that I > could use the "gr_modtool makexml" command to generate this. Unfortunately > it seems that I don't understand how to use it: > > gr_specest_jared$ ls > apps AUTHORS build cmake CMakeLists.txt COPYING docs examples grc > include lib python README swig > gr_specest_jared$ gr_modtool makexml moving_average_vff > GNU Radio module name identified: specest > Warning: This is an experimental feature. Don't expect any magic. > Searching for matching files in lib/: > None found. > - > There is a file called moving_average_vff.cc in the lib directory, so I > guess something more is needed here which I don't know about. > > I tried looking at the page > http://gnuradio.org/redmine/projects/gnuradio/wiki/OutOfTreeModules?version=16#Making-your-blocks-available-in-GRCwhere > there are links to example xml blocks to understand a bit more, but > it seems these links are broken. Also the link to the gr_block > documentation in the next section (There's more:...) is broken. > > I'm grateful for any hints on how to make the block moving_average_vff > visible in the GRC. > > Best regards, > Eskil > > > 2013/10/4 Jared Clements > >> I updated gr-specest so it would compile with 3.7, see my repo on >> www.github.com/dfxx if you want to try that route. The changes were >> almost all namespace stuff and cmake stuff, i.e. I don't think I broke >> anything. >> >> Jared >> On Oct 4, 2013 7:33 AM, "Eskil Varenius" >> wrote: >> >>> Hi everyone, >>> After a long break since June I am now back learning about Gnuradio. I >>> asked in June for a way to average vectors elementwise and Martin Braun >>> suggested the moving_average_Vff block in the gr-specest. He also said it >>> would be available PyBOMBS. Now update: >>> >>> Since I had installed Gnuradio using the build-script I wanted to >>> re-install it using pybombs. I uninstalled the old gnuradio by doing a >>> "sudo make uninstall" in each build directory for the old release. Seems to >>> work. Now I installed gnuradio 3.6 (since gr-specest is still only verified >>> for 3.6, although I'm happy to see people working towards a 3.7 release). I >>> did the install using the instructions on the pybombs quickstart page: >>> >>> git clone git://github.com/pybombs/pybombs >>> cd pybombs >>> git checkout gr-3.6 >>> ./pybombs install gnuradio >>> >>> Gnuradio seemed to install without problems but: I realised I had >>> path-problems since I could not start anything (gnuradio companion, import >>> gnuradio etc. fails). Perhaps this was related to me using a custom target >>> directory (/opt/gnuradio_pybombs). I looked around and found path >>> instructions for custom directory installs at " >>> http://gnuradio.org/redmine/projects/gnuradio/wiki/UbuntuInstall#Installing-in-a-custom-directory";, >>> i.e. put the following in my .bashrc: >>> >>> # GNU Radio installation >>> export PATH=$PATH:/opt/gnuradio_pybombs/bin >>> export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:/opt/gnuradio_pybombs/lib >>> export >>> PKG_CONFIG_PATH=$PKG_CONFIG_PATH:/opt/gnuradio_pybombs/lib/pkgconfig >>> export >>> PYTHONPATH=$PYTHONPATH:/opt/gnuradio_pybombs/lib/python2.6/site-packages >>> >>> However, that didn't work completely - I still could not find the >>> gnuradio python module. I realised two things: the 2.6 should probably be >>> 2.7 for me, and also the pythonpath should end in dist-packages, not >>> site-packages, since the site-packages folder was empty. After modifying >>> the pythonpath with 2.7 and dist-packages everything runs, I can import >>> gnuradio and also use gnuradio companion. So far so good! >>> >>> Now for gr-specest. I tried to install it using app store (cool stuff, >>> you guys are amazing!) and also just command line which is equivalent, i.e. >>> I run using "sudo ./pybombs install gr-specest" I get a lot of output, but >>> the perhaps most interesting one before it ends abruptly is: >>> -- checking for module 'gruel' >>> -- package 'gruel' not found >>> -- Could NOT find GRUEL (missing: GRUEL_LIBRARIES GRUEL_INCLUDE_DIRS) >>> -- checking for module 'gnuradio-core' >>> -- package 'gnuradio-core' not found >>>
[Discuss-gnuradio] AM transmitter
Hi, I'm new user of GNU. Can someone please help me in creating a flowgraph of AM transmitter. I have to use it for communication of radio having a range 3-30 MHz. Receiver part is already done. I just wanted a waveform of transmitter part only. I have to integrate this waveform with FM receiver. Please help. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Avoiding jargon how might GNUradio, software defined radio be explained to AM-FM radio listeners unfamiliar with technology generally?
Avoiding jargon how might GNUradio, software defined radio be explained to AM-FM radio listeners unfamiliar with technology generally? Already checked relatively more technical material at http://gnuradio.org/redmine/projects/gnuradio/wiki/FAQ http://en.wikipedia.org/wiki/Gnuradio http://en.wikipedia.org/wiki/Software-defined_radio ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] energy detection based spectrum sensing
Hello every one... can any buddy say , is it possible to make simulation of enegergy detection based spectrum sensing without USRP or Fun-cube dongle .??? if , yes . How? guide me. as per my opinion .. it may be possible by redefine block which give frequency band we require to sense -- *Thanks and regard:* * MR.Maheshkumar Pandit ** * *call @ 9662784649 * ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Avoiding jargon how might GNUradio, software defined radio be explained to AM-FM radio listeners unfamiliar with technology generally?
I've described it like this: Traditionally radios have been purpose-built for specific types of tasks using electronic components to perform those tasks. Many of the crucial "systems" in a radio are actually performing mathematical "transformations" on the signals going through them. Sometimes really well, sometimes rather poorly. In a software-defined radio, the computer does the "math" on those signals, instead of a string of fixed-purpose electronic components. What this means is that today your computer can be doing regular broadcast FM radio, and tomorrow, it could be doing radar, and the only thing that changes is the software. on Oct 08, 2013, don warner saklad wrote: Avoiding jargon how might GNUradio, software defined radio beexplained to AM-FM radio listeners unfamiliar with technology generally?Already checked relatively more technical material athttp://gnuradio.org/redmine/projects/gnuradio/wiki/FAQhttp://en.wikipedia.org/wiki/Gnuradiohttp://en.wikipedia.org/wiki/Software-defined_radio___Discuss-gnuradio mailing listDiscuss-gnuradio@gnu.orghttps://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] AM transmitter
First of all, I'm sorry that I could not understand clearly what you want. Are you using any hardware or you are just running a simulation using *GNU Radio*? What do you mean by waveform of transmitter? How do you integrate AM transmitter with FM receiver? If you have USRP and want DSBSC AM, it is easy to construct. Take a audio sample file. Connect it to USRP sink with appropriate interpolation. That can be counted as AM. On Tue, Oct 8, 2013 at 8:51 PM, Bijendra Singh wrote: > Hi, > I'm new user of GNU. Can someone please help me in creating a flowgraph of > AM transmitter. I have to use it for communication of radio having a range > 3-30 MHz. Receiver part is already done. I just wanted a waveform of > transmitter part only. I have to integrate this waveform with FM receiver. > Please help. > > ___ > Discuss-gnuradio mailing list > Discuss-gnuradio@gnu.org > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio > > -- Manu T S ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Again bladerf / gqrx / gr-osmosdr
I did make uninstall and make clean in bladerf, gr-osmosdr and gqrx, then rebuild it all, still this error: /usr/local/lib/libgnuradio-osmosdr.so: undefined reference to `bladerf_fpga_version' /usr/local/lib/libgnuradio-osmosdr.so: undefined reference to `bladerf_fw_version' collect2: ld returned 1 exit status make: *** [gqrx] Error 1 ras@ubuntu:~/gqrx$ Time to restore the backup :) With best regards Ralph. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] gr_firdes.cc/firdes.cc - window functions - flawe
Hi Tom and Chris,
Thanks for your detailed guidance on this. I'll try this out.
Bob
On Mon, Oct 7, 2013 at 9:49 PM, KB3CS - Chris wrote:
> $ git diff v3.6.3 HEAD gr-filter/lib/firdes.cc (but modified since you
> remain @ v3.6.3)
>
> diff --git a/gr-filter/lib/firdes.cc b/gr-filter/lib/firdes.cc
> index 5c3320d..d55a4ba 100644
> --- a/gr-filter/lib/firdes.cc
> +++ b/gr-filter/lib/firdes.cc
> @@ -746,6 +746,7 @@ namespace gr {
>case WIN_RECTANGULAR:
> for(int n = 0; n < ntaps; n++)
>taps[n] = 1;
> +break;
>
>case WIN_HAMMING:
> for(int n = 0; n < ntaps; n++)
> @@ -774,16 +775,13 @@ namespace gr {
> double IBeta = 1.0/Izero(beta);
> double inm1 = 1.0/((double)(ntaps));
> double temp;
> - //fprintf(stderr, "IBeta = %g; inm1 = %g\n", IBeta, inm1);
>
> - for(int i=0; i - temp = i * inm1;
> - //fprintf(stderr, "temp = %g\n", temp);
> - taps[i] = Izero(beta*sqrt(1.0-temp*temp)) * IBeta;
> - //fprintf(stderr, "taps[%d] = %g\n", i, taps[i]);
> - }
> + for(int i= 0; i +temp = 2*i*inm1 - 1;
> +taps[i] = Izero(beta*sqrt(1.0-temp*temp)) * IBeta;
> + }
> }
> - break;
> + break;
>
>default:
> throw std::out_of_range("firdes:window: type out of range");
> @@ -804,7 +802,7 @@ namespace gr {
> throw std::out_of_range("firdes check failed: 0 < fa <=
> sampling_freq / 2");
>
>if(transition_width <= 0)
> - throw std::out_of_range("gr_dirdes check failed: transition_width
> > 0");
> + throw std::out_of_range("gr_firdes check failed: transition_width
> > 0");
> }
>
> void
>
> .. but don't make the #include file changes in your v3.6.3 and you should
> change the version number (VERSION_INFO_MAINT_VERSION) in CMakeLists.txt
>
>
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] GNU Radio training class opening
One of our private GNU Radio training classes in San Antonio, TX, has had a couple slots open up, and our customer is willing to allow 3rd parties to attend. It's happening Oct. 21-25. The first three days is the Intro class that comes with a USRP, and the last two days is the Advanced add-on class. It's short notice, but please contact me *off list* if this is of interest to you. -- Johnathan Corgan, Corgan Labs SDR Training and Development Services http://corganlabs.com <> signature.asc Description: OpenPGP digital signature ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] PFB Arbitrary Resampler
In the benchmark_tx.py code for MPSK modulation, the pfb_arbitrary_resampler block is instantiated with 32 * 11 * floor(samples_per_symbol) taps. I understand that 32 is the number of filters in the filterbank, but I'm not sure what motivates the factor of 11. Has anybody been able to fine tune these numbers to improve performance of the resampling filter, e.g., reducing the number of taps? Thanks, Sean ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] PFB Arbitrary Resampler
On Tue, Oct 8, 2013 at 6:54 PM, Nowlan, Sean wrote: > In the benchmark_tx.py code for MPSK modulation, the pfb_arbitrary_resampler > block is instantiated with 32 * 11 * floor(samples_per_symbol) taps. I > understand that 32 is the number of filters in the filterbank, but I’m not > sure what motivates the factor of 11. Has anybody been able to fine tune > these numbers to improve performance of the resampling filter, e.g., > reducing the number of taps? > > > > Thanks, > > Sean Good, undocumented, question. As you say, the 32 comes from the number of filters. We're going to create a large set of taps and distributed them over the N number of filters. So each filter will have 11*sps taps in it. Because we're using a non-Nyquist filter (the RRC), we are introducing memory into our system. Ideally, these filters go from minus to plus infinity. But we want to truncate it to a number that's practical, so we have to make some assumption about how far away is good enough that the effects of the symbol M samples away is too small to care. We (I think Eric originally; before my time at least) came up with 11. I've heard 7 is also a good number for this. It's likely that we could calculate a good number based on the quantization effects we'll be dealing with later in the hardware. I /think/ that if we figure out what's the most amount of noise the filter can possibly add to a symbol M samples away and make sure that that is just about the same as the quantization noise. If it's the same or less, it should be ok to use. If it's more, we might be introducing more ISI into our system. We assume, of course, a matched filter with the same channel length will correct for this ISI at the receiver, but other channel conditions may affect this assumption. The 11 is probably more than necessary but also in a sense 'safe' to use. Tom ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Bug in freq_xlating_fir_filter_XXX
I was playing around with fir_filter_XXX and freq_xlating_fir_filter_XXX and noticed that the two do not give the same output for the same input (and center_freq=0 in the xlating filter). Looking at the implementation of the latter it is obvious why: the taps are reversed in the line: std::reverse(ctaps.begin(), ctaps.end()); For consistency the taps should not be reversed (as in all other filters) We also need to set float fwT0 = 2 * M_PI * d_center_freq / d_sampling_freq; (instead of the minus sign in the code). unless there is an objection, I will go ahead and push a correction, Achilleas ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] How to integrate a specific number of vectors element-wise in gnuradio?
Thanks for the ideas, I could do that and Rgrep seems useful indeed. However, I'm new to coding Gnuradio and would like to use the tools provided as far as possible, i.e. I would very much like to use the gr_modtool to help me with creating the xml files. But, after some investigations it seems the gr_modtool cannot be used in this case since there is no "_impl" file for the moving_average_vff.cc. This raises a few basic questions which I've tried to answer reading e.g. the coding guide at http://gnuradio.org/redmine/projects/gnuradio/wiki/Coding_guide_impl and http://gnuradio.org/redmine/projects/gnuradio/wiki/BlocksCodingGuide#Implementation-Source-File. But these instructions are I feel a bit over my head at the moment since I'm new to the block coding, so instead I have three more basic questions which I hope someone could help me with: 1) What is the relation between cc files in the lib directory with and without the _impl suffix? 2) Does the file moving_average_vff.cc need to be converted into a _impl.cc file before I can use this block with gnuradio companion, or can I go ahead and write an XML file for the current block files? 3) Where should I start reading if I want to learn how to convert the block moving_average_vff to something that can be recognized by the gr_modtool makexml? I'm sorry if these questions are stupid or the wrong forum, but I'm very grateful for all ideas and pointers to get me on the right track. If there's a better place to ask these things, please let me know. Best regards, Eskil 2013/10/8 Jared Clements > I've been poking around in other GRC files to find examples. The ones in > specest are a little tough around the edges, but I've found the ones in > GNURadio/gr-fft and other sub blocks of GNURadio to be decent examples. > Rgrep has been helpful... > > Jared > On Oct 8, 2013 1:26 AM, "Eskil Varenius" wrote: > >> Hi again, >> I uninstalled what I had installed through PyBOMBS and installed Gnuradio >> 3.7 through the build_gnuradio script. Then I tried Jareds repo for specest >> with 3.7 (http://www.github.com/dfxx) and it seems to compile just fine, >> well done! I can also import specest in python without problems. >> >> Now: I would very much like to use the block moving_average_vff in >> Gnuradio Companion. Unfortunately it seems there are no xml files for that >> block, hence invisible to the GRC. I got a hint from Martin Braun that I >> could use the "gr_modtool makexml" command to generate this. Unfortunately >> it seems that I don't understand how to use it: >> >> gr_specest_jared$ ls >> apps AUTHORS build cmake CMakeLists.txt COPYING docs examples >> grc include lib python README swig >> gr_specest_jared$ gr_modtool makexml moving_average_vff >> GNU Radio module name identified: specest >> Warning: This is an experimental feature. Don't expect any magic. >> Searching for matching files in lib/: >> None found. >> - >> There is a file called moving_average_vff.cc in the lib directory, so I >> guess something more is needed here which I don't know about. >> >> I tried looking at the page >> http://gnuradio.org/redmine/projects/gnuradio/wiki/OutOfTreeModules?version=16#Making-your-blocks-available-in-GRCwhere >> there are links to example xml blocks to understand a bit more, but >> it seems these links are broken. Also the link to the gr_block >> documentation in the next section (There's more:...) is broken. >> >> I'm grateful for any hints on how to make the block moving_average_vff >> visible in the GRC. >> >> Best regards, >> Eskil >> >> >> 2013/10/4 Jared Clements >> >>> I updated gr-specest so it would compile with 3.7, see my repo on >>> www.github.com/dfxx if you want to try that route. The changes were >>> almost all namespace stuff and cmake stuff, i.e. I don't think I broke >>> anything. >>> >>> Jared >>> On Oct 4, 2013 7:33 AM, "Eskil Varenius" >>> wrote: >>> Hi everyone, After a long break since June I am now back learning about Gnuradio. I asked in June for a way to average vectors elementwise and Martin Braun suggested the moving_average_Vff block in the gr-specest. He also said it would be available PyBOMBS. Now update: Since I had installed Gnuradio using the build-script I wanted to re-install it using pybombs. I uninstalled the old gnuradio by doing a "sudo make uninstall" in each build directory for the old release. Seems to work. Now I installed gnuradio 3.6 (since gr-specest is still only verified for 3.6, although I'm happy to see people working towards a 3.7 release). I did the install using the instructions on the pybombs quickstart page: git clone git://github.com/pybombs/pybombs cd pybombs git checkout gr-3.6 ./pybombs install gnuradio Gnuradio seemed to install without problems but: I realised I had path-problems since I could not start anything (gnuradio companion, impo
