gr_block::set_history()

[cjpatton]

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!

[Kyle Zhou]

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

_______________________________________________
Discuss-gnuradio mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Tom Rondeau-2]

On Thu, Sep 20, 2012 at 8:15 PM, Kyle Zhou <[hidden email]> wrote:

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

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

_______________________________________________
Discuss-gnuradio mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[cjpatton]

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

[Tom Rondeau-2]

On Fri, Sep 21, 2012 at 1:18 PM, cjpatton <[hidden email]> 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

_______________________________________________
Discuss-gnuradio mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[cjpatton]

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

[Tom Rondeau-2]

On Fri, Sep 21, 2012 at 1:47 PM, cjpatton <[hidden email]> wrote:

> 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

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

tom

_______________________________________________
Discuss-gnuradio mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[cjpatton]

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

[Tom Rondeau-2]

On Mon, Sep 24, 2012 at 12:47 PM, cjpatton <[hidden email]> wrote:

> 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

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

_______________________________________________
Discuss-gnuradio mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio