Re: [Discuss-gnuradio] How to control latency

[Daniele Nicolodi]

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


On 13/05/15 18:45, Marcus Müller wrote:
> 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 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
>>
>>
>> _______________________________________________
>> Discuss-gnuradio mailing list
>> address@hidden
>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
> 
> 
> _______________________________________________
> Discuss-gnuradio mailing list
> address@hidden
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>