Gr_message_sink

I was wondering if someone could perhaps clarify how the
gr_message_sink works . I’m trying to make a modified version of the
fft_sink. I noticed that the sample stream is turned into a vector
streasm and then sent to a message sink.

When the data is unpacked from the messages, then it seems there are a
varying number of fft frames in each message. How does this happen? Why
isn’t there only one frame per message?

Also, what exactly are msg.arg(1) and msg.arg(2). Are they part of the
message payload or part a special frame? Lastly, what does
self.msgq.delete_head() do?

Regards

Lance

On Sun, Oct 07, 2007 at 04:09:48PM -0700, seph 004 wrote:

I was wondering if someone could perhaps clarify how the gr_message_sink works . I’m trying to make a modified version of the fft_sink. I noticed that the sample stream is turned into a vector streasm and then sent to a message sink.

When the data is unpacked from the messages, then it seems there
are a varying number of fft frames in each message. How does this
happen? Why isn’t there only one frame per message?

It builds a message that contains however many items were handed it by
work. It could be changed such that each item was placed into it’s
own message, but that didn’t seem to make sense. Consider what would
happen if the items were floats.

Also, what exactly are msg.arg(1) and msg.arg(2). Are they part of
the message payload or part a special frame? Lastly, what does
self.msgq.delete_head() do?

Regards
Lance

See:

http://gnuradio.org/doc/doxygen/classgr__msg__queue.html
http://gnuradio.org/doc/doxygen/classgr__message.html
http://gnuradio.org/doc/doxygen/classgr__message__sink.html

A quick look at the source:

int
gr_message_sink::work(int noutput_items,
gr_vector_const_void_star &input_items,
gr_vector_void_star &output_items)
{
const char *in = (const char *) input_items[0];

// if we’d block, drop the data on the floor and say everything is OK
if (d_dont_block && d_msgq->full_p())
return noutput_items;

// build a message to hold whatever we’ve got
gr_message_sptr msg = gr_make_message(0, // msg type
d_itemsize, // arg1 for other end
noutput_items, // arg2 for other end (redundant)
noutput_items * d_itemsize); // len of msg
memcpy(msg->msg(), in, noutput_items * d_itemsize);

d_msgq->handle(msg); // send it

return noutput_items;
}

Eric

— Eric B. [email protected] wrote:

it seems there
Consider what would

See:

http://gnuradio.org/doc/doxygen/classgr__msg__queue.html

http://gnuradio.org/doc/doxygen/classgr__message.html

http://gnuradio.org/doc/doxygen/classgr__message__sink.html

(redundant)
Eric

Thanks for those links. I think I understand what is
happening a bit better now.

I was wondering if there is a way to align messages,
or at least, the samples within the messages. I made
some changes to the fpga code to insert a particular
sample pattern into the receive sample stream.

What I’d like to do is only plot a certain number of
samples that follow on after the sample pattern. This
lead me to the fft sink which also plots sets of
samples at a time, but not aligned to any particular
point.

Are there changes I could make at the python level to
plot samples relative to a particular pattern?

Regards

Lance


Yahoo! oneSearch: Finally, mobile search
that gives answers, not web links.
http://mobile.yahoo.com/mobileweb/onesearch?refer=1ONXIC

This forum is not affiliated to the Ruby language, Ruby on Rails framework, nor any Ruby applications discussed here.

| Privacy Policy | Terms of Service | Remote Ruby Jobs