A Question on Packet Processing

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.

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

Thanks for the info. That was very informative write-up of the
proposed m-block architecture. I think I will wait until the
preliminary m-block stuff is done and then look at packet processing
again.

Tim

On Wed, Feb 21, 2007 at 12:46:59PM -0500, Tim M. 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.

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