discuss-gnuradio
[Top][All Lists]
Advanced

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

Re: [Discuss-gnuradio] Which blocks do you like?


From: marco Ribero
Subject: Re: [Discuss-gnuradio] Which blocks do you like?
Date: Mon, 18 May 2015 10:41:50 +0000

For the bug, wouldn't be sufficient to substiture the above code

 // Find the magnitude squared of the correlation
      std::vector<float> corr_mag(noutput_items);
      volk_32fc_magnitude_squared_32f(&corr_mag[0], corr, noutput_items);

with:

      std::vector<float> corr_mag(noutput_items+1);
      volk_32fc_magnitude_squared_32f(&corr_mag[0], corr, noutput_items);       corr_mag[noutput_items]=-1;
In theory the vector cannot contain negative value.


Actually I'm not usign sync_block,but only the generick gr::block..I try to explain how I am currently managing memory:
between each couple of attached block,where is a circular buffer(e.g. 32 position if we don't have problems with latency),where each element is a device memory page(e.g. with 4096 elements).
At the beginning,for each link the bottom block send his preference about memory(e.g. min/max size,history page,mandatory divisor for each page[mandatory for FFT],other stuff)..the upon block will take decision about memory,sending down its choices. (for multiple input blocks attached to same output things would be similar)
So it is possible that for a "synch_block" the number of input page is different to n° output page.
Usually CUDA blocks send only one item each time to following block in order to wake up.(data are passed throught device memory and others)

The final return and consume_each() are done according if all elements in CUDA buffer were consumed or not,and if there are new items in output

reply via email to

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