Re: [Discuss-gnuradio] costas ambiguity and correlate-and-sync block in qpsk

[Andy Walls]

On Tue, 2016-04-05 at 00:00 +0000, Landsman, Arik wrote:
> Hi Andy, 
> 
> Added a few comments inline (marked with "==" in lieu of a better email 
> client)..
> 
> But overall corr_est works very consistently. I did have a few observations: 

Hi Arik:

For my responses to the next two, I'm assuming that ultimately you'll be
working with a radio modem that sends bursts of energy and then cuts off
RF energy.   And that you'll also be tuning the RF down-conversion
receiver such that the RF channel of interest is either completely above
or below the DC spike in the receiver.


> - changed feed-forward AGC num_samples = 128 (from 2048, to allow
> faster recovery with fading ch sim). The value has some effect on
> whether the first packet correlates or gets scrambled.

When you have a constant envelope waveform that's transmitted in bursts,
you should use a smarter AGC.

Some other oh b the ways:
- you may want to keep your bursts short relative to the fade variation
time.
- you may want to perform AGC before the channel is frequency rotated
down to baseband.  For complex streams it doesn't matter so much, the
magnitude when passing through DC will still be OK; but for real streams
with components near DC, the instantaneous phase can really throw off
the magnitude computation.
- don't receive with your direct down-conversion receiver tuned to the
center of the channel of interest, the DC spike and images from I/Q
imbalance will mess with the envelope.


So, one sketch for implementing a smarter AGC is, for example:
a) Write yourself a burst/energy detector block (ideally one that has a
message input port for noise floor estimate messages from another block)
that tags at least the start of a burst with a "rx_sob" tag.  You can
tag the "rx_eob" too, if it helps you.
  
(Be warned, writing a robust energy detector in gnuradio, where bursts,
including declaration windows, can span calls to work() or be completely
contained in a call to work, is not as easy as it first seems.)
 
b) Write a Feed Forward AGC block that is sensitive to the rx_sob tag
(and rx_eob tag if needed), looks at the envelop somewhere after the
tag, and then applies an appropriate gain until the next rx_sob tag is
encountered.  You at least want the preamble to have a nice, constant
envelope.

c) The extra mile: Write a noise floor estimation block that uses a
Forward Consecutive Mean Excision algorithm that periodically, on a
random subset of time domain samples in the interval, estimates a noise
floor threshold with a certain probability of false alarm.  It should
emit a message each interval that the burst detector block can use as
it's new threshold between signal and noise. 


> - added FLL for course freq alignment, which you alluded to below.
> this works well only on a uniform spectrum, so repeating 4B 4B symbols
> was causing issues.. initially setting eb=0.5 and increasing the
> filter size helped a bit.

Well, in reality, in a system with bursts with a preamble, you can do
better than the FLL. You can implement a Data-Aided coarse frequency
correction.

One possible implementation:

1. As with the AGC above, use a burst/energy detector to mark the start
of burst with a rx_sob tag.

2. Since the first 6 bits (i.e. three symbols) of your preamble are
constant 1s, the slope of the phase, i.e. d(phi)/dt (aka the
instantaneous frequency) of the center of this group of three symbols
should be 0.  If d(phi)/dt is not 0, the properly scaled d(phi)/dt is
the carrier frequency offset of your signal.  You can write a block to
look for the rx_sob tag, and compute the frequency correction from the
preamble, and tag the burst with the freq_offset value.  The quadrature
demodulator block has the math you need for computing d(phi)/dt.

3. Write a block that watches for the freq_offset tags, and then
performs a frequency rotation (aka spectrum rotation) of the signal in
the opposite direction by that amount, to remove the frequency offset.
The rotator block has the math you need to do the rotation.
Writing your own "rotate by tag value" block should be pretty easy.


>   
> - with tx_sps=10, setting *output* sps values for the polyphase block
> to anything other than 2, 5, or 10 results in a periodic phase
> rotation. my guess is the tagged packet was getting dropped at the
> polyphase output when tx_sps % osps != 0, i.e. tx_sps/osps should be
> an integer. 

Proper tag propagation through rate changing blocks is a known
headahce. :(

I'm sure Tom wouldn't mind you testing out these fixes for him:

https://github.com/gnuradio/gnuradio/pull/758



> I was half-expecting your answer on alternate way for generating the
> samples via a separate flowgraph :)  nevertheless thank you for the
> level of detail, as always. 

The modulate vector block was supposed to eliminate the need for that.
Unfortunately, unpredictable filter delays mean that one almost has to
do something equivalent in effort to a separate flowgraph anyway, to
find the correct sample sequence. :(


> My plan is to change tx_sps to something other than 10, and try to
> repeat your calibration method (i.e. the symbol trimming). I hope you
> don't mind another question or two as I go along.  

> Best Regards,
> Arik 


> == very much appreciated, lots of good information here. Going to spend a bit 
> more time on it in the next couple of days.  

You're welcome.

Regards,
Andy