Re: [Discuss-gnuradio] Questions regarding hierarchical polyphase channelizer
So I reacquainted myself with the hierarchical implementation again, and you're correct that it doesn't support oversampling. Looking at the regular version it seems that the main thing required to support oversampling would be that the logic determining which input samples go into which filter, and then how the filter outputs are fed into the FFT gets more complicated. You'd have to go through the regular version, work out how the oversampling effects the connections between the input/filters/fft/output and then implement new signal processing blocks to take care of this more complicated plumbing. The new plumbing blocks could then be included in the hierarchical decoder. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Questions regarding hierarchical polyphase channelizer
The algorithm should be identical in the hierarchical case. The only difference is that because the hierarchical implementation splits the logic over several signal processing blocks, GNURadio is able to easily parallelize the implementation. The n_filterbanks parameter is just the number of filterbank blocks that are used for the filtering. More filterbank blocks means more parallelizable, but also more overhead. I'd have to spend some time reacquainting myself with the code to answer your last question properly, but it should be possible to do everything with the hierarchical implementation that you can with the single-block implementation. On Mon, Oct 24, 2016 at 6:30 AM, Piotr Krysik <per...@o2.pl> wrote: > Hi all, > > Recently I did simple benchmark of hierarchical polyphase channelizer > block (written by Ben Reynwar according to git blame) vs regular > polyphase channelizer block. It seems that hierarchical version is 2-3 > times faster. > > The documentation of the hierachical polyphase channelizer seems to be a > bit too brief though (at least for me). This topic has been touched on > this list before, but produced no more info about the block (in the > "hierarchical polyphase channelizer vs polyphase channelizer blocks in > GRC" thread). > > A bit more info is needed about the block's parameters and how it > capabilities relate to normal polyphase channelizer block. Especially: > > -what n_filterbanks parameter is for? > > -is it possible to do oversampling of the signal at the output channels > with this block the way it is possible with normal polyphase channelizer > block? > > > -- > > Thanks and regards, > > Piotr Krysik > > > ___ > 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] GRCon15: Hotels
There are also two hostels nearby for about $35/night. https://www.google.com/maps/search/hostel+near+Center+for+Strategic+and+International+Studies/@38.9065175,-77.0376912,15z On Thu, Apr 23, 2015 at 9:41 AM, Michael Dickens michael.dick...@ettus.com wrote: In case folks are wondering, there are quite a few hotels and other lodging places within easy walking distance of the GRCon15 venue: the Center for Strategic and International Studies [1]. For whatever reason, places of lodging near the CSIS are quite reasonably priced for Washington, DC right now: typically $110 to $180 / night before taxes such [2]. There will be no conference-sponsored group-rate hotels, given these prices. So, knowing that GRCon15 is August 24 through 28, book your lodging sooner rather than later to lock in these prices! We will also include this information on the GRCon15 website, which we're actively working on. - MLD Suggested Hotels: a) Courtyard Washington Embassy Row 1600 Rhode Island Avenue, NW, Washington, DC 20036 Rates starting at $169/night http://www.marriott.com/hotels/travel/wasem-courtyard-washington-embassy-row/ b) The Beacon Hotel 1615 Rhode Island Avenue, NW, Washington, DC 20036 Rates starting at $140/night. Book 45 days in advance for the best rate. http://www.beaconhotelwdc.com/default.aspx?pg=homehid=587vl=516d3e7f-095e-4f30-9ea9-2d59b250405f [1] CSIS, 1616 Rhode Island Avenue NW, Washington, DC http://csis.org/about-us/conference-center-csis/ [2] Google Maps: hotels near CSIS with prices for August 23 - 29 https://www.google.com/maps/search/hotels/@38.906542,-77.0377236,17z/data=!4m9!2m8!3m3!1shotels!2s1616+Rhode+Island+Ave+NW,+Washington,+DC+20036!3s0x89b7b7c09fe71ec7:0x3b622617cab9f901!5m3!5m2!1s2015-08-23!2i6 ___ 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] Error in Constellation Decoder block
Try changing: digital.constellation_qpsk.base() to: digital.constellation_qpsk().base() Note the brackets after the constellation_qpsk constructor. On Thu, Mar 6, 2014 at 9:05 AM, Azza Ben Mosbah azza.ben.mos...@gmail.com wrote: Thank you. Actually, I am doing it in the GRC interface. When I use the .base(), it returns the following error: Param - Constellation Object(constellation): Value digital.constellation_qpsk.base() cannot be evaluated: 'function' object has no attribute 'base' I don't know what is the matter. But, maybe, there is some issues with my GRC version (GNU Radio Companion 3.6.2). Regards, - Azza Ben Mosbah On Thu, Mar 6, 2014 at 10:54 AM, Tom Rondeau t...@trondeau.com wrote: On Wed, Mar 5, 2014 at 8:59 AM, Azza Ben Mosbah azza.ben.mos...@gmail.com wrote: Tom, Thank you for the help. But, even that didn't work. I tried a different approach. I configured the Constellation Object block with the symbol map and the constellation points. Then, I called it in the argument of the Constellation Decoder block. And it worked. I am still wondering what is the right way to define a 'digital_constellation_sptr' type in the Constellation Decoder argument without passing by the Constellation Object block. Regards, Azza Yes, that Constellation Object in GRC returns the .base() automatically for you so that you can pass it to the Constellation Decode/Receiver blocks easily. You really should be able to use the .base() method of those constellation blocks this way. Are you in GRC doing this or doing your own Python? There could be some issues with GRC properly interpreting your casting using base() (which is likely related to why the Constellation Objects just return the.base() method for you). Tom On Tue, Mar 4, 2014 at 5:16 PM, Tom Rondeau t...@trondeau.com wrote: On Tue, Mar 4, 2014 at 4:17 PM, Azza Ben Mosbah azza.ben.mos...@gmail.com wrote: Hi All, I am manipulating GNU Radio Companion. While using the Constellation Decoder block, I have put digital.constellation_qpsk as a Constellation Object argument. But, I have found an error when I have executed the flow graph: Traceback (most recent call last): File /users/anb10/metrics/error_rate.py, line 342, in module tb = error_rate() File /users/anb10/metrics/error_rate.py, line 225, in __init__ self.digital_constellation_decoder_cb_0 = digital.constellation_decoder_cb(digital.constellation_qpsk) File /usr/lib64/python2.6/site-packages/gnuradio/digital/digital_swig.py, line 3096, in constellation_decoder_cb return _digital_swig.constellation_decoder_cb(*args, **kwargs) TypeError: in method 'constellation_decoder_cb', argument 1 of type 'digital_constellation_sptr' I don't know what went wrong. I have even tried digital.psk.psk_constellation(m=4,mod_code='gray'), digital.constellation_8psk and digital.psk.psk_constellation(m=8,mod_code='gray') as a Constellation Object argument. So, what is the proper way to define the argument (Constellation Object) in the Constellation Decoder block? I hope you can give me some ideas. Any help is appreciated. Thank you. Regards, Azza Azza, Check out the documentation page: http://gnuradio.org/doc/doxygen/classgr_1_1digital_1_1constellation__decoder__cb.html It's not entirely clear (unless you know to look for it). You want to pass the constellation object using the base() parameter to get to the parent class. Basically, you'd call it: digital.constellation_decoder_cb(digital.constellation_qpsk.base()) 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] how to get the data of gr.probe_signal_vf
You want the level attribute not value. On Tue, Sep 3, 2013 at 9:22 AM, sunday iliya sundayiliyagot...@yahoo.com wrote: Dear All, I'm a PhD student at De Montfort University UK and I'm new to gnuradio. I was using gr.probe_signal_vf gr.probe_signal_vc to obtain data for USRP and fft magnitude but when i used the dot value() attribute to get the data, i received an error message saying the object of gr.probe_signal_vf has no value attribute. please kindly help. Thanks Sunday ___ 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] Public transport in Boston
There are also a few backpacking hostels in downtown boston, some of which probably have private rooms. Not quite the same as a hotel, but normally way cheaper. On Mon, Aug 5, 2013 at 8:12 AM, Philip Balister phi...@balister.org wrote: I am looking at hotels in Boston GR Con. Needless to say, I will never complain about Si valley rates again. Does anyone have any comments about public transport in Boston? Especially about getting from cheaper hotels to the conference location. Thanks, Philip ___ 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] Meetup in London?
I'll be in England that week, and should be able to make it. No preference on the day. On Fri, Jun 21, 2013 at 7:10 AM, Tom Rondeau t...@trondeau.com wrote: Hi everyone, I'll be in London the week of July 8 for a few lectures at a summer school at King's College [1]. I'd like to have a meetup of GNU Radio and SDR people while I'm in town. I'm working with a venue now to set things up. We can either do Tuesday (July 9) or Thursday (July 11). Can I get a show of hands who might be able and willing to come out and join me for an evening? If there's a strong preference on the date, let me know that, too. Tom [1] http://www.iot.kcl.ac.uk/summerschool2013/ ___ 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] Setting PythonPath
Also, as of a couple of weeks ago, if you put gnuradio/build/gnuradio-runtime/python in your PYTHONPATH then that will work too. You'll need to be using the current master branch for this to work. On Tue, Jun 18, 2013 at 9:03 AM, Marcus Leech mle...@ripnet.com wrote: If you had used the build-gnuradio script, it will, as one of the last things it does, suggest what PYTHONPATH to use on your system. Ubuntu typically puts locally-installed Python packages in: /usr/local/lib/python2.X/dist-packages Also, keep in mind that the default terminal window configuration for Ubuntu does't set the run as login shell flag, so your .bashrc file is never run. You can change this behaviour in the preferences for the terminal window. on Jun 18, 2013, Aaron Henderson egine...@hotmail.com wrote: Hello All, I have worked on setting the PythonPath for 3 weeks now. I have followed the steps in the following posting: http://gnuradio.org/redmine/projects/gnuradio/wiki/UbuntuInstall Here is my latest attempt of editing my bash file: # GNU Radio installation export PATH=$PATH:/usr/local export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:/usr/local/lib export PKG_CONFIG_PATH=$PKG_CONFIG_PATH:/usr/local/lib/pkgconfig export PYTHONPATH=$PYTHONPATH:/usr/local/lib/python2.6/site-packages and here is the error code that persists no matter what I do when I use my benchmark code: Traceback (most recent call last): File benchmark_rx2.6a.py, line 23, in module from gnuradio import gr, gru, modulation_utils ImportError: No module named gnuradio Does anyone have any tips or clues as to what I am doing wrong? Aaron henderson ___ 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] Setting PythonPath
My suggestion was probably unnecessarily complicating things.
You need to find where the gnuradio has been installed to. There will
be a directory containing a gnuradio folder which in turn will contain
an __init__.py file.
You could find it by brute force using something like:
find / -name gnuradio 2/dev/null | xargs -I{} find '{}' -maxdepth 1
-name __init__.py
If you're sure you've got the correct location then you're likely not
setting your PYTHONPATH like you think you are. Trying doing it
manually in a shell. Run python from that shell and see if you can
import gnuradio.
On Tue, Jun 18, 2013 at 1:26 PM, Aaron Henderson egine...@hotmail.com wrote:
I have tried both of these options. I found my GNURadio file inside the
dist-packages file and made the change to the first posting. I also tried
using the last suggestion from Ben. Thank you both for the help; however, I
get the same error message when I attempt to use the benchmark code. I am
using Ubuntu 11.10 and GNURadio 3.6.3.
Would the GNURadio 3.6.3.1 being installed fix this problem or is it a
totally different bug fix?
Date: Tue, 18 Jun 2013 11:01:36 -0700
Subject: Re: [Discuss-gnuradio] Setting PythonPath
From: b...@reynwar.net
To: mle...@ripnet.com
CC: egine...@hotmail.com; discuss-gnuradio@gnu.org
Also, as of a couple of weeks ago, if you put
gnuradio/build/gnuradio-runtime/python in your PYTHONPATH then that
will work too. You'll need to be using the current master branch for
this to work.
On Tue, Jun 18, 2013 at 9:03 AM, Marcus Leech mle...@ripnet.com wrote:
If you had used the build-gnuradio script, it will, as one of the last
things it does, suggest what PYTHONPATH to use on your system. Ubuntu
typically puts locally-installed Python packages in:
/usr/local/lib/python2.X/dist-packages
Also, keep in mind that the default terminal window configuration for
Ubuntu
does't set the run as login shell flag, so your .bashrc file is never
run.
You can change this behaviour in the preferences for the terminal
window.
on Jun 18, 2013, Aaron Henderson egine...@hotmail.com wrote:
Hello All,
I have worked on setting the PythonPath for 3 weeks now.
I have followed the steps in the following posting:
http://gnuradio.org/redmine/projects/gnuradio/wiki/UbuntuInstall
Here is my latest attempt of editing my bash file:
# GNU Radio installation
export PATH=$PATH:/usr/local
export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:/usr/local/lib
export PKG_CONFIG_PATH=$PKG_CONFIG_PATH:/usr/local/lib/pkgconfig
export PYTHONPATH=$PYTHONPATH:/usr/local/lib/python2.6/site-packages
and here is the error code that persists no matter what I do when I use
my
benchmark code:
Traceback (most recent call last):
File benchmark_rx2.6a.py, line 23, in module
from gnuradio import gr, gru, modulation_utils
ImportError: No module named gnuradio
Does anyone have any tips or clues as to what I am doing wrong?
Aaron henderson
___
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] Dev Call May 16 / Google Hangout
Looks like we get an increase to a 15 person limit if the person who starts the hangout is using a google apps account. http://googleenterprise.blogspot.com/2012/11/larger-hangouts-in-google-for.html On Thu, May 16, 2013 at 6:08 AM, Martin Braun (CEL) martin.br...@kit.edu wrote: Quick reminder... if you want to join the dev call, make sure you have the plugin installed, your mic works (and doesn't echo), and you're in IRC by 1700 UTC to make sure you don't miss anything. MB On Mon, May 13, 2013 at 12:57:19PM +0200, Martin Braun (CEL) wrote: This Thursday, May 16, we will do our monthly developers call. As before, at's at 10 AM Pacific, 19:00 CEST, 1700 UTC. IMPORTANT: We will be using a Google+ hangout via our G+ community, which you can find at: https://plus.google.com/communities/105194615257651755927 To participate, you must install the plugin beforehand. You can find it at: https://tools.google.com/dlpage/hangoutplugin Make sure you've checked your audio is working and the plugin works *before* the dev call. Also, we've identified some trouble with the hangout notification. Usually, to join the hangout, you go to the G+ GNU Radio page (see above), and you'll see a 'Join Hangout' button at the right. Last time, this didn't work for everyone. If you can't join, tell us in IRC and we'll send you an invite directly. In case this was unclear: We will continue to use IRC as part of the note-taking. All off this G+ stuff is still in testing phase, so bear with us. 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 -- 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
Re: [Discuss-gnuradio] where is gnuradio-examples/python/pfb?
Thanks for letting us know the documentation is out of date. You should find filterbank examples in gr-filter/examples. On Tue, May 14, 2013 at 12:28 PM, LD Zhang ldz10...@gmail.com wrote: Hi, I am reading the polyphase filterbank documentation. It points to a directory where examples are contained: gnuradio-examples/python/pfb. In my installation I have the following directories and files: -rw-rw-r-- 1 ldz ldz 4041 Sep 18 2012 README-win32-mingw-short.txt -rw-rw-r-- 1 ldz ldz 10237 Sep 18 2012 README.hacking -rw-rw-r-- 1 ldz ldz 1695 Sep 18 2012 README.building-boost -rw-rw-r-- 1 ldz ldz 4846 Sep 18 2012 README -rw-rw-r-- 1 ldz ldz 35147 Sep 18 2012 COPYING -rw-rw-r-- 1 ldz ldz 9527 Sep 18 2012 CMakeLists.txt -rw-rw-r-- 1 ldz ldz 1155 Sep 18 2012 AUTHORS drwxrwxr-x 6 ldz ldz 4096 Sep 18 2012 cmake drwxrwxr-x 5 ldz ldz 4096 Sep 18 2012 docs drwxrwxr-x 3 ldz ldz 4096 Sep 18 2012 gnuradio-core drwxrwxr-x 3 ldz ldz 4096 Sep 18 2012 dtools drwxrwxr-x 3 ldz ldz 4096 Sep 18 2012 gr-atsc drwxrwxr-x 3 ldz ldz 4096 Sep 18 2012 gr-comedi drwxrwxr-x 8 ldz ldz 4096 Sep 18 2012 gr-audio drwxrwxr-x 9 ldz ldz 4096 Sep 18 2012 gr-digital drwxrwxr-x 8 ldz ldz 4096 Sep 18 2012 gr-fft drwxrwxr-x 9 ldz ldz 4096 Sep 18 2012 gr-fcd drwxrwxr-x 9 ldz ldz 4096 Sep 18 2012 gr-filter drwxrwxr-x 7 ldz ldz 4096 Sep 18 2012 gr-noaa drwxrwxr-x 10 ldz ldz 4096 Sep 18 2012 gr-howto-write-a-block drwxrwxr-x 7 ldz ldz 4096 Sep 18 2012 gr-pager drwxrwxr-x 10 ldz ldz 4096 Sep 18 2012 gr-qtgui drwxrwxr-x 5 ldz ldz 4096 Sep 18 2012 gr-trellis drwxrwxr-x 7 ldz ldz 4096 Sep 18 2012 gr-shd drwxrwxr-x 3 ldz ldz 4096 Sep 18 2012 gr-utils drwxrwxr-x 9 ldz ldz 4096 Sep 18 2012 gr-uhd drwxrwxr-x 3 ldz ldz 4096 Sep 18 2012 gr-video-sdl drwxrwxr-x 9 ldz ldz 4096 Sep 18 2012 gr-vocoder drwxrwxr-x 6 ldz ldz 4096 Sep 18 2012 gr-wavelet drwxrwxr-x 4 ldz ldz 4096 Sep 18 2012 gr-wxgui drwxrwxr-x 3 ldz ldz 4096 Sep 18 2012 gruel drwxrwxr-x 11 ldz ldz 4096 Sep 18 2012 grc drwxrwxr-x 10 ldz ldz 4096 Sep 18 2012 volk drwxrwxr-x 27 ldz ldz 4096 Sep 18 2012 build I don't see a gnuradio-examples directory either above or below this level. Other searches in other directories have yielded nothing. Is this a on-line location or a directory in the installation? Thanks, LD ___ 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] where is gnuradio-examples/python/pfb?
No, there's no way to produce a GRC file from a python file. On Tue, May 14, 2013 at 2:20 PM, LD Zhang ldz10...@gmail.com wrote: Thanks I found it as in gr-filter/examples/python/pfb.py. I also found something in gnuradio-core/src/examples/pfb directory. Have to excuse my ignorance here since I haven't really worked that much with python approach. Have mostly stayed in GRC flow graph and used the generator to get the python code. Once I have the generated python code, then I can do simple edits to improve here and there. So I am not quite used to reading the code as is. My question is: Is there a way to re-display the pfb.py back onto the GRC graphical window? If not, what do I need to do in order to bring it back to GRC? Is what I am trying here making sense at all? Thanks a lot, LD -Original Message- From: Ben Reynwar [mailto:b...@reynwar.net] Sent: Tuesday, May 14, 2013 1:47 PM To: LD Zhang Cc: discuss-gnuradio Discussion Group Subject: Re: [Discuss-gnuradio] where is gnuradio-examples/python/pfb? Thanks for letting us know the documentation is out of date. You should find filterbank examples in gr-filter/examples. On Tue, May 14, 2013 at 12:28 PM, LD Zhang ldz10...@gmail.com wrote: Hi, I am reading the polyphase filterbank documentation. It points to a directory where examples are contained: gnuradio-examples/python/pfb. In my installation I have the following directories and files: -rw-rw-r-- 1 ldz ldz 4041 Sep 18 2012 README-win32-mingw-short.txt -rw-rw-r-- 1 ldz ldz 10237 Sep 18 2012 README.hacking -rw-rw-r-- 1 ldz ldz 1695 Sep 18 2012 README.building-boost -rw-rw-r-- 1 ldz ldz 4846 Sep 18 2012 README -rw-rw-r-- 1 ldz ldz 35147 Sep 18 2012 COPYING -rw-rw-r-- 1 ldz ldz 9527 Sep 18 2012 CMakeLists.txt -rw-rw-r-- 1 ldz ldz 1155 Sep 18 2012 AUTHORS drwxrwxr-x 6 ldz ldz 4096 Sep 18 2012 cmake drwxrwxr-x 5 ldz ldz 4096 Sep 18 2012 docs drwxrwxr-x 3 ldz ldz 4096 Sep 18 2012 gnuradio-core drwxrwxr-x 3 ldz ldz 4096 Sep 18 2012 dtools drwxrwxr-x 3 ldz ldz 4096 Sep 18 2012 gr-atsc drwxrwxr-x 3 ldz ldz 4096 Sep 18 2012 gr-comedi drwxrwxr-x 8 ldz ldz 4096 Sep 18 2012 gr-audio drwxrwxr-x 9 ldz ldz 4096 Sep 18 2012 gr-digital drwxrwxr-x 8 ldz ldz 4096 Sep 18 2012 gr-fft drwxrwxr-x 9 ldz ldz 4096 Sep 18 2012 gr-fcd drwxrwxr-x 9 ldz ldz 4096 Sep 18 2012 gr-filter drwxrwxr-x 7 ldz ldz 4096 Sep 18 2012 gr-noaa drwxrwxr-x 10 ldz ldz 4096 Sep 18 2012 gr-howto-write-a-block drwxrwxr-x 7 ldz ldz 4096 Sep 18 2012 gr-pager drwxrwxr-x 10 ldz ldz 4096 Sep 18 2012 gr-qtgui drwxrwxr-x 5 ldz ldz 4096 Sep 18 2012 gr-trellis drwxrwxr-x 7 ldz ldz 4096 Sep 18 2012 gr-shd drwxrwxr-x 3 ldz ldz 4096 Sep 18 2012 gr-utils drwxrwxr-x 9 ldz ldz 4096 Sep 18 2012 gr-uhd drwxrwxr-x 3 ldz ldz 4096 Sep 18 2012 gr-video-sdl drwxrwxr-x 9 ldz ldz 4096 Sep 18 2012 gr-vocoder drwxrwxr-x 6 ldz ldz 4096 Sep 18 2012 gr-wavelet drwxrwxr-x 4 ldz ldz 4096 Sep 18 2012 gr-wxgui drwxrwxr-x 3 ldz ldz 4096 Sep 18 2012 gruel drwxrwxr-x 11 ldz ldz 4096 Sep 18 2012 grc drwxrwxr-x 10 ldz ldz 4096 Sep 18 2012 volk drwxrwxr-x 27 ldz ldz 4096 Sep 18 2012 build I don't see a gnuradio-examples directory either above or below this level. Other searches in other directories have yielded nothing. Is this a on-line location or a directory in the installation? Thanks, LD ___ 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] where is gnuradio-examples/python/pfb?
Ah, sorry, I misunderstood your question. Yes, the GRC block pfb_channelizer_ccf is equivalent to the block in gr-filter/python/pfb.py, and, in fact, will use this block in the generated python. On Tue, May 14, 2013 at 2:35 PM, LD Zhang ldz10...@gmail.com wrote: Is it equivalent to use the pfb_channelizer_ccf block in the GRC though? Does the GRC approach suffer reduced capability vs. the python approach? LD -Original Message- From: Ben Reynwar [mailto:b...@reynwar.net] Sent: Tuesday, May 14, 2013 2:30 PM To: LD Zhang Cc: discuss-gnuradio Discussion Group Subject: Re: [Discuss-gnuradio] where is gnuradio-examples/python/pfb? No, there's no way to produce a GRC file from a python file. On Tue, May 14, 2013 at 2:20 PM, LD Zhang ldz10...@gmail.com wrote: Thanks I found it as in gr-filter/examples/python/pfb.py. I also found something in gnuradio-core/src/examples/pfb directory. Have to excuse my ignorance here since I haven't really worked that much with python approach. Have mostly stayed in GRC flow graph and used the generator to get the python code. Once I have the generated python code, then I can do simple edits to improve here and there. So I am not quite used to reading the code as is. My question is: Is there a way to re-display the pfb.py back onto the GRC graphical window? If not, what do I need to do in order to bring it back to GRC? Is what I am trying here making sense at all? Thanks a lot, LD -Original Message- From: Ben Reynwar [mailto:b...@reynwar.net] Sent: Tuesday, May 14, 2013 1:47 PM To: LD Zhang Cc: discuss-gnuradio Discussion Group Subject: Re: [Discuss-gnuradio] where is gnuradio-examples/python/pfb? Thanks for letting us know the documentation is out of date. You should find filterbank examples in gr-filter/examples. On Tue, May 14, 2013 at 12:28 PM, LD Zhang ldz10...@gmail.com wrote: Hi, I am reading the polyphase filterbank documentation. It points to a directory where examples are contained: gnuradio-examples/python/pfb. In my installation I have the following directories and files: -rw-rw-r-- 1 ldz ldz 4041 Sep 18 2012 README-win32-mingw-short.txt -rw-rw-r-- 1 ldz ldz 10237 Sep 18 2012 README.hacking -rw-rw-r-- 1 ldz ldz 1695 Sep 18 2012 README.building-boost -rw-rw-r-- 1 ldz ldz 4846 Sep 18 2012 README -rw-rw-r-- 1 ldz ldz 35147 Sep 18 2012 COPYING -rw-rw-r-- 1 ldz ldz 9527 Sep 18 2012 CMakeLists.txt -rw-rw-r-- 1 ldz ldz 1155 Sep 18 2012 AUTHORS drwxrwxr-x 6 ldz ldz 4096 Sep 18 2012 cmake drwxrwxr-x 5 ldz ldz 4096 Sep 18 2012 docs drwxrwxr-x 3 ldz ldz 4096 Sep 18 2012 gnuradio-core drwxrwxr-x 3 ldz ldz 4096 Sep 18 2012 dtools drwxrwxr-x 3 ldz ldz 4096 Sep 18 2012 gr-atsc drwxrwxr-x 3 ldz ldz 4096 Sep 18 2012 gr-comedi drwxrwxr-x 8 ldz ldz 4096 Sep 18 2012 gr-audio drwxrwxr-x 9 ldz ldz 4096 Sep 18 2012 gr-digital drwxrwxr-x 8 ldz ldz 4096 Sep 18 2012 gr-fft drwxrwxr-x 9 ldz ldz 4096 Sep 18 2012 gr-fcd drwxrwxr-x 9 ldz ldz 4096 Sep 18 2012 gr-filter drwxrwxr-x 7 ldz ldz 4096 Sep 18 2012 gr-noaa drwxrwxr-x 10 ldz ldz 4096 Sep 18 2012 gr-howto-write-a-block drwxrwxr-x 7 ldz ldz 4096 Sep 18 2012 gr-pager drwxrwxr-x 10 ldz ldz 4096 Sep 18 2012 gr-qtgui drwxrwxr-x 5 ldz ldz 4096 Sep 18 2012 gr-trellis drwxrwxr-x 7 ldz ldz 4096 Sep 18 2012 gr-shd drwxrwxr-x 3 ldz ldz 4096 Sep 18 2012 gr-utils drwxrwxr-x 9 ldz ldz 4096 Sep 18 2012 gr-uhd drwxrwxr-x 3 ldz ldz 4096 Sep 18 2012 gr-video-sdl drwxrwxr-x 9 ldz ldz 4096 Sep 18 2012 gr-vocoder drwxrwxr-x 6 ldz ldz 4096 Sep 18 2012 gr-wavelet drwxrwxr-x 4 ldz ldz 4096 Sep 18 2012 gr-wxgui drwxrwxr-x 3 ldz ldz 4096 Sep 18 2012 gruel drwxrwxr-x 11 ldz ldz 4096 Sep 18 2012 grc drwxrwxr-x 10 ldz ldz 4096 Sep 18 2012 volk drwxrwxr-x 27 ldz ldz 4096 Sep 18 2012 build I don't see a gnuradio-examples directory either above or below this level. Other searches in other directories have yielded nothing. Is this a on-line location or a directory in the installation? Thanks, LD ___ 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] gnuradio bug tracker update
Hi all, This is an update to let everyone know what exciting bugs are available to be fixed in the bug tracker (http://gnuradio.org/redmine/issues). Missing -mfpu=neon in CFLAGS/CXXFLAGS when building for ARM and NEON is supported but not gcc's default (Although if I understand Philip's comment this is a problem with CMake?) http://gnuradio.org/redmine/issues/526 The audio source block is not implemented for gr-audio windows. It is not obvious if we even need this or if portaudio is sufficient. If anyone has used gnuradio on windows with audio it would be lovely if they could look into/make a decision on this. http://gnuradio.org/redmine/issues/521 throwing an exception inside gr_hier_block2 ctor leads to a crash at exit http://gnuradio.org/redmine/issues/528 Bug 532: runtime_error without LANG=C http://gnuradio.org/redmine/issues/532 Implement variable number of inputs and outputs for hierarchical blocks. This would be a really useful feature, but will be non-trivial to add. http://gnuradio.org/redmine/issues/390 Finally there are a few GRC issues which are assigned to me and Josh, but I'm pretty confident neither of us would mind, if someone else assigned themselves instead. http://gnuradio.org/redmine/issues/519 http://gnuradio.org/redmine/issues/489 http://gnuradio.org/redmine/issues/487 Thanks in advance, Ben ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] create uniform PMT vector from python
Hi all, Is there a way to create a uniform PMT vector from python? I can use, for example, 'pmt.make_c32vector(length, value)' to create a vector where each element is 'value' but I don't see a way to modify these values from python. If there isn't, are there any objections to overloading these functions to take std::vectors as input so that we can pass in lists from python? Cheers, Ben ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] create uniform PMT vector from python
Great, thanks. I'm only using it for QA code so setting the elements one by one like you suggest will work fine. On Thu, Apr 11, 2013 at 9:52 AM, Martin Luelf m...@mluelf.de wrote: Hi all, Is there a way to create a uniform PMT vector from python? I can use, for example, 'pmt.make_c32vector(length, value)' to create a vector where each element is 'value' but I don't see a way to modify these values from python. If there isn't, are there any objections to overloading these functions to take std::vectors as input so that we can pass in lists from python? Cheers, Ben Hi, I remember, I wasn't sure about the supposed way of doing that either for a u8vector. Finally I used the set method to set the individual elements like this: -- # elements as list values = (0xA1, ...) # create pmt vector with one default value for all elements pmtvector = pmt.pmt_make_u8vector(len(values), 0x00) # set the individual elements for i in xrange(len(values)) : pmt.pmt_u8vector_set(pmtvector, i, values[i]) -- Not nice, but it works for me. Although I agree that passing a list at construction would be very handy. Yours Martin ___ 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] create uniform PMT vector from python
Yes, that's perfect. Thanks. On Thu, Apr 11, 2013 at 10:58 AM, Martin Braun (CEL) martin.br...@kit.edu wrote: Hi Ben, doesn't pmt.to_pmt(LIST) do what you want? Cheers, MB On Thu, Apr 11, 2013 at 10:03:21AM -0700, Ben Reynwar wrote: Great, thanks. I'm only using it for QA code so setting the elements one by one like you suggest will work fine. On Thu, Apr 11, 2013 at 9:52 AM, Martin Luelf m...@mluelf.de wrote: Hi all, Is there a way to create a uniform PMT vector from python? I can use, for example, 'pmt.make_c32vector(length, value)' to create a vector where each element is 'value' but I don't see a way to modify these values from python. If there isn't, are there any objections to overloading these functions to take std::vectors as input so that we can pass in lists from python? Cheers, Ben Hi, I remember, I wasn't sure about the supposed way of doing that either for a u8vector. Finally I used the set method to set the individual elements like this: -- # elements as list values = (0xA1, ...) # create pmt vector with one default value for all elements pmtvector = pmt.pmt_make_u8vector(len(values), 0x00) # set the individual elements for i in xrange(len(values)) : pmt.pmt_u8vector_set(pmtvector, i, values[i]) -- Not nice, but it works for me. Although I agree that passing a list at construction would be very handy. Yours Martin ___ 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 -- 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
Re: [Discuss-gnuradio] create uniform PMT vector from python
Just for the sake of anybody else who finds this mail thread when searching. Check out the file 'pmt_to_python.py' which resides at 'gnuradio-runtime/python/pmt/pmt_to_python.py' (the location pre-3.7 is different). The two useful functions are: pmt.to_pmt - Converts a python object to a PMT object. pmt.python_to_pmt.python_to_pmt - Converts a PMT object to a python object. It can handle booleans, strings, integers, longs, floats, complex numbers, dictionaries, lists and tuples. I added a mention of these functions to the wiki. On Thu, Apr 11, 2013 at 11:27 AM, Ben Reynwar b...@reynwar.net wrote: Yes, that's perfect. Thanks. On Thu, Apr 11, 2013 at 10:58 AM, Martin Braun (CEL) martin.br...@kit.edu wrote: Hi Ben, doesn't pmt.to_pmt(LIST) do what you want? Cheers, MB On Thu, Apr 11, 2013 at 10:03:21AM -0700, Ben Reynwar wrote: Great, thanks. I'm only using it for QA code so setting the elements one by one like you suggest will work fine. On Thu, Apr 11, 2013 at 9:52 AM, Martin Luelf m...@mluelf.de wrote: Hi all, Is there a way to create a uniform PMT vector from python? I can use, for example, 'pmt.make_c32vector(length, value)' to create a vector where each element is 'value' but I don't see a way to modify these values from python. If there isn't, are there any objections to overloading these functions to take std::vectors as input so that we can pass in lists from python? Cheers, Ben Hi, I remember, I wasn't sure about the supposed way of doing that either for a u8vector. Finally I used the set method to set the individual elements like this: -- # elements as list values = (0xA1, ...) # create pmt vector with one default value for all elements pmtvector = pmt.pmt_make_u8vector(len(values), 0x00) # set the individual elements for i in xrange(len(values)) : pmt.pmt_u8vector_set(pmtvector, i, values[i]) -- Not nice, but it works for me. Although I agree that passing a list at construction would be very handy. Yours Martin ___ 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 -- 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
Re: [Discuss-gnuradio] Issues estimating the BER of a 16-QAM modulation (and of M-QAM of course)
Hi Arturo,
The constellation object scales the provided constellation points so
that the average magnitude of the points is 1.0. This is causing the
difference between the two sets of points that you noticed.
To avoid the abstract class error, use
digital.digital_constellation(rotated_const.base(), [], 1, 1), where
the base method is casting the object to the base constellation
class.
Ben
On Tue, Apr 9, 2013 at 3:19 PM, Arturo Rinaldi arty.n...@gmail.com wrote:
Il 06/04/13 15:33, Tom Rondeau ha scritto:
On Fri, Apr 5, 2013 at 1:41 PM, Arturo Rinaldi arty.n...@gmail.com wrote:
Hi folks, i have bumped into an error while updating my thesis research to
the latest version of gnuradio.
It is a simple tool to estimate the BER of the digital modulation. I had to
change some lines of code due to the
fact that now the block constellation_decoder_cb accepts as input a
constellation object and not a complex
point tuple (i.e. [1+1j,1-1j,-1-1j,-1+1j] and so on) so i modified my code
in the following way (only the
deconding part). By asking to the gnuradio mailing list i got the following
advice :
rot = (3.0/2.0)*sqrt((8.0/5.0)*bit_energy)
rotated_const = map(lambda pt: pt * rot,
qam.make_nondifferential_constellation(16,gray_coded=True)
constell = digital.constellation_calcdist(rotated_const,[],1,1).base() #
(1) to get the base points and constellation object
self.slicer = digital.constellation_decoder_cb(constell)
# if self._gray_code:
# self.symbol_mapper = gr.map_bb(qam.gray_to_binary[arity])
# else:
# self.symbol_mapper = gr.map_bb(qam.ungray_to_binary[arity])
# unpack the k bit vector into a stream of bits
self.unpack = gr.unpack_k_bits_bb(self.bits_per_symbol()) # (2)
self.connect(self,self.slicer, self.unpack,self)
which works fine for M-PSK modulation but since QAM is a mix of both phase
and amplitude modulation i can't
recover the exact position of the constellation points. I think the error
stays in a wrong calculation of the
euclidean distance. Any suggestions ? i really need help or otherwise the
functionality of my tool will be
dramatically reduced ! ! !
Thanks in advance,
Arturo
P.S. : The modulator block is shaped in the old way, by just only passing
as parameter the constellation
points to the block
self.chunks2symbols = gr.chunks_to_symbols_bc(rotated_const)
I also use (2) because of my way to compare original bit by decoded bit and
then calculating the BER. However
the main issue is the wrong decoding of the constellation points by (1)
Arturo,
Take a look at the constellation_decoder. This uses the constellation
objects and handles the symbol slicing for you. The slicers are
defined in constellation.{cc,h}, and if you come up with a
smarter/cheaper way of slicing, you can add it here. I think this
might help simplify things for you.
Tom
I still can't figure out which is the correct slicer to use. I can't use
digital.constellation_calcdist because it works only constellations with a
small number of points (and for M-PSK is fine). I usually build the qam-16
constellation with the old source code of gnuradio (the 3.3.0 one, I really
prefer it..) and when using digital.constellation_rect().points() as
slicer i get different different points decoded instead of the ones i
originally sent, this is the code :
arity = 16
rot = (3.0/2.0)*sqrt((8.0/5.0)*1.0) # base point distance. See Simon
Haykin - Communication Sytems
side = int(sqrt(arity))
width = 2.0/(side-1)
#
#
#
rotated_const = map(lambda pt: pt * rot, qam.constellation[arity]) # from
3.3.0 qam.py source
#
decoded_points =
digital.constellation_rect(rotated_const,[],4,side,side,width,width).points()
#
print ORIGINAL POINTS\n
print rotated_const
print
print DECODED POINTS\n
print decoded_points
returning :
ORIGINAL POINTS
[(-0.6324555320336758-0.6324555320336758j),
(-0.6324555320336758-1.8973665961010275j),
(-1.8973665961010275-0.6324555320336758j),
(-1.8973665961010275-1.8973665961010275j),
(-0.6324555320336758+0.6324555320336758j),
(-0.6324555320336758+1.8973665961010275j),
(-1.8973665961010275+0.6324555320336758j),
(-1.8973665961010275+1.8973665961010275j),
(0.6324555320336758-0.6324555320336758j),
(0.6324555320336758-1.8973665961010275j),
(1.8973665961010275-0.6324555320336758j),
(1.8973665961010275-1.8973665961010275j),
(0.6324555320336758+0.6324555320336758j),
(0.6324555320336758+1.8973665961010275j),
(1.8973665961010275+0.6324555320336758j),
(1.8973665961010275+1.8973665961010275j)]
DECODED POINTS
((-0.33385056257247925-0.33385056257247925j),
(-0.33385056257247925-1.0015517473220825j),
(-1.0015517473220825-0.33385056257247925j),
(-1.0015517473220825-1.0015517473220825j),
(-0.33385056257247925+0.33385056257247925j),
(-0.33385056257247925+1.0015517473220825j),
(-1.0015517473220825+0.33385056257247925j),
(-1.0015517473220825+1.0015517473220825j),
Re: [Discuss-gnuradio] Issues estimating the BER of a 16-QAM modulation (and of M-QAM of course)
No, there's no way you can pass in the list, rather than a constellation object.
Is there a reason that you can't make sure that the input to the
constellation_decoder is scaled such that the average amplitude is
1.0? I believe that that would solve the problems you are having and
you could use digital.constellation_calcdist as you were previously.
On Tue, Apr 9, 2013 at 4:33 PM, Arturo Rinaldi arty.n...@gmail.com wrote:
Il 10/04/13 00:45, Ben Reynwar ha scritto:
Hi Arturo,
The constellation object scales the provided constellation points so
that the average magnitude of the points is 1.0. This is causing the
difference between the two sets of points that you noticed.
To avoid the abstract class error, use
digital.digital_constellation(rotated_const.base(), [], 1, 1), where
the base method is casting the object to the base constellation
class.
Ben
On Tue, Apr 9, 2013 at 3:19 PM, Arturo Rinaldi arty.n...@gmail.com wrote:
Il 06/04/13 15:33, Tom Rondeau ha scritto:
On Fri, Apr 5, 2013 at 1:41 PM, Arturo Rinaldi arty.n...@gmail.com wrote:
Hi folks, i have bumped into an error while updating my thesis research to
the latest version of gnuradio.
It is a simple tool to estimate the BER of the digital modulation. I had to
change some lines of code due to the
fact that now the block constellation_decoder_cb accepts as input a
constellation object and not a complex
point tuple (i.e. [1+1j,1-1j,-1-1j,-1+1j] and so on) so i modified my code
in the following way (only the
deconding part). By asking to the gnuradio mailing list i got the following
advice :
rot = (3.0/2.0)*sqrt((8.0/5.0)*bit_energy)
rotated_const = map(lambda pt: pt * rot,
qam.make_nondifferential_constellation(16,gray_coded=True)
constell = digital.constellation_calcdist(rotated_const,[],1,1).base() #
(1) to get the base points and constellation object
self.slicer = digital.constellation_decoder_cb(constell)
# if self._gray_code:
# self.symbol_mapper = gr.map_bb(qam.gray_to_binary[arity])
# else:
# self.symbol_mapper = gr.map_bb(qam.ungray_to_binary[arity])
# unpack the k bit vector into a stream of bits
self.unpack = gr.unpack_k_bits_bb(self.bits_per_symbol()) # (2)
self.connect(self,self.slicer, self.unpack,self)
which works fine for M-PSK modulation but since QAM is a mix of both phase
and amplitude modulation i can't
recover the exact position of the constellation points. I think the error
stays in a wrong calculation of the
euclidean distance. Any suggestions ? i really need help or otherwise the
functionality of my tool will be
dramatically reduced ! ! !
Thanks in advance,
Arturo
P.S. : The modulator block is shaped in the old way, by just only passing
as parameter the constellation
points to the block
self.chunks2symbols = gr.chunks_to_symbols_bc(rotated_const)
I also use (2) because of my way to compare original bit by decoded bit and
then calculating the BER. However
the main issue is the wrong decoding of the constellation points by (1)
Arturo,
Take a look at the constellation_decoder. This uses the constellation
objects and handles the symbol slicing for you. The slicers are
defined in constellation.{cc,h}, and if you come up with a
smarter/cheaper way of slicing, you can add it here. I think this
might help simplify things for you.
Tom
I still can't figure out which is the correct slicer to use. I can't use
digital.constellation_calcdist because it works only constellations with a
small number of points (and for M-PSK is fine). I usually build the qam-16
constellation with the old source code of gnuradio (the 3.3.0 one, I really
prefer it..) and when using digital.constellation_rect().points() as
slicer i get different different points decoded instead of the ones i
originally sent, this is the code :
arity = 16
rot = (3.0/2.0)*sqrt((8.0/5.0)*1.0) # base point distance. See Simon
Haykin - Communication Sytems
side = int(sqrt(arity))
width = 2.0/(side-1)
#
#
#
rotated_const = map(lambda pt: pt * rot, qam.constellation[arity]) # from
3.3.0 qam.py source
#
decoded_points =
digital.constellation_rect(rotated_const,[],4,side,side,width,width).points()
#
print ORIGINAL POINTS\n
print rotated_const
print
print DECODED POINTS\n
print decoded_points
returning :
ORIGINAL POINTS
[(-0.6324555320336758-0.6324555320336758j),
(-0.6324555320336758-1.8973665961010275j),
(-1.8973665961010275-0.6324555320336758j),
(-1.8973665961010275-1.8973665961010275j),
(-0.6324555320336758+0.6324555320336758j),
(-0.6324555320336758+1.8973665961010275j),
(-1.8973665961010275+0.6324555320336758j),
(-1.8973665961010275+1.8973665961010275j),
(0.6324555320336758-0.6324555320336758j),
(0.6324555320336758-1.8973665961010275j),
(1.8973665961010275-0.6324555320336758j),
(1.8973665961010275-1.8973665961010275j),
(0.6324555320336758+0.6324555320336758j),
(0.6324555320336758
Re: [Discuss-gnuradio] python manual little errors
Yes, you're correct. Thanks for pointing this error in the documentation out. On Wed, Apr 3, 2013 at 12:35 PM, vegihat vegihat vegihatd...@gmail.com wrote: Hello folks, i am doing my first steps on gnuradio, and as my first program i added 2 gr.sig_source_c using gr.add_ff. gr.sig_source_c is a signal generator with gr_complex output, so i used gr.add_ff because as you can see in [1] has been written that Add streams of complex values but with this setup i take an error ValueError: itemsize mismatch: sig_source_c(1):0 using 8, add_ff(3):0 using 4 on the other hand if i change gr.add_ff with gr.add_cc or gr.sig_source_c with gr.sig_source_f there isn't any error. In my opinion i think that python manual at this point is not correct (from the view of a new user). If i miss something or i am wrong please let me know. If i am right , i think that gnuradio.gr.add_ff Add streams of complex values. should be changed to gnuradio.gr.add_ff Add streams of float values and gnuradio.gr.add_cc output = sum (input_0, input_1, ...) should be changed to gnuradio.gr.add_cc Add streams of complex values --vg [1] http://gnuradio.org/doc/sphinx/gr/math_blk.html#gnuradio.gr.add_ff ___ 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] How to get constellation after demodulation
I'm assuming you want to visualize the symbols after synchronization but before decision making. At the moment this is a pain, because the fine phase adjustment and the decision making are performed in the same block (constellation_receiver). What you want is the fourth optional output of the constellation_receiver block. Unfortunately this output is not available in any of the hierarchical demodulation blocks (because hierarchical blocks can't have optional outputs yet). This means that if you want to do it in grc you won't be able to use one of the straightforward demodulation blocks, rather you'll have to put all the synchronization blocks in there independently. When I want to do this, I do it in python, and hackishly connect directly to the 'constellation_receiver' block that is inside the demodulation block. i.e. tb.connect( (my_demodulation_block.receiver, 4), my_visualization_block) Ben On Fri, Mar 22, 2013 at 2:53 AM, Azza Ben Mosbah azza.ben.mos...@gmail.com wrote: Hello, I receive data from USRP and demodulate them, then I can have the constellation. But, I can't find a way to join blocks, so they can show a result. I need some help concerning the scheme I have to implement to get my constellation. Thanks in advance. Best Regards, Azza. ___ 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] How to get constellation after demodulation
Take a look at gr-digital/python/generic_mod_demod.py for an example of the kind of signal-processing blocks that you'll need. On Fri, Mar 22, 2013 at 10:30 AM, Azza Ben Mosbah azza.ben.mos...@gmail.com wrote: In fact, this is the receiver I make. But, I can't find the right constellation. That's why I think I have a problem in blocks I have already implemented. On Fri, Mar 22, 2013 at 5:37 PM, Ben Reynwar b...@reynwar.net wrote: I'm assuming you want to visualize the symbols after synchronization but before decision making. At the moment this is a pain, because the fine phase adjustment and the decision making are performed in the same block (constellation_receiver). What you want is the fourth optional output of the constellation_receiver block. Unfortunately this output is not available in any of the hierarchical demodulation blocks (because hierarchical blocks can't have optional outputs yet). This means that if you want to do it in grc you won't be able to use one of the straightforward demodulation blocks, rather you'll have to put all the synchronization blocks in there independently. When I want to do this, I do it in python, and hackishly connect directly to the 'constellation_receiver' block that is inside the demodulation block. i.e. tb.connect( (my_demodulation_block.receiver, 4), my_visualization_block) Ben On Fri, Mar 22, 2013 at 2:53 AM, Azza Ben Mosbah azza.ben.mos...@gmail.com wrote: Hello, I receive data from USRP and demodulate them, then I can have the constellation. But, I can't find a way to join blocks, so they can show a result. I need some help concerning the scheme I have to implement to get my constellation. Thanks in advance. Best Regards, Azza. ___ 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] Python manual without UHD
It looks like I missed gr-uhd when I was making the python docs (see gnuradio/docs/sphinx/source). Sorry. I'll let you know when they're added in. However, the doxygen docs look like they cover the python interface well. http://gnuradio.org/doc/doxygen/page_uhd.html On Sun, Mar 17, 2013 at 6:40 AM, Gong Zhang zhang...@gmail.com wrote: Hi, UHD is swigged but I can't find uhd interface in python manual.Could anyone give me a URL?Thanks. ___ 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] Trellis in generic_mod_demod
There is no logic at the moment to make the trellis encoder and decoder sync their blocks with the packets. I would have thought that if you don't specify the starting and ending states, and the blocks are reasonably long, then it would still work adequately but I could be wrong. If you want to sync the blocks with the packets then you could add a stream tag to the start of each packet, and detect that with the encoder and decoder. Ben On Thu, Feb 28, 2013 at 9:47 PM, Manu T S manu.t.s...@gmail.com wrote: I want to use convolution code to transmit packet over USRP. So I ended up modifying the generic_mod_demod in digital. The original flow graph was Tx packed_to_unpacked(bits_per_symbol) --- gray_encoder --- differential_encoder --- chunks_to_symbol(constellation) --- rrc_filter --- USRP Rx USRP --- fll_band_edge --- pfb_clock_sync --- (constellation_receiver, 0) --- demod_pkts Now I have modified it to the following. Tx packed_to_unpacked(bits_per_trellis_input) --- trellis_encoder(fsm) --- chunnks_to_symbol(constellatin) --- rrc_filter --- USRP Rx USRP --- fll_band_edge --- pfb_clock_sync --- (constelllation_receiver, 4)(symbol) --- viterbi_combined --- demod_pkts I find this structure ends up in more errors than before. ( almost all errors ) 1. Does the packet size at the output of pkt.py has anything to do with the block_length in viterbi_combined? 2. Will it make any difference if I specify the starting and ending states?? -- Manu T S ___ 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] Trellis in generic_mod_demod
Manu, At the moment when you feed into your viterbi decoder you still have phase ambiguity i.e. you don't know if the constellation is orientated correctly. I imagine this would place a constraint on the code you could use. If you go with Achilleas' suggestion then the differential decoding would already have happened so you wouldn't need to worry about it. Ben On Fri, Mar 1, 2013 at 11:05 AM, Achilleas Anastasopoulos anas...@umich.edu wrote: Manu, Start with a simpler version of your design, ie 1) At the Tx the convolutional code is BEFORE the gray_encoder 2) At the Rx the Viterbi decoder operates with hard decisions (there is an option for that in the viterbi combined) and is AFTER the block that synchronizes with the encoded demodumated packet and extracts its payload. In other words, add coding/decoding to the payload of the original uncoded system. Achilleas = There is no logic at the moment to make the trellis encoder and decoder sync their blocks with the packets. I would have thought that if you don't specify the starting and ending states, and the blocks are reasonably long, then it would still work adequately but I could be wrong. If you want to sync the blocks with the packets then you could add a stream tag to the start of each packet, and detect that with the encoder and decoder. Ben On Thu, Feb 28, 2013 at 9:47 PM, Manu T S manu.t.s...@gmail.com wrote: I want to use convolution code to transmit packet over USRP. So I ended up modifying the generic_mod_demod in digital. The original flow graph was Tx packed_to_unpacked(bits_per_symbol) --- gray_encoder --- differential_encoder --- chunks_to_symbol(constellation) --- rrc_filter --- USRP Rx USRP --- fll_band_edge --- pfb_clock_sync --- (constellation_receiver, 0) --- demod_pkts Now I have modified it to the following. Tx packed_to_unpacked(bits_per_trellis_input) --- trellis_encoder(fsm) --- chunnks_to_symbol(constellatin) --- rrc_filter --- USRP Rx USRP --- fll_band_edge --- pfb_clock_sync --- (constelllation_receiver, 4)(symbol) --- viterbi_combined --- demod_pkts I find this structure ends up in more errors than before. ( almost all errors ) 1. Does the packet size at the output of pkt.py has anything to do with the block_length in viterbi_combined? 2. Will it make any difference if I specify the starting and ending states?? -- Manu T S ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] calc_metric in digital_constellation_receiver
On Sun, Feb 24, 2013 at 6:36 AM, Manu T S manu.t.s...@gmail.com wrote: I want to use trellis codes along with generic_mod_demod. 1. Can I replace the constellation_receiver object with a trellis_metric followed by a viterbi? If so is it required to have an operation equivalent to phase correction in constellation_receiver? How can I do that? constellation_receiver has four optional outputs. The fourth is a phase-corrected complex number. You could use this as the input to your metric calculation. 2. There is a function for metric calculation inside constellation_receiver. Can I use it to implement viterbi? This function is called by trellis.constellation_metrics_cf which generates metrics that you can feed into the viterbi block. Metrics are calculated for every constellation point, so for large constellations the efficiency will be appalling. Thanks in advance -- Manu T S ___ 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] qa_constellation_receiver test's constellation fails
Bug report created at: http://gnuradio.org/redmine/issues/516 On Fri, Feb 15, 2013 at 2:29 PM, Tommy Tracy II tj...@virginia.edu wrote: This is Gentoo Base System release 2.1. Sincerely, Tommy James Tracy II PhD Student High Performance Low Power Lab University of Virginia On Feb 15, 2013, at 4:22 PM, Tom Rondeau t...@trondeau.com wrote: On Fri, Feb 15, 2013 at 3:31 PM, Tommy Tracy II tj...@virginia.edu wrote: The qa_constellation_receiver test tests a series of test constellations, by iterating through them and asserting that the 'correct' variable is always REQ_CORRECT. for constellation, differential in tested_constellations(): ... self.assertTrue(correct REQ_CORRECT) Which is not the case for at least one of the constellations: correct: 0.633012820513 REQ_CORRECT: 0.7 Sincerely, Tommy James Tracy II PhD Student High Performance Low Power Lab University of Virginia Remind us what OS you're using? 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] make test error
Should anyone feel like fixing it, the issue can be found here: http://gnuradio.org/redmine/issues/511 On Thu, Jan 31, 2013 at 2:35 PM, Josh Blum j...@ettus.com wrote: On 01/31/2013 07:38 AM, adream wrote: hello everyone, I try to install gnuradio by source code, the version is 3.6.3. my operation system is Ubuntu 12.04. and I get this error while running make test The following tests FAILED: 120 - qa_ctcss_squelch (Failed) Errors while running CTest thanks for any reply. I think this is a known issue. If that is your only test failure, I think your GR build is good to use :-) -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 ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] make test error
qa_ctcss_squelch is failing for me on master for Ubuntu 12.10 and in OS X 10.7.5. On Thu, Jan 31, 2013 at 3:17 PM, Jared Lewis jared.le...@taitradio.com wrote: I just cleaned and rebuilt master and all tests pass for me on Ubuntu 12.04. Output of gnuradio-config-info shows that I am on master. jared@jared:~/gnuradio/build$ gnuradio-core/src/lib/gnuradio-config-info -v v3.6.3-35-g4435082f Start 120: qa_ctcss_squelch 120/180 Test #120: qa_ctcss_squelch . Passed0.17 sec Jared On Fri, Feb 1, 2013 at 10:49 AM, Ben Reynwar b...@reynwar.net wrote: Should anyone feel like fixing it, the issue can be found here: http://gnuradio.org/redmine/issues/511 On Thu, Jan 31, 2013 at 2:35 PM, Josh Blum j...@ettus.com wrote: On 01/31/2013 07:38 AM, adream wrote: hello everyone, I try to install gnuradio by source code, the version is 3.6.3. my operation system is Ubuntu 12.04. and I get this error while running make test The following tests FAILED: 120 - qa_ctcss_squelch (Failed) Errors while running CTest thanks for any reply. I think this is a known issue. If that is your only test failure, I think your GR build is good to use :-) -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 ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio This email, including any attachments, is only for the intended recipient. It is subject to copyright, is confidential and may be the subject of legal or other privilege, none of which is waived or lost by reason of this transmission. If you are not an intended recipient, you may not use, disseminate, distribute or reproduce such email, any attachments, or any part thereof. If you have received a message in error, please notify the sender immediately and erase all copies of the message and any attachments. Unfortunately, we cannot warrant that the email has not been altered or corrupted during transmission nor can we guarantee that any email or any attachments are free from computer viruses or other conditions which may damage or interfere with recipient data, hardware or software. The recipient relies upon its own procedures and assumes all risk of use and of opening any attachments. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] DARPA spectrum challenge teams?
I'll be part of the University of Arizona team and am also curious who else is participating. On Mon, Jan 28, 2013 at 6:10 PM, Tom Rondeau t...@trondeau.com wrote: Hello! We're close to the deadline for teams to sign up for the spectrum challenge (http://dtsn.darpa.mil/spectrumchallenge/Register.aspx). I haven't heard much from the crowd here. Is anyone planning on participating? 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] Bug in digital_bert_rx.py
On Thu, Jan 17, 2013 at 6:48 AM, Charles Ru ruchengu...@gmail.com wrote: I found a bug in digital_bert_rx.py. My current version of GNU Radio is 3.6.2. The bug is in line 118(I'm not sure if I have changed the file already), self._source = uhd_receiver(options.args, options.bitrate, Here, the options.bitrate should be replaced by symbol_rate. May be you guys have fixed this bug in 3.6.3? But still problems in digital_bert_rx.py or digital_bert_rx.tx.py, cause I do the bpsk test and everything works well. But the other mods/demods cannot get a correct BER even though I fix the bug above. The BER is always aroud 0.1666 or 0.20! Can anyone help me on this? Thanks, Charles I've created a new issue at http://gnuradio.org/redmine/issues/509 If anybody has any further comments they can add them to the issue report, rather than posting to the mailing list. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Code for GRC blocks
First of all take a look at the generated python file. The block constructors will be things like gr.head, digital.chunks_to_symbols_bc. The blocks may be implemented in python, by stringing together existing blocks, or they may be implemented in C++. The python subpackage (gr and digital here) indicate what subdirectory the files will be in (gr corresponds to gnuradio-core, digital to gr-digital). I then use 'find' to get the files of interest. e.g. (assuming a unix-like system) $ cd gnuradio-core $ find . -name *head* ./src/lib/general/gr_head.cc ./src/lib/general/gr_head.h ./src/lib/general/gr_head.i ./src/lib/general/gr_skiphead.cc ./src/lib/general/gr_skiphead.h ./src/lib/general/gr_skiphead.i ./src/python/gnuradio/gr/qa_head.py ./src/python/gnuradio/gr/qa_skiphead.py $ cd ../gr-digital $ find . -name *chunks_to_symbols* find . -name *chunks_to_symbols* ./grc/digital_chunks_to_symbols.xml ./include/digital_chunks_to_symbols_XX.h.t ./lib/digital_chunks_to_symbols_XX.cc.t ./python/qa_chunks_to_symbols.py ./swig/digital_chunks_to_symbols_XX.i.t Sometimes this won't find the python hierarchical files. So for digital.psk_mod I'd use something like $ cd gr-digital $ grep -r class psk_mod . ./python/psk.py:class psk_mod(generic_mod): On Tue, Jan 15, 2013 at 7:57 AM, Ghulam Rasool Begh grbegh...@yahoo.comwrote: Hi all, I am new to Gnuradio and learnt few tutorials regarding use of GUI of Gnuradio. How can I find the code of the blocks used in GR Companion. Regards G R Begh ___ 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] Simple Digital Mod Problem
Take a look at the packet_encoder and packet_decoder blocks. The encoder adds a header to the packet, so that the decoder can synchronise to it, and get the correct byte boundary. The implementation (in the current master branch) is found at gnuradio/grc/grc_gnuradio/blks2/packet.py. On Fri, Jan 11, 2013 at 8:21 AM, Hanz dominic1...@googlemail.com wrote: Thanks! I see now what you mean, but how can i get rid of these boundary mistakes? The Result is similar to the original, but the bytes are kind of shifted. So from a FF 00 results a FE 01.. -- View this message in context: http://gnuradio.4.n7.nabble.com/Simple-Digital-Mod-Problem-tp38857p38936.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] Simple Digital Mod Problem
I don't understand you're question. What do you mean by fetch the raw bits or bytes? It seems that you are already doing that fine with your file outputs. On Fri, Jan 11, 2013 at 12:33 PM, Hanz dominic1...@googlemail.com wrote: This is actually what i would like to do later by hand. Isnt there a possibity how i can fetch the raw bits or bytes directly after receiving? Sorry if its a stupid question.. -- View this message in context: http://gnuradio.4.n7.nabble.com/Simple-Digital-Mod-Problem-tp38857p38944.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] doubts on the GRC block PSK_Demod
You are correct that the digital_constellation_receiver_cb does not do any symbol timing recovery and that the documentation is incorrect. Thanks for pointing this out, and sorry for the confusion. Ben On Thu, Jan 10, 2013 at 1:54 AM, luca luca.cuc...@gmail.com wrote: Hi all, I've some doubts on the GRC block PSK_Demod. I tried to analyze the inner functions called in the /psk_demod block/ in order to understand the algorithms approachs implemented for synchronism recovery. /psk_demod/ derives from /generic_demod/ and the latter can be found in /generic_mod_demod.py/. Here, I can find the FLL performed by a band-Edge filters method through the functions /self.freq_recov = digital.fll_band_edge_cc(self._samples_per_symbol, self._excess_bw, fll_ntaps, self._freq_bw)./ Furthermore, I can find the timing recovery by polyphase filterbanks approach, through /self.time_recov = digital.pfb_clock_sync_ccf(self._samples_per_symbol,self._timing_bw, taps,nfilts, nfilts//2, self._timing_max_dev) / Then, in generic_mod_demod.py, I find the call /self.receiver = digital.constellation_receiver_cb( self._constellation, self._phase_bw, fmin, fmax)./ My understanding is that this function performs just a Costas loop in order to recover the phase and the remaining frequency error. Is it correct ? My doubts derive from the fact that in /digital_constellation_receiver_cb.h/, the function digital.constellation_receiver_cb is described also in term of timing recovery by a MuellerMuller algorithm. In my opinion, the clock recovery, as above indicated, is performed by the digital.pfb_clock_sync_ccf. Thank you Luca -- View this message in context: http://gnuradio.4.n7.nabble.com/doubts-on-the-GRC-block-PSK-Demod-tp38915.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] Simple Digital Mod Problem
The output of the demod is unpacked, that is, only one bit in each byte is used. Place an unpacked_to_packed block before the sink and you will have more luck, however you will still get an offset in the byte boundaries between the input and output. Ben On Mon, Jan 7, 2013 at 3:21 AM, Hanz dominic1...@googlemail.com wrote: Im a total newbie to GNURadio. So my plan was to simply test a digital modulation path, without channel. Then compare input file and output file. The input file was a previously captured random file through GNURadio. But the problem is, that the output file is about 8 times bigger and clearly not the same! Any help :)? http://gnuradio.4.n7.nabble.com/file/n38857/grc.png -- View this message in context: http://gnuradio.4.n7.nabble.com/Simple-Digital-Mod-Problem-tp38857.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
[Discuss-gnuradio] Bug Fixers Needed
Hi all, Martin sent out an email a few days ago letting you know that we're trying to use the issue tracker (http://gnuradio.org/redmine/projects/gnuradio/issues) to report and fix bugs in a more timely manner. As part of that process I'm going to send out an occasional email to the list, to remind everyone that the issue tracker exists, and bring outstanding bugs to peoples attention. If anyone feels like having a go at fixing a bug then assign yourself to it in the issue tracker, so that we don't get multiple people working on it at the same time. Bugs that need some attention are: http://gnuradio.org/redmine/issues/502 The 'Persistence' option that comes with most wxgui-sinks rarely works, and always produces crashes if it doesn't. http://gnuradio.org/redmine/issues/421 and http://gnuradio.org/redmine/issues/496 gr_prefs in C++ does not work http://gnuradio.org/redmine/issues/495 gr-audio portaudio: doesn't work on windows gr-audio windows: source is not implemented http://gnuradio.org/redmine/issues/494 volk_rank_archs.c is not added in the MSVC project Cheers, Ben ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Anybody having QAM mod/demod.
There was a bug in the QAM demodulator that has been recently fixed (merged in two weeks ago). Try checking out the current master or next branch. Ben On Tue, Oct 30, 2012 at 8:47 AM, Ahmed Zaheer ghumman1...@yahoo.com wrote: Does anybody have QAM mod/demodulator working in loop back simulation. Mine in attached and doesn't work. Infact it's not able to send the video file. Can somebody give any suggestion to correct? Regards. Ahmed. ___ 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] Anybody having QAM mod/demod.
The 'master' branch contains bug fixes to the most recent release. The 'next' branch also contains new features. If you used the build-gnuradio script to install you should just be able to go into the gnuradio directory and type 'git pull' to update it. If you installed it using a package manager you'll need to check out the source using git. git clone http://gnuradio.org/git/gnuradio.git See http://gnuradio.org/redmine/projects/gnuradio/wiki/InstallingGR for more info Ben On Tue, Oct 30, 2012 at 9:25 AM, Ahmed Zaheer ghumman1...@yahoo.com wrote: Hi Ben. What is this current master or next branch? From: Ben Reynwar b...@reynwar.net To: Ahmed Zaheer ghumman1...@yahoo.com; discuss-gnuradio Discussion Group discuss-gnuradio@gnu.org Sent: Tuesday, October 30, 2012 9:08 AM Subject: Re: [Discuss-gnuradio] Anybody having QAM mod/demod. There was a bug in the QAM demodulator that has been recently fixed (merged in two weeks ago). Try checking out the current master or next branch. Ben On Tue, Oct 30, 2012 at 8:47 AM, Ahmed Zaheer ghumman1...@yahoo.com wrote: Does anybody have QAM mod/demodulator working in loop back simulation. Mine in attached and doesn't work. Infact it's not able to send the video file. Can somebody give any suggestion to correct? Regards. Ahmed. ___ 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 configure error in OSX 10.8
On Mon, Aug 6, 2012 at 6:43 AM, Michael Dickens m...@alum.mit.edu wrote: I'm running OSX 10.8.0, Xcode 4.4, latest updates; all background dependencies are installed as both 32 and 64 bit, and includes orc. Please let me know what tests I can run to get more/better info to help correct this issue. - MLD % clang --version Apple clang version 4.0 (tags/Apple/clang-421.0.57) (based on LLVM 3.1svn) Target: x86_64-apple-darwin12.0.0 Thread model: posix % gcc --version i686-apple-darwin11-llvm-gcc-4.2 (GCC) 4.2.1 (Based on Apple Inc. build 5658) (LLVM build 2336.11.00) % uname -a Darwin mld-mbp-17.comcast.net 12.0.0 Darwin Kernel Version 12.0.0: Sun Jun 24 23:00:16 PDT 2012; root:xnu-2050.7.9~1/RELEASE_X86_64 x86_64 % cmake ../git [snip] -- Compiler name: GNU -- x86* CPU detected -- GCC missing xgetbv, Overruled arch avx -- CPU width is 64 bits, Overruled arch 32 -- Available architectures: generic;altivec;neon;64;3dnow;abm;popcount;mmx;sse;sse2;orc;norc;sse3;ssse3;sse4_a;sse4_1;sse4_2 -- Available machines: generic_orc;neon_orc;sse2_64_mmx_orc;sse3_64_orc;ssse3_64_orc;sse4_a_64_orc;sse4_1_64_orc;sse4_2_64_orc;altivec -- Using install prefix: /usr/local [snip] % make VERBOSE=on [snip] /opt/local/bin/cmake -H/opt/GNURadio/source/git -B/opt/GNURadio/source/builds/10.8 --check-build-system CMakeFiles/Makefile.cmake 0 /opt/local/bin/cmake -E cmake_progress_start /opt/GNURadio/source/builds/10.8/CMakeFiles /opt/GNURadio/source/builds/10.8/CMakeFiles/progress.marks make -f CMakeFiles/Makefile2 all make -f volk/lib/CMakeFiles/volk.dir/build.make volk/lib/CMakeFiles/volk.dir/depend cd /opt/GNURadio/source/builds/10.8 /opt/local/bin/cmake -E cmake_depends Unix Makefiles /opt/GNURadio/source/git /opt/GNURadio/source/git/volk/lib /opt/GNURadio/source/builds/10.8 /opt/GNURadio/source/builds/10.8/volk/lib /opt/GNURadio/source/builds/10.8/volk/lib/CMakeFiles/volk.dir/DependInfo.cmake --color= make -f volk/lib/CMakeFiles/volk.dir/build.make volk/lib/CMakeFiles/volk.dir/build /opt/local/bin/cmake -E cmake_progress_report /opt/GNURadio/source/builds/10.8/CMakeFiles [ 0%] Building C object volk/lib/CMakeFiles/volk.dir/volk_machine_neon_orc.c.o cd /opt/GNURadio/source/builds/10.8/volk/lib /usr/bin/gcc -Dvolk_EXPORTS -DHAVE_FENV_H -DHAVE_DLFCN_H -O3 -DNDEBUG -fPIC -I/opt/GNURadio/source/builds/10.8/volk/include -I/opt/GNURadio/source/git/volk/include -I/opt/GNURadio/source/builds/10.8/volk/lib -I/opt/GNURadio/source/git/volk/lib -I/opt/local/include/orc-0.4 -I/opt/local/include-fvisibility=hidden -mfpu=neon -mfloat-abi=softfp -funsafe-math-optimizations -o CMakeFiles/volk.dir/volk_machine_neon_orc.c.o -c /opt/GNURadio/source/builds/10.8/volk/lib/volk_machine_neon_orc.c cc1: error: unrecognized command line option -mfpu=neon cc1: error: unrecognized command line option -mfloat-abi=softfp make[2]: *** [volk/lib/CMakeFiles/volk.dir/volk_machine_neon_orc.c.o] Error 1 make[1]: *** [volk/lib/CMakeFiles/volk.dir/all] Error 2 make: *** [all] Error 2 ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio I'm having this issue now. How did you get it working? Cheers, Ben ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] vector sink data
tb.start() while not_finished: time.sleep(10) my_data = tb.my_probe_signal.level() print(my_data) tb.stop() You can use gr.probe_signal_vc to grab a vector of data, however you'll only grab data every 10 seconds in the above example. This method will only give you occasional snapshots of the data so will not allow an exhaustive search. If you want to do an exhaustive search then writing a custom signal processing block in C++ is the way to go. Ben On Thu, Aug 16, 2012 at 12:28 AM, abdullah unutmaz abdullahunut...@yahoo.com wrote: Greetings, Could I set up an ordinary paralel output shift register using vector_sink or probe_signal? When I examined both vector_sink probe_signal, process was ended when the output was displayed. But, I need an ongoing data acquisition, though I can get different outputs from both of the blocks, I need a flow of samples. If I can set this up, most of the work will be done. In main function, I embed tb.run() time.sleep(10) my_data = tb.my_vec_snk.data() print data: ,my_data into a while(True) loop, but this time everything starts from the begining, it takes sometime from the FPGA to settle, and data acquisition cuts down. As an alternative solution, I keep larger amount of samples than actual number of samples I need to, and search the pattern in the kept sequence. But it is time consuming, this study is for a final year project, when I discuss solutions with my professor, he decisively wants the system to be ongoing data flow, even though in both of the possible solutions the process ends right after the data is acquired :). Thanks, Abdullah From: abdullah unutmaz abdullahunut...@yahoo.com To: Ben Reynwar b...@reynwar.net; discuss-gnuradio@gnu.org discuss-gnuradio@gnu.org Sent: Friday, August 10, 2012 3:25 PM Subject: Re: [Discuss-gnuradio] vector sink data Thanks, I realized what I need to do. Next monday I can try it, probably it will solve the problem. From: Ben Reynwar b...@reynwar.net To: abdullah unutmaz abdullahunut...@yahoo.com; discuss-gnuradio Discussion Group discuss-gnuradio@gnu.org Sent: Friday, August 10, 2012 8:37 PM Subject: Re: [Discuss-gnuradio] vector sink data I can't tell what your problem might be without seeing your entire script. A minimal script doing something like this is: from gnuradio import gr tb = gr.top_block() src = gr.vector_source_f([1,2,3,4,5,6]) snk = gr.vector_sink_f() tb.connect(src, snk) tb.run() print(snk.data()) On Fri, Aug 10, 2012 at 4:05 AM, abdullah unutmaz abdullahunut...@yahoo.com wrote: @Ben, first of all thanks for replying. I tried both of the solutions, the output I get is a vector containing only zeros, data: (0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0) When I use probe_signal data: 0.0 But I was sending a vector composed of eleven elements of a combination of ones and zeros. It seems extra-ordinary, when I open the file to see the data I keep, I see two different symbols, ascii-codes, sequenced periodically after skipping an amount of the first stored data. What may be the problem, any idea? - Abdullah From: Ben Reynwar b...@reynwar.net To: abdullah unutmaz abdullahunut...@yahoo.com; discuss-gnuradio Discussion Group discuss-gnuradio@gnu.org Sent: Thursday, August 9, 2012 6:29 PM Subject: Re: [Discuss-gnuradio] vector sink data On Thu, Aug 9, 2012 at 1:53 PM, abdullah unutmaz abdullahunut...@yahoo.com wrote: Greetings, I would like to ask you how to read the data stored in a vector sink. I tried the solutions I found in the discussion list. You can see some part of my python code below. -- ## # Connections ## self.connect((self.my_vec_src, 0), (self.my_thro, 0)) vector_source - throttle self.connect((self.my_thro, 0), (self.my_h, 0)) throttle - head self.connect((self.my_h, 0), (self.my_vec_snk, 0))head - vector_sink time.sleep(10) my_data=self.my_vec_snk.data() print data: ,my_data if __name__ == '__main__': parser = OptionParser(option_class=eng_option, usage=%prog: [options]) (options, args) = parser.parse_args() tb = top_block() tb.Run(True) -- Output of the program : data: () I need to read an incoming data to correlate with some predefined data, vector. If I am
Re: [Discuss-gnuradio] vector sink data
I can't tell what your problem might be without seeing your entire script. A minimal script doing something like this is: from gnuradio import gr tb = gr.top_block() src = gr.vector_source_f([1,2,3,4,5,6]) snk = gr.vector_sink_f() tb.connect(src, snk) tb.run() print(snk.data()) On Fri, Aug 10, 2012 at 4:05 AM, abdullah unutmaz abdullahunut...@yahoo.com wrote: @Ben, first of all thanks for replying. I tried both of the solutions, the output I get is a vector containing only zeros, data: (0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0) When I use probe_signal data: 0.0 But I was sending a vector composed of eleven elements of a combination of ones and zeros. It seems extra-ordinary, when I open the file to see the data I keep, I see two different symbols, ascii-codes, sequenced periodically after skipping an amount of the first stored data. What may be the problem, any idea? - Abdullah From: Ben Reynwar b...@reynwar.net To: abdullah unutmaz abdullahunut...@yahoo.com; discuss-gnuradio Discussion Group discuss-gnuradio@gnu.org Sent: Thursday, August 9, 2012 6:29 PM Subject: Re: [Discuss-gnuradio] vector sink data On Thu, Aug 9, 2012 at 1:53 PM, abdullah unutmaz abdullahunut...@yahoo.com wrote: Greetings, I would like to ask you how to read the data stored in a vector sink. I tried the solutions I found in the discussion list. You can see some part of my python code below. -- ## # Connections ## self.connect((self.my_vec_src, 0), (self.my_thro, 0)) vector_source - throttle self.connect((self.my_thro, 0), (self.my_h, 0)) throttle - head self.connect((self.my_h, 0), (self.my_vec_snk, 0))head - vector_sink time.sleep(10) my_data=self.my_vec_snk.data() print data: ,my_data if __name__ == '__main__': parser = OptionParser(option_class=eng_option, usage=%prog: [options]) (options, args) = parser.parse_args() tb = top_block() tb.Run(True) -- Output of the program : data: () I need to read an incoming data to correlate with some predefined data, vector. If I am not wrong the best solution is to save data in a vector sink same length as the predefined vector, then applying the cross-correlation to them. The program above is just a test program to examine what the vector sink stores, but I am confused why it does not work, because I saw a similar working use of a vector sink with USRPs. I already save the data in a file, but it does not seem to me as a good solution at least due to possible memory waste, though clearing the file is possible in run-time. Thanks in advance, Abdullah ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio vector_sink is useful if you're running for a short time, for example in a test. You can access that data using snk.data() after tb.run() has completed. So something like: tb.run() time.sleep(10) my_data = tb.my_vec_snk.data() print data: ,my_data To extract data from a running flow graph use the probe blocks (gr.probe_signal_*). tb.start() time.sleep(10) my_data = tb.my_probe_signal.level() print data: ,my_data ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] QPSK Constellation
There no way to do this simply by passing an appropriate argument but you could do it without recompiling by adding in appropriate digital.map_bb blocks into the modulation and demodulation blocks. On Fri, Aug 10, 2012 at 9:18 AM, David Miller davidernestmil...@gmail.com wrote: Hey List, Is it possible to easily change the QPSK mapping for the PSK modulator/demodulators, or does it require a re-compile? David ___ 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] vector sink data
On Thu, Aug 9, 2012 at 1:53 PM, abdullah unutmaz abdullahunut...@yahoo.com wrote: Greetings, I would like to ask you how to read the data stored in a vector sink. I tried the solutions I found in the discussion list. You can see some part of my python code below. -- ## # Connections ## self.connect((self.my_vec_src, 0), (self.my_thro, 0)) vector_source - throttle self.connect((self.my_thro, 0), (self.my_h, 0)) throttle - head self.connect((self.my_h, 0), (self.my_vec_snk, 0))head - vector_sink time.sleep(10) my_data=self.my_vec_snk.data() print data: ,my_data if __name__ == '__main__': parser = OptionParser(option_class=eng_option, usage=%prog: [options]) (options, args) = parser.parse_args() tb = top_block() tb.Run(True) -- Output of the program : data: () I need to read an incoming data to correlate with some predefined data, vector. If I am not wrong the best solution is to save data in a vector sink same length as the predefined vector, then applying the cross-correlation to them. The program above is just a test program to examine what the vector sink stores, but I am confused why it does not work, because I saw a similar working use of a vector sink with USRPs. I already save the data in a file, but it does not seem to me as a good solution at least due to possible memory waste, though clearing the file is possible in run-time. Thanks in advance, Abdullah ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio vector_sink is useful if you're running for a short time, for example in a test. You can access that data using snk.data() after tb.run() has completed. So something like: tb.run() time.sleep(10) my_data = tb.my_vec_snk.data() print data: ,my_data To extract data from a running flow graph use the probe blocks (gr.probe_signal_*). tb.start() time.sleep(10) my_data = tb.my_probe_signal.level() print data: ,my_data ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] hanging on top_block.stop
Hi all, The following script hangs for me about 1 time in 10 on the call to top_block.stop. Drilling in a bit, it appears to get stuck on a call to 'interrupt' of a boost::thread instance on line 91 of gruel/src/lib/thread_group.cc. Has anyone else had this problem? Cheers, Ben import time from gnuradio import gr def execute(): tb = gr.top_block() src = gr.vector_source_c([1], True) snk = gr.null_sink(gr.sizeof_gr_complex) tb.connect(src, snk) tb.start() time.sleep(0.01) print(**About to Stop***) tb.stop() print(**Stopped***) if __name__ == __main__: execute() ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] hanging on top_block.stop
On Tue, Aug 7, 2012 at 10:31 AM, Ben Reynwar b...@reynwar.net wrote: Hi all, The following script hangs for me about 1 time in 10 on the call to top_block.stop. Drilling in a bit, it appears to get stuck on a call to 'interrupt' of a boost::thread instance on line 91 of gruel/src/lib/thread_group.cc. Has anyone else had this problem? Cheers, Ben import time from gnuradio import gr def execute(): tb = gr.top_block() src = gr.vector_source_c([1], True) snk = gr.null_sink(gr.sizeof_gr_complex) tb.connect(src, snk) tb.start() time.sleep(0.01) print(**About to Stop***) tb.stop() print(**Stopped***) if __name__ == __main__: execute() Also, if I write the same logic in straight C++ it works fine. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] hanging on top_block.stop
Upgrading to boost 1.48 fixed the problem. Thanks again, Ben On Tue, Aug 7, 2012 at 2:43 PM, Ben Reynwar b...@reynwar.net wrote: Great, thanks. I'm using boost 1.46.1 so hopefully this will go away once I upgrade to 1.47. On Tue, Aug 7, 2012 at 2:20 PM, Don Ward don2387w...@sprynet.com wrote: You don't say what OS or version of boost you are using, but it sounds like an old problem. Try looking at http://lists.gnu.org/archive/html/discuss-gnuradio/2011-12/msg00098.html in the mailing list archives. -- Don W. - Original Message - From: Ben Reynwar b...@reynwar.net To: discuss-gnuradio Discussion Group discuss-gnuradio@gnu.org Sent: Tuesday, August 07, 2012 1:31 PM Subject: [Discuss-gnuradio] hanging on top_block.stop Hi all, The following script hangs for me about 1 time in 10 on the call to top_block.stop. Drilling in a bit, it appears to get stuck on a call to 'interrupt' of a boost::thread instance on line 91 of gruel/src/lib/thread_group.cc. Has anyone else had this problem? Cheers, Ben import time from gnuradio import gr def execute(): tb = gr.top_block() src = gr.vector_source_c([1], True) snk = gr.null_sink(gr.sizeof_gr_complex) tb.connect(src, snk) tb.start() time.sleep(0.01) print(**About to Stop***) tb.stop() print(**Stopped***) if __name__ == __main__: execute() ___ 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] Constallation receiver block in gnuradio companion
On Thu, Jun 14, 2012 at 4:53 PM, Nazmul Islam mnis...@winlab.rutgers.edu wrote: Hello, I want to transmit a continuous stream of data and obtain its synchronized version (before decoding) at the receiver using gnuradio companion. Following the generic_mod_demod.py, I have designed the transmit and receive path in the following way Tx: GLFSR source (producing +1 -1) -- RRC filter -- USRP Sink Rx: USRP Source -- AGC2 -- FLL Band Edge -- Polyphase Clock Sync. I want to insert the Constellation Receiver block at the end of the Polyphase Clock Sync. I have two questions on this: 1. The Constellation Receiver block asks for constellation object and it accepts raw data type. What should I put here? I tried using the options 2 and bpsk but they did not work. digital.constellation_bpsk() 2. The Constellation_Receiver_cb accepts baseband complex streams and returns byte level data. Will it output the decoded data? I want the complex data, that has gone through the costas and MM recovery block, but has not been decoded yet. How can I obtain that? constellation_receiver_cb only does some fine tuning of the phase, and then the mapping to symbols. If you want to get the fine tuning without the mapping then you'll need to edit gr-digital/lib/gr_constellation_receiver_cb.cc. Currently the block can have 1 or 4 outputs. If one it just outputs the symbols. If four it outputs symbol, phase error, phase estimate, and frequency estimate. You could edit the block so that it also outputs the fined tuned complex data. Any suggestion will be appreciated. Thanks, Nazmul -- 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 ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] qam modulation blocks in GRC cannot work btw two computers?
On Thu, Jun 14, 2012 at 10:58 PM, jiajue ou azalea.a...@yahoo.com.cn wrote: Hi all, I’m playing with qam modulation and demodulation blocks using GRC. To begin with, I built a flow graph in one computer as follows: File sourcepacket encoderqam mod-qam demod packet decoder-file sink It worked well. The file sink can get what is in the file source. Then, I separated the flow graph in two computers connected to a USRP N210 each to test real environment performance: Computer1: File sourcepacket encoderqam mod-usrp sink Computer2:usrp source qam demod packet decoder-file sink However, the file sink cannot get anything.(both with/without differential encoding ) To find out why, I pinted out the transmitted symbols in qam mod block in gnuradio/gnuradio-core/src/gengen/chunks_to_symbol_bc.cc in a txt file, and received symbols in qam demod block in gnuradio/gr-digital/lib/digital_constellation_recever_cb.cc in another txt file. Next, I demodulate those symbols based on closet Euclidean distance criterion by MATLAB, however,bit error rate turned to be around 0.5 (some shift is made to find the minimum ber ) which implies that received symbols and transmitted symbols are independent. AM I RIGHT ABOUT WHERE TO PRINTING OUT THE SYMBOLS? One thing to notice, when I changed qam blocks to OFDM blocks, the file sink can get what is transmitted properly even in the case of two computers. Therefore, I’m wondering if there is any problem with the qam blocks, like synchronization or channel equalization etc. that result in transmission failure. How can I solve it? MY PURPOSE IS TO GET correct symbols to demap to bits by myself. Sorry for sending such a long mail. Thank you very much for your help. Best, Jia ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio The synchronization can be slow, so if you're sending for only a short time, you might not ever be synchronizing. How does it work if you put a channel block with a frequency shift in the one computer flow graph? ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] QAM Demod error in GRC
This is a bug. In file gr-digital/grc/digital_qa_demod.xml the line gray_coded = $gray_coded should be changed to mod_code = $mod_code On Wed, Jun 13, 2012 at 7:56 AM, jiajue ou azalea.a...@yahoo.com.cn wrote: Hi all, I’m using GRC and the simple flow graph(1) at receiver is as follows: Usrp sourceqam demodfile sink It works fine at first. However, when I tried to execute another similar flow graph(2) that was built before UPDATING GNURADIO from 3.5.0 to 3.6.0. an error occurs: Generating:”/home/azalea/exp/top_block.py” executing:”/home/azalea/exp/top_block.py” File :”/home/azalea/exp/top_block.py”, line 79 Self.digital_qam_demod_0=--- Syntax error: invalid syntax (I looked up the python file, line 79 and line 80 are: Self.digital_qam_demod_0=--- Cannot find ‘gray_coded’: digital.qam.qam_demod( ) Then, I return to the mentioned flow graph(1), same error again. I also tried to start a new flow graph or make/make install gnuradio, but in vain. I’m just confused. The flow graph(1) worked well even after updating gnuradio. After that and before the error I didn’t remove or modify any module in gnuradio. Thanks a lot! Best, Jia ___ 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] QAM Mod and QAM Demod block in GRC
The python generic_demod.py block uses the constellation_receiver_cb block to do both some fine-tuning of the phase and the mapping to bits. It can be found at: gnuradio/gr-digital/lib/digital_constellation_receiver_cb.cc This in turn will use the decision_maker method of the constellation object to do the mapping which can be found in: gnuradio/gr-digital/lib/digital_constellation.cc What exactly are you trying to do? On Thu, May 31, 2012 at 8:12 PM, jiajue ou azalea.a...@yahoo.com.cn wrote: Hi Ben, What you mean is the qam blocks in gnuradio companion are implemented in Python only? If I want to get the complex symbols before they are demapped to bits, I should modify related python scripts? Thank you. Jia -Original Message- From: Ben Reynwar [mailto:b...@reynwar.net] Sent: Friday, June 01, 2012 12:39 AM To: jiajue ou; discuss-gnuradio Discussion Group Subject: Re: [Discuss-gnuradio] QAM Mod and QAM Demod block in GRC These blocks are implemented in python. Have a look at the following two files to start off with: gnuradio/gr-digital/python/qam.py gnuradio/gr-digital/python/generic_mod_demod.py Ben On Wed, May 30, 2012 at 11:41 PM, jiajue ou azalea.a...@yahoo.com.cn wrote: Hi all, I'm working on an experiment which needs to modify qam modulation block in gnuradio. But I cannot find the source C++ file the qam blocks use. e.g., OFDM demod block uses digital_ofdm_frame_sink in gnuradiobuild/gnuradio/gr-digital/lib. What about qam blocks? Thank you for your help! Best, jia ___ 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] Question on DQPSK Modulation - issue with output
Hi Vahid, First I'd try using a much longer string of bits and see if that help. Second I'd find an example in gnuradio (gr-digital/python/qa_constellation.py should have a working dqpsk test) and then work from there. Thirdly if you want pi/4-dqpsk you won't be able to use the standard dqpsk_mod and dqpsk_demod, but will need to define a two-dimensional constellation and use the generic_mod and generic_demod blocks. The two-dimensional constellation would be defined something like: normal_qpsk_points = [blah, blah, blah, blah] rotated_qpsk_points = [blah, blah, blah, blah] two_d_points = [] for p in normal_qpsk_points: for q in rotated_qpsk_points: two_d_points += [p, q] pi4dqpsk_constellation = digital.constellation_calcdist(two_d_points, [], 4, 2) Cheers, Ben On Sat, Jun 2, 2012 at 4:20 PM, Vahid Behzadan vbehza...@yahoo.com wrote: Dear all, I am currently trying to implement a pi/4 dqpsk modulator and demodulator. I have tried two approaches, one uses the CQPSK.py (included in osmocom's TETRA project) and the other uses digital.qpsk.dqpsk_mod. Both of these approaches have failed to return the same string of bits after the process of modulations-demodulation. The input comes from a .dat file and is a string of bits (tried different sizes, from 2 bits to 32 bits), then the output of modulation is written to a sink.dat as gr_complex. This file is then fed to a demodulator which saves the output to a final.dat. I have attached important bits of the code which uses qpsk.dqpsk_mod/demod. I would greatly appreciate any advice. Also, could anyone please confirm that what I can achieve a --PI/4--DQPSK using the dqpsk_mod? Best Regards, Vahid --- Modulator: . . . sample_rate = options.sample_rate symbol_rate = 18000 sps = 2 IN = gr.file_source(gr.sizeof_gr_complex, options.input_file, repeat = False) #IN = (1,0,0,0,1,1,0,0) src = gr.vector_source_b (IN) MOD = digital.qpsk.dqpsk_mod( samples_per_symbol = sps, excess_bw=0.35, log=options.log, gray_coded=True, verbose=options.verbose) self.connect(src,MOD) OUT = gr.file_sink(gr.sizeof_gr_complex, options.output_file) self.sink1 = gr.vector_sink_f() self.sink2 = gr.vector_sink_f() real = gr.complex_to_real() imag = gr.complex_to_imag() self.connect(MOD,real) self.connect(MOD,imag) self.connect(real,self.sink1) self.connect(imag,self.sink2) self.connect(MOD,OUT) def print_data(self): print data in sink1 is: ,self.sink1.data() print data in sink2 is: ,self.sink2.data() . . . - Demodulator: sample_rate = options.sample_rate symbol_rate = 18000 sps = 2 # output rate will be 36,000 ntaps = 11 * sps new_sample_rate = symbol_rate * sps channel_taps = gr.firdes.low_pass(1.0, sample_rate, options.low_pass, options.low_pass * 0.1, gr.firdes.WIN_HANN) FILTER = gr.freq_xlating_fir_filter_ccf(1, channel_taps, options.calibration, sample_rate) IN = gr.file_source(gr.sizeof_gr_complex, options.input_file) #IN = (1,1,0,1,1,1,0,0) #src = gr.vector_source_b (IN) DEMOD = digital.qpsk.dqpsk_demod( samples_per_symbol = sps, excess_bw=0.35, gray_coded=True, log=options.log, verbose=options.verbose) OUT = gr.file_sink(gr.sizeof_char, options.output_file) self.sink1 = gr.vector_sink_b() r = float(sample_rate) / float(new_sample_rate) INTERPOLATOR = gr.fractional_interpolator_cc(0, r) self.connect(IN, FILTER, INTERPOLATOR, DEMOD, OUT) self.connect(DEMOD,self.sink1) def print_data(self): print data in sink1 is: ,self.sink1.data() -- View this message in context: http://old.nabble.com/Question-on-DQPSK-Modulation---issue-with-output-tp33950307p33950307.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] Question on DQPSK Modulation - issue with output
On Sun, Jun 3, 2012 at 4:31 PM, Ben Reynwar b...@reynwar.net wrote: Hi Vahid, First I'd try using a much longer string of bits and see if that help. Second I'd find an example in gnuradio (gr-digital/python/qa_constellation.py should have a working dqpsk test) and then work from there. Thirdly if you want pi/4-dqpsk you won't be able to use the standard dqpsk_mod and dqpsk_demod, but will need to define a two-dimensional constellation and use the generic_mod and generic_demod blocks. The two-dimensional constellation would be defined something like: normal_qpsk_points = [blah, blah, blah, blah] rotated_qpsk_points = [blah, blah, blah, blah] two_d_points = [] for p in normal_qpsk_points: for q in rotated_qpsk_points: two_d_points += [p, q] pi4dqpsk_constellation = digital.constellation_calcdist(two_d_points, [], 4, 2) Just checked the code and it looks like multi-dimensional constellations aren't supported yet by generic_mod and generic_demod. Another way might be to edit digital.constellation_receiver_cb so that it shifts the phase back and forth by pi/4. Cheers, Ben On Sat, Jun 2, 2012 at 4:20 PM, Vahid Behzadan vbehza...@yahoo.com wrote: Dear all, I am currently trying to implement a pi/4 dqpsk modulator and demodulator. I have tried two approaches, one uses the CQPSK.py (included in osmocom's TETRA project) and the other uses digital.qpsk.dqpsk_mod. Both of these approaches have failed to return the same string of bits after the process of modulations-demodulation. The input comes from a .dat file and is a string of bits (tried different sizes, from 2 bits to 32 bits), then the output of modulation is written to a sink.dat as gr_complex. This file is then fed to a demodulator which saves the output to a final.dat. I have attached important bits of the code which uses qpsk.dqpsk_mod/demod. I would greatly appreciate any advice. Also, could anyone please confirm that what I can achieve a --PI/4--DQPSK using the dqpsk_mod? Best Regards, Vahid --- Modulator: . . . sample_rate = options.sample_rate symbol_rate = 18000 sps = 2 IN = gr.file_source(gr.sizeof_gr_complex, options.input_file, repeat = False) #IN = (1,0,0,0,1,1,0,0) src = gr.vector_source_b (IN) MOD = digital.qpsk.dqpsk_mod( samples_per_symbol = sps, excess_bw=0.35, log=options.log, gray_coded=True, verbose=options.verbose) self.connect(src,MOD) OUT = gr.file_sink(gr.sizeof_gr_complex, options.output_file) self.sink1 = gr.vector_sink_f() self.sink2 = gr.vector_sink_f() real = gr.complex_to_real() imag = gr.complex_to_imag() self.connect(MOD,real) self.connect(MOD,imag) self.connect(real,self.sink1) self.connect(imag,self.sink2) self.connect(MOD,OUT) def print_data(self): print data in sink1 is: ,self.sink1.data() print data in sink2 is: ,self.sink2.data() . . . - Demodulator: sample_rate = options.sample_rate symbol_rate = 18000 sps = 2 # output rate will be 36,000 ntaps = 11 * sps new_sample_rate = symbol_rate * sps channel_taps = gr.firdes.low_pass(1.0, sample_rate, options.low_pass, options.low_pass * 0.1, gr.firdes.WIN_HANN) FILTER = gr.freq_xlating_fir_filter_ccf(1, channel_taps, options.calibration, sample_rate) IN = gr.file_source(gr.sizeof_gr_complex, options.input_file) #IN = (1,1,0,1,1,1,0,0) #src = gr.vector_source_b (IN) DEMOD = digital.qpsk.dqpsk_demod( samples_per_symbol = sps, excess_bw=0.35, gray_coded=True, log=options.log, verbose=options.verbose) OUT = gr.file_sink(gr.sizeof_char, options.output_file) self.sink1 = gr.vector_sink_b() r = float(sample_rate) / float(new_sample_rate) INTERPOLATOR = gr.fractional_interpolator_cc(0, r) self.connect(IN, FILTER, INTERPOLATOR, DEMOD, OUT) self.connect(DEMOD,self.sink1) def print_data(self): print data in sink1 is: ,self.sink1.data() -- View this message in context: http://old.nabble.com/Question-on-DQPSK-Modulation---issue-with-output-tp33950307p33950307.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] QAM Mod and QAM Demod block in GRC
These blocks are implemented in python. Have a look at the following two files to start off with: gnuradio/gr-digital/python/qam.py gnuradio/gr-digital/python/generic_mod_demod.py Ben On Wed, May 30, 2012 at 11:41 PM, jiajue ou azalea.a...@yahoo.com.cn wrote: Hi all, I’m working on an experiment which needs to modify qam modulation block in gnuradio. But I cannot find the source C++ file the qam blocks use. e.g., OFDM demod block uses digital_ofdm_frame_sink in gnuradiobuild/gnuradio/gr-digital/lib. What about qam blocks? Thank you for your help! Best, jia ___ 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] file sink issue
It depends what you mean by readable format. If you just want to get an idea of the values and the file isn't to big then do: from gnuradio import gr src = gr.file_source(1, the_file_name) snk = gr.vector_sink_b() tb = gr.top_block() tb.connect(src, snk) tb.run() # The bytes will be presented as a list of integers in python. data = snk.data() print(data) On Tue, May 22, 2012 at 9:47 PM, ambily joseph josephamb...@gmail.com wrote: Sir My file sink input type in 'bytes'...Smthng being written to that folder..nd size of that file is increasing,,but when i try to open it its octet-stream file...How can i make into a readable format? On Mon, May 21, 2012 at 7:44 PM, Ben Reynwar b...@reynwar.net wrote: On Mon, May 21, 2012 at 12:19 AM, ambily joseph josephamb...@gmail.com wrote: Sir I am trying to build an SID SDR receiver,,where i require a file sink... When i run my flow graph,,i get a file of format octet-stream being written into my computer. But i am not able to access or open my dat octet-stream file. Sir may i know how can i access the data being written into it? Thank you ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio The file sink is just a dump of the data stream. If the data stream content was simple bytes then the content of the file is straightforward. If the data stream contained complex numbers then the file will contain a list of complex numbers where each complex number is given by two floats and each float by (usually) 4 bytes. See the files gnuradio/gnuradio-core/src/lib/io/gr_file_sink.cc and gr_file_source.cc for the implementations of the gnuradio file reading and writing blocks. You could also use python and gnuradio to convert the files into some other format. from gnuradio import gr # Assuming the data stream was complex numbers. src = gr.file_source(gr.sizeof_gr_complex, the_file_name) snk = gr.vector_sink_c() tb = gr.top_block() tb.connect(src, snk) tb.run() # The complex numbers are then accessible as a python list. data = snk.data() Ben ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] file sink issue
On Mon, May 21, 2012 at 12:19 AM, ambily joseph josephamb...@gmail.com wrote: Sir I am trying to build an SID SDR receiver,,where i require a file sink... When i run my flow graph,,i get a file of format octet-stream being written into my computer. But i am not able to access or open my dat octet-stream file. Sir may i know how can i access the data being written into it? Thank you ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio The file sink is just a dump of the data stream. If the data stream content was simple bytes then the content of the file is straightforward. If the data stream contained complex numbers then the file will contain a list of complex numbers where each complex number is given by two floats and each float by (usually) 4 bytes. See the files gnuradio/gnuradio-core/src/lib/io/gr_file_sink.cc and gr_file_source.cc for the implementations of the gnuradio file reading and writing blocks. You could also use python and gnuradio to convert the files into some other format. from gnuradio import gr # Assuming the data stream was complex numbers. src = gr.file_source(gr.sizeof_gr_complex, the_file_name) snk = gr.vector_sink_c() tb = gr.top_block() tb.connect(src, snk) tb.run() # The complex numbers are then accessible as a python list. data = snk.data() Ben ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] make test failure at qa_constellation_receiver
It appears that each test case is being run twice. I think once to generate the xml output, and once to generate output for stdout and tell you whether it failed. The random number generator isn't being reseeded at the start of each test so they can produce different results, so you can sometimes see debug statements that indicate it should fail, but the output to stdout claims that is passes. I've attached a patch that make each test use it's own random number generating object which seems a tidier way to do this, and makes the tests repeatable. Since there seem to be a fair number of choices of seed that produce an error fraction of over 0.2, I've also increased the acceptable error rate in the test to 0.3, as Alick initially suggested. On Sat, Apr 14, 2012 at 9:39 AM, Alick Zhao alick9...@gmail.com wrote: On Sat, 14 Apr 2012 13:40:35 +0200, Martin Braun wrote: On Sat, Apr 14, 2012 at 05:20:13PM +0800, Alick Zhao wrote: Yes the bug still occurs. I just wrote a simple script to ran the test for 50 times on T60 with Ubuntu, GNU Radio 3.5.3 equipped, before and after FREQUENCY_OFFSET set to 0. All failed the test. (n_pass is 0/50 in both sets) Every test's output is almost identical in each set except particular test time length. The ones before FREQUENCY_OFFSET change is basically the same as test.t60.log already attached. One of the ones with FREQUENCY_OFFSET set to 0 is attached below. I guess the almost same contents of output is due to fixed random seed. I also ran the script on a Dell desktop with Fedora, and the result is 50/50 pass the test. Then I notice one line in the qa python file says that seed 1234 fails. However, 50/50 are OK with seed 1234 on the Dell desktop. So, I tried this on a native 32-Bit Ubuntu 11.10, and it fails (tells me it's using Volk machine: sse3_32. I also noticed the line that says seed=1234 fails. Also, the seed is set multiple times in the script. If this is the source of the bug or not, it should be fixed, because the seed is reset somewhere in the guts of the test. I'll post a patch on patch-gnuradio--this eliminates the problem on my machine, for some reason. If it does the same for you, this might actually be the solution. MB I applied the patch and tested it. No failure, yeah! However, with my debugging line, I can see this: [...] constellation: constellation psk (m=32) differential: True correct: 0.942307692308 constellation: constellation psk (m=64) differential: True correct: 0.772435897436 constellation: constellation psk (m=2) differential: True correct: 1.0 [...] So why 0.77XXX on the second line does not cause the assert to fail? alick ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio 0001-Improving-qa_constellation_receiver.patch Description: Binary data ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] make test failure at qa_constellation_receiver
2012/4/12 Alick Zhao alick9...@gmail.com: Hi all, Recently I have upgraded my gnuradio build to v3.5.3 on several computers, and I find that on two machines with Ubuntu 11.10, make test will fail the test qa_constellation_receiver while on the other two with Fedora 16 all tests are passed. To investigate the problem, I add one line in the file `gr-digital/python/qa_constellation_receiver.py` which just print the value of constellation, differential, and correct before the assert. Then I run the script `build/gr-digital/python/qa_constellation_receiver_test.sh`. The output is recorded and attached below. Among them: * test.t41.log is from a Thinkpad T41 with Ubuntu 11.10 32bit installed, * test.t60.log is from a Thinkpad T60 with Ubuntu 11.10 32bit installed, * test.f16.log is from a HP 6531s with Fedora 16 x86_64 installed. Hope these logs are helpful to diagnose the problem. PS: As a side note, my debugging line's output appears later than the result, which is not the case for screen output. I think this is probably related to stdout buffering. PS2: I once changed the REQ_CORRECT to 0.7 on one Ubuntu machine, and then made the test passed. I wonder if it is a valid fix. alick ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio Weird. This test is probabilistic (not ideal really) but the chance of it failing due to chance should be very small. If it's consistently failing on one machine but not another then there's something fishy going on, and lowering REQ_CORRECT, while making the test pass, wouldn't help finding what's causing the problem. First thing I'd do would be to repeat the test a bunch of times and confirm you're getting a consistently higher BER on one computer than another. Then I'd do a complete uninstall and reinstall of gnuradio on a computer having the issue. If the problem is still there then it's probably going to be an unpleasant bug to find. Has anybody else seen this? Cheers, Ben ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] make test failure at qa_constellation_receiver
2012/4/12 Alick Zhao alick9...@gmail.com: Hi all, Recently I have upgraded my gnuradio build to v3.5.3 on several computers, and I find that on two machines with Ubuntu 11.10, make test will fail the test qa_constellation_receiver while on the other two with Fedora 16 all tests are passed. To investigate the problem, I add one line in the file `gr-digital/python/qa_constellation_receiver.py` which just print the value of constellation, differential, and correct before the assert. Then I run the script `build/gr-digital/python/qa_constellation_receiver_test.sh`. The output is recorded and attached below. Among them: * test.t41.log is from a Thinkpad T41 with Ubuntu 11.10 32bit installed, * test.t60.log is from a Thinkpad T60 with Ubuntu 11.10 32bit installed, * test.f16.log is from a HP 6531s with Fedora 16 x86_64 installed. Hope these logs are helpful to diagnose the problem. PS: As a side note, my debugging line's output appears later than the result, which is not the case for screen output. I think this is probably related to stdout buffering. PS2: I once changed the REQ_CORRECT to 0.7 on one Ubuntu machine, and then made the test passed. I wonder if it is a valid fix. alick ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio It sounds like this is definitely a bug, but it's hard for me to track it down because I can't replicate it. Does the bug still occur if you set FREQUENCY_OFFSET = 0 in the test case? ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Modifying C++ Files
On Wed, Apr 11, 2012 at 3:29 PM, Samuel Ibarra sibar...@ucr.edu wrote: Hello Ben, Thank you for your help. I was able to get the result I wanted with the line of code you suggested. I was changing d_constellation[0] = gr_complex(-1,0) to d_constellation[0]= gr_complex(0,0). In order to demodulate my signal, I should be able to make the same change in the demodulator part of the code, correct? Yes. On the off chance that you decide you want to edit the digital_constellation.cc file (rather than using the generic constellation_calcdist) make sure that you also edit the decision_maker method. Thank you very much for your help and time. Thanks Sam On Tue, Apr 10, 2012 at 7:09 PM, Ben Reynwar b...@reynwar.net wrote: Hi Sam, In bpsk.py you'll see the line constellation = digital_swig.constellation_bpsk() If you change this to: constellation = digital.constellation_calcdist((1+0i, 0+0i), [], 1, 1) , you should get the change in modulation you want. You only need to mess with the digital_constellation.cc file if you want to implement an efficient non-generic decision maker for this modulation. To know why what you're doing isn't working, I'd need to know what modifications you're making to the .cc file. It sounds like you're doing everything right. Cheers, Ben On Tue, Apr 10, 2012 at 11:34 AM, sibar002 sibar...@ucr.edu wrote: Hello, I am attempting to modify the bpsk.py file in order to obtain OOK modulation. I would like to change my constellation points to 1+0i and 0+0i. I understand that the digital_costellation.cc file is being used to set these parameters. I have tried to modify the digitial_constellation.cc file in the gr-digital folder, but I am not able to see any changes. I have made sure that I make and make install every time I change the file. I was hoping someone could tell me what I am doing wrong. I would greatly appreciate any help or advice that anyone could give me. Thank you for your time and help. Sam -- View this message in context: http://old.nabble.com/Modifying-C%2B%2B-Files-tp33663518p33663518.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] Modifying C++ Files
Hi Sam, In bpsk.py you'll see the line constellation = digital_swig.constellation_bpsk() If you change this to: constellation = digital.constellation_calcdist((1+0i, 0+0i), [], 1, 1) , you should get the change in modulation you want. You only need to mess with the digital_constellation.cc file if you want to implement an efficient non-generic decision maker for this modulation. To know why what you're doing isn't working, I'd need to know what modifications you're making to the .cc file. It sounds like you're doing everything right. Cheers, Ben On Tue, Apr 10, 2012 at 11:34 AM, sibar002 sibar...@ucr.edu wrote: Hello, I am attempting to modify the bpsk.py file in order to obtain OOK modulation. I would like to change my constellation points to 1+0i and 0+0i. I understand that the digital_costellation.cc file is being used to set these parameters. I have tried to modify the digitial_constellation.cc file in the gr-digital folder, but I am not able to see any changes. I have made sure that I make and make install every time I change the file. I was hoping someone could tell me what I am doing wrong. I would greatly appreciate any help or advice that anyone could give me. Thank you for your time and help. Sam -- View this message in context: http://old.nabble.com/Modifying-C%2B%2B-Files-tp33663518p33663518.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] Problem with USRP!
For the vector source it looks like you're using [1,1,1,0,0,0]. Perhaps the rest is getting cut-off, but if not then I would change this to use a long random vector for the testing. If you are using [1,1,1,0,0,0] repeated then the four symbols won't be used with similar frequency, which might make things more difficult. Also the differential encoding and decoding should be taken care of within the DPSK mod and demod blocks, so that should be OK. On Sun, Apr 8, 2012 at 2:25 PM, huzaifazafar108 huzaifazafar...@gmail.com wrote: We just removed the throttle blocks and the same problem remains. Please let us know how to achieve symbol synchronization. huzaifazafar108 wrote: Dear John, Thank you for such a prompt reply. Okay, we will remove the throttle blocks just now. But can you guide us how to achieve symbol synchronization then? Best Regards, Huzaifa John Malsbury wrote: You do not need to use throttles when using a UHD sink/source, because the device provides timing for the flowgraph. Remove the throttles and try again. If you still see the failure I'd say you are not achieving symbol sync. -John On 04/08/2012 01:58 PM, Huzaifa Zafar wrote: Dear all, I am working with 3 people on a project involving GNU Radio and USRP1. We have tried to implement a simple point to point digital communication system in GRC involving DQPSK modulation. Using a vector source we are sending a finite stream of zeros and ones (the vector source has Repeat set to yes). On the receiver side, what we receive is really very strange: The same stream of zeros and ones, but with extra zeros in between our actual data. For example, we send three ones and three zeros, but what we receive is a one followed by seven zeros, another one followed by seven zeros, another one followed by seven zeros, and then a zero followed by seven zeros e.t.c. We tried to experiment more by using the 'KEEP 1 in N' block and the 'DECIMATING FIR FILTER', but things are not working out the way they should. I am also attaching a snapshot of the .grc file for your reference. Please tell us the reason why these extra zeros are present between our data bits, and the way to combat this effect (remember that the decimating fir filter and keep 1 in N block are not showing the desired output). Any kind of help is appreciated in advance. -- Huzaifa Zafar ___ 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 -- View this message in context: http://old.nabble.com/Problem-with-USRP%21-tp33653047p33653150.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] Pack k bits?
So I'll add a bit more detail, and bump the thread because I don't understand this either. If we apply the following unpackings to a byte of value 69 we get: gr.packed_to_unpacked_bb(1, gr.GR_LSB_FIRST) - (1, 0, 1, 0, 0, 0, 1, 0) gr.packed_to_unpacked_bb(1, gr.GR_MSB_FIRST) - (0, 1, 0, 0, 0, 1, 0, 1) gr.packed_to_unpacked_bb(2, gr.GR_LSB_FIRST) - (2, 2, 0, 2) gr.packed_to_unpacked_bb(2, gr.GR_MSB_FIRST) - (1, 0, 1, 1) packed_to_unpacked and unpacked_to_packed are consistent with one another. On Fri, Mar 30, 2012 at 1:33 PM, Nowlan, Sean sean.now...@gtri.gatech.edu wrote: Any comment on this? I think the current implementation of gr_packed_to_unpacked_bb(int k, gr_endianness_t endianness) puts bits in an incorrect order when k 1 and endianness = gr.GR_LSB_FIRST. 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: Wednesday, March 28, 2012 9:26 AM To: discuss-gnuradio@gnu.org Subject: Re: [Discuss-gnuradio] Pack k bits? I think it would work if I modified gnuradio/gnuradio-core/src/lib/gengen/gr_packed_to_unpacked_XX.cc.t (line 119) to the following: x = (x1) | (get_bit_le(in, index_tmp) (d_bits_per_chunk - 1) ); -OR- x |= get_bit_le(in, index_tmp) j; I haven’t tested, but I think these are functionally equivalent. Does this change sound reasonable? -- Sean 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: Wednesday, March 28, 2012 8:49 AM To: discuss-gnuradio@gnu.org Subject: [Discuss-gnuradio] Pack k bits? I want to take an input stream of bytes in which only one LSB is relevant (e.g., the output of the GR GLFSR block) and pack these bits into bytes with k relevant bits. For example, I’d like to take a stream of raw bits generated by the GLFSR and feed them to an M-PSK modulator, which requires chunks with k=log2(M) bits. Unfortunately I haven’t found this to be straightforward. There is no “pack_k_bits” module that I could find, so I tried using unpacked_to_packed_bb and packed_to_unpacked_bb. They are not working like I would expect. For instance, here’s an example in Python: … data = [1,0,1,0, 0,0,1,0, 1,1,1,0, 0,1,1,0] # 45 67 self.source = gr.vector_source_b(data, False, 1) self.pack = gr.unpacked_to_packed_bb(1, gr.GR_LSB_FIRST) self.unpack = gr.packed_to_unpacked_bb(2, gr.GR_LSB_FIRST) # stuff 2 bits into LSB of each output byte self.head = gr.head(gr.sizeof_char, 8) # should have 16/2 = 8 output bytes self.sink = gr.file_sink(gr.sizeof_char, “out.bin”) self.connect(self.source, self.pack, self.unpack, self.head, self.sink) … This gives the following: $ hexdump -C out.bin 000 02 02 00 02 03 02 01 02 |……..| 008 But I would expect the following: 000 01 01 00 01 03 01 02 01 |……..| 008 Notice that the two least significant bits are in reverse order. Any clue what’s going on here? Thanks, 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] Looking for working hello world example for function probe with signal probe
On Wed, Mar 28, 2012 at 6:04 AM, mario behn mario.b...@gmail.com wrote: Hi, I'm looking for a working hello world example for using function probe with signal probe in gnuradio companion. I can't get it to work with the existing documentation found. Thanks for any input. Mario In the Function Probe block you want: Block ID: whatever the ID of your Probe Signal block is. Function Name: level ___ 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] Building new blocks in Gnu Radio
On Mon, Mar 26, 2012 at 12:54 PM, Ben Reynwar b...@reynwar.net wrote: On Mon, Mar 26, 2012 at 10:42 AM, Francisco francisco_pais...@hotmail.com wrote: Ben Reynwar ben at reynwar.net writes: I think that the best way to get started is to use Martins gr-modtool. It will help you to make out-of-tree blocks (out-of-tree means separate but compatible with your main gnuradio installation). It can be found at: https://github.com/mbant/gr-modtool On Mon, Mar 26, 2012 at 2:58 AM, Ebtisam Ahmed ebtisamahmed90 at gmail.com wrote: Indeed i have read but i cant understand the building process. I built it the i understood but it failed terribly, i have made .h .cc .i and makefile.am. Put them in one folder and then done make. i also tried ./configure and ./bootstrap but it doesnt work Anyways thanx for ur time and help me on this Regards, Ebtisam ___ Discuss-gnuradio mailing list Discuss-gnuradio at gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio Hi all, I've decided to follow your suggestion and get gr_modtool.py. First I created the module with this script which created some folders, files and the .cc and .h files with skeleton code. Then I put my code in the .cc and .h files. I also changed the .xml file so I can use GRC (I haven't used python yet to create graphs). After this, I used cmake. I wrote: cmake -i sudo make sudo make install sudo ldconfig These were my steps to build a new block to use in GRC. However, I get this error: ImportError: /usr/local/lib/python2.7/dist- packages/mycoolstuff/_mycoolstuff_swig.so: undefined symbol: _Z38mycoolstuff_make_decimated_average_vccifi Yes. My module and block are called mycoolstuff and decimated_average_vcc.cc It seems that there is a problem with the swig. Do I have to configure anything in the .i files before starting to use cmake? Regards, Francisco ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio It looks like there is currently a bug in gr-modtool where when you generate a new block it gets the module and block name wrong way round. There's no bug. I'm just incompetent. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Building new blocks in Gnu Radio
On Mon, Mar 26, 2012 at 10:42 AM, Francisco francisco_pais...@hotmail.com wrote: Ben Reynwar ben at reynwar.net writes: I think that the best way to get started is to use Martins gr-modtool. It will help you to make out-of-tree blocks (out-of-tree means separate but compatible with your main gnuradio installation). It can be found at: https://github.com/mbant/gr-modtool On Mon, Mar 26, 2012 at 2:58 AM, Ebtisam Ahmed ebtisamahmed90 at gmail.com wrote: Indeed i have read but i cant understand the building process. I built it the i understood but it failed terribly, i have made .h .cc .i and makefile.am. Put them in one folder and then done make. i also tried ./configure and ./bootstrap but it doesnt work Anyways thanx for ur time and help me on this Regards, Ebtisam ___ Discuss-gnuradio mailing list Discuss-gnuradio at gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio Hi all, I've decided to follow your suggestion and get gr_modtool.py. First I created the module with this script which created some folders, files and the .cc and .h files with skeleton code. Then I put my code in the .cc and .h files. I also changed the .xml file so I can use GRC (I haven't used python yet to create graphs). After this, I used cmake. I wrote: cmake -i sudo make sudo make install sudo ldconfig These were my steps to build a new block to use in GRC. However, I get this error: ImportError: /usr/local/lib/python2.7/dist- packages/mycoolstuff/_mycoolstuff_swig.so: undefined symbol: _Z38mycoolstuff_make_decimated_average_vccifi Yes. My module and block are called mycoolstuff and decimated_average_vcc.cc It seems that there is a problem with the swig. Do I have to configure anything in the .i files before starting to use cmake? The only thing that 'must' be edited are the gr_make_io_signature arguments in the .cc file, although without editing the work function you won't get much signal processing going on. All the swig stuff should be taken care of by gr-modtool. You can test whether it's working in python by doing: from mycoolstuff import decimated_average_vcc that way you can get it working without worrying about the grc stuff. Regards, Francisco ___ 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] Building new blocks in Gnu Radio
I think that the best way to get started is to use Martins gr-modtool. It will help you to make out-of-tree blocks (out-of-tree means separate but compatible with your main gnuradio installation). It can be found at: https://github.com/mbant/gr-modtool On Mon, Mar 26, 2012 at 2:58 AM, Ebtisam Ahmed ebtisamahme...@gmail.com wrote: Indeed i have read but i cant understand the building process. I built it the i understood but it failed terribly, i have made .h .cc .i and makefile.am. Put them in one folder and then done make. i also tried ./configure and ./bootstrap but it doesnt work Anyways thanx for ur time and help me on this Regards, Ebtisam ___ 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] Building new blocks in Gnu Radio
On Mon, Mar 26, 2012 at 10:42 AM, Francisco francisco_pais...@hotmail.com wrote: Ben Reynwar ben at reynwar.net writes: I think that the best way to get started is to use Martins gr-modtool. It will help you to make out-of-tree blocks (out-of-tree means separate but compatible with your main gnuradio installation). It can be found at: https://github.com/mbant/gr-modtool On Mon, Mar 26, 2012 at 2:58 AM, Ebtisam Ahmed ebtisamahmed90 at gmail.com wrote: Indeed i have read but i cant understand the building process. I built it the i understood but it failed terribly, i have made .h .cc .i and makefile.am. Put them in one folder and then done make. i also tried ./configure and ./bootstrap but it doesnt work Anyways thanx for ur time and help me on this Regards, Ebtisam ___ Discuss-gnuradio mailing list Discuss-gnuradio at gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio Hi all, I've decided to follow your suggestion and get gr_modtool.py. First I created the module with this script which created some folders, files and the .cc and .h files with skeleton code. Then I put my code in the .cc and .h files. I also changed the .xml file so I can use GRC (I haven't used python yet to create graphs). After this, I used cmake. I wrote: cmake -i sudo make sudo make install sudo ldconfig These were my steps to build a new block to use in GRC. However, I get this error: ImportError: /usr/local/lib/python2.7/dist- packages/mycoolstuff/_mycoolstuff_swig.so: undefined symbol: _Z38mycoolstuff_make_decimated_average_vccifi Yes. My module and block are called mycoolstuff and decimated_average_vcc.cc It seems that there is a problem with the swig. Do I have to configure anything in the .i files before starting to use cmake? Regards, Francisco ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio It looks like there is currently a bug in gr-modtool where when you generate a new block it gets the module and block name wrong way round. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] usrp_nbfm_ptt.py Error: __init__() takes exactly 4 arguments (6 given)
That sounds like the example is out-of-date. It's calling some function that expects a different number of arguments than it is giving it. If you included the entire error output then we could better see what the problem was (i.e. which function is raising this error). Cheers, Ben On Fri, Mar 23, 2012 at 9:02 AM, mario behn mario.b...@gmail.com wrote: Hi, I'm trying to make usrp_nbfm_ptt.py to work with a N210 Rev.4. on Ubuntu 11.10 and with Gnuradio 3.5.2.1 After my normal system info (see below), however, I get following message: The debugged program raised the exception unhandled TypeError __init__() takes exactly 4 arguments (6 given) File: /home/usrp1/USRP/gnuradio/gr-uhd/examples/usrp_nbfm_ptt.py, Line: 81 I wonder if anyone has seen this error and let me know what I'm doing wrong. With kind regards Mario Behn -- linux; GNU C++ version 4.6.1; Boost_104601; UHD_003.004.000-325-g7e296167 -- Opening a USRP2/N-Series device... -- Current recv frame size: 1472 bytes -- Current send frame size: 1472 bytes UHD Warning: The hardware does not support the requested TX sample rate: Target sample rate: 0.32 MSps Actual sample rate: 0.320513 MSps PCM name: pulse Access types: MMAP_INTERLEAVED NO MMAP_NONINTERLEAVED NO MMAP_COMPLEX NO RW_INTERLEAVED YES RW_NONINTERLEAVED NO Formats: U8 YES S16_LE YES S16_BE YES S32_LE YES S32_BE YES FLOAT_LE YES FLOAT_BE YES MU_LAW YES A_LAW YES Number of channels min channels: 1 max channels: 32 1 channels YES 2 channels YES 3 channels YES 4 channels YES 5 channels YES 6 channels YES 7 channels YES 8 channels YES 9 channels YES 10 channels YES 11 channels YES 12 channels YES 13 channels YES 14 channels YES 15 channels YES 16 channels YES Sample Rates: min rate: 1 (dir = 0) max rate: 192000 (dir = 0) 8000 YES 16000 YES 22050 YES 32000 YES 44100 YES 48000 YES 96000 YES 192000 YES audio_alsa_source[pulse]: using S32_LE Using Volk machine: avx_32 gr_fir_fff: using SSE gr_fir_ccf: using SSE ___ 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] usrp_nbfm_ptt.py Error: __init__() takes exactly 4 arguments (6 given)
On Fri, Mar 23, 2012 at 11:30 AM, mario behn mario.b...@gmail.com wrote: On Fri, Mar 23, 2012 at 5:50 PM, Ben Reynwar b...@reynwar.net wrote: That sounds like the example is out-of-date. It's calling some function that expects a different number of arguments than it is giving it. If you included the entire error output then we could better see what the problem was (i.e. which function is raising this error). Cheers, Ben Hi Ben, thank you for your answer. I agree, here is the total text of the error, eric4 gives me: The debugged program raised the exception unhandled TypeError __init__() takes exactly 4 arguments (6 given) File: /home/usrp1/USRP/gnuradio/gr-uhd/examples/usrp_nbfm_ptt.py, Line: 81 and highlights line 81 correspondingly: 76 self.txpath = transmit_path(options.args, options.spec, 77 options.antenna, options.tx_gain, 78 options.audio_input) 79 self.rxpath = receive_path(options.args, options.spec, 80 options.antenna, options.rx_gain, 81 options.audio_output) 82 self.connect(self.txpath) 83 self.connect(self.rxpath) and it is actually the file available here: http://gnuradio.org/redmine/projects/gnuradio/repository/revisions/v3.5.3git/changes/gr-uhd/examples/usrp_nbfm_ptt.py Is there any quick fix I can apply? Cheers Mario Behn Yep, there is an error in that file. The receive_path defined on line 371 isn't compatible with the call to receive_path on line 79. Perhaps try removing options.spec and options.antenna from the call, but I'm just guessing, I haven't used this example before. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] usrp_nbfm_ptt.py Error: __init__() takes exactly 4 arguments (6 given)
I'm pretty sure this will fix it. replace line 372: def __init__(self, args, gain, audio_output): with def __init__(self, args, spec, antenna, gain, audio_output): On Fri, Mar 23, 2012 at 1:23 PM, Ben Reynwar b...@reynwar.net wrote: On Fri, Mar 23, 2012 at 11:30 AM, mario behn mario.b...@gmail.com wrote: On Fri, Mar 23, 2012 at 5:50 PM, Ben Reynwar b...@reynwar.net wrote: That sounds like the example is out-of-date. It's calling some function that expects a different number of arguments than it is giving it. If you included the entire error output then we could better see what the problem was (i.e. which function is raising this error). Cheers, Ben Hi Ben, thank you for your answer. I agree, here is the total text of the error, eric4 gives me: The debugged program raised the exception unhandled TypeError __init__() takes exactly 4 arguments (6 given) File: /home/usrp1/USRP/gnuradio/gr-uhd/examples/usrp_nbfm_ptt.py, Line: 81 and highlights line 81 correspondingly: 76 self.txpath = transmit_path(options.args, options.spec, 77 options.antenna, options.tx_gain, 78 options.audio_input) 79 self.rxpath = receive_path(options.args, options.spec, 80 options.antenna, options.rx_gain, 81 options.audio_output) 82 self.connect(self.txpath) 83 self.connect(self.rxpath) and it is actually the file available here: http://gnuradio.org/redmine/projects/gnuradio/repository/revisions/v3.5.3git/changes/gr-uhd/examples/usrp_nbfm_ptt.py Is there any quick fix I can apply? Cheers Mario Behn Yep, there is an error in that file. The receive_path defined on line 371 isn't compatible with the call to receive_path on line 79. Perhaps try removing options.spec and options.antenna from the call, but I'm just guessing, I haven't used this example before. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] segfault in volk_32fc_x2_multiply_32fc_a_sse3 using current master branch
I'm seeing a segfault in volk_32fc_x2_multiply_32fc_a_sse3 and am using the current master branch. It occurs when I connect a gr.multiply_cc to a running flowgraph (using tb.lock() and tb.unlock()). If the multiply_cc block is connected before the flowgraph starts running then I don't see a segfault. I have attached: - a minimal python script that reproduces the problem for me. - the output from gdb (backtrace and disassemble) OS is 32 bit Ubuntu 11.04 beta. cpu is Intel(R) Core(TM) i3-2100 CPU @ 3.10GHz minimal_segfault.py Description: Binary data gdb.log Description: Binary data ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Help on blks2.ofdm_mod
On Sat, Mar 17, 2012 at 12:21 AM, Ebtisam Ahmed ebtisamahme...@gmail.com wrote: hi all, Im interested in making the ofdm program in python and im facing problem in the input arguements of the blks2.ofdm_mod. I tried to find that in the net but cant find it satisfactorily. can any one help me out in this. Thanx for ur time Regards, Ebtisam ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio Looking at the source code is currently the easiest solution. If you know where the source code is and you're on a unix system you could go to the source directory and do a: grep -r ofdm_mod . to try to find the file where it is defined. This might even turn up some example files where the block is used. If you don't where the source is, then you can find where the python source is installed using python by: import gnuradio gnuradio.__file__ Finally, yes, it would be nice to be able to get this information without diving into the source code, and we're working on that. Cheers, Ben ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] how to rebuild the digital_swig for the modification of ofdm
Depends on what exactly your trying to do: 1) modify existing blocks in gnuradio.digital. 2) add new blocks to gnuradio.digital 3) add new blocks out-of-tree In the case of 1) you can just edit the files, recompile and reinstall. In the case of 2) you need to edit some other files so the new blocks are included. For a purely cmake build a list of the files you'd have to edit is: gr-digital/swig/digital_swig.i, gr-digital/lib/CMakeLists.txt, gr-digital/include/CMakeLists.txt, gr-digital/swig/CMakeLists.txt (Disclaimer: I didn't test this so it's possible I left one out) In the case of 3) you can use Martin's fabulous gr_modtool. Cheers, Ben On Tue, Mar 13, 2012 at 10:54 PM, Alex Zhang cingular.a...@gmail.com wrote: Hi Gurus, I am modifying some c++ code over the current ofdm modulator and demodulator. My question is: As the all the sub C++ blocks of ofdm are combined together into the digital_swig, how can I re-generate these blocks? If I follow the guide of how_to_write_a_signal_process_block， I am expecting that only one of the block can be generated instead of combing it into the digital_swig module. I don't know how to update the digital_swig correctly. Does any friend has the clues? -- Alex, Dreams can come true – just believe. ___ 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] Unhandled exception after upgrading gnuradio- backtrace included
On Sat, Mar 10, 2012 at 5:38 AM, Tom Rondeau t...@trondeau.com wrote: On Sat, Mar 10, 2012 at 5:20 AM, MOHD RAFIQ mohd_rafiq...@yahoo.com wrote: Hi, pls suggest fix for this, i have attached my cat /proc/cpuinfo . Thanks I already did. To quote: Ok, I have a branch 'volk_32bit_fixes' published at: git://github.com/trondeau/gnuradio.git This should fix the fft_filter issue and another issue in one of the volk convert functions (that is not used in GNU Radio but was failing anyway). I'm still seeing the 32fc_x2_dot_product_32fc failure. It looks like this is in the SSE_32 proto-kernel. I'm seeing if we can get a quick fix for it. This is the same problem Martin was seeing. If we can't get a fix for it, I'm going to temporarily disable it until we get it fixed. Tom I have been waiting for people with 32-bit machines to try it out and report back before merging it. Tom I also had this segfault issue. With the fixed branch, it appears to work fine again. From: MOHD RAFIQ mohd_rafiq...@yahoo.com To: discuss-gnuradio@gnu.org discuss-gnuradio@gnu.org Sent: Thursday, 8 March 2012 9:45 PM Subject: Re: [Discuss-gnuradio] Unhandled exception after upgrading gnuradio- backtrace included I apologise for not being clear, here is the backtrace [New Thread 0xb21feb70 (LWP 16921)] [Thread 0xb19fdb70 (LWP 16920) exited] [New Thread 0xb19fdb70 (LWP 16922)] [New Thread 0xb29ffb70 (LWP 16923)] [New Thread 0xb33ffb70 (LWP 16924)] [New Thread 0xb3dffb70 (LWP 16925)] [New Thread 0xb51ffb70 (LWP 16926)] [New Thread 0xb47ffb70 (LWP 16927)] [New Thread 0xb11fcb70 (LWP 16928)] [New Thread 0xb09fbb70 (LWP 16929)] [New Thread 0xb01fab70 (LWP 16930)] Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 0xb29ffb70 (LWP 16923)] 0x002fc4a0 in volk_32fc_x2_multiply_32fc_a_sse3 () from /usr/local/lib/libvolk.so.0.0.0 (gdb) bt #0 0x002fc4a0 in volk_32fc_x2_multiply_32fc_a_sse3 () from /usr/local/lib/libvolk.so.0.0.0 #1 0x002c25d2 in get_volk_32fc_x2_multiply_32fc_a () from /usr/local/lib/libvolk.so.0.0.0 #2 0x005125bf in gri_fft_filter_ccc_generic::filter(int, std::complexfloat const*, std::complexfloat*) () from /usr/local/lib/libgnuradio-core-3.5.3git.so.0.0.0 #3 0x005196ff in gr_fft_filter_ccc::work(int, std::vectorvoid const*, std::allocatorvoid const* , std::vectorvoid*, std::allocatorvoid* ) () from /usr/local/lib/libgnuradio-core-3.5.3git.so.0.0.0 #4 0x004e537a in gr_sync_decimator::general_work(int, std::vectorint, std::allocatorint , std::vectorvoid const*, std::allocatorvoid const* , std::vectorvoid*, std::allocatorvoid* ) () from /usr/local/lib/libgnuradio-core-3.5.3git.so.0.0.0 #5 0x004c983c in gr_block_executor::run_one_iteration() () from /usr/local/lib/libgnuradio-core-3.5.3git.so.0.0.0 #6 0x004e7a7f in gr_tpb_thread_body::gr_tpb_thread_body(boost::shared_ptrgr_block, int) () from /usr/local/lib/libgnuradio-core-3.5.3git.so.0.0.0 #7 0x004e2374 in boost::detail::function::void_function_obj_invoker0gruel::thread_body_wrappertpb_container, void::invoke(boost::detail::function::function_buffer) () from /usr/local/lib/libgnuradio-core-3.5.3git.so.0.0.0 #8 0x006c8156 in boost::detail::thread_databoost::function0void ::run() () from /usr/local/lib/libgruel-3.5.3git.so.0.0.0 #9 0x0017444d in thread_proxy () from /usr/lib/libboost_thread-mt.so.1.46.0 #10 0x4f94ca2e in start_thread () from /lib/libpthread.so.0 #11 0x4f86689e in clone () from /lib/libc.so.6 Thanks, rafiq From: Tom Rondeau t...@trondeau.com To: MOHD RAFIQ mohd_rafiq...@yahoo.com Cc: discuss-gnuradio@gnu.org discuss-gnuradio@gnu.org Sent: Thursday, 8 March 2012 8:51 PM Subject: Re: [Discuss-gnuradio] Unhandled exception after upgrading gnuradio On Thu, Mar 8, 2012 at 5:40 AM, MOHD RAFIQ mohd_rafiq...@yahoo.com wrote: Hi, I am using benchmark_tx.py and benchmark_rx.py in code to make WBX usrp2 as transceiver, this was running without error until I upgraded my gnuradio from 3.5.1 to current version v3.5.2-1-g57ad294b, when I run the same code now it gives a segmenatation fault(core dump), below are the /var/log/messages when seg. fault occurs Mar 8 15:29:10 MRAFIQ-NGN kernel: [75426.998302] python[12650] general protection ip:b2d4a0 sp:b51fee80 error:0 in libvolk.so.0.0.0[ae2000+be000] Mar 8 15:29:11 MRAFIQ-NGN abrt[12658]: saved core dump of pid 12635 (/usr/bin/python) to /var/spool/abrt/ccpp-2012-03-08-15:29:10-12635.new/coredump (127561728 bytes) Mar 8 15:29:11 MRAFIQ-NGN abrtd: Directory 'ccpp-2012-03-08-15:29:10-12635' creation detected Mar 8 15:29:11 MRAFIQ-NGN abrtd: Interpreter crashed, but no packaged script detected: 'python algo-sink.py' Mar 8 15:29:11 MRAFIQ-NGN abrtd: Corrupted or bad dump /var/spool/abrt/ccpp-2012-03-08-15:29:10-12635 (res:2), deleting In the code this occurs at tb.start() inside
Re: [Discuss-gnuradio] Unhandled exception after upgrading gnuradio- backtrace included
On Wed, Mar 14, 2012 at 1:12 PM, Ben Reynwar b...@reynwar.net wrote: On Sat, Mar 10, 2012 at 5:38 AM, Tom Rondeau t...@trondeau.com wrote: On Sat, Mar 10, 2012 at 5:20 AM, MOHD RAFIQ mohd_rafiq...@yahoo.com wrote: Hi, pls suggest fix for this, i have attached my cat /proc/cpuinfo . Thanks I already did. To quote: Ok, I have a branch 'volk_32bit_fixes' published at: git://github.com/trondeau/gnuradio.git This should fix the fft_filter issue and another issue in one of the volk convert functions (that is not used in GNU Radio but was failing anyway). I'm still seeing the 32fc_x2_dot_product_32fc failure. It looks like this is in the SSE_32 proto-kernel. I'm seeing if we can get a quick fix for it. This is the same problem Martin was seeing. If we can't get a fix for it, I'm going to temporarily disable it until we get it fixed. Tom I have been waiting for people with 32-bit machines to try it out and report back before merging it. Tom I also had this segfault issue. With the fixed branch, it appears to work fine again. Forgot: cpu is Intel(R) Core(TM) i3-2100 CPU @ 3.10GHz From: MOHD RAFIQ mohd_rafiq...@yahoo.com To: discuss-gnuradio@gnu.org discuss-gnuradio@gnu.org Sent: Thursday, 8 March 2012 9:45 PM Subject: Re: [Discuss-gnuradio] Unhandled exception after upgrading gnuradio- backtrace included I apologise for not being clear, here is the backtrace [New Thread 0xb21feb70 (LWP 16921)] [Thread 0xb19fdb70 (LWP 16920) exited] [New Thread 0xb19fdb70 (LWP 16922)] [New Thread 0xb29ffb70 (LWP 16923)] [New Thread 0xb33ffb70 (LWP 16924)] [New Thread 0xb3dffb70 (LWP 16925)] [New Thread 0xb51ffb70 (LWP 16926)] [New Thread 0xb47ffb70 (LWP 16927)] [New Thread 0xb11fcb70 (LWP 16928)] [New Thread 0xb09fbb70 (LWP 16929)] [New Thread 0xb01fab70 (LWP 16930)] Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 0xb29ffb70 (LWP 16923)] 0x002fc4a0 in volk_32fc_x2_multiply_32fc_a_sse3 () from /usr/local/lib/libvolk.so.0.0.0 (gdb) bt #0 0x002fc4a0 in volk_32fc_x2_multiply_32fc_a_sse3 () from /usr/local/lib/libvolk.so.0.0.0 #1 0x002c25d2 in get_volk_32fc_x2_multiply_32fc_a () from /usr/local/lib/libvolk.so.0.0.0 #2 0x005125bf in gri_fft_filter_ccc_generic::filter(int, std::complexfloat const*, std::complexfloat*) () from /usr/local/lib/libgnuradio-core-3.5.3git.so.0.0.0 #3 0x005196ff in gr_fft_filter_ccc::work(int, std::vectorvoid const*, std::allocatorvoid const* , std::vectorvoid*, std::allocatorvoid* ) () from /usr/local/lib/libgnuradio-core-3.5.3git.so.0.0.0 #4 0x004e537a in gr_sync_decimator::general_work(int, std::vectorint, std::allocatorint , std::vectorvoid const*, std::allocatorvoid const* , std::vectorvoid*, std::allocatorvoid* ) () from /usr/local/lib/libgnuradio-core-3.5.3git.so.0.0.0 #5 0x004c983c in gr_block_executor::run_one_iteration() () from /usr/local/lib/libgnuradio-core-3.5.3git.so.0.0.0 #6 0x004e7a7f in gr_tpb_thread_body::gr_tpb_thread_body(boost::shared_ptrgr_block, int) () from /usr/local/lib/libgnuradio-core-3.5.3git.so.0.0.0 #7 0x004e2374 in boost::detail::function::void_function_obj_invoker0gruel::thread_body_wrappertpb_container, void::invoke(boost::detail::function::function_buffer) () from /usr/local/lib/libgnuradio-core-3.5.3git.so.0.0.0 #8 0x006c8156 in boost::detail::thread_databoost::function0void ::run() () from /usr/local/lib/libgruel-3.5.3git.so.0.0.0 #9 0x0017444d in thread_proxy () from /usr/lib/libboost_thread-mt.so.1.46.0 #10 0x4f94ca2e in start_thread () from /lib/libpthread.so.0 #11 0x4f86689e in clone () from /lib/libc.so.6 Thanks, rafiq From: Tom Rondeau t...@trondeau.com To: MOHD RAFIQ mohd_rafiq...@yahoo.com Cc: discuss-gnuradio@gnu.org discuss-gnuradio@gnu.org Sent: Thursday, 8 March 2012 8:51 PM Subject: Re: [Discuss-gnuradio] Unhandled exception after upgrading gnuradio On Thu, Mar 8, 2012 at 5:40 AM, MOHD RAFIQ mohd_rafiq...@yahoo.com wrote: Hi, I am using benchmark_tx.py and benchmark_rx.py in code to make WBX usrp2 as transceiver, this was running without error until I upgraded my gnuradio from 3.5.1 to current version v3.5.2-1-g57ad294b, when I run the same code now it gives a segmenatation fault(core dump), below are the /var/log/messages when seg. fault occurs Mar 8 15:29:10 MRAFIQ-NGN kernel: [75426.998302] python[12650] general protection ip:b2d4a0 sp:b51fee80 error:0 in libvolk.so.0.0.0[ae2000+be000] Mar 8 15:29:11 MRAFIQ-NGN abrt[12658]: saved core dump of pid 12635 (/usr/bin/python) to /var/spool/abrt/ccpp-2012-03-08-15:29:10-12635.new/coredump (127561728 bytes) Mar 8 15:29:11 MRAFIQ-NGN abrtd: Directory 'ccpp-2012-03-08-15:29:10-12635' creation detected Mar 8 15:29:11 MRAFIQ-NGN abrtd: Interpreter crashed, but no packaged script detected: 'python algo-sink.py' Mar 8 15:29:11 MRAFIQ-NGN abrtd: Corrupted or bad dump
Re: [Discuss-gnuradio] Reference documentation to the python interface
On Thu, Mar 8, 2012 at 7:00 AM, Martin Braun martin.br...@kit.edu wrote: On Wed, Mar 07, 2012 at 04:36:57PM -0700, Ben Reynwar wrote: I've got a somewhat complete reference for the python interface of gnuradio radio done now. It can be found at: www.reynwar.net/gnuradio/sphinx/ Hi Ben, fantastic stuff! Any suggestions on how we could improve these docs? I'm not sure if this goes here or if it's due to the swig_doc stuff, but it would be great if block methods would also appear in the docs. A lot of the blocks have functions to configure them (e.g. add_cc.set_k()) which aren't in the docs. Yep, I overlooked this. Thanks for pointing it out. But it's still great stuff :) 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
Re: [Discuss-gnuradio] Reference documentation to the python interface
On Thu, Mar 8, 2012 at 7:19 AM, Michael Dickens m...@alum.mit.edu wrote: Hi Ben - Ditto Martin: great stuff! I think keep filling in the blanks is my improvement recommendation :) -- some items contain This docstring is not useful or the equivalent, or are just empty (e.g., gnuradio.optfir.band_pass). I'm guessing some items are like this because the source code does not contain useful info (yet). Nice work! - MLD Yeah, I think in most cases it's because the documentation is missing in the source code, and fixing that for all of gnuradio is obviously an undertaking that I am not keen or able to do. In optfir.bandpass it is because the documentation is given as a comment rather than a docstHopefully having the documentation accessible like this will help us spot where documentation needs work. ___ 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] Reference documentation to the python interface
On Thu, Mar 8, 2012 at 8:35 AM, Tom Rondeau t...@trondeau.com wrote: On Thu, Mar 8, 2012 at 10:22 AM, Ben Reynwar b...@reynwar.net wrote: On Thu, Mar 8, 2012 at 7:19 AM, Michael Dickens m...@alum.mit.edu wrote: Hi Ben - Ditto Martin: great stuff! I think keep filling in the blanks is my improvement recommendation :) -- some items contain This docstring is not useful or the equivalent, or are just empty (e.g., gnuradio.optfir.band_pass). I'm guessing some items are like this because the source code does not contain useful info (yet). Nice work! - MLD Yeah, I think in most cases it's because the documentation is missing in the source code, and fixing that for all of gnuradio is obviously an undertaking that I am not keen or able to do. In optfir.bandpass it is because the documentation is given as a comment rather than a docstHopefully having the documentation accessible like this will help us spot where documentation needs work. Hey Ben, Since you're having more luck with Sphinx than we have in the past with Doxygen for the Python documentation, I'd say we're ok changing the documentation markup to make it more friendly with Sphinx. I think you're right that a lot of the empty documentation here is due to the formatting of the documentation in the Python files (as well as an absence in some instances). Have you been able to fully automate the process? I think that's really key to the success. We don't want any manual effort to have to go into building these. When you've got it working and everything, we can then update the documentation on the Wiki for how to document the Python code so that it works nicely with this. Thanks! Tom I haven't done any work on the automation yet. My goal with that is to automate the inclusion of signal processing blocks but to leave other objects to be added manually. So if you add a new signal processing block the documentation should take care of itself, but if you add a new utility function you have to explicitly alter the documentation source files so that it is included. Since it's not desirable that all functions defined appear in the documentation, something like this is necessary. For example, if you added a new utility function to gr.digital this might consist of adding the line gnuradio.digital.my_new_function to gnuradio/docs/sphinx/digital/index.rst and the line .. autofunction:: gnuradio.digital.my_new_function to gnuradio/docs/sphinx/digital/utilities.rst ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Reference documentation to the python interface
On Thu, Mar 8, 2012 at 10:01 AM, Tom Rondeau t...@trondeau.com wrote: On Thu, Mar 8, 2012 at 11:44 AM, Ben Reynwar b...@reynwar.net wrote: On Thu, Mar 8, 2012 at 8:35 AM, Tom Rondeau t...@trondeau.com wrote: On Thu, Mar 8, 2012 at 10:22 AM, Ben Reynwar b...@reynwar.net wrote: On Thu, Mar 8, 2012 at 7:19 AM, Michael Dickens m...@alum.mit.edu wrote: Hi Ben - Ditto Martin: great stuff! I think keep filling in the blanks is my improvement recommendation :) -- some items contain This docstring is not useful or the equivalent, or are just empty (e.g., gnuradio.optfir.band_pass). I'm guessing some items are like this because the source code does not contain useful info (yet). Nice work! - MLD Yeah, I think in most cases it's because the documentation is missing in the source code, and fixing that for all of gnuradio is obviously an undertaking that I am not keen or able to do. In optfir.bandpass it is because the documentation is given as a comment rather than a docstHopefully having the documentation accessible like this will help us spot where documentation needs work. Hey Ben, Since you're having more luck with Sphinx than we have in the past with Doxygen for the Python documentation, I'd say we're ok changing the documentation markup to make it more friendly with Sphinx. I think you're right that a lot of the empty documentation here is due to the formatting of the documentation in the Python files (as well as an absence in some instances). Have you been able to fully automate the process? I think that's really key to the success. We don't want any manual effort to have to go into building these. When you've got it working and everything, we can then update the documentation on the Wiki for how to document the Python code so that it works nicely with this. Thanks! Tom I haven't done any work on the automation yet. My goal with that is to automate the inclusion of signal processing blocks but to leave other objects to be added manually. So if you add a new signal processing block the documentation should take care of itself, but if you add a new utility function you have to explicitly alter the documentation source files so that it is included. Since it's not desirable that all functions defined appear in the documentation, something like this is necessary. For example, if you added a new utility function to gr.digital this might consist of adding the line gnuradio.digital.my_new_function to gnuradio/docs/sphinx/digital/index.rst and the line .. autofunction:: gnuradio.digital.my_new_function to gnuradio/docs/sphinx/digital/utilities.rst Tha's ok. When I was talking about being automated, I was really thinking about automating the generation of the output docs during make. I think you had said before that there was some hand-editing you were doing each time. As long as we just have to amend the index file once for a new block, that's fine. I just don't want to have to do any manual intervention every time we want to build it. Tom Ah! No wonder you were worried :). Sorry for the confusion. I meant that I couldn't completely automate the generation of the files which are then used to generate the documentation. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Reference documentation to the python interface
I've got a somewhat complete reference for the python interface of gnuradio radio done now. It can be found at: www.reynwar.net/gnuradio/sphinx/ Any suggestions on how we could improve these docs? I also have two questions: - I need improved docstrings for the subpackages. In particular noaa, pager, and video_sdl. Suggestions from people who know what these are would be much appreciated. - A lot of python blocks contain doxygen markup (e.g. @param). Anyone object to me changing this to a more pythonesque format since we're not using doxygen for the python code? For example: brief description detailed description Args: arg1: description arg2: description can be easily parsed by sphinx. I've also modifed doxyxml so that it extracts parameter descriptions from the doxygen xml, and swig_doc.py so that it generates docstrings for the swiged blocks in the above format. Things to do: - Add a sphinx extension to automate the inclusion of signal processing blocks. - Handling of latex formatted math notation. Cheers, Ben ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Documentation generation using Sphinx
Just to clarify, I'm not suggesting we get rid of the Doxygen documentation. I think it documents the C++ side of things really well. What I'm suggesting is that we have two sets of documentation. Doxygen-generated docs for the C++ stuff, and sphinx-generated docs for the python interface. At the moment the subheaders are coming from the \ingroup tag indirectly, in that I use that them to generate the initial documentation, but it won't update automatically if they are changed. I think automating the documentation generation to the level where these would update automatically would complicate things more than it would help. I'll continue extending and tidying up the documentation and let you know when it's at a more presentable point. Cheers, Ben On Thu, Mar 1, 2012 at 7:57 AM, Tom Rondeau t...@trondeau.com wrote: Ben, Yes, I was definitely confused. I think this is promising. So you're saying that it gets populated by Doxygen markup that's already in the files? So we don't have to redo any of the documentation that we already have, right? Also, I've been adding Doxygen pages (.dox files) with more descriptions, examples, etc. into the Doxygen manual. I really like this way as it keeps things all together as part of the code and the automatically generated manual. If we can keep these as well, that's great. And I'm assuming that the subheaders like Signal Sources and Signal Sinks are taken from the \ingroup tags? Another thing that I've been doing with the Doxygen manual is keeping older versions of it alive on the website so that people can look at the manual for their particular version of GNU Radio (http://gnuradio.org/redmine/projects/gnuradio/wiki/Old-docs). So again, I'd like to be able to easily host these. Looking at your URL, it looks like it'll be simple. So yes, I say continue on this path. Taking what Martin and Michael said about fixing some of the structure/styling would really help it, too. Thanks! Tom On Thu, Mar 1, 2012 at 5:42 AM, Martin Braun martin.br...@kit.edu wrote: On Wed, Feb 29, 2012 at 08:05:46PM -0700, Ben Reynwar wrote: What I'm trying to do with this is to create some nice documentation that we can put online that serves as a reference for someone developing with gnuradio in python. I had a go at this last year, but didn't get very far, partly because the swig_doc stuff wasn't fully working. Now that the swig_docs is all sorted, it felt like a good time to push with the documentation again. Stuff that needs work is - (*args, **kwargs) appears for some blocks but for others it displays the parameters correctly. - sometimes it displays __dummy_0_ for parameter types - there a bunch of subpackages which I haven't touched yet It'll take a bit of work to get this done, and unless people are on board with the general concept of using sphinx to generate this documentation, it doesn't make sense for me to spend time doing it, which is why I'm bugging you all now with some half-finished documentation. I think it's great! Something like this is really missing, especially if you're used to browsing the official Python docs; in that case Sphinx is probably a sight you're used to. One thing I don't love is this: snip gnuradio.gr.glfsr_source_b Creates a glfsr_source_b blocksk. gnuradio.gr.glfsr_source_f Creates a glfsr_source_f block. gnuradio.gr.lfsr_32k_source_s Creates a lfsr_32k_source_s block. gnuradio.gr.nowull_source Creates a null_source block. gnuradio.gr.noise_source_c Createseates a noise_source_c block. gnuradio.gr.noise_source_f Creates a noise_source_fse_source_f block. /snip This contains zero information. To get to the interesting information, I have to first click the entry. If I try help(gr.glfsr_source_b) on my machine, I get the interesting part of the docs straight away (Galois LFSR pseudo-random source generating float outputs -1.0 - 1.0. instead of Creates a glfsr_source_b block). In the gr.digital package, this isn't quite as bad. Perhaps a documentation standard wouldn't be a bad idea (but none of this has anything to do with Sphinx, I guess ;). 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 mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman
Re: [Discuss-gnuradio] Documentation generation using Sphinx
On Thu, Mar 1, 2012 at 11:20 AM, Tom Rondeau t...@trondeau.com wrote: On Thu, Mar 1, 2012 at 12:16 PM, Ben Reynwar b...@reynwar.net wrote: Just to clarify, I'm not suggesting we get rid of the Doxygen documentation. I think it documents the C++ side of things really well. What I'm suggesting is that we have two sets of documentation. Doxygen-generated docs for the C++ stuff, and sphinx-generated docs for the python interface. It looks like you have all of the C++ blocks moved over into the Sphinx-generated docs, too, though, which duplicates what's in Doxygen. Having two sets of documentation seems a bit confusing to me, but I can see how a C++-only developer might get confused about stuff mentioned in the manual that's only available if using Python. So with the latter argument in mind, I guess we could (and maybe should) have separate documents for the two cases. Yeah, ideally it would be nice to have one set of documentation that covers the C++ and python levels, but I can't think of a way to do that, that doesn't do a bad job of one or the other. Creating two sets of documentation is the path of least resistance to finally getting a reference for the python interface out there. At the moment the subheaders are coming from the \ingroup tag indirectly, in that I use that them to generate the initial documentation, but it won't update automatically if they are changed. I think automating the documentation generation to the level where these would update automatically would complicate things more than it would help. I think Josh worked out in cmake how to regenerate the swigdoc output if any of the files are changed, so it seems like a similar thing should be applicable here, too. Although I generated the source files for sphinx to avoid tediousness, I also did a bunch of manual editing afterwards. There are lots of objects in the python modules that aren't swiged signal processing blocks and so don't have \ingroup tags, for example python hierarchical blocks, constellation objects, utility functions, and random internal stuff that is floating around in the module namespace. Automating the decision on whether to include or exclude these objects in the documentation, and what category to place them in would be non-trivial. This is why using a tool like epydoc does not work for us. At the moment, when the html is regenerated, the docstrings themselves will be updated, but the organization of the objects into categories will not change unless the sphinx source files have been manually edited. I'll continue extending and tidying up the documentation and let you know when it's at a more presentable point. Cheers, Ben Thanks, Tom On Thu, Mar 1, 2012 at 7:57 AM, Tom Rondeau t...@trondeau.com wrote: Ben, Yes, I was definitely confused. I think this is promising. So you're saying that it gets populated by Doxygen markup that's already in the files? So we don't have to redo any of the documentation that we already have, right? Also, I've been adding Doxygen pages (.dox files) with more descriptions, examples, etc. into the Doxygen manual. I really like this way as it keeps things all together as part of the code and the automatically generated manual. If we can keep these as well, that's great. And I'm assuming that the subheaders like Signal Sources and Signal Sinks are taken from the \ingroup tags? Another thing that I've been doing with the Doxygen manual is keeping older versions of it alive on the website so that people can look at the manual for their particular version of GNU Radio (http://gnuradio.org/redmine/projects/gnuradio/wiki/Old-docs). So again, I'd like to be able to easily host these. Looking at your URL, it looks like it'll be simple. So yes, I say continue on this path. Taking what Martin and Michael said about fixing some of the structure/styling would really help it, too. Thanks! Tom On Thu, Mar 1, 2012 at 5:42 AM, Martin Braun martin.br...@kit.edu wrote: On Wed, Feb 29, 2012 at 08:05:46PM -0700, Ben Reynwar wrote: What I'm trying to do with this is to create some nice documentation that we can put online that serves as a reference for someone developing with gnuradio in python. I had a go at this last year, but didn't get very far, partly because the swig_doc stuff wasn't fully working. Now that the swig_docs is all sorted, it felt like a good time to push with the documentation again. Stuff that needs work is - (*args, **kwargs) appears for some blocks but for others it displays the parameters correctly. - sometimes it displays __dummy_0_ for parameter types - there a bunch of subpackages which I haven't touched yet It'll take a bit of work to get this done, and unless people are on board with the general concept of using sphinx to generate this documentation, it doesn't make sense for me to spend time
Re: [Discuss-gnuradio] Documentation generation using Sphinx
On Thu, Mar 1, 2012 at 12:05 PM, Tom Rondeau t...@trondeau.com wrote: On Thu, Mar 1, 2012 at 2:00 PM, Ben Reynwar b...@reynwar.net wrote: On Thu, Mar 1, 2012 at 11:20 AM, Tom Rondeau t...@trondeau.com wrote: On Thu, Mar 1, 2012 at 12:16 PM, Ben Reynwar b...@reynwar.net wrote: At the moment the subheaders are coming from the \ingroup tag indirectly, in that I use that them to generate the initial documentation, but it won't update automatically if they are changed. I think automating the documentation generation to the level where these would update automatically would complicate things more than it would help. I think Josh worked out in cmake how to regenerate the swigdoc output if any of the files are changed, so it seems like a similar thing should be applicable here, too. Although I generated the source files for sphinx to avoid tediousness, I also did a bunch of manual editing afterwards. There are lots of objects in the python modules that aren't swiged signal processing blocks and so don't have \ingroup tags, for example python hierarchical blocks, constellation objects, utility functions, and random internal stuff that is floating around in the module namespace. Automating the decision on whether to include or exclude these objects in the documentation, and what category to place them in would be non-trivial. This is why using a tool like epydoc does not work for us. At the moment, when the html is regenerated, the docstrings themselves will be updated, but the organization of the objects into categories will not change unless the sphinx source files have been manually edited. Ok, I see. Is there a way to just stick all of these into an uncategorized section? We could then edit the offenders to give them a proper group. Tom I you're really keen on getting the block categorization automated then I'm sure I can come up with a way. Sphinx is extendable so I would probably create a new sphinx markup command that includes all the blocks for a given category. In this way the sphinx source file would still be manually edited if you want to add a new utility function, or python hierarchical block to the documentation but the swiged signal processing blocks would be added automatically. I'll continue extending and tidying up the documentation and let you know when it's at a more presentable point. Cheers, Ben Thanks, Tom On Thu, Mar 1, 2012 at 7:57 AM, Tom Rondeau t...@trondeau.com wrote: Ben, Yes, I was definitely confused. I think this is promising. So you're saying that it gets populated by Doxygen markup that's already in the files? So we don't have to redo any of the documentation that we already have, right? Also, I've been adding Doxygen pages (.dox files) with more descriptions, examples, etc. into the Doxygen manual. I really like this way as it keeps things all together as part of the code and the automatically generated manual. If we can keep these as well, that's great. And I'm assuming that the subheaders like Signal Sources and Signal Sinks are taken from the \ingroup tags? Another thing that I've been doing with the Doxygen manual is keeping older versions of it alive on the website so that people can look at the manual for their particular version of GNU Radio (http://gnuradio.org/redmine/projects/gnuradio/wiki/Old-docs). So again, I'd like to be able to easily host these. Looking at your URL, it looks like it'll be simple. So yes, I say continue on this path. Taking what Martin and Michael said about fixing some of the structure/styling would really help it, too. Thanks! Tom On Thu, Mar 1, 2012 at 5:42 AM, Martin Braun martin.br...@kit.edu wrote: On Wed, Feb 29, 2012 at 08:05:46PM -0700, Ben Reynwar wrote: What I'm trying to do with this is to create some nice documentation that we can put online that serves as a reference for someone developing with gnuradio in python. I had a go at this last year, but didn't get very far, partly because the swig_doc stuff wasn't fully working. Now that the swig_docs is all sorted, it felt like a good time to push with the documentation again. Stuff that needs work is - (*args, **kwargs) appears for some blocks but for others it displays the parameters correctly. - sometimes it displays __dummy_0_ for parameter types - there a bunch of subpackages which I haven't touched yet It'll take a bit of work to get this done, and unless people are on board with the general concept of using sphinx to generate this documentation, it doesn't make sense for me to spend time doing it, which is why I'm bugging you all now with some half-finished documentation. I think it's great! Something like this is really missing, especially
[Discuss-gnuradio] Documentation generation using Sphinx
Hi all, Every 6 months or so I have a crack at getting some python level documentation working. In this attempt, I've generated documentation for the gr and digital modules using sphinx. The generated html is at: http://www.reynwar.net/gnuradio/sphinx/ Source for the generated documentation is at: https://github.com/benreynwar/gnuradio/tree/sphinx/docs/sphinx/source The documentation generation is semi-automatic. I created files containing lists of the objects we want to document, and organized them into categories. The actual documentation itself was pulled from the docstrings automatically. It would be necessary to manually edit files when new blocks or other objects are added, so there is a danger that this kind of documentation could become incomplete, however because the content is taken from the docstrings it should remain accurate, if not complete. Are there any objections to me continuing down this path of documentation generation? Any suggestions? Cheers, Ben ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Documentation generation using Sphinx
On Wed, Feb 29, 2012 at 6:50 PM, Tom Rondeau t...@trondeau.com wrote: On Wed, Feb 29, 2012 at 3:26 PM, Ben Reynwar b...@reynwar.net wrote: Hi all, Every 6 months or so I have a crack at getting some python level documentation working. In this attempt, I've generated documentation for the gr and digital modules using sphinx. The generated html is at: http://www.reynwar.net/gnuradio/sphinx/ Source for the generated documentation is at: https://github.com/benreynwar/gnuradio/tree/sphinx/docs/sphinx/source The documentation generation is semi-automatic. I created files containing lists of the objects we want to document, and organized them into categories. The actual documentation itself was pulled from the docstrings automatically. It would be necessary to manually edit files when new blocks or other objects are added, so there is a danger that this kind of documentation could become incomplete, however because the content is taken from the docstrings it should remain accurate, if not complete. Are there any objections to me continuing down this path of documentation generation? Any suggestions? Cheers, Ben I'm a bit confused, Ben. What does this do that we aren't doing in the swig_docs work we put in last year? Tom The swig_doc stuff got all the documentation from doxygen into the python docstrings. What I'm trying to do with this is to create some nice documentation that we can put online that serves as a reference for someone developing with gnuradio in python. I had a go at this last year, but didn't get very far, partly because the swig_doc stuff wasn't fully working. Now that the swig_docs is all sorted, it felt like a good time to push with the documentation again. Stuff that needs work is - (*args, **kwargs) appears for some blocks but for others it displays the parameters correctly. - sometimes it displays __dummy_0_ for parameter types - there a bunch of subpackages which I haven't touched yet It'll take a bit of work to get this done, and unless people are on board with the general concept of using sphinx to generate this documentation, it doesn't make sense for me to spend time doing it, which is why I'm bugging you all now with some half-finished documentation. Cheers, Ben ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Detection and classification of signals
Hi all, I'm working an a little project using gnuradio for receiving ham radio psk31 signals. I can decode a signal given a rough estimate of the carrier frequency but I'd really like to take a big swath of bandwidth as the input, detect the psk31 signals, and decode them all in parallel. However I don't even know what search terms to use to find methods to detect the peaks, and make a guess as to whether they are psk31. What words should I be typing into my google searches? My naive first attempt would be to find the peaks in the intensity that have about the correct width and then try to decode them, but I thought there might be more robust techniques out there. Cheers, Ben ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Detection and classification of signals
Wicked, thank you. That'll go a long way towards getting me started. It's frustrating when you're so ignorant you don't even know which search terms to type in. On Tue, Feb 21, 2012 at 3:31 PM, Ben Hilburn b...@ettus.com wrote: I'll note that none of my suggestions are actual techniques, but just keywords that such techniques fall under. If anyone is aware of actual techniques for Ben to use, that would probably be more directly helpful. Cheers, Ben On Tue, Feb 21, 2012 at 2:30 PM, Ben Hilburn b...@ettus.com wrote: Ben - Searching for Automatic Modulation Classification (AMC), on Google or IEEExplore, will give you fairly good start =) Related terms may be: Peak Detection, Robust Statistics, and even Primary User Detection (from the cognitive radio side of things). Cheers, Ben On Tue, Feb 21, 2012 at 1:54 PM, Ben Reynwar b...@reynwar.net wrote: Hi all, I'm working an a little project using gnuradio for receiving ham radio psk31 signals. I can decode a signal given a rough estimate of the carrier frequency but I'd really like to take a big swath of bandwidth as the input, detect the psk31 signals, and decode them all in parallel. However I don't even know what search terms to use to find methods to detect the peaks, and make a guess as to whether they are psk31. What words should I be typing into my google searches? My naive first attempt would be to find the peaks in the intensity that have about the correct width and then try to decode them, but I thought there might be more robust techniques out there. Cheers, Ben ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] need help for digital.constellation_decoder_cb in release 3.5.0
On Thu, Dec 8, 2011 at 5:33 PM, Arturo Rinaldi arty.n...@gmail.com wrote: I noticed dramatic changes in the 3.5.0 release in the generation of the constellation points of digital modulations. So, if the easy part is to again modify the source code to match my needs, i need some help in using the new block : digital.constellation_decoder_cb(arg1) instead of gr.constellation_decoder(arg1,arg2) I usually used the last one where arg1 is a list containing the complex values of a generic digital modulation and arg2 is the symbol mapping (Gray Coding for instance). Which blocks do i need to put together to get the same result ? Regards, Arturo ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio Simplest solution is probably: constell = digital.digital_constellation(list_of_complex_points, [], 1, 1) decoder = digital.constellation_decoder_cb(constell) To get the symbol mapping you want, just choose the appropriate order of the complex points in the list. The 2nd, 3rd and 4th arguments to the constellation constructor while not relevant to this example are: - a mapping to be applied before differential encoding. - the rotational-symmetry of the constellation - the dimensionality of the constellation (i.e. number of complex points that together map to one symbol) Functions to simplify the creation of commonly used constellations can be found in digital.bpsk, digital.qpsk, digital.psk, and digital.qam. Ben ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Problem with new swig docs stuff
On Tue, Dec 6, 2011 at 3:51 PM, Josh Blum j...@ettus.com wrote: snip [ 47%] Generating general_swig_doc.i Error in xml in file /home/gr/source/git/gnuradio/build/gnuradio-core/src/lib/swig/general_swig_doc_swig_docs/xml/gr__simple__framer__sync_8h.xml Traceback (most recent call last): File /home/gr/source/git/gnuradio/docs/doxygen/swig_doc.py, line 253, in module make_swig_interface_file(di, swigdocfilename, custom_output=custom_output) File /home/gr/source/git/gnuradio/docs/doxygen/swig_doc.py, line 196, in make_swig_interface_file blocks = di.in_category(Block) File /home/gr/source/git/gnuradio/docs/doxygen/doxyxml/base.py, line 140, in in_category self.confirm_no_error() File /home/gr/source/git/gnuradio/docs/doxygen/doxyxml/base.py, line 206, in confirm_no_error self.check_parsed() File /home/gr/source/git/gnuradio/docs/doxygen/doxyxml/base.py, line 203, in check_parsed self._parse() File /home/gr/source/git/gnuradio/docs/doxygen/doxyxml/doxyindex.py, line 51, in _parse self._members += converted.members() File /home/gr/source/git/gnuradio/docs/doxygen/doxyxml/base.py, line 174, in members self.confirm_no_error() File /home/gr/source/git/gnuradio/docs/doxygen/doxyxml/base.py, line 206, in confirm_no_error self.check_parsed() File /home/gr/source/git/gnuradio/docs/doxygen/doxyxml/base.py, line 203, in check_parsed self._parse() File /home/gr/source/git/gnuradio/docs/doxygen/doxyxml/doxyindex.py, line 163, in _parse self.set_descriptions(self._retrieved_data.compounddef) AttributeError: 'NoneType' object has no attribute 'compounddef' make[2]: *** [gnuradio-core/src/lib/swig/general_swig_doc.i] Error 1 make[1]: *** [gnuradio-core/src/lib/swig/CMakeFiles/_gnuradio_core_filter.dir/all] Error 2 make: *** [all] Error 2 Tom/Ben, I think doxyindex.py may be relying on an xml field that older doxygen's do not define. Perhaps we could put a big try/catch around this in case it fails and print to stderr. That way the build keeps going, and its just a warning printed out in the terminal. -josh You're right, it clearly needs to be more robust. I'll have a look tonight. Ben ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] raised cosine filter taps implementation
PSK31 for ham radio uses a raised cosine filter rather than the RRC. On Mon, Nov 14, 2011 at 9:26 AM, Tom Rondeau trondeau1...@gmail.com wrote: On Mon, Nov 14, 2011 at 10:40 AM, Nowlan, Sean sean.now...@gtri.gatech.edu wrote: Because I need a raised cosine filter. If I convolve root raised cosine filter coefficients with themselves (generated with gr_firdes), do I need to apply a scaling factor? Ok, but my question was Why do you need a raised cosine filter? I'm just curious about what applications use this instead of RRC filters? Tom From: Tom Rondeau [mailto:trondeau1...@gmail.com] Sent: Monday, November 14, 2011 9:56 AM To: Nowlan, Sean Cc: discuss-gnuradio@gnu.org Subject: Re: [Discuss-gnuradio] raised cosine filter taps implementation On Sun, Nov 13, 2011 at 6:56 PM, Nowlan, Sean sean.now...@gtri.gatech.edu wrote: I want to add a raised cosine filter to gr_firdes.* in gnuradio/gnuradio-core/src/lib/general/. I see there's already a root-raised cosine there. After looking through a few sources, I have the following time-domain response of an RC filter: h(t) = [sin(pi * t / T_s) / (pi * t / T_s)] / [cos(pi * alpha * t / T_s) / (1 - (2 * alpha * t / T_s )^2 )] As far as I can tell, I should be able to compute the taps using: for n = -FLOOR(ntaps/2) to FLOOR(ntaps/2), do h(n) = [sin(pi * n) / (pi * n)] / [cos(pi * alpha * n) / (1 - (2 * alpha * n)^2 )] end_for The things I'll have to worry about: 1) if n is 0: h(n) = 1 2) if n is +/- 1/(2 * alpha): h(n) = (1 / (8 * alpha) ) * sin(pi / (2 * alpha) ) #I think I did this right... 3) rounding errors: not sure what to do here given we're operating with floats. Any tips/suggestions? Thanks, Sean Sean, We've gotten this question before, and I'm again curious why you want a raised cosine filter? If you really are using it for something, the easiest thing to do is just create a root raised cosine filter and convolve it with itself. 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] raised cosine filter taps implementation
On Mon, Nov 14, 2011 at 10:03 AM, Tom Rondeau trondeau1...@gmail.com wrote: On Mon, Nov 14, 2011 at 12:01 PM, Ben Reynwar b...@reynwar.net wrote: PSK31 for ham radio uses a raised cosine filter rather than the RRC. Interesting. Thanks. Do you know why the do it? Do they just have the filter on one side? Tom I don't think it's for any good reason. The raised cosine filter is on the transmit side and I guess you can put whatever you want on the receive side. I would have thought another raised cosine filter on the receiver side was the best way to go to maximise the signal and then deal with the ISI afterwards. I haven't looked at other peoples code to see how they're doing it. On Mon, Nov 14, 2011 at 9:26 AM, Tom Rondeau trondeau1...@gmail.com wrote: On Mon, Nov 14, 2011 at 10:40 AM, Nowlan, Sean sean.now...@gtri.gatech.edu wrote: Because I need a raised cosine filter. If I convolve root raised cosine filter coefficients with themselves (generated with gr_firdes), do I need to apply a scaling factor? Ok, but my question was Why do you need a raised cosine filter? I'm just curious about what applications use this instead of RRC filters? Tom From: Tom Rondeau [mailto:trondeau1...@gmail.com] Sent: Monday, November 14, 2011 9:56 AM To: Nowlan, Sean Cc: discuss-gnuradio@gnu.org Subject: Re: [Discuss-gnuradio] raised cosine filter taps implementation On Sun, Nov 13, 2011 at 6:56 PM, Nowlan, Sean sean.now...@gtri.gatech.edu wrote: I want to add a raised cosine filter to gr_firdes.* in gnuradio/gnuradio-core/src/lib/general/. I see there's already a root-raised cosine there. After looking through a few sources, I have the following time-domain response of an RC filter: h(t) = [sin(pi * t / T_s) / (pi * t / T_s)] / [cos(pi * alpha * t / T_s) / (1 - (2 * alpha * t / T_s )^2 )] As far as I can tell, I should be able to compute the taps using: for n = -FLOOR(ntaps/2) to FLOOR(ntaps/2), do h(n) = [sin(pi * n) / (pi * n)] / [cos(pi * alpha * n) / (1 - (2 * alpha * n)^2 )] end_for The things I'll have to worry about: 1) if n is 0: h(n) = 1 2) if n is +/- 1/(2 * alpha): h(n) = (1 / (8 * alpha) ) * sin(pi / (2 * alpha) ) #I think I did this right... 3) rounding errors: not sure what to do here given we're operating with floats. Any tips/suggestions? Thanks, Sean Sean, We've gotten this question before, and I'm again curious why you want a raised cosine filter? If you really are using it for something, the easiest thing to do is just create a root raised cosine filter and convolve it with itself. 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] raised cosine filter taps implementation
On Mon, Nov 14, 2011 at 11:11 AM, Tom Rondeau trondeau1...@gmail.com wrote: On Mon, Nov 14, 2011 at 1:09 PM, Ben Reynwar b...@reynwar.net wrote: On Mon, Nov 14, 2011 at 10:03 AM, Tom Rondeau trondeau1...@gmail.com wrote: On Mon, Nov 14, 2011 at 12:01 PM, Ben Reynwar b...@reynwar.net wrote: PSK31 for ham radio uses a raised cosine filter rather than the RRC. Interesting. Thanks. Do you know why the do it? Do they just have the filter on one side? Tom I don't think it's for any good reason. The raised cosine filter is on the transmit side and I guess you can put whatever you want on the receive side. I would have thought another raised cosine filter on the receiver side was the best way to go to maximise the signal and then deal with the ISI afterwards. I haven't looked at other peoples code to see how they're doing it. I would have figured it was on the Tx side for bandwidth control, and you could do various things on the receiver side with that. It's of course why we normally use RRC filters though; restrict the transmitted signal bandwidth, then the receive RRC does both a matched filter and creates Nyquist pulses (ignoring multipath). Tom Yep. I meant that I don't think there was a good reason for the author of PSK31 choosing raised cosine over RRC. On Mon, Nov 14, 2011 at 9:26 AM, Tom Rondeau trondeau1...@gmail.com wrote: On Mon, Nov 14, 2011 at 10:40 AM, Nowlan, Sean sean.now...@gtri.gatech.edu wrote: Because I need a raised cosine filter. If I convolve root raised cosine filter coefficients with themselves (generated with gr_firdes), do I need to apply a scaling factor? Ok, but my question was Why do you need a raised cosine filter? I'm just curious about what applications use this instead of RRC filters? Tom From: Tom Rondeau [mailto:trondeau1...@gmail.com] Sent: Monday, November 14, 2011 9:56 AM To: Nowlan, Sean Cc: discuss-gnuradio@gnu.org Subject: Re: [Discuss-gnuradio] raised cosine filter taps implementation On Sun, Nov 13, 2011 at 6:56 PM, Nowlan, Sean sean.now...@gtri.gatech.edu wrote: I want to add a raised cosine filter to gr_firdes.* in gnuradio/gnuradio-core/src/lib/general/. I see there's already a root-raised cosine there. After looking through a few sources, I have the following time-domain response of an RC filter: h(t) = [sin(pi * t / T_s) / (pi * t / T_s)] / [cos(pi * alpha * t / T_s) / (1 - (2 * alpha * t / T_s )^2 )] As far as I can tell, I should be able to compute the taps using: for n = -FLOOR(ntaps/2) to FLOOR(ntaps/2), do h(n) = [sin(pi * n) / (pi * n)] / [cos(pi * alpha * n) / (1 - (2 * alpha * n)^2 )] end_for The things I'll have to worry about: 1) if n is 0: h(n) = 1 2) if n is +/- 1/(2 * alpha): h(n) = (1 / (8 * alpha) ) * sin(pi / (2 * alpha) ) #I think I did this right... 3) rounding errors: not sure what to do here given we're operating with floats. Any tips/suggestions? Thanks, Sean Sean, We've gotten this question before, and I'm again curious why you want a raised cosine filter? If you really are using it for something, the easiest thing to do is just create a root raised cosine filter and convolve it with itself. 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] raised cosine filter taps implementation
On Mon, Nov 14, 2011 at 11:21 AM, Ben Reynwar b...@reynwar.net wrote: On Mon, Nov 14, 2011 at 11:11 AM, Tom Rondeau trondeau1...@gmail.com wrote: On Mon, Nov 14, 2011 at 1:09 PM, Ben Reynwar b...@reynwar.net wrote: On Mon, Nov 14, 2011 at 10:03 AM, Tom Rondeau trondeau1...@gmail.com wrote: On Mon, Nov 14, 2011 at 12:01 PM, Ben Reynwar b...@reynwar.net wrote: PSK31 for ham radio uses a raised cosine filter rather than the RRC. Interesting. Thanks. Do you know why the do it? Do they just have the filter on one side? Tom I don't think it's for any good reason. The raised cosine filter is on the transmit side and I guess you can put whatever you want on the receive side. I would have thought another raised cosine filter on the receiver side was the best way to go to maximise the signal and then deal with the ISI afterwards. I haven't looked at other peoples code to see how they're doing it. I would have figured it was on the Tx side for bandwidth control, and you could do various things on the receiver side with that. It's of course why we normally use RRC filters though; restrict the transmitted signal bandwidth, then the receive RRC does both a matched filter and creates Nyquist pulses (ignoring multipath). Tom Yep. I meant that I don't think there was a good reason for the author of PSK31 choosing raised cosine over RRC. I just remembered it's raised cosine in time not raised cosine in frequency space, and so completely different from what the original question was about. Oh well. Cheers, Ben On Mon, Nov 14, 2011 at 9:26 AM, Tom Rondeau trondeau1...@gmail.com wrote: On Mon, Nov 14, 2011 at 10:40 AM, Nowlan, Sean sean.now...@gtri.gatech.edu wrote: Because I need a raised cosine filter. If I convolve root raised cosine filter coefficients with themselves (generated with gr_firdes), do I need to apply a scaling factor? Ok, but my question was Why do you need a raised cosine filter? I'm just curious about what applications use this instead of RRC filters? Tom From: Tom Rondeau [mailto:trondeau1...@gmail.com] Sent: Monday, November 14, 2011 9:56 AM To: Nowlan, Sean Cc: discuss-gnuradio@gnu.org Subject: Re: [Discuss-gnuradio] raised cosine filter taps implementation On Sun, Nov 13, 2011 at 6:56 PM, Nowlan, Sean sean.now...@gtri.gatech.edu wrote: I want to add a raised cosine filter to gr_firdes.* in gnuradio/gnuradio-core/src/lib/general/. I see there's already a root-raised cosine there. After looking through a few sources, I have the following time-domain response of an RC filter: h(t) = [sin(pi * t / T_s) / (pi * t / T_s)] / [cos(pi * alpha * t / T_s) / (1 - (2 * alpha * t / T_s )^2 )] As far as I can tell, I should be able to compute the taps using: for n = -FLOOR(ntaps/2) to FLOOR(ntaps/2), do h(n) = [sin(pi * n) / (pi * n)] / [cos(pi * alpha * n) / (1 - (2 * alpha * n)^2 )] end_for The things I'll have to worry about: 1) if n is 0: h(n) = 1 2) if n is +/- 1/(2 * alpha): h(n) = (1 / (8 * alpha) ) * sin(pi / (2 * alpha) ) #I think I did this right... 3) rounding errors: not sure what to do here given we're operating with floats. Any tips/suggestions? Thanks, Sean Sean, We've gotten this question before, and I'm again curious why you want a raised cosine filter? If you really are using it for something, the easiest thing to do is just create a root raised cosine filter and convolve it with itself. 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] Building on Mac OSX
On Wed, Oct 26, 2011 at 8:44 AM, Jeff Scaparra j...@scaparra.com wrote: Hello, I have almost gotten all the dependencies needed for gnuradio recognized however I have qt qwt and wx installed but they aren't being recognized by cmake. I have also tried to manually enable them with the -DENABLE_GR_QTGUI AND -DENABLE_GR_WXGUI options with no luck. I have used homebrew to install almost all of the dependencies and it has been a great help. If anyone have any experience building gnuradio on OSX I would appreciate any input. Thanks, Jeff (KK4EPP) ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio If you're not using homebrew for anything else, it's probably easier just to switch to using macports. I had a good crack at getting gnuradio installed via homebrew but switched to macports in the end because I couldn't get the gui stuff working. Cheers, Ben ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] gr-trellis broken on next branch
The block I added into gr-trellis is trellis_constellation_metrics_cf. This block is equivalent to trellis_metrics_c in that it takes a stream of symbols and outputs a stream of metrics. The difference is that treliis_constellation_metrics_cf uses a constellation object (which is passed to it upon initialisation) to perform the symbol to metrics conversion. trellis_metrics_c calculates the distance between each symbol and each constellation point, which could clearly be improved upon by the modulation specific method in a constellation object, especially for large constellations. The constellation classes themselves are defined in gr-digital, so all modulation specific code would be contained in gr-digital. The dependency on gr-digital enables modulation specific code to be accessed by the gr-trellis code without requiring that modulation specific code be in gr-trellis itself. I think that's a pretty logical arrangement. from gnuradio import digital, trellis constellation = digital.qam.qam_constellation(16) symbols_to_metrics = trellis.constellation_metrics_cf(constellation, digital.TRELLIS_EUCLIDEAN) Although currently there's just the one block with a dependency on gr-digital, going forward it might be nice to have combined blocks using constellation objects, so I would be disinclined to move it out of gr-trellis. Cheers, Ben On Fri, Oct 21, 2011 at 1:06 PM, Achilleas Anastasopoulos anas...@umich.edu wrote: Tom, this requires some further discussion. We need to know what is the plan with gr-digital. In some sense EVERYTHING can be included in there, however this is not a good design. gr-trellis is not an implementation of digital modulation; it provides digital encoding/decoding techniques that is important to keep modulation INDEPENDENT. This was the design philosophy from the first line of code that went into this and can be seen in all the examples that are provided: the only aspect of these examples that depends on a specific modulation is the lookuptable of the constellation. I would like to welcome more users/developers to comment on this before we make any significant changes to the module. best, Achilleas On 10/21/2011 3:19 PM, Tom Rondeau wrote: On Thu, Oct 20, 2011 at 10:34 PM, Achilleas Anastasopoulos anas...@umich.edu mailto:anas...@umich.edu wrote: After installing the next branch i realized that gr-trellis is not working properly! This is due to some work (by Ben Raynwar) that makes gr-trellis dependent on gr-digital (???) In particular the constants related to trellis_metric_type.h cannot be accessed in python/grc as part of the trellis module, but as part of the digital module (this problem appears for instance if you run some of the pccc/sccc examples in gnuradio-examples/grc/trellis). This can be an easy fix (import digital in all the grc blocks requiring metric types, and make appropriate changes). However I wonder what is the point of making a self-contained module like gr-trellis dependent on another module (gr-digital) If the only reason is to to use the constellation object in the metrics blocks then these blocks should reside in the gr-digital module instead of the gr-trellis, so that the latter can still be self-contained. Ben, can you please explain what is your rational in doing these changes. thanks, Achilleas Achilleas, This was my doing. Ben had moved the metric types into gnuradio-core to work with his constellation work, so I moved them over with everything else into gr-digital. I then made gr-trellis depend on gr-digital because of this. Because gr-trellis is an implementation of digital modulation, it makes sense that it should depend on gr-digital. I made sure that gr-trellis would both build and pass 'make check,' so the QA code is obviously not testing all of the proper dependencies and cases in gr-trellis. We need to fix that to make sure the applications still run as we move stuff around. Depending on what gr-trellis requires out of gr-digital, we could possibly import digital into the trellis module inside of the __init__.py file. 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] Ben's docstring work
I've made a few changes to doxyxml so that the DoxyFile objects should
be exposing their descriptions and have changed swig_doc.py so that
it's grabbing documentation from the file if it is present. It
doesn't appear to be picking any file descriptions up and I'm not sure
if that's because it's not working or because there aren't any. If
you know of some good blocks to test it on let me know.
commit is
https://github.com/benreynwar/gnuradio/commit/d6e36498174dcb20f92369cc6097514a5d102ded
At the moment the layout for a docstring for a python creator function:
brief description from class
detailed description from class
brief description from make func
detailed description from make func
brief description from file
detailed description from file
Params: (list of input parameters)
The docstring for the class itself is the same without the parameter
list at the end.
Cheers,
Ben
On Mon, Oct 17, 2011 at 9:36 AM, Josh Blum j...@joshknows.com wrote:
Ahhh much better. I added generation for a few of the components in core
(general, gengen, filter, io)
http://gnuradio.org/cgit/jblum.git/commit/?h=swig_docsid=d65572359a74e97ee6a01d89dcc44fd77ce54fef
Basically, its pretty nice. The xml only regenerates when header files
change, and the swig docs.i only regenerate when the xml is changed, and
so on. No checked-in generated files. XML generation is very quick. Your
python script actually takes a bit longer (but im not complaining). :-)
I would like to get the grc docs parser looking for __doc__ strings soon.
A few comments on your doc generator. Im not sure we agree on a standard
here for documenting headers... but useful doc blocks may be in several
places in the header:
1) docs for the factor/make function
2) docs for class definition
3) docs just in the header, think \file
It looks like the generated docstrings only gets one of these. I suggest
concatenating all forms of docs into the one class docstring so the full
amount of docs is available at runtime to python.
-Josh
It was the position of the %include swig_doc.i in the digital_swig.i file.
It needs to be at the top rather than at the bottom.
Here's a diff.
diff --git a/gr-digital/swig/digital_swig.i b/gr-digital/swig/digital_swig.i
index c804b5c..f6372b1 100644
--- a/gr-digital/swig/digital_swig.i
+++ b/gr-digital/swig/digital_swig.i
@@ -23,6 +23,8 @@
%include gri_control_loop.i
+%include swig_doc.i
+
%{
#include digital_binary_slicer_fb.h
#include digital_clock_recovery_mm_cc.h
@@ -59,8 +61,6 @@
%include digital_cpmmod_bc.i
%include digital_gmskmod_bc.i
-%include swig_doc.i
-
#if SWIGGUILE
%scheme %{
(load-extension-global libguile-gnuradio-digital_swig
scm_init_gnuradio_digital_swig_module)
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Ben's docstring work
On Sat, Oct 15, 2011 at 10:58 PM, Ben Reynwar b...@reynwar.net wrote: On Sat, Oct 15, 2011 at 4:16 PM, Josh Blum j...@joshknows.com wrote: Hi Josh, The docstrings should be accessible using the __doc__ property in the normal way. If you look at the generated python file the docstrings should be present in the function and class definitions as usual. e.g. def kurtolic_equalizer_cc(blah blah): docstring here blah blah blah If that's not happening, then it's not working. Looks like i did it wrong then. But I cant see anything wrong with the process. :-) python -c from gnuradio import digital; print digital.kurtotic_equalizer_cc.__doc__ kurtotic_equalizer_cc(int num_taps, float mu) - digital_kurtotic_equalizer_cc_sptr I cloned your repo and checked out your swig_docs branch but got a compilation error. [ 46%] Generating gengen/gr_peak_detector_fb.i, gengen/gr_peak_detector_ib.i, gengen/gr_peak_detector_sb.i [ 51%] Built target gengen_generated [ 51%] Swig source [ 52%] Swig source /home/ben/gnuradio-jblum/jblum/gnuradio-core/src/lib/gengen/gengen.i:33: Error: Unable to find 'gengen_generated.i' make[2]: *** [gnuradio-core/src/lib/swig/gnuradio_core_gengenPYTHON_wrap.cxx] Error 1 make[1]: *** [gnuradio-core/src/lib/swig/CMakeFiles/_gnuradio_core_filter.dir/all] Error 2 make: *** [all] Error 2 Ah, yea, I fixed that this morning but forgot to push. Just re-checkout the repo. -Josh So, it's a bug in swig_doc.py, but I haven't worked out where yet.. It should be generating a docstring for kurtotic_equalizer_cc, but it is generating it for digital_make_kurtotic_equalizer_cc instead. There's some stuff in swig_doc.py that determines whether a class or function is part of a Block or just a normal class or function. That appears to be not working. I'll see if I can work out why not. Nope, that wasn't the problem. I have no idea why it's not working. I'll have another look at it tomorrow night. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Ben's docstring work
On Sat, Oct 15, 2011 at 11:33 PM, Josh Blum j...@joshknows.com wrote:
On 10/15/2011 11:30 PM, Ben Reynwar wrote:
On Sat, Oct 15, 2011 at 10:58 PM, Ben Reynwar b...@reynwar.net wrote:
On Sat, Oct 15, 2011 at 4:16 PM, Josh Blum j...@joshknows.com wrote:
Hi Josh,
The docstrings should be accessible using the __doc__ property in the
normal way.
If you look at the generated python file the docstrings should be
present in the function and class definitions as usual.
e.g.
def kurtolic_equalizer_cc(blah blah):
docstring here
blah blah blah
If that's not happening, then it's not working.
Looks like i did it wrong then. But I cant see anything wrong with the
process. :-)
python -c from gnuradio import digital; print
digital.kurtotic_equalizer_cc.__doc__
kurtotic_equalizer_cc(int num_taps, float mu) -
digital_kurtotic_equalizer_cc_sptr
I cloned your repo and checked out your swig_docs branch but got a
compilation error.
[ 46%] Generating gengen/gr_peak_detector_fb.i,
gengen/gr_peak_detector_ib.i, gengen/gr_peak_detector_sb.i
[ 51%] Built target gengen_generated
[ 51%] Swig source
[ 52%] Swig source
/home/ben/gnuradio-jblum/jblum/gnuradio-core/src/lib/gengen/gengen.i:33:
Error: Unable to find 'gengen_generated.i'
make[2]: ***
[gnuradio-core/src/lib/swig/gnuradio_core_gengenPYTHON_wrap.cxx]
Error 1
make[1]: ***
[gnuradio-core/src/lib/swig/CMakeFiles/_gnuradio_core_filter.dir/all]
Error 2
make: *** [all] Error 2
Ah, yea, I fixed that this morning but forgot to push. Just re-checkout
the repo.
-Josh
So, it's a bug in swig_doc.py, but I haven't worked out where yet..
It should be generating a docstring for kurtotic_equalizer_cc, but
it is generating it for digital_make_kurtotic_equalizer_cc instead.
There's some stuff in swig_doc.py that determines whether a class or
function is part of a Block or just a normal class or function.
That appears to be not working. I'll see if I can work out why not.
It wouldnt be so bad to parameterize the package name for swig_doc.py.
Each invocation of the generation macro would just need to pass this
package name into the python script like so:
python swig_doc.py $builddir/gr-digital/swig/doxygen/xml
$builddir/gr-digital/swig/swig_doc.i digital
... if that makes life easier
Nope, that wasn't the problem. I have no idea why it's not working.
I'll have another look at it tomorrow night.
ok cool
im looking forward to generating docs for each package, and getting grc
to read the docstrings rather than the xml
It was the position of the %include swig_doc.i in the digital_swig.i file.
It needs to be at the top rather than at the bottom.
Here's a diff.
diff --git a/gr-digital/swig/digital_swig.i b/gr-digital/swig/digital_swig.i
index c804b5c..f6372b1 100644
--- a/gr-digital/swig/digital_swig.i
+++ b/gr-digital/swig/digital_swig.i
@@ -23,6 +23,8 @@
%include gri_control_loop.i
+%include swig_doc.i
+
%{
#include digital_binary_slicer_fb.h
#include digital_clock_recovery_mm_cc.h
@@ -59,8 +61,6 @@
%include digital_cpmmod_bc.i
%include digital_gmskmod_bc.i
-%include swig_doc.i
-
#if SWIGGUILE
%scheme %{
(load-extension-global libguile-gnuradio-digital_swig
scm_init_gnuradio_digital_swig_module)
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
