On Mon, May 18, 2015 at 5:14 PM, Andy Walls <[email protected]> wrote:
> On Mon, 2015-05-18 at 12:01 -0400, [email protected] > wrote: > > > Message: 4 > > Date: Mon, 18 May 2015 09:52:26 +0200 > > From: Marcus M?ller <[email protected]> > > To: [email protected] > > Subject: Re: [Discuss-gnuradio] Which blocks do you like? > > [snip] > > > > > > > std::vector<float> corr_mag(noutput_items); > > > int i = d_sps; > > > while(i < noutput_items) { > > > if((corr_mag[i] - corr_mag[i-d_sps]) > d_thresh) { > > > while(corr_mag[i] < corr_mag[i+1]) > > > i++; > > > > > > is not possible that the variable i will go outside the > > > array corr_mag?I know that is necessary a strange pattern in order to > > > have the last item greater than the previous.. > > > > > I agree, relying on the signal to limit execution of this loop feels a > > bit "dangerous", but I also agree that as long as your "known symbol" > > has a sane shape, this won't be a problem. The problem is that this is > > indeed a bit of a CPU-hungry bit of code, so every additional condition > > might slow things down; I think it should be possible to come up with a > > nearly-as-effective implementation that is more secure, but I can't > > think of one right now. Any hints? [1] > > At any rate, the outer `while` shouldn't run till `noutput_items`, but > > till `noutput_items - 1`, because of the inner `while(corr_mag[i] < > > corr_mag[i+1])`. Thanks for spotting that!If you don't mind, I'd like to > > ask you to fix that line > > (`while(i<noutput_items)`->`while(i<noutput_items-1)`)and submit a pull > > request on github [2] (if possible, base it off the "maint" branch). > > Hi Marcus and Marco, > > The corr_est block fixes this bug, and a few others, that the original > correlate_and_sync block has. The corr_est block should perform > reliably, whereas the correlate_and_sync block does not, due to bugs. > They are different blocks because the corr_est block has different input > arguments, to handle more general cases. > > If you wish to spend time optimizing the performance of a block, I'd > recommend you optimize the corr_est block, not the correlate_and_sync > block. Optimally doing something unreliably is still doing something > unreliably. :) > > Regards, > Andy Plus this block will be removed in 3.8, so it doesn't have a long life left. Tom
_______________________________________________ Discuss-gnuradio mailing list [email protected] https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
