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

[Andy Walls]

On Sun, 2016-03-13 at 01:35 -0500, address@hidden
wrote:
> Message: 1
> Date: Sat, 12 Mar 2016 21:34:03 +0000
> From: "Landsman, Arik" 

> 
> Hello folks, 
> 
> I am trying to resolve the 90* ambiguity of costas for a QPSK
> receiver, and was hoping folks could weigh-in in case anyone had
> success with this in the past. 
> 
> yes, diff encoding works.. :) trying to make it work without though. 
> 
> Also, I had seen Tom R's example of his cor-and-sync block
> implementation in BPSK (but not qpsk). maybe the block could be
> "hacked" to support qpsk, such as by passing the preamble as bpsk but,
> say, upsampling the block to make the generated complex reference
> align with the incoming qpsk stream. going to try this when I get home
> tonight. 
> 
> Since Trx will be bursty and will use a preamble anyways, another
> thought was to correlate the stream with the 4 possible versions of
> the preamble (i.e. constellation rotations), and pass the best
> candidate downstream to select the proper constell object for demod
> (as opposed to adjusting costas, as in cor-and-sync block), or use the
> result for post-processing the incorrectly demodulated data. But both
> seem a bit indirect or wastefull..
> 
> Any thoughts?  

Using a preamble makes sense to me.

Do not use the correlate_and_sync block; it is unreliable and provides
and errant "phase_est" value.

Use the corr_est block; it does correctly and more generically what the
correlate_and_sync block aimed to do.

To use the corr_est block:

1. Generate a vector of samples which represents your preamble.  A
test_corr_est.grc file can be found here:

https://github.com/gnuradio/gnuradio/tree/master/gr-digital/examples/demod

which should give an example of how to use gnuradio modulator blocks to
build the preamble samples vector for you.  You could also use, pyhton,
Matlab, octave, or whatever.


2. Tell the corr_est block where on the preamble you want it to place
the tags.  You must give the tag delay in units of samples.  Common
choices are:
a. start of preamble
b. middle of first symbol after start of preamble
c. middle of last symbol before end of preamble
d. end of preamble

3. The corr_est block outputs the following tags:

corr_start: that start of your preamble

corr_est: the absolute value of the correlation squared

phase_est: the phase offset between the reference preamble and the
received preamble at the sample corresponding to the correlation peak
(which happens at the end of the preamble).

time_est: the fractional sample delay from the sample that is at the
correlation peak to where the actual coorelation peak (which happens in
between samples) 


4. If you are well synchronized in frequency, you can just apply the
phase_est correction to the whole burst with a phase rotation by
multiplying the burst by exp(1.0j*-phase_est_value), IIRC.

If you are not well synchronized in frequency, the phase_est value is
only sensible to apply at the samples at the end of the preamble.
But that's enough to resync a tracking loop.


5. Modify your downstream blocks to look for the above tags, and reset
their state as appropriate, to acquire and maintain synchronization.

6. BTW, avoid a preamble that has a clock pattern (1010101010..).  It
causes duplicate correlation peaks (which you then have to inspect the
corr_est tag for the highest value), and the M&M clock recovery block
really drifts off such preambles badly for some reason.

> Thank you in advance, 
> Arik 


Regards,
Andy