GrExtras - write blocks in python, message passing, misc features

GNU Radio
1

Hey list,

I have put together a project on github with all (but a few) of the
various features I have created for GNU Radio in the past 6 months or
so. I have probably posted a link a few times, but I have been waiting
to find the time to clean it up, make a wiki page, and announce. So here
it is: GR Extras - Misc GNU Radio Blocks and Features

Most of the description is in the wiki page:

And here is a handy coding guide for more detail:

So among the features listed on that wiki page, I think the most
prominent and useful features to users may be the ability to code blocks
in python, and the message passing API.

Coding blocks in python gives you access to the all the typical gr_block
C++ API stuff, but from python. The scheduler thread itself will
actually call into your python work() function.

Message passing builds on top of the existing GNU Radio stream tags - to
give the user an API to simply pass tags (without the streams) as
messages between blocks. The user can use this feature to implement a
packet layer in gnuradio, or even do control plane stuff - but all the
while, sticking to the standard block flow graph model that users are
familiar with.

Previously, many of these features were implemented on branches as
changesets against gnuradio. I think this was a barrier for people to
get started. What changeset to cherry-pick, what branch to merge etc. So
I am pleased to point out that all of GrExtras can be compiled against a
standard GNU Radio install. No special branches or changesets are
necessary.

I hope that somebody may find this work useful. Happy coding!
-josh

2

On Sat, Jun 02, 2012 at 10:52:50AM -0700, Josh B. wrote:

Message passing builds on top of the existing GNU Radio stream tags - to
give the user an API to simply pass tags (without the streams) as
messages between blocks. The user can use this feature to implement a
packet layer in gnuradio, or even do control plane stuff - but all the
while, sticking to the standard block flow graph model that users are
familiar with.

Hi Josh,

this is nice stuff. I’ll be definitely playing around with it.

One question on the messages: is there a reason messages can’t be passed
upstream? That might come in handy on occasions.

MB

–
Karlsruhe Institute of Technology (KIT)
Communications Engineering Lab (CEL)

Dipl.-Ing. Martin B.
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

3

On Tue, Jun 05, 2012 at 01:25:33PM -0700, Josh B. wrote:

Actually, I think that should work just fine.

I haven’t created a control-plane sort of demo, I guess I should make
that a mini project this weekend. But in theory, if block A feeds block
B a stream, block B could have a message source that feeds a message
sink on block A.

That shouldnt violate any of gnuradio’s circular link checks when it
flattens the hierarchy, because the message part of the blocks are
actually separate blocks internally.

Yep, it works :slight_smile:

I actually tried to connect two blocks such that the upstream block
passes msgs to the downstream block through tags (they also pass
samples) and the downstream block feeds back messages to the first one.

So although the second connection is not synched to the rest, this
allows some sort of feedback loops, and that’s pretty nice.

MB

Karlsruhe Institute of Technology (KIT)
Communications Engineering Lab (CEL)

Dipl.-Ing. Martin B.
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

4

On 06/05/2012 01:17 PM, Martin B. wrote:

this is nice stuff. I’ll be definitely playing around with it.

Cool thanks!

One question on the messages: is there a reason messages can’t be passed
upstream? That might come in handy on occasions.

Actually, I think that should work just fine.

I haven’t created a control-plane sort of demo, I guess I should make
that a mini project this weekend. But in theory, if block A feeds block
B a stream, block B could have a message source that feeds a message
sink on block A.

That shouldnt violate any of gnuradio’s circular link checks when it
flattens the hierarchy, because the message part of the blocks are
actually separate blocks internally.

-josh

5

On Sat, Jun 02, 2012 at 10:52:50AM -0700, Josh B. wrote:

Most of the description is in the wiki page:
Home · guruofquality/grextras Wiki · GitHub

And here is a handy coding guide for more detail:
Blocks Coding Guide · guruofquality/grextras Wiki · GitHub

Hi Josh,

I’m not quite behind all of this yet. Here’s two questions, if you could
spare a minute:

First thing I tried was the Python blocks, and I wrote a random number
generator (yep, I know that already exists, but I just wanted something
simple to start with).
Q: Why can’t I assign arrays to output_items? See the code:

from gnuradio import gr import gnuradio.extras import numpy MAXRND = 1000

class rng_i(gr.block):
" random number generator "
def init(self):
gr.block.init(self, name=“rng_i”, in_sig=None,
out_sig=[numpy.int32])

def work(self, input_items, output_items):
    # Doesn't work:
    #output_items[0] = numpy.array(numpy.random.randint(0, MAXRND,

len(output_items[0])), dtype=numpy.int32)[:]
# Works:
for i in xrange(len(output_items[0])):
output_items[0][i] = numpy.random.randint(0, MAXRND)
return len(output_items[0])

I’m assuming it’s something like copy vs. reference, but I thought I was
doing everything right.

Q: The first argument of post_msg, is this simply == the number of
stream ports? Say I have one stream output and one msg output, do I
always post to port 1?
Reason I ask is you mention ‘group indexes’ and I’m not sure what that
means.

Apart from that, I quite like your code and would like to lobby towards
getting some of it into the mainline repository. Now I just have to come
up with something useful to do with it :slight_smile:

MB

–
Karlsruhe Institute of Technology (KIT)
Communications Engineering Lab (CEL)

Dipl.-Ing. Martin B.
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

6

On 06/06/2012 11:04 AM, Johnathan C. wrote:

uncover any bugs/issues that way before merging.

If you merge the python blocks into gnuradio, the GrExtras equivalent
should overlay nicely: i.e. no conflicting issues. -josh

7

On Wed, Jun 6, 2012 at 9:52 AM, Martin B. [email protected]
wrote:

Apart from that, I quite like your code and would like to lobby towards
getting some of it into the mainline repository. Now I just have to come
up with something useful to do with it :slight_smile:

The Python blocks feature is intended to go into mainline fairly soon.
It’s good that it is getting some use in the community–hopefully we’ll
uncover any bugs/issues that way before merging.

Johnathan

8

On 06/06/2012 09:52 AM, Martin B. wrote:

spare a minute:
MAXRND = 1000

class rng_i(gr.block):
" random number generator "
def init(self):
gr.block.init(self, name=“rng_i”, in_sig=None,
out_sig=[numpy.int32])

def work(self, input_items, output_items):
    # Doesn't work:
    #output_items[0] = numpy.array(numpy.random.randint(0, MAXRND,

len(output_items[0])), dtype=numpy.int32)[:]

I think I documented something about the numpy index operator, but maybe
I deleted it… have to check. Basically, use the indexing operator on
the left side of the assignment.

output_items[0][:] = numpy.array(numpy.random.randint(0, MAXRND,
len(output_items[0])), dtype=numpy.int32)

Q: The first argument of post_msg, is this simply == the number of
stream ports? Say I have one stream output and one msg output, do I
always post to port 1?
Reason I ask is you mention ‘group indexes’ and I’m not sure what that
means.

The group index refers to the index of the message source ports. This
would be zero for the 1st message source port. I should clarify that in
the docs… :slight_smile:

Apart from that, I quite like your code and would like to lobby towards
getting some of it into the mainline repository. Now I just have to come
up with something useful to do with it :slight_smile:

Thanks for trying it out.
-josh