On Wed, Feb 21, 2007 at 12:46:59PM -0500, Tim Meehan wrote:
> Hello All,
>
> I have been looking into using gnuradio for packet processing. I am
> having a hard time understanding exactly how to make this work.
Yes, packet processing in the flow graph environment is a bit of a
challenge. Hence the development of the m-block stuff (coming soon to
an SVN repository near you...)
> What I would like to do is send out packets of around 200 symbols or
> so. I think I understand how to do this at the transmit end.
> What I am stuck on is how to build a receive flowgraph that detects
> packets and sends signals to processing blocks further down the line.
> For example, I would want to detect the start of a packet and then
> send a signal to a downstream viterbi decoder to "reset" back to an
> initial state. I might also want to select one of N different blocks
> depending on what type of packet is detected.
>
> I have been looking at the examples in
> gnuradio-examples/python/channel-coding/
>
> In these examples the flowgraph is set up from scratch for each packet.
> This method works fine but there seems to be a lot of overhead with
> setting up the flowgraph (it takes a LONG time to run lots of
> packets). Perhaps the answer is to get away from python?
>
> I have taken a look at the examples that use pkt.py but I am not sure
> how to use things like gr-trellis with them.
>
> Any hints would be much appreciated.
>
> Tim
One way to handle packets on the receive end is to pass ancillary info
in a parallel stream of flags. We do something like that in the
pkt.py code, but the flags are contained in-band. The
gr.correlate_access_code_bb block looks for the beginning of a packet,
and when it finds one it set an additional bit in the output. The low
bit in the byte is the raw data from the demodulator, bit 1 is the
"I've seen a header flag".
I checked in code yesterday that implements gr_io_signatures with
heterogenous types for the streams. E.g., you may want a block that
consumes and produces two streams: one samples (e.g., float or
complex) and one a stream of unsigned char for per-sample flags.
We used a very similar technique in the ATSC receiver.
When the m-block stuff is ready for prime time, you'll be more easily
able to deal with packet based data, since there's an explicit
representation for it.
For me info on the m-blocks, see
http://gnuradio.org/trac/wiki/MessageBlocks
Eric