Send Discuss-gnuradio mailing list submissions to
address@hidden
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
address@hidden
You can reach the person managing the list at
address@hidden
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<address@hidden>
To: Dimitris Symeonidis<address@hidden>
Cc: DiscussGnuRadio<address@hidden>
Subject: Re: [Discuss-gnuradio] minor bug
Message-ID:
<address@hidden>
Content-Type: text/plain; charset=ISO-8859-1
On Sun, Aug 28, 2011 at 12:08 PM, Dimitris Symeonidis<address@hidden> wrote:
On 27 August 2011 23:10, Tom Rondeau<address@hidden> wrote:
On Fri, Aug 26, 2011 at 10:00 AM, Dimitris Symeonidis<address@hidden> 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
address@hidden
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<address@hidden>
To: Dimitris Symeonidis<address@hidden>
Cc: DiscussGnuRadio<address@hidden>
Subject: Re: [Discuss-gnuradio] minor bug
Message-ID:
<address@hidden>
Content-Type: text/plain; charset=ISO-8859-1
On Sun, Aug 28, 2011 at 6:09 PM, Dimitris Symeonidis<address@hidden> 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<address@hidden> wrote:
On 27 August 2011 23:10, Tom Rondeau<address@hidden> wrote:
On Fri, Aug 26, 2011 at 10:00 AM, Dimitris Symeonidis<address@hidden> 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
address@hidden
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<address@hidden>
To: Sivan Toledo<address@hidden>
Cc: discuss-gnuradio<address@hidden>
Subject: Re: [Discuss-gnuradio] Two instances of QT GUI Sink in a
single program
Message-ID:
<address@hidden>
Content-Type: text/plain; charset=ISO-8859-1
On Sun, Aug 28, 2011 at 7:15 AM, Sivan Toledo<address@hidden> 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<address@hidden>
wrote:
On Thu, Aug 25, 2011 at 4:41 AM, Sivan Toledo<address@hidden>
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
address@hidden
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
------------------------------
Message: 4
Date: Mon, 29 Aug 2011 12:39:32 -0400
From: Tom Rondeau<address@hidden>
To: GNURadio Discussion List<address@hidden>
Subject: [Discuss-gnuradio] Conference Update
Message-ID:
<address@hidden>
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<address@hidden>
To: address@hidden
Subject: [Discuss-gnuradio] How to use gr.buffer
Message-ID:<address@hidden>
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<address@hidden>
To: address@hidden
Subject: Re: [Discuss-gnuradio] How to use gr.buffer
Message-ID:<address@hidden>
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