On 08/30/2011 06:01 PM,
discuss-gnuradio-request@gnu.org wrote:
> Send Discuss-gnuradio mailing list submissions to
>
discuss-gnuradio@gnu.org>
> To subscribe or unsubscribe via the World Wide Web, visit
>
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio> or, via email, send a message with subject or body 'help' to
>
discuss-gnuradio-request@gnu.org>
> You can reach the person managing the list at
>
discuss-gnuradio-owner@gnu.org>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of Discuss-gnuradio digest..."
>
>
> Today's Topics:
>
> 1. Re: minor bug (Tom Rondeau)
> 2. Re: minor bug (Tom Rondeau)
> 3. Re: Two instances of QT GUI Sink in a single program (Tom Rondeau)
> 4. Conference Update (Tom Rondeau)
> 5. How to use gr.buffer (Zhonghua)
> 6. Re: How to use gr.buffer (Martin Braun)
> 7. sampling rate of USRP2 (Marcin Szelest)
> 8. Re: sampling rate of USRP2 (Nick Foster)
> 9. GNU Radio Conference 2011 (Tuan (Johnny) Ta)
> 10. Re: GNU Radio Conference 2011 (Marcus D. Leech)
> 11. Re: GNU Radio Conference 2011 (Patrik Tast)
> 12. Re: GNU Radio Conference 2011 (Tuan (Johnny) Ta)
> 13. Re: GNU Radio Conference 2011 (Tuan (Johnny) Ta)
> 14. Diagnostics for N210 (Gregory Perry)
> 15. Re: GNU Radio Conference 2011 (Martin Braun)
> 16. Re: GNU Radio Conference 2011 (Tuan (Johnny) Ta)
> 17. Re: GNU Radio Conference 2011 (Scott Johnston)
> 18. Re: GNU Radio Conference 2011 (Tuan (Johnny) Ta)
> 19. Re: GNU Radio Conference 2011 (Tom Rondeau)
> 20. Re: GNU Radio Conference 2011 (Tom Rondeau)
> 21. Re: GNU Radio Conference 2011 (Tom Rondeau)
> 22. "superblock" concept / idea (Michael Dickens)
> 23. Re: "superblock" concept / idea (Nick Foster)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Mon, 29 Aug 2011 12:00:54 -0400
> From: Tom Rondeau<
trondeau1122@gmail.com>
> To: Dimitris Symeonidis<
azimout@gmail.com>
> Cc: DiscussGnuRadio<
discuss-gnuradio@gnu.org>
> Subject: Re: [Discuss-gnuradio] minor bug
> Message-ID:
> <CANc0s2PWuJ=eqB+VY8R4PH+xziPWQntouXM27KLEarq=
03sNLw@mail.gmail.com>
> Content-Type: text/plain; charset=ISO-8859-1
>
> On Sun, Aug 28, 2011 at 12:08 PM, Dimitris Symeonidis<
azimout@gmail.com> wrote:
>> On 27 August 2011 23:10, Tom Rondeau<
trondeau1122@gmail.com> wrote:
>>> On Fri, Aug 26, 2011 at 10:00 AM, Dimitris Symeonidis<
azimout@gmail.com> wrote:
>>>> I noticed that the "docs" component passes the configuration tests
>>>> even without doxygen installed. This on Ubuntu 11.04, latest gnuradio
>>>> from git master.
>>> That might actually be on purpose, since there is more in the docs
>>> than just the Doxygen-generated stuff. Does this generate and failures
>>> during make, make check, or make distcheck for you?
>> No, no errors in make&& make check.
>>
>> Make distcheck gives me an (irrelevant) error in gnuradio-core/src/lib/swig:
>> *** No rule to make target `guile/gnuradio_core_filter.cc', needed by
>> `distdir'. ?Stop.
>> Is this just me?
> This is a bit of an annoyance with some of the Guile support added
> late last year. To run make distcheck, you need to add
> "--enable-guile" to the configure line. The Guile build isn't
> necessary at other times, and it removes the need for guile-dev as a
> dependency. If you are running make distcheck, you'll need guile-dev
> and to enable it. Since most people in their daily lives don't need to
> do a distcheck, we haven't really said anything about it. Thanks for
> checking into it, though.
>
>>>> Also, it seems fort77 is no longer a dependency, not sure when it went away...
>>> Yeah, I don't recall why we had fort77 as a dependency. If it really
>>> isn't necessary, it shouldn't be listed.
>> This used to be required in order for ./configure to check for the
>> existence of the python headers (python-dev), or else ./configure
>> would claim that Python.h is missing.
>> Here's what I blogged almost exactly 2 years ago about this:
>>
http://sdrblog.wordpress.com/2009/08/22/building-from-source-now-also-needs-fortran-compiler/> It's probably a good thing to keep in the dependency list, then, since
> people are still working on older systems where this might cause a
> problem.
>
> Thanks!
> Tom
>
>
>>>> Have a nice weekend
>>>>
>>>> Dimitrios Symeonidis
>>>> "If you think you're too small to make a difference, try sleeping with
>>>> a mosquito!" - Amnesty International
>>>>
>>>> _______________________________________________
>>>> Discuss-gnuradio mailing list
>>>>
Discuss-gnuradio@gnu.org>>>>
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio>>>>
>>
>> Dimitrios Symeonidis
>> "If you think you're too small to make a difference, try sleeping with
>> a mosquito!" - Amnesty International
>>
>
>
> ------------------------------
>
> Message: 2
> Date: Mon, 29 Aug 2011 12:19:14 -0400
> From: Tom Rondeau<
trondeau1122@gmail.com>
> To: Dimitris Symeonidis<
azimout@gmail.com>
> Cc: DiscussGnuRadio<
discuss-gnuradio@gnu.org>
> Subject: Re: [Discuss-gnuradio] minor bug
> Message-ID:
> <
CANc0s2Od+6udWCNXZ9d_9pAdGcUdo_h0u9qkK_ZAiS5dE-uY9g@mail.gmail.com>
> Content-Type: text/plain; charset=ISO-8859-1
>
> On Sun, Aug 28, 2011 at 6:09 PM, Dimitris Symeonidis<
azimout@gmail.com> wrote:
>> Tom, I tried some more to clean up the dependencies list on Ubuntu.
>>
>> I found a few dependencies that we were installing that don't seem to
>> be needed. ./configure, make and make check pass without errors. Can
>> you please confirm that in fact they are not necessary? Thanks!
>> * guile and guile-1.8-dev
> I think we removed the need for the guile dependency fairly recently,
> but it's still required in the older releases of GNU Radio. As I
> mentioned in my last email, the guile-dev is required for distcheck
> and to access the Guile build system (it's an undocumented way of
> making static flowgraphs in scheme instead of Python). It's not a
> requirement for everyone, though.
>
>> * python-opengl
>> * pyqt4-dev-tools and qt4-dev-tools
>> * libqwtplot3d-qt4-dev
> I'm not sure if the opengl is really necessary or not. We can probably
> get rid of it, but would have to make sure it doesn't impact older
> systems/releases in some way. I don't know the specific requirements
> for it to say for certain.
>
> The QT dev tools are needed if you want to build any QT-based systems.
> So while they might not be necessary to install GNU Radio, they are
> necessary if you are doing anything with gr-qtgui. We could
> potentially remove them as dependencies and put in proper checks and
> warnings when people want to make anything in gr-qtgui.
>
> The qwtplot3d requirements have been removed. But, again, it was
> necessary with older releases, so it should be mentioned for those.
>
>> What's more, there are a few dependencies that don't need to be stated
>> explicitly, as they get pulled in automatically by other packages we
>> install:
>> * libpulse-dev (pulled in by libsdl1.2-dev)
>> * sdcc-libraries (pulled in by sdcc)
>> * libqt4-dev (pulled in by libqwt5-qt4-dev)
>> * libqtcore4 (pulled in by python-qwt5-qt4)
> Agreed that they don't need to be stated explicitly. But it's probably
> a good thing that they are. First, things might change in how they are
> pulled in. Not likely, but it's possible, and since we require them,
> they should be listed. But some of these things are not "requirements"
> for a working GNU Radio installation. Perhaps some of these should be
> removed from the required list. We could have a "Required" dependency
> list and "Recommended" dependency list.
>
>> Finally, there are three dependencies of gr-qtgui that are not checked
>> by ./configure (i.e. configure passes, but make fails):
>> * libfontconfig1-dev
>> * libxrender-dev
>> * libxi-dev
> That's definitely a potential problem and should be addressed.
>
> So here's a few thoughts on this (Josh and Johnathan, please pay
> attention here!). It's likely that we are going to move to using cmake
> soon. I'm not really too interested in making any significant changes
> to the build system or dependency list until we make the decision to
> go with cmake or stay with autotools. When that happens, though,
> here's what we need to thing about:
>
> 1. There are some dependencies that we require that we could probably
> do without. The guile and guile-dev stuff needs to be looked into.
> First, can we get rid of guile as a dependency? Can we fix the issue
> of guile-dev in cmake?
> 2. Figure out if we need python-opengl or not
> 3. Remove requirements for QT dev tools but throw proper warnings
> where they are needed after installation.
> 4. Fix the checks for the missing packages in qtgui.
> 5. Think about making a "recommended" dependency list so that fewer
> dependency _have_ to be installed for a working system.
>
> It's important to keep in mind that we still have older versions of
> OSes and GNU Radio about that have different dependency requirements.
> I think the webpage list should encompass the maximum possible overlap
> for any given system. While we are trimming down some dependencies,
> that's often very new (like just in the git repo code), so we can't
> remove these dependencies from the list based on that.
>
> I also don't want to get into a mode of separating the "git" version
> from the "release" version of the software, nor even differences
> between releases. That would start to get things way too cluttered, I
> think, and right now, they are close enough that it's not too bad to
> ask people to pull in all of them. If things diverge a lot, we can
> rethink this policy.
>
> On a desktop/laptop system, we have so much space these days and
> Internet speeds are constantly increasing, so I don't think that
> having more dependencies than are absolutely required is too much of a
> burden. Those working with older or more limited systems, I hope are
> also savvy enough with their systems to understand it and make their
> own choices. This would be helped by separating into a "required" and
> "recommended" list of dependencies (I say recommended as opposed to
> optional because, while they are optional, it's highly recommended to
> use them all).
>
> Thanks for pointing all of this out, Dimitrios.
>
> Tom
>
>
>> Dimitrios Symeonidis
>> "If you think you're too small to make a difference, try sleeping with
>> a mosquito!" - Amnesty International
>>
>>
>>
>> On 28 August 2011 18:08, Dimitris Symeonidis<
azimout@gmail.com> wrote:
>>> On 27 August 2011 23:10, Tom Rondeau<
trondeau1122@gmail.com> wrote:
>>>> On Fri, Aug 26, 2011 at 10:00 AM, Dimitris Symeonidis<
azimout@gmail.com> wrote:
>>>>> I noticed that the "docs" component passes the configuration tests
>>>>> even without doxygen installed. This on Ubuntu 11.04, latest gnuradio
>>>>> from git master.
>>>> That might actually be on purpose, since there is more in the docs
>>>> than just the Doxygen-generated stuff. Does this generate and failures
>>>> during make, make check, or make distcheck for you?
>>> No, no errors in make&& make check.
>>>
>>> Make distcheck gives me an (irrelevant) error in gnuradio-core/src/lib/swig:
>>> *** No rule to make target `guile/gnuradio_core_filter.cc', needed by
>>> `distdir'. ?Stop.
>>> Is this just me?
>>>
>>>>> Also, it seems fort77 is no longer a dependency, not sure when it went away...
>>>> Yeah, I don't recall why we had fort77 as a dependency. If it really
>>>> isn't necessary, it shouldn't be listed.
>>> This used to be required in order for ./configure to check for the
>>> existence of the python headers (python-dev), or else ./configure
>>> would claim that Python.h is missing.
>>> Here's what I blogged almost exactly 2 years ago about this:
>>>
http://sdrblog.wordpress.com/2009/08/22/building-from-source-now-also-needs-fortran-compiler/>>>
>>>> Thanks!
>>>> Tom
>>>>
>>>>
>>>>> Have a nice weekend
>>>>>
>>>>> Dimitrios Symeonidis
>>>>> "If you think you're too small to make a difference, try sleeping with
>>>>> a mosquito!" - Amnesty International
>>>>>
>>>>> _______________________________________________
>>>>> Discuss-gnuradio mailing list
>>>>>
Discuss-gnuradio@gnu.org>>>>>
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio>>>>>
>>>
>>> Dimitrios Symeonidis
>>> "If you think you're too small to make a difference, try sleeping with
>>> a mosquito!" - Amnesty International
>>>
>
>
> ------------------------------
>
> Message: 3
> Date: Mon, 29 Aug 2011 12:20:49 -0400
> From: Tom Rondeau<
trondeau1122@gmail.com>
> To: Sivan Toledo<
sivan.toledo@gmail.com>
> Cc: discuss-gnuradio<
discuss-gnuradio@gnu.org>
> Subject: Re: [Discuss-gnuradio] Two instances of QT GUI Sink in a
> single program
> Message-ID:
> <CANc0s2PcK3WGUa0=
BBXO5G8bDeJZOP1aQikaSumh21+ib0s+2g@mail.gmail.com>
> Content-Type: text/plain; charset=ISO-8859-1
>
> On Sun, Aug 28, 2011 at 7:15 AM, Sivan Toledo<
sivan.toledo@gmail.com> wrote:
>> Thanks Tom. I guess I did not make myself clear. I do have several QT GUI
>> blocks in the program, which I indeed generate using GRC. I have many
>> sliders, a checkbox, and a sink (FFT). If I add a slider, I see it on the
>> screen when I run the new program. When when I add a sink block, there is
>> still only one FFT display, showing the results from one of the FFT blocks.
>> The problem is only with the QT Sink block, not with all the QT blocks.
>>
>> Sivan
> When you create more than one GT GUI window, they get stacked
> vertically. It's likely that one is just off screen. Look into using
> the QT GUI Tab Widget to be able to tab between windows. It helps
> clean up the desktop.
>
> Tom
>
>
>> On Sun, Aug 28, 2011 at 12:14 AM, Tom Rondeau<
trondeau1122@gmail.com>
>> wrote:
>>> On Thu, Aug 25, 2011 at 4:41 AM, Sivan Toledo<
sivan.toledo@gmail.com>
>>> wrote:
>>>> Is it possible to put two QT GUI Sinks (FFT displays) in a single
>>>> application window? I want to use one to show the radio spectrum
>>>> (to/from
>>>> UHD) and another to show the audio spectrum, at the same time.
>>>>
>>>> When I put two QT GUI Sink blocks in a GRC graph, I see only one of them
>>>> in
>>>> the application windows, unlike QT GUI Entries and other GUI elements
>>>> that
>>>> can have many instances in the same window.
>>>>
>>>> Thanks, Sivan Toledo
>>> You can definitely have more than one QT GUI blocks in a program. It's
>>> probably an initialization problem that's going wrong in your code.
>>> You can see multiple QT GUI's used in
>>> gnuradio-examples/python/digital/benchmark_qt_loopback.py.
>>>
>>> Also, gnuradio-companion now works with QT GUI (set in the Options
>>> block), and it handles multiple QT GUI blocks. You could create
>>> something there, build the flow graph, and then see how the QT GUI
>>> objects are manipulated to make sure they all get shown properly.
>>>
>>> Tom
>>
>> _______________________________________________
>> Discuss-gnuradio mailing list
>>
Discuss-gnuradio@gnu.org>>
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio>>
>>
>
>
> ------------------------------
>
> Message: 4
> Date: Mon, 29 Aug 2011 12:39:32 -0400
> From: Tom Rondeau<
trondeau1122@gmail.com>
> To: GNURadio Discussion List<
discuss-gnuradio@gnu.org>
> Subject: [Discuss-gnuradio] Conference Update
> Message-ID:
> <CANc0s2OGvn-T8rfuA605o3v5RuNijwaiLvZ8=
hE0nPo8ZFCSew@mail.gmail.com>
> Content-Type: text/plain; charset=ISO-8859-1
>
> Just a few weeks until our first GNU Radio Conference! I have a few
> things to discuss.
>
> 1. Try to get your travel plans set now. I just heard from the admin
> I'm working with at the university that there is a large medical
> conference happening the same week as ours, so hotels are getting
> booked. This is the main reason I haven't gotten a group code for us
> for this event. We're still working to get some rooms reserved for a
> few of the places in Philly, but I just wanted to warn everyone so
> that you can be proactive and find a place yourselves. If you look at
>
http://gnuradio.squarespace.com/grc2011-location/, you'll find the
> conference location and a couple of hotel recommendations.
>
> 2. There are still a few seats left for anyone who wants to join us!
>
> 3. Speakers: The schedule is pretty much all set:
>
http://gnuradio.squarespace.com/grc2011-dates/> I have received a couple of abstracts, so please send me a short
> abstract of your talk so I can post it online.
>
> 4. Audio. I hope to have audio recording facilities for the speakers.
> I would like to be able to put an audio recording along with the
> presentations for everyone who's willing. I'm working now on getting
> this capability set up. You don't have to be recorded if you don't
> want to, but I wanted to give everyone a head's up that I would like
> to do this so you can prepare as you see fit.
>
> That's all for now.
>
> Tom
>
>
>
> ------------------------------
>
> Message: 5
> Date: Mon, 29 Aug 2011 19:04:35 +0200
> From: Zhonghua<
zhonghua@sics.se>
> To:
discuss-gnuradio@gnu.org> Subject: [Discuss-gnuradio] How to use gr.buffer
> Message-ID:<
4E5BC6A3.8000608@sics.se>
> Content-Type: text/plain; charset=ISO-8859-1; format=flowed
>
> Hi every one,
> I want to use a buffer to receive streams from my transmitter module,
> read streams from this buffer and send the obtained streams to my
> receiver module. I followed the document of "Simple User Manual for
> Gnuradio 3.1.1" to use buffer as the format:
> buf=gr.buffer(4000,gr.sizeof_gr_complex). There is an error says
> "TypeError: Required argument 'link' (pos 3) not found". I checked some
> information and knew there should be a 'gr_block_sptr link' in the arg
> lists. But I don't know the detail of usage. I looked up from Google but
> got nothing helpful. There even has no one instance showing how to use
> buffer in gnu radio. I can only see some explains that how the buffer be
> constructed in C++ modules. Anybody used buffer in gnuradio? Thanks for
> your instruction.
>
> BR,
> Zhonghua
>
>
>
>
>
>
> ------------------------------
>
> Message: 6
> Date: Mon, 29 Aug 2011 19:22:06 +0200
> From: Martin Braun<
martin.braun@kit.edu>
> To:
discuss-gnuradio@gnu.org> Subject: Re: [Discuss-gnuradio] How to use gr.buffer
> Message-ID:<
20110829172206.GA4791@int.uni-karlsruhe.de>
> Content-Type: text/plain; charset="utf-8"
>
> On Mon, Aug 29, 2011 at 07:04:35PM +0200, Zhonghua wrote:
>> Hi every one,
>> I want to use a buffer to receive streams from my transmitter
>> module, read streams from this buffer and send the obtained streams
>> to my receiver module. I followed the document of "Simple User
>> Manual for Gnuradio 3.1.1" to use buffer as the format:
>> buf=gr.buffer(4000,gr.sizeof_gr_complex). There is an error says
>> "TypeError: Required argument 'link' (pos 3) not found". I checked
>> some information and knew there should be a 'gr_block_sptr link' in
>> the arg lists. But I don't know the detail of usage. I looked up
>> from Google but got nothing helpful. There even has no one instance
>> showing how to use buffer in gnu radio. I can only see some explains
>> that how the buffer be constructed in C++ modules. Anybody used
>> buffer in gnuradio? Thanks for your instruction.
> Hi Zhonghua,
>
> I have the strong suspicion you have misunderstood something:
> - Like most other objects, you create buffers with the 'make' function,
> in this case gr_make_buffer().
> - I have, in several years of GNU Radio, never actually created a
> gr_buffer myself (although I've visited the source several times :).
> So unless you're doing something totally funky to the GR core, I
> doubt you actually need it.
> That's why you don't see it anywhere in GR.
>
> MB
>
Hi Martin,
Thank you for your information. Actually I do not have to use buffers. I
just want to apply a buffer to simulate a FIFO. As you said, there maybe
no way to create a buffer in Python level by adopting the method of
gr.buffer(). I looked up the gr_buffer class and found there is a
friends of 'gr_make_buffer'. Unfortunately, I don't know how to use it
if I must use a buffer. Apart from this, I don't know exactly what the
function of gr_buffer class, in which occasion it should be used and how
to use it. Do you have any suggestions?
BR,
Zhonghua
_______________________________________________
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
