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 _______________________________________________ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio