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 Nicolodi <dani...@grinta.net> wrote: > 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 > > > _______________________________________________ > Discuss-gnuradio mailing list > Discuss-gnuradio@gnu.org > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio >
_______________________________________________ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
