Python function processing block

GNU Radio
1

There was discussion on the list a few months ago about adding the
ability to hook a python function
into the processing chain. I don’t remember what the conclusion of
that discussion was.

I have a need to be able to hook a user-defined Python code snippet into
the processing chain, near the end
where the sample rate is very low (1Hz). Is this easily done, and if
so, how?

2

Johnathan C. wrote:

[snipped]

Marcus–I hope you’ll see this on the list, as your mail system at your
employer filtered my direct copy to you. Looks like my mail server
ended up on someones’ RBL list.

Johnathan C., AE6HO
[email protected]

3

Marcus L. wrote:

There was discussion on the list a few months ago about adding the
ability to hook a python function
into the processing chain. I don’t remember what the conclusion of
that discussion was.

I have a need to be able to hook a user-defined Python code snippet into
the processing chain, near the end
where the sample rate is very low (1Hz). Is this easily done, and if
so, how?

Take a look at gr.feval_xx class:

http://gnuradio.org/trac/browser/gnuradio/trunk/gnuradio-core/src/lib/general/gr_feval.h

It defines a function ‘eval’ that can be called either from C++ or from
Python. In Python you can subclass this and override the eval function
with whatever you want. When the function is called from C++, control
flow passes to the Python interpreter to evaluate the function and
return.

I haven’t used it myself, but you can get a good feel for what is
possible by looking at the QA code for the block at:

http://gnuradio.org/trac/browser/gnuradio/trunk/gnuradio-core/src/python/gnuradio/gr/qa_feval.py

Johnathan C., AE6HO
[email protected]

4

Eric B. wrote:

This is all good info.

You could build a few classes derived from gr_sync_block that would
use the same techniques.

Eric

Looking at the qa_feval stuff, how does this conflict with Pythons
builtin “eval” function, which is used to
do a runtime evaluation of an expression?

I’d like the end-user to be able to pass a simple codelet in on the
command line, and have it evaluated.

5

On Mon, Oct 02, 2006 at 09:08:00AM -0700, Johnathan C. wrote:

so, how?
I haven’t used it myself, but you can get a good feel for what is
possible by looking at the QA code for the block at:

http://gnuradio.org/trac/browser/gnuradio/trunk/gnuradio-core/src/python/gnuradio/gr/qa_feval.py

Johnathan C., AE6HO
[email protected]

This is all good info.

You could build a few classes derived from gr_sync_block that would
use the same techniques.

Eric

6

On Tue, Oct 03, 2006 at 09:19:19AM -0400, Marcus L. wrote:

Looking at the qa_feval stuff, how does this conflict with Pythons
builtin “eval” function, which is used to
do a runtime evaluation of an expression?

It doesn’t conflict at all. It’s just a class with a method called
“eval”.

I’d like the end-user to be able to pass a simple codelet in on the
command line, and have it evaluated.

Shouldn’t be a problem. You’ll want to wrap some something around the
user provided codelet to turn it into a function using either the
lambda syntax (if it’s a single expression) or adding the def
foo_9876567(a,b,c): …
wrapper. Then eval that. At that point foo_9876567 is in the namespace
and can be called.

If you need more than this hand-waving, let me know :wink:

Eric

7

On Tue, Oct 03, 2006 at 11:40:14AM -0400, Marcus L. wrote:

possible by looking at the QA code for the block at:

http://gnuradio.org/trac/browser/gnuradio/trunk/gnuradio-core/src/python/gnuradio/gr/qa_feval.py

Ok, so gr_feval_ff() appears in the C++ code, but doesn’t appear to have
an interface generated in the SWIG stuff–
whazzup with that?

Looks like whomever added it, failed to add the .i file entry.
Note that in reality, it doesn’t make much sense to have a _ff, since
the _dd does effectively the same thing. All python floating point
numbers are doubles.

8

Eric B. wrote:

http://gnuradio.org/trac/browser/gnuradio/trunk/gnuradio-core/src/python/gnuradio/gr/qa_feval.py

Johnathan C., AE6HO
[email protected]

Ok, so gr_feval_ff() appears in the C++ code, but doesn’t appear to have
an interface generated in the SWIG stuff–
whazzup with that?