Hello,
I have a system where I acquire a signal through an Ettus N210 at 200
kHz and I process it through a few GNURadio blocks. Those blocks include
a first low pass filtering and decimation to 1 kHz sampling rate and
further resampling down to 10 Hz or so.
In this configuration the output samples are delivered to the last block
of the flow-graph bunched in packets so that a packet is received every
3 seconds.
This does not seem to depend on the last resampling neither on the
maximum buffer site (set calling tb.run(size) where tb is the top
block of the flow-graph). I also tried to change the UHD frame size with
the recv_frame_size, but it had no effect on the latency.
As I’m trying to implement a control loop, I would like to obtain data
at a real 10 Hz rate from my last block. I think the system should be
able to handle the computing overhead just fine.
How can I accomplish this?
Thank you. Cheers,
Daniele
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 better luck just using a much higher sample rate. If you
just
decimate less, and have a sample rate of about 10 kHz you won’t have
this
problem. You’ll use more CPU, but it will still be a tiny amount.
Matt
On Tue, Mar 31, 2015 at 11:20 AM, Daniele N. [email protected]
On 01/04/15 00:30, Matt E. 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 better luck just using a much higher sample
rate. If you just decimate less, and have a sample rate of about 10 kHz
you won’t have this problem. You’ll use more CPU, but it will still be
a tiny amount.
Hello Matt,
thank for your answer. Sorry if I come back to this so late.
The low samples rate are unfortunately necessary in my application, or I
don’t know how to avoid them. What I’m implementing is a control loop
and the communication with the actuator is rather slow (commands send
through a RS232 connection).
However, I found where the problem was coming from: I was using gnuradio
fft filter implementation, and it looks like that this block has a
minimum number of output elements that increases rapidly with increasing
number of taps. I suspect this is due to alignment requirements of the
underlying fftw library, but I haven’t check that. Indeed, using higher
hardware sampling rates required longer filters and made things worst.
Switching from fft filter to simple fir filter blocks, the problem of
too large buffers goes away and at those modest sampling rates the
higher computational cost is not a problem.
Cheers,
Daniele
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
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 the reason of the subtraction in line two
of the above code snippet?
Thanks. Cheers,
Daniele