Re: [Discuss-gnuradio] Re: Combining gr.trellis and mod_pkt

[Steven Clark]

On Jan 31, 2008 1:13 PM, Eric Blossom <address@hidden> wrote:
> On Thu, Jan 31, 2008 at 10:49:50AM -0500, Steven Clark 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

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:
1) 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.

2) 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.

mod_pkt_test.py
Description: Text Data