The function call set_output_multiple() is your friend. You can specify
the size of the output buffer explicitly (although it may be 2X, 3X,
etc. of that size). Here's some example code.
Ron
#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 michael {
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 michael */
} /* namespace gr */
On 11/24/19 16:32, Michael Bassi wrote:
Hi guys,
Firstly, I feel obliged to explain that I'm a young engineer
relatively new to Linux, SDR, GNU radio and USRP, and currently
overwhelmed with the task assigned to me! Many thanks in advance to
any help provided. First time posting to the
I have written a custom OOT block for GNU Radio that reads in
information from a file (in this case, pulse width (PW), and pulse
repetition interval (PRI)), and outputs a corresponding waveform with
matching characteristics. I am attempting to run this from a USRP E312
device. It is currently partially working, and I have several questions:
1/ In the work function, an output array is provided as follows "out =
output_items[0]". The length of this array seems to be maxed at 8192,
however some times it's much less. Is this because the scheduler
doesn't always have enough resources to do the send the full 8192 - I
found this statement GNU website somewhere, is it related to this
'phenomenon'?
/* By default, GNU Radio runs a scheduler that attempts to optimize
throughput. Using a dynamic scheduler,blocks in a flowgraph pass
chunks of items from sources to sinks.The sizes of these chunks will
vary depending on the speed of processing. For each block, the number
of items it can process is dependent on how much space it has in its
output buffer(s) and how many items are available on the input
buffer(s). */
Could someone please explain the output_items object to me?
2/ This is how i'm setting the output, out array within my custom
block work function:
self.num_samples_pri = int(self.sample_rate * float(self.pri))
self.num_samples_pw = int(self.sample_rate * float(self.pw))
for i in range(self.num_samples_pri):
if i < len(out):
if i < self.num_samples_pw:
out[i] = 1
else:
out[i] = 0
If the out array length is < num_samples_pw, my waveform is cut short,
and I get uneven spacing between some of the waveform pulses.
My question is, how do I deal with this issue? I have tried to
appending more elements to out array, but they seem to be ignored.
3/ I have built a GRC project with my custom block as source, and UHD:
USRP sink block as output so that I can run my project soley on the
USRP device with no connection to the PC.
When I run the compiled file on my USRP device, I am getting
continuous under-run errors.I know that under-run occurs when a block
is not receiving enough samples. In my case, the sample rate used in
my code matches that entered in the UHD USRP sink block. D
Is the underrun occurring because my USRP device isn't running my
custom code fast enough?
How do I deal with this?
4/ Should I be using custom blocks written in C++ instead of python,
when the intent is to run on the USRP device. I have heard that C++ is
faster.
5/ I was able to run my custom PYTHON block from the USRP by copying
the gr-custom_block folder to the device, and building using cmake,
etc. however the C++ implementation of my custom block was not
recognized.
AttributeError: 'module' object has no attribute 'readfilesource_cpp'
I got some advice on stack overflow about setting up a cross
compilation tool-chain, and recommended Ettus procedures to follow
AN-311 and AN-315. However, It was a struggle.
I would love some more advice on this!
Cheers,
Mike
