Re: [Discuss-gnuradio] gr_message_sink

[seph 004]

--- Eric Blossom <[EMAIL PROTECTED]> wrote:

> 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
> 

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


___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] gr_message_sink

[Eric Blossom]

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


___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] gr_message_sink

[seph 004]

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

   
-
Shape Yahoo! in your own image.  Join our Network Research Panel today!___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio