On 10/09/2013 02:59 PM, Juha Vierinen wrote: > Hi, > > I'm writing a block that always outputs the same number of items as it > gets in. > > The block is doing FFT on a fixed length vector, so I always need nfft > samples in and nfft samples out. I've achieved this (I think) by > using: set_min_noutput_items(nfft) and set_max_noutput_items(nfft). > However, when I increase nfft to 8192, I get a message about not > enough buffer space. I tested various things and ended up calling > set_min_output_buffer(2*nfft) as just nfft wasn't enough. It all > seems to work nicely, except that the rx_time tags are screwed up -- I > get a nearly random offset in the beginning, even though there are no > dropped packets on the USRP. > > Is this a bug or a feature? What is the correct way to increase the > value of noutput_items without breaking rx_time tags? > > juha > > > _______________________________________________ > Discuss-gnuradio mailing list > Discuss-gnuradio@gnu.org > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio Juha,
An easier way to achieve this is, is calling set_output_multiple(nfft) in the block constructor - which assures noutput_items = n*nfft where n >= 1 then if its a sync block without the relative rate or forecast being change, it will also assume it also needs nfft items each work call set_min_noutput_nitems and set_min_output_buffer are bigger hammers that probably shouldn't be used in this case unless you have really big vectors - I think by default there should be no problems with an output multiple <= 8k are you consuming nfft each time in your current block? If it is providing you nfft+extra samples each time through work you would get strange offsets if you simply consumed noutput_items each time. -Tim
_______________________________________________ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
