If you use set_output_multiple(), you don't have to check the input
buffer. The block will only execute if there are a multiple of the value
used in set_output_multiple() items available. For example, if
set_output_multiple() is set to 256, the block will only execute if
noutput_items is at least 256, but it could also be 512, 768, 1024,
1280, 1536, etc.
Since forecast() sets ninput_items_required to noutput_items, the same
number of items appears on the input buffer.
Here's a dummy block that just copies input to output to show the
structure. The loop in general_work() allows for any value of CHUNK_SIZE
to work properly. With a size of 8900, the loop will typically only
execute once.
#ifdef HAVE_CONFIG_H
#include "config.h"
#endif
#include <gnuradio/io_signature.h>
#include <stdio.h>
#include "buffer_cc_impl.h"
#define CHUNK_SIZE 8900
namespace gr {
namespace laura {
buffer_cc::sptr
buffer_cc::make()
{
return gnuradio::get_initial_sptr
(new buffer_cc_impl());
}
/*
* The private constructor
*/
buffer_cc_impl::buffer_cc_impl()
: gr::block("buffer_cc",
gr::io_signature::make(1, 1, sizeof(gr_complex)),
gr::io_signature::make(1, 1, sizeof(gr_complex)))
{
set_output_multiple(CHUNK_SIZE);
}
/*
* Our virtual destructor.
*/
buffer_cc_impl::~buffer_cc_impl()
{
}
void
buffer_cc_impl::forecast (int noutput_items, gr_vector_int
&ninput_items_required)
{
ninput_items_required[0] = noutput_items;
}
int
buffer_cc_impl::general_work (int noutput_items,
gr_vector_int &ninput_items,
gr_vector_const_void_star &input_items,
gr_vector_void_star &output_items)
{
const gr_complex *in = (const gr_complex *) input_items[0];
gr_complex *out = (gr_complex *) output_items[0];
printf("noutput_items = %d\n", noutput_items);
for (int i = 0; i < noutput_items; i += CHUNK_SIZE) {
memcpy(out, in, CHUNK_SIZE * sizeof(gr_complex));
in += CHUNK_SIZE;
out += CHUNK_SIZE;
}
consume_each (noutput_items);
// Tell runtime system how many output items we produced.
return noutput_items;
}
} /* namespace laura */
} /* namespace gr */
Ron
On 8/30/19 15:58, Laura Arjona wrote:
Thank you very much Marcus, Michael, Abin, and Ron, really appreciate
your responses.
To give some context, I just started designing a prototype reader to
implement a custom protocol for backscatter neural implants; very
excited to build my platform with GNU-radio :)
After reading all the information from your responses and links
provided, I still have a problem with my implementation. According to
the buffer sizes that you mentioned, I should not have this problem, but
I think I am missing something. I may need to re-design my
system/flow-graph, but I would like to get a last advice/help, if
possible. Thanks in advance!
_I want my block Decoder to /consume_each(>8900/) but I get overflows
"D" messages. See details below_
I have 2 general out of tree blocks: Gate and Decoder.
They both have/:/
/ ninput_items_required[0] = noutput_items;/
/ const gr_complex *in = (const gr_complex *)
input_items[0];/
/ gr_complex *out = (gr_complex *) output_items[0];
/
/
/
/
/
The flow-graph looks like /uhd_source -> /fir_filter_ccc ->/*Gate* ->
*Decode**r* -> other blocks. (Using a USRP N210 + SBX)
/
The idea is that I want the block /Decoder/ to only process the input
samples when I have received /k/ samples. Let's set k=~8900
So, at the /Decoder/ block general_work(), I set /consume_each(0)
/until /ninput_items[0]>=k./
Basically, at the Decoder general_work() I have the following (just a
overview, not pseudo-code):
/ if (ninput_items[0] <k)/
/ //do nothing/
/ //consume_each(0)/
/else/
/ // process the input samples/
/ //consume_each(k)/
/
/
My problem is that if I set k~8900/, I get 'D' messages on the terminal.
/
And one interesting? thing happens. When /ninput_items[0]/ gets close
to /k=8500/ (or higher value), is when I start getting 'D', and after
that /ninput_items[0] = 800/, no matter the value of /k/.
/
/
/
/
Thank you.
Cheers
Laura.
On Fri, Aug 30, 2019 at 7:29 AM Müller, Marcus (CEL) <[email protected]
<mailto:[email protected]>> wrote:
Hi Ron,
just because I think this might be interesting to people dealing with
really high rates:
The maximum size is typically limited by the size of mmap'able memory
that you can allocate; that depends on the circular buffer factory
used:
For the posix shared memory thing, I don't think anything is stopping
you from using "memory space size" order amounts of buffer.
For anonymous file-backed mmap'ed buffers, I'd expect that we haven't
addressed the possibility of using more than 32 bit addresses, so
somewhere around 2 GB you'd find your upper limit.
Best regards,
Marcus
On Fri, 2019-08-30 at 06:20 -0700, Ron Economos wrote:
> Just to put a number on this question, the DVB-T2 transmitter
uses up to 16 Megabyte buffers between blocks. I'm not sure what
the absolute maximum is, but 16 Megabytes should cover most
applications.
> The DVB-T2 blocks use set_output_multiple() in conjunction with
forecast() to allocate these large buffers.
> Ron
> On 8/28/19 11:46, Laura Arjona wrote:
> > Hello GNURadio community,
> >
> > Does anyone know what is the maximum number of input items
that an Out Of Tree block can consume on each input stream?
> >
> > consume_each(consumed) --> what is the maximum value that the
variable consumed can take?
> >
> > Thank you very much.
> >
> >
> > --
> > Laura Arjona
> > Washington Research Foundation Innovation Postdoctoral Fellow
in Neuroengineering
> >
> > Paul G. Allen School of Computer Science & Engineering
> > 185 E Stevens Way NE
> > University of Washington
> > Seattle, WA 98195-2350
> >
> >
> > _______________________________________________
> > Discuss-gnuradio mailing list
> > [email protected] <mailto:[email protected]>
> > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
> _______________________________________________
> Discuss-gnuradio mailing list
> [email protected] <mailto:[email protected]>
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
_______________________________________________
Discuss-gnuradio mailing list
[email protected] <mailto:[email protected]>
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
--
*Laura Arjona*
Washington Research Foundation Innovation Postdoctoral Fellow in
Neuroengineering
*Paul G. Allen School of Computer Science & Engineering*
185 E Stevens Way NE
University of Washington
Seattle, WA 98195-2350
_______________________________________________
Discuss-gnuradio mailing list
[email protected]
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
