Forum: GNU Radio gr_block::set_history()

Posted by cjpatton (Guest)
on 2012-09-20 23:59
(Received via mailing list)
I have a general work function for which I will use GNU Radio's history
functionality. In the block's constructor, I call set_history( m ). I 
cast
the input buffer in the standard way:

  const float *in = (const float *) input_items[0];

My question is wheere in[0] refers to in the buffer. It would make sense 
to
me that noutput_items is the number of new items for the block to 
consume
and ninput_items[0] refers to the total number of data in the buffer. 
So,
in[noutput_items-1] is the last element of the array, in[0] is the start 
of
the new items, and the in[-m] refers to the beginning of the history 
block.
Thus, ninput_items[0] is greater than or equal to m + noutput_items.

I don't know if this assumption is true and would be pleased if someone 
knew
how this works. The GNU Radio API is somewhat vague in this respect. 
Thanks
in advance!




--
View this message in context: 
http://gnuradio.4.n7.nabble.com/gr-block-set-histo...
Sent from the GnuRadio mailing list archive at Nabble.com.
Posted by Kyle Zhou (Guest)
on 2012-09-21 19:18
(Received via mailing list)
> I have a general work function for which I will use GNU Radio's history
functionality. In the block's constructor, I call set_history( m ). I 
cast
the input buffer in the standard way:

  const float *in = (const float *) input_items[0];

My question is wheere in[0] refers to in the buffer. It would make sense 
to
me that noutput_items is the number of new items for the block to 
consume
and ninput_items[0] refers to the total number of data in the buffer. 
So,
in[noutput_items-1] is the last element of the array, in[0] is the start 
of
the new items, and the in[-m] refers to the beginning of the history 
block.
Thus, ninput_items[0] is greater than or equal to m + noutput_items.

I don't know if this assumption is true and would be pleased if someone 
knew
how this works. The GNU Radio API is somewhat vague in this respect. 
Thanks
in advance!

> *************************************************


From you description you should use sync block.
Anyway, my knowledge on history is: (assuming 1:1 in-out ratio)
in[0] to in[noutput_items+m-2] are what you can use to produce 
noutput_items outputs.
in[0] is the oldest and in[noutput_items+m-2] is the newest sample.
ninput_items[0]==noutput_items+m-1

Any one can correct me?
KZ
Posted by Tom Rondeau (Guest)
on 2012-09-21 20:37
(Received via mailing list)
On Thu, Sep 20, 2012 at 8:15 PM, Kyle Zhou <kylenix@gmail.com> wrote:
> me that noutput_items is the number of new items for the block to consume
> *************************************************
> KZ
Kyle,

Yes, that's how the set_history works. Basically, when told you have
noutput_items, you know that you have noutput_items+(history()-1). The
default for set_history(m) is m=1, so that's where the -1 comes from.
It allows you to look beyond the number of items you've been given.

Tom
Posted by cjpatton (Guest)
on 2012-09-21 21:24
(Received via mailing list)
Tom and Kyle,

Thanks for your replies. Suppose I want in[0] to refer to the beginning 
of
the new data. Then I could do this:

   const float *in = (const float *) input_items[history()-1];

So in[noutput_items-1] is the last? Thanks!

Chris





--
View this message in context: 
http://gnuradio.4.n7.nabble.com/gr-block-set-histo...
Sent from the GnuRadio mailing list archive at Nabble.com.
Posted by Tom Rondeau (Guest)
on 2012-09-21 21:30
(Received via mailing list)
On Fri, Sep 21, 2012 at 1:18 PM, cjpatton <cjpatton@ucdavis.edu> wrote:
> Tom and Kyle,
>
> Thanks for your replies. Suppose I want in[0] to refer to the beginning of
> the new data. Then I could do this:
>
>    const float *in = (const float *) input_items[history()-1];
>
> So in[noutput_items-1] is the last? Thanks!
>
> Chris

Chris,
Close. Remember that input_buffers is a vector of buffers. So you want
the first buffer and then offset it. I think this should work:

>    const float *in = (const float *)(&input_items[0][history()-1]);

A good one to look at is the gr_quadrature_demod_cf block where the
history is set to 2 and the work function has:

    const float *in = (const float *) input_items[0];
    in++;

So the 'in++' sets the pointer forward that one sample so that in[i-1] 
is valid.

Tom
Posted by cjpatton (Guest)
on 2012-09-21 21:53
(Received via mailing list)
Hello Tom,

Of course, how could I forget? I had to modify your code a bit to get to
work, however:

   const float *in = (const float *) &((const
float*)input_items[0])[history()-1];

It just needed a type cast in there. My code works now. The suggestion 
about
gr_quadrature_demod_cf is very helpful; this will be a good reference 
moving
forward on this project. Many thanks

Chris Patton



--
View this message in context: 
http://gnuradio.4.n7.nabble.com/gr-block-set-histo...
Sent from the GnuRadio mailing list archive at Nabble.com.
Posted by Tom Rondeau (Guest)
on 2012-09-21 22:05
(Received via mailing list)
On Fri, Sep 21, 2012 at 1:47 PM, cjpatton <cjpatton@ucdavis.edu> wrote:
> forward on this project. Many thanks
>
> Chris Patton

Yeah, I figured I had gotten something like that wrong. You got the
point, though.

tom
Posted by cjpatton (Guest)
on 2012-09-24 18:48
(Received via mailing list)
Hello Tom,

I have a follow-up question about how history works in gnuradio. Making 
no
assumptions about the input/output ratio of a gr_block, is it safe to 
assume
that noutput_items is the number of new data given to the block? I.e., 
Does
calling 'consume(noutput_items)' consume all the new data available when 
the
work function is called? If this is is the case, what does ninput_items
represent?

Thanks again,
Chris Patton



--
View this message in context: 
http://gnuradio.4.n7.nabble.com/gr-block-set-histo...
Sent from the GnuRadio mailing list archive at Nabble.com.
Posted by Tom Rondeau (Guest)
on 2012-10-02 03:05
(Received via mailing list)
On Mon, Sep 24, 2012 at 12:47 PM, cjpatton <cjpatton@ucdavis.edu> wrote:
> Chris Patton
Chris,

By default, yes, an input will have at least noutput_items available
to it. This is due to the forecast function that defaults to say that
the required number of inputs is the number of outputs plus the
history. So unless you overload the forecast function, this is how it
works.

When you say consume(i, noutput_items), then you are just telling the
scheduler that that is how many items read from the input. But there
could be more items available; you just (probably) wouldn't process
them because you don't have the space on the output.

Tom
Please log in before posting. Registration is free and takes only a minute.
Existing account (Switch to SSL-encrypted connection)
NEW: Do you have a Google/GoogleMail or Yahoo account? No registration required!
Log in with Google account | Log in with Yahoo account
No account? Register here.