Re: [Discuss-gnuradio] Correlation Estimator Bugs

I'm really glad you confirmed my conclusion about the false tag placement. I've been debugging this for so long, I stopped trusting any of my own conclusions. I'll write a block that picks the tag with the highest corr value and that should take care of it for my purposes. Thanks for the motivational boost!

I'm not using a Barker code, because they are so short. I'm using a 106 bit pseudo random sequence that does produce a nice big peak.

I'm using a power squelch to protect the synchronizers from tracking noise, which can make synchronization take longer if they go off into la la land and have a ways to come back. I realize that the correlation estimator would make that a non-issue if it's tag estimates were correct. I don't have enough confidence in the block yet to trust it. It's been weeks of banging my head against the wall thinking this block is the source of my problems. I'm still not even sure it is.

I used ctrl ports to profile the feed forward AGC. It was by far and away the most processor intensive block in my modem with a block size of 1024. That's not a big deal if the computer can handle it, but I found it was causing D's to creep up after a little time. The flowgraph couldn't keep up with the sample rate of the USRP. I'm only using a sample rate of 320k, so there isn't much lower I can go. With the AGC block there is no issues with D's and processing time. Using a block size less than 1024 proved no good for the modem. It would fail in other ways.

Finally, as far as downsampling at the input of the radio, with a symbol rate of 80k and 4 samples per symbol that brings me to 320k and that is what I run the USRP at, so I'm at the minimum sample rate for my symbol rate already. I do have a filter at the input to minimize out of band noise.

Thank you for all the feedback, I really needed it. I think I'm going a little insane over here with this radio!

v/r,

Rich

On Fri, Jul 17, 2015 at 2:17 PM, Andy Walls <andy@silverblocksystems.net> wrote:

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