Hello Marcus, I checked my sliding fft works fine and the bug was somewhere else :)
In fact I want to detect a known sequence within data non-coherently. After detection I want to neglect this 'work' process. How would you prefer to stop this work process after detection? (Something like putting this thread to sleep! ) Best, Mostafa On Sat, Oct 25, 2014 at 3:56 PM, Marcus Müller <[email protected]> wrote: > Hi Mostafa, > > >is there any "race" problem between these 2 threads and the work one? > I think you might be confused what the FFT multithreading means here; I > hope I can illustrate this. Let's set the FFT multithreading level to two > threads: > > sliding_fft_impl::work() > | > enter "fft->execute" > spawn thread 1 & spawn thread 2 > | | > calculate calculate > | | > +--------v-------+ > join threads > | > return from "fft->execute" > continue ::work > > The work thread waits for fft->execute to return; there can be no > interference while the fft threads run, because at that time, the work > thread isn't "active". > > >Inj another words, is it possible that this work being called before > finishing the fft execution? > > no, a single block's work() cannot get called before the previous run of > work() has finished. That wouldn't make any sense -- how would the second > work now how many input samples it has, if the first one hadn't already > consumed? > > Your code looks correct. I know I tell you this in almost every discussion > on here, but: > Please, tell us what "undesired" means. That would greatly reduce the > guesswork for the rest of the mailing list. > > Also, sliding FFTs do look like a computational heavy load. What is the > application for that? I ask because getting an fft_length FFT for every > item increases item/sample rate without giving you > (information-theoretically speaking) any advantage over doing one FFT ever > fft_length samples. > > Greetings, > Marcus > > > > On 10/25/2014 12:03 PM, Mostafa Alizadeh wrote: > > Hi all, > I have the following c++ code which gets fft by sliding on sample by > sample fo the input. > > /* > > * The private constructor > > */ > > sliding_fft_impl::sliding_fft_impl(uint fft_size) > > : gr::sync_block("sliding_fft", > > gr::io_signature::make(1, 1, sizeof(gr_complex)), > > gr::io_signature::make(1, 1, fft_size * sizeof(gr_complex))), > > d_fft_size(fft_size) > > { > > d_fft = new fft::fft_complex (d_fft_size, 1, 2); > > set_history(fft_size); > > } > > sliding_fft_impl::~sliding_fft_impl() > > { > > delete d_fft; > > } > > int > > sliding_fft_impl::work(int noutput_items, > > gr_vector_const_void_star &input_items, > > gr_vector_void_star &output_items) > > { > > const gr_complex *in = (const gr_complex *) input_items[0]; > > gr_complex *out = (gr_complex *) output_items[0]; > > memcpy(d_fft->get_inbuf(), in, d_fft_size * sizeof(gr_complex)); > > d_fft->execute(); > > memcpy(out, d_fft->get_outbuf(), d_fft_size * sizeof(gr_complex)); > > //delete d_fft; > > return 1; > > } > > If I run the fft execution on 2 threads, or more, is there any "race" > problem between these 2 threads and the work one? Inj another words, is it > possible that this work being called before finishing the fft execution? > > If it is so, there will be a race problem because "work" wants to write on > d_fft->get_inbuf() while fft execution wants to read from it! > > please help me with this code. I don't know why at the runtime, the data I > give at the output aren't desired after a while!! > > Best, > > Mostafa > > > > _______________________________________________ > Discuss-gnuradio mailing > [email protected]https://lists.gnu.org/mailman/listinfo/discuss-gnuradio > > > > _______________________________________________ > Discuss-gnuradio mailing list > [email protected] > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio > > -- *********************************************************** Department of Electrical Engineering Aboureyhan Building MMWCL LAB Amirkabir University Of Technology Tehran IRAN Tel: +98 (919) 158-7730 LAB: http://ele.aut.ac.ir/~mmwcl/?page_id=411 Homepage: http://ele.aut.ac.ir/~alizadeh/ ***********************************************************
_______________________________________________ Discuss-gnuradio mailing list [email protected] https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
