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