Where to start in learning to develop and contribute to GNU Radio?

I recently graduated with my degree in Computer Engineering, and the GNU
Radio project is by far the most complex thing I’ve desired to work on.
I’m
looking for tips on how to get started learning GNU Radio from the
ground
up, build custom modules, and help develop the source.

For example, an known issue that I would like to eventually be able to
work
on is solving Message Passing blocks not terminating from head block
(and
similar) termination.

So my question is, what type of road map should I construct for learning
the in’s and out’s of gnu radio, from custom module writing, all the way
down to the scheduler. I have the absolute basics down (writing blocks
in
python) and will move to the C API next. But I’m not sure on where to
start
understanding the foundation of how it all works together.

Through my journey, I’m looking to improve the Documentation of GNU
Radio
so it is easy for new people to join the project.

Ken

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi Ken,
welcome to the community!

I’ll go ahead and answer in-line, since this seems to make sense here:
On 11.04.2014 23:16, Ken A. wrote:

I recently graduated with my degree in Computer Engineering, and
the GNU Radio project is by far the most complex thing I’ve desired
to work on. I’m looking for tips on how to get started learning GNU
Radio from the ground up, build custom modules, and help develop
the source.
just go through the Information on the main wiki side
http://gnuradio.org . A lot of people make the mistake to skip the
first pages (what GNU Radio is etc), and end up having misconceptions
after weeks of development.

For example, an known issue that I would like to eventually be able
to work on is solving Message Passing blocks not terminating from
head block (and similar) termination.
That’s actually a rather complicated scheduler problem. A solution is
highly desirable, but to make it short: The GNU Radio asynchronous
message passing interface does not support specifying an “end of
usage” state for the message port. If GR stopped execution when the
synchronous sample stream flowgraph was finished, not all messages
might have been delivered…
I see this as an architectural challenge, actual.

So my question is, what type of road map should I construct for
learning the in’s and out’s of gnu radio, from custom module
writing, all the way down to the scheduler. I have the absolute
basics down (writing blocks in python) and will move to the C API
next. But I’m not sure on where to start understanding the
foundation of how it all works together.

You’ll learn by doing, actually.
“Official” written documentation is sparse (a little bit) and can be
found in some presentations and papers.
But the main source of information is of course the (luckily in most
parts nicely readable) source code.

Through my journey, I’m looking to improve the Documentation of GNU
Radio so it is easy for new people to join the project.
I like your attitude :wink:

Greetings,
and: happy hacking!

Marcus
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQEcBAEBAgAGBQJTSGKkAAoJEBQ6EdjyzlHts+cH/i/DqWt0PujHlfGHln73B96p
dvY+hfeWmiJQTwgbc5gaPeG1eTxoWnoUMpxZPcVieP8Fb0o7q7YWmcH4a20a7Fuj
sKjpQ54Zg+JKZXQJqw5NekgG4+lidq3iZlgOk3P8M4ALqk125+smWWUxZ77FA/RX
AP6uorVY/lB6O6NgsqUNHLwFOMIi1mV4ZL6zqnunRxVmk+zGgt2wLQeEAbMSoN4J
hzP8J41VG7RTzLK/5s9ceivblUXsFo8NeM7e9+jbIPhSvqE2VpqBR1NS06lJbG5x
Oqw/tJS0VZHCnCrN9IHJ36SINETpJlW4ha9SF88+U/IS0Mf5ZvilQgc7B8IPOnM=
=Sntn
-----END PGP SIGNATURE-----

Hey Ken,

welcome to the crew, and I’m happy to hear you’re interested in
participating.
Let me add to Marcus’ email:

First of all, we have a page for people like you:
http://gnuradio.org/redmine/projects/gnuradio/wiki/Development.

On 04/11/2014 11:46 PM, Marcus M. wrote:

For example, an known issue that I would like to eventually be able
to work on is solving Message Passing blocks not terminating from
head block (and similar) termination.
That’s actually a rather complicated scheduler problem. A solution is
highly desirable, but to make it short: The GNU Radio asynchronous
message passing interface does not support specifying an “end of
usage” state for the message port. If GR stopped execution when the
synchronous sample stream flowgraph was finished, not all messages
might have been delivered…
I see this as an architectural challenge, actual.

Yeah, hold back on that. Even if it were simple, deep architectural
changes like this need to be discussed. We have monthly calls you can
join.

So my question is, what type of road map should I construct for
learning the in’s and out’s of gnu radio, from custom module
writing, all the way down to the scheduler. I have the absolute
basics down (writing blocks in python) and will move to the C API
next. But I’m not sure on where to start understanding the
foundation of how it all works together.

Make sure you’ve read all there is on the wiki.
Something we want to do is to port all Python blocks to C++, maybe
that’s a good place to start. I think the FM pre-/de-emphasis blocks are
among those, if you want a place to start.

Have fun, and come back here for questions!

Martin