Re: [Discuss-gnuradio] Correlation Estimator Bugs

[Andy Walls]

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.


> 
> 
> Observations:
> 
> 1) The choice of AGC effects proper tag placement. If I use the Feed
> Forward AGC, the correlator tags the correct peak. If I use the AGC
> block, the correlator often misplaces tags so that packet drops occur.
> I often see on the plots tags that are way out in the middle of no
> where that should not be there.

So optimally doing the wrong thing, is still doing the wrong thing.  If
the normal AGC block gives you those effects, you really can't use it.
Knowing the underlying root cause probably won't matter to you in the
end.

The AGC is going to ramp up noise to +/- whatever reference level you
set.  If your preamble looks like pseudo-random noise, you're going to
correlate to noise on occasion.


> I can't use the Feed Forward AGC however, because its so processor
> intensive it eventually leads to D's (packet drops at the USRP from
> buffer overflow).

Huh, I guess I never profiled the FF AGC.  I usually throw lots of CPU
horsepower at SDR problems at first and then optimize later.

The FF AGC will consume less CPU, if you specify a smaller
"num_samples".

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".
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.

> 
> 2) Whether there is an AGC or not in the system, I often see a false
> tags placed near the real peak. The real peak will get tagged
> correctly, but the next sample after the real peak will also be
> tagged. I attribute this to the scheduler buffer alignment issue that
> I've brought up in other emails. I'll attach that picture again here
> for completeness.

Yup.  That can happen.  I assume you are using a barker code or
something else which has a nice single correlation peak.

The reason it can happen is right here:
https://github.com/gnuradio/gnuradio/blob/master/gr-digital/lib/corr_est_cc_impl.cc#L251
because we're looking for a peak right as we run out of samples in this
particular call to work.
So you'll cross the threshold at the beginning of the next call to work
too, and mark a peak there too.

There are many reasons why this is too hard to fix in the block itself.

The way to deal with it is to have the down stream blocks that care,
look at the value stuffed in the corr_start or corr_est tag and pick the
larger of the two if they fall within some window of samples you define.

For things like AIS where the preamble is not so nice:
110011001100110011001111, one often gets 3 nearby correlation peaks.
Downstream blocks have to make a decision about which peak they want to
use in this case: the first?  the strongest?
If doing TOA processing, maybe the first is best.

Your can write a custom block that looks for this situation and strips
out the duplicate nearby tag.  That way you can leave all the other
downstream blocks blissfully unaware.  Be advised your custom block will
still have to deal with the work boundary problem, but it should be
easy, since it's job doesn't have the other functional constraints of
the corr_est block.

> 
> Is anyone using the correlation estimator block with a real radio over
> the air successfully for extended periods of time? If other people
> have this working, then I know it's user error on my part. Can you
> maybe give some details of the blocks your using around it to get it
> to work?

All the time with AIS myself.  After channel filtering and downsampling
to 96ksps, I run it through a coarse freq sync process, feed forward
AGC, and then the correlator block. 


Regards,
Andy

> Lastly, I've heard rumors of an example GNU Radio BPSK example that
> works over the air, but I have no idea where to get my hands on that.
> I'd love to see how it works. Would someone point me to that please.
> 
> 
> Appreciated,
> 
> Rich