On 01/04/15 00:30, Matt Ettus wrote:
>
> Daniele,
>
> GNU Radio tries to maximize the size of the chunks of data it deals
> with. Clearly that works well for high rate data, but not low rate
> data. There are some handles to control buffer sizes and things within
> GNU Radio, but you may have b
*
* NEWSDR 2015 *
* *
* New England Workshop on Software-Defined Radio *
*
Dear All,
I am trying to make an out of tree module by following the tutorial on Gnu
radio website. I can write simple blocks in C++, compile it and install it
to it usable in Gnuradio company.
But for some complex block, I want to implement them based on the gnuradio
build-in blocks, for example
Hi Daniele,
alignment requirements for the FFTw aren't that strict, but you'll have
to wait for a decimation*ntaps of samples to accumulate before you can
do the FFT.
Greetings,
Marcus
On 05/13/2015 05:47 PM, Daniele Nicolodi wrote:
> On 01/04/15 00:30, Matt Ettus wrote:
>> Daniele,
>>
>> GNU Ra
Hi Su Li,
have you added the new source files to the CMakeLists.txt in lib,
include and grc?
Do these block have the YOURMODULE_API property?
Best regards,
Marcus
On 05/13/2015 06:38 PM, Su Li wrote:
> Dear All,
>
> I am trying to make an out of tree module by following the tutorial on
> Gnu rad
Hi Marcus,
Thank you for your reply.
The source files are added to the CMakeLists.text files. But they are not
added by my self, they are added when I use "gr_modtool add -t general
my_block" and "gr_modtool makexml my_block" to make a new block and xml
file.
Only the my_block.h file in include
I've had a similar problem when I generated files for my own module
using the gr_modtool and then copied some existing code by replacing the
file(s) that gr_modtool generates. It turns out I had overlooked that
the new "my_block" name needs to be changed in several places, like the
namespace de
Hello Marcus,
I went looking at the code and I found this:
d_fftsize = (int) (2 * pow(2.0, ceil(log(double(ntaps)) / log(2.0;
d_nsamples = d_fftsize - d_ntaps + 1;
set_output_multiple(d_nsamples);
which I'm not sure I understand, but is in agreement with what I
observe. Can someone explain t
I have 5 blocks in my flowgraph:
USRP Src -> PFB Decim by 2 -> Mult 32768 -> Cplx-iShort -> FileSink
I am running 14 MS/s x 2 x 32 bits from the USRP, 7 MS/s x 2 x 16 bits
to the disk.
Previously, even setting the USRP num_recv_frames=512 or 1024, it
would run for about a minute fine then print 1-4
