Re: [Discuss-gnuradio] Correlation Estimator Bugs

[Andy Walls]

On Fri, 2015-07-17 at 16:54 -0400, Andy Walls wrote:
> On Wed, 2015-07-15 at 16:30 -0700, Richard Bell wrote:
> > Hi Andy,
> > 
> > 
> > I've been pulling my hair out trying to figure out how I'm using this
> > block wrong, or if it's bugs I'm seeing. I don't feel much closer to a
> > decision. Let me explain what I've been seeing and hopefully you or
> > someone else can shed some light on it.
> > 
> > 
> > The Setup:
> > 
> > A BPSK modulated single carrier radio using USRP N210's. The order of
> > blocks in my receiver are as follows:
> > 
> > 
> > USRP -> Power Squelch -> AGC -> FLL Band Edge -> Correlation Estimator
> > -> Polyphase Clock Sync -> Costas Loop -> LMS DD Equalizer ->
> > Header/Payload Demux -> Rest of Demodulation Chain
> 
> No channel filtering or down sampling before the power squelch?
> 
> Things outside of your desired channel can break your squelch.  You
> should be channelizing.
> 
> USRP usually only support certain rates (e.g. 500 ksps) which are
> usually a much higher rate than you need for a single narrowband
> channel.  Downsampling early will give you back CPU for everything else.

Also, why are you using squelch for a data channel?  Normally you only
need squelch for voice or audio.  Modems don't care about garbage coming
in, as they have to deal with it anyway.

[snip]

> The FF AGC block could stand some improvement.  Just off the cuff:
> 
> 1. It does a bubble-sort-ish search for the max on num_samples for every
> new sample. That's O(n^2).  A quicksort and then plucking the max value
> would be better for largish values of "num_samples".

Bah, forget the nonsense about sorts.  I don't know what I was thinking.
Still, improvements can be made to the block.

> 2. It could also cache the envelope values it computes for samples
> instead of continually recomputing them.
> 
> I'm sure there's other things that can be done to that block's
> internals.
> 

Regards,
Andy