[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Discuss-gnuradio] timestamp tags and set_min_output_buffer

From: Juha Vierinen
Subject: Re: [Discuss-gnuradio] timestamp tags and set_min_output_buffer
Date: Wed, 9 Oct 2013 15:42:35 -0400


I've modified the code. I now call set_output_multiple(nfft) in the constructor. This is probably for the better, as I can now use sync_block again. I also got rid of the buffer size error message on larger fft sizes. 

However, I still have the problem with random rx_time tags triggered in the beginning of the acquisition. I'll keep investigating this. It could be that this is a feature of the n200 + gpsdo combination. 


On Wed, Oct 9, 2013 at 3:09 PM, Tim <address@hidden> wrote:
On 10/09/2013 02:59 PM, Juha Vierinen wrote:

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?


Discuss-gnuradio mailing list

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.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]