Secret documentation and Python 2.4

GNU Radio
1

Hi there,

I must be missing something - recently I saw a note here on this list
about --enable-doxygen to autogenerate documentation for gnuradio-core.
Very nice! It would be very useful if this kind of information was on
the
wiki. Is there some other “official” information repository? I wonder
what
other nuggets of information I am missing out on.

On a vaguely related note, I came across an installation guide for
gnuradio
(http://www.eecis.udel.edu/~manicka/Research/GnuRadio_InstallationNotes.pdf),
which claims that as of gnuradio 2.8, python 2.4 was required. Is that
the
true?

Seems like this thing is a little underdocumented. How can we help?

Cheers,
Jan

2

On Thu, Jul 13, 2006 at 11:52:27PM -0700, Jan S. wrote:

Hi there,

I must be missing something - recently I saw a note here on this list
about --enable-doxygen to autogenerate documentation for gnuradio-core.
Very nice! It would be very useful if this kind of information was on the
wiki. Is there some other “official” information repository? I wonder what
other nuggets of information I am missing out on.

This particular nugget of info is secreted in gnuradio-core/README :wink:

On a vaguely related note, I came across an installation guide for
gnuradio
(http://www.eecis.udel.edu/~manicka/Research/GnuRadio_InstallationNotes.pdf),
which claims that as of gnuradio 2.8, python 2.4 was required. Is that the
true?

Not true, python 2.3 works fine.

Seems like this thing is a little underdocumented. How can we help?

Hi Jan,

Thanks for the offer to help. We could definitely use additional
documentation. If you’d like to write some and contribute it, that
would be most welcome. Part of the problem you’re seeing is that
folks have generated documentation outside of the project (no problem
with that), however, since it’s not in our repository, we can’t edit
it to make corrections, extensions, etc. Besides Naveens’s, we’ve got
the same problem with Dawei Shen’s tutorial.

There is currently a CVS module ‘docs’ which contains a couple of
articles. If you’d like to add more, that would be the place to do
it. The current stuff is in docbook format so we can generate pdf’s
and html, but beggars can’t be choosers :wink:

We have a wiki (http://comsec.com/wiki), but as a result of an
extraordinary amount of wiki spam, it’s currently locked against
editing. Johnathan C. and others are checking out some other
options on the wiki front including trac and media wiki.

I can set you up as a committer to the docs module, or you can send a
patch (the new files) to [email protected]. Let me know.

Cheers,
Jan

Thanks again for your offer to help!

Eric

3

Hi Eric,

This particular nugget of info is secreted in gnuradio-core/README :wink:

I had long given up on README files, as I found them to mostly contain
trivial stuff. Maybe it is time to revise that policy :-).

Seems like this thing is a little underdocumented. How can we help?

would be most welcome. Part of the problem you’re seeing is that
folks have generated documentation outside of the project (no problem
with that), however, since it’s not in our repository, we can’t edit
it to make corrections, extensions, etc. Besides Naveens’s, we’ve got
the same problem with Dawei Shen’s tutorial.

Any chance that the authors of this external documentation might be
talked into contributing it to the docs module?

Let me ramble a bit about the potential “customers” for more
documentation. Gnu Radio is really a great technology and significantly
lowers the barrier to entry to playing with SDR. However, the learning
curve is still pretty steep. Particularly as not everybody has the
knowledge or patience to resolve all the build dependencies, or the
money to buy an USRP. I am thinking of e.g. some hams that may have a
Windows PC, a little dusty programming knowledge but some exposure to
DSP concepts and plenty of motivation. The kind of motivation that you
get from reading the “Exploring GNU Radio” article. But there is a big
gap to “How to write a block”. We are still very much in early-adopter
land here, and getting more people playing with this stuff would make a
big difference.

So if there was this hypothetical binary distribution, I think it might
look like this:

  • gnuradio-core and audio-support in binary form, to be installed on top
    of an existing Python install
  • Optional USRP support
  • A few How-Tos: Getting started (mini-Python primer, mini-SDR primer,
    Running your first example program, Catalog of the existing examples,
    Audio experiments involving your favorite MP3, Radio experiments with
    downloadable waveform snippets, etc)
  • An easy ordering option for USRPs :slight_smile:
  • Commented/documented examples
  • The secret gnuradio-core library docs as HTML (or CHM on Windows)

Basically, documentation for anything that you can do without a C++
compiler, with a focus on How-Tos, examples and ideas for experiments.

Does this make sense? Or am I barking up the wrong tree here? If so, any
other ideas on where to focus?

Also, does this hypothetical binary distribution exist, or is somebody
maybe working on it?

I haven’t used docbook, but it doesn’t exactly look like rocket science.
Any recommendations on authoring tools? (Please, let the answer not be
“Emacs, of course!”). Vex looked pretty promising, OpenOffice didn’t
seem to offer much support.

Cheers,
Jan

4

Folks,
I’m confused with -i option in siggen.py…

If I want to generate a pure 1MHz sine wave centered
at 10MHz carrier is it correct to use:

siggen.py --const --sine -f 1e6 -c 10e6

or should I use:

siggen.py --const --sine -f 1e6 -c 10e6 -i 32

or neither one ???

Would somebody elaborate on that?

Thankx,

Angilberto.

Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around

5

On Tue, 2006-07-18 at 08:57 -0700, Angilberto Muniz Sb wrote:

siggen.py --const --sine -f 1e6 -c 10e6 -i 32

or neither one ???

Would somebody elaborate on that?

[ posting to list in case I make any mistakes, pls correct ]

Quick answer: Either one, and don’t use --const, just --sine.

That must be an older version of usrp_siggen.py as the
latest does not have a -c option. You would use just --sine,
as --const is for a constant (DC) signal.

In that version you could specify waveform frequency before
upconverting to the output frequency, the upconverter (DUC)
frequency and the interpolation. It looks like this:

(waveform) ----> (duc) -----> (output freq)
^ ^
usb_rate 128e6

Interpolation is the ratio of DAC rate (128e6) to the usb_rate,
default is 64 and you ask for 32 above. So for an interpolation
of 32 the usb_rate would be 4MHz (128e6 / 32) so your waveform
could be anything from -2 to +2Mhz and the output would be the
DUC freq plus the waveform frequency.

If you use siggen.py --sine -f 1e6 -c 10e6 -i 32

you would get an output at 11Mhz. IF you use default interp = 64
you might want to use a smaller waveform freq as 1MHz would be
right at the edge of the usb_rate and it loses amplitude some.
Something like siggen.py --sine -f 50e3 -c 10.95e6

In the newer versions -f is the DUC frequency and -w is the
waveform frequency.

6

On Tue, Jul 18, 2006 at 12:44:08AM -0700, Jan S. wrote:

folks have generated documentation outside of the project (no problem
with that), however, since it’s not in our repository, we can’t edit
it to make corrections, extensions, etc. Besides Naveens’s, we’ve got
the same problem with Dawei Shen’s tutorial.

Any chance that the authors of this external documentation might be
talked into contributing it to the docs module?

Looks like we’re making progress in that direction :wink:

land here, and getting more people playing with this stuff would make a
big difference.

Agreed.

With regard to Windows, unless some Windows programmers step up to do
the work, I don’t think we’ll ever end up very polished on that
platform. Martin and Stephane have done good work getting it to work
under MinGW and Cygwin, but neither of them are windows users. [We
could be seeing a cultural difference here. Folks from the free
software world understand that software gets written by people, not by
some abstract “company” located someplace else. If the hypothetical
GNU Radio windows users keep waiting for somebody else to do it, it’ll
most likely never get done.]

  • Commented/documented examples
  • The secret gnuradio-core library docs as HTML (or CHM on Windows)

Sounds reasonable. I think I’d consider this the minimum set:

gnuradio-core, gnuradio-examples, gr-audio-, usrp,
gr-usrp, gr-wxgui

regardless of whether they had a usrp or not. I expect that at some
point in the future we’ll have a gr-pyqtgui, and then we’ll see how the
two GUI options compare.

Basically, documentation for anything that you can do without a C++
compiler, with a focus on How-Tos, examples and ideas for experiments.

Seems reasonable.

Does this make sense? Or am I barking up the wrong tree here? If so, any
other ideas on where to focus?

Also, does this hypothetical binary distribution exist, or is somebody
maybe working on it?

I’m not aware of anyone currently working on a .rpm distribution.
Ramakrishnan has been generating Debian .debs for the past few years.
I’d love to have .rpms, if somebody is willing to generate and test
the .spec files on say, SuSE 10.*, Fedora Core 5, and perhaps Mandriva
200{6,7}

I haven’t used docbook, but it doesn’t exactly look like rocket science.
Any recommendations on authoring tools? (Please, let the answer not be
“Emacs, of course!”). Vex looked pretty promising, OpenOffice didn’t
seem to offer much support.

Actually, I think that most people use emacs, of course :wink:
There are a couple of docbook modes to choose from…

I’d definitely stay away from using OpenOffice to generate docbook.
I’m not familiar with Vex, let us know how it works out.

Cheers,
Jan

Thanks again for all your input and ideas.

Eric

7

Thank you very much for the explanation, Charles.
That explains what I see on the Spectrum Analyser and
why I was getting some weird signals in Matlab…

Thank you,

Angilberto.

— Charles S. [email protected]
wrote:

correct ]
In that version you could specify waveform frequency
Interpolation is the ratio of DAC rate (128e6) to

is the
waveform frequency.

Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around