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 Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio