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

[Tom Rondeau]

On Mon, May 18, 2015 at 5:14 PM, Andy Walls <address@hidden> wrote:

On Mon, 2015-05-18 at 12:01 -0400, address@hidden
wrote:

> Message: 4
> Date: Mon, 18 May 2015 09:52:26 +0200
> From: Marcus M?ller <address@hidden>
> To: address@hidden
> 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