Combining gr.trellis and mod_pkt

stevenc · January 28, 2008, 12:40am

'lo all.

I would like to place code in the rx_callback of the packet mod
architecture that takes each received payload and runs it though
gr.trellis’s viterbi decoder.
Should this be possible?

It seems like I’d have to set up, run, and tear-down a flowgraph or
top-block in the duration of the callback. But wouldn’t this interfere
with the top-block/flowgraph that was already existing for the packet
demod framework?

Any thoughts?

-Steven

stevenc · January 31, 2008, 4:50pm

Pardon the bump. Maybe I should simplify the question:

With the packet modulator, is it possible to run the packet payload
bits through any kind of flow-graph/block during the rx_callback?

stevenc · January 31, 2008, 7:14pm

On Thu, Jan 31, 2008 at 10:49:50AM -0500, Steven C. wrote:

Pardon the bump. Maybe I should simplify the question:

With the packet modulator, is it possible to run the packet payload
bits through any kind of flow-graph/block during the rx_callback?

Yes. You could push the bits back into a message source, do what you
like, and suck them back out of a message sink. No need for a
separate flow graph, just more blocks (The top_block code currently
has an implementation limitation that allows only a single top_block.)

Eric

stevenc · February 6, 2008, 3:12am

On 2/5/08, Steven C. [email protected] wrote:

With this second block chain inside the top block, tb.wait() never
returns. I can’t even ctrl-c out of python, it’s just stuck.

Your msg_source, which is a gr.message_source, is blocked, waiting for
new messages to arrive. In order to allow the second block chain to
exit, you need to send it a message that causes it to unblock. The
flowgraph scheduler thread that is running this chain will then see
the indication that it should exit, and do so.

–
Johnathan C.
Corgan Enterprises LLC
http://corganenterprises.com/

stevenc · February 6, 2008, 12:35am

On Jan 31, 2008 1:13 PM, Eric B. [email protected] wrote:

Eric

Thanks Eric-

So I created a test case for this by modifying the
digital/benchmark_loopback.py example.
The top block initially consisted of 1 chain:

self.connect(self.txpath, self.throttle, self.rxpath)

I added a second, parallel chain inside the top block:
msg_src = gr.message_source(gr.sizeof_short)
in_msg_q = msg_src.msgq()
self.add = gr.add_const_ss(1)
self.msg_sink = gr.file_descriptor_sink(gr.sizeof_short, 1)

self.connect(msg_src, self.add, self.msg_sink)

During the rx_callback I take the packet string, and place it in the
in_msg_q. The secondary chain then treats that string as a stream of
shorts, and adds one to each short. The result is sent to stdout.
This works, sort of. I send 6 packets of ‘ASDF’ in and I observe 6
'BSEF’s being printed. (I was actually expecting ‘ATDG’, but I guess I
had the byte order backwards. No biggie).

Problems:

With this second block chain inside the top block, tb.wait() never
returns. I can’t even ctrl-c out of python, it’s just stuck.
If I change the msg_sink from stdout to another message queue, how
do I know when it is safe to pull the result out?

My code is attached.

stevenc · February 6, 2008, 7:58pm

Your msg_source, which is a gr.message_source, is blocked, waiting for
new messages to arrive. In order to allow the second block chain to
exit, you need to send it a message that causes it to unblock. The
flowgraph scheduler thread that is running this chain will then see
the indication that it should exit, and do so.

Ok, so with Johnathan’s help I see that adding a gr.message(1) to the
input queue has a special EOF meaning, and allows things to exit
nicely. Is this stuff documented anywhere?

On a broader note, I find that I often have difficulty finding things
in / navigating the GNURadio source tree. I frequently see some class
or block at the python level, and want to look at its source. I have
no idea if it is defined in C or python, or where it is located. Is
there any way, other than through sheer stumbling around, to figure
out that:
blk2.mod_pkts is defined in
gnuradio-core/src/python/gnuradio/blks2impl/pkt.py
gr.msg_queue is defined in gnuradio-core/src/lib/runtime/gr_msg_queue.cc
gr.message_source is defined in
gnuradio-core/src/lib/io/gr_message_source.cc
etc.?

This has been a pretty big barrier to entry into GNU Radio for me, and
probably for some others as well.

stevenc · February 6, 2008, 10:36pm

On Wed, Feb 06, 2008 at 01:58:16PM -0500, Steven C. wrote:

Your msg_source, which is a gr.message_source, is blocked, waiting for
new messages to arrive. In order to allow the second block chain to
exit, you need to send it a message that causes it to unblock. The
flowgraph scheduler thread that is running this chain will then see
the indication that it should exit, and do so.

Ok, so with Johnathan’s help I see that adding a gr.message(1) to the
input queue has a special EOF meaning, and allows things to exit
nicely. Is this stuff documented anywhere?

Nope, please feel free to submit a patch for the gr_message_source.h
header documentation.

This has been a pretty big barrier to entry into GNU Radio for me, and
probably for some others as well.

If you’re an emacs user, you could use “etags” and M-. That’ll handle
all the C++ and Python stuff. Having good tools is essential to
success in the s/w world.

$ man etags

In emacs use “info” and search for tags.

Here it is on the web:

http://www.gnu.org/software/emacs/manual/html_node/emacs/Tags.html

Then look at the “find tag” command

http://www.gnu.org/software/emacs/manual/html_node/emacs/Find-Tag.html#Find-Tag

The python stuff is all under gnuradio-core/src/python.
Some of the subdivisions are implementation details that allows us to
merge everything into particular python namespaces at installation
time. It’s a bit ugly, but there’s only a couple of things you need
to remember.

Worst case use a recursive grep or find.

From a fresh checkout

$ find . -type f ! -path ‘*.svn’ -print | sort

will get you a pretty clean set of filenames.

Eric