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

[Landsman, Arik]

Hi Andy, 

I gave it a few more touches since we last spoke, but to no avail... Costas 
still flips sporadically on a simulated channel. 

Generally the corr_est block would show a large spike in |corr|^2 on the very 
first packet I send (>1600), but on all subsequent loops (same packet) the 
value diminishes to ~100 with multiple peaks. 

I tried various preamble formats and sizes, including an 8 byte long version to 
avoid any possible corr with payload. corr^2 certainly changes but results in 
either multiple peaks at low levels (say 100 and 140), or with a huge spike at 
start as mentioned. 

I can generate  tags by reducing the threshold to extremely low values (say 
0.1, 0.3), which I suppose makes sense with the delta between the first and 
subsequent spike levels. 

In either case there are more than one tag generated per packet as the packet 
loops. Only one preamble per packet, non repeating.


matched filter taps - can the corr_est block accept taps in any way? I'd like 
to hold sps=8 at least for the time being, and without a filter there is little 
correlation between the stream and the reference preamble. sps=2 was too low 
for timing recovery without a preamble.  what do you generally use? (btw all of 
the debug above was with sps=2). 

 I am told I've been loosing sleep over this.. in any case I'll keep trying but 
in the meanwhile if you had any comments I would deeply appreciate it.

Many Thanks,
Arik 





 



From: Landsman, Arik
Sent: Monday, March 14, 2016 11:59 AM
To: Andy Walls; address@hidden
Subject: RE: [Discuss-gnuradio] costas ambiguity and correlate-and-sync block 
in qpsk

Hi Andy,

Thank you for the detailed answer, I am certainly going to try what you suggest 
in the next couple of days. will post with updates as progressing along.

As a side, I tried to hack the corr_and_sync block using a preamble which in 
BPSK looks the same as both I and Q of the QPSK data (e.g. [1,-1] in bpsk is 
[1+j,-1-j] in qpsk). This does not quite work in practice, I was getting 
sinusoids with very weak correlation (amplitude in 30's 40's) from the corr 
port. Strange, since the block should ignore the imaginary portion of the 
stream anyways since designed for BPSK.

in terms of a clock pattern for preamble, looks like Barker codes is the way to 
go, at least statistically speaking for low correlation with any random 
"preamble-like" bit combinations in the payload. So avoiding clock patterns for 
sure.

Will look to tag the end of preamble, from your comments it appears to be the 
more universal approach. In my case freq lock should be fairly good though,  
channel is largely stationary, and I am using a FLL (although it does require 
longer bit combinations that are to result in a balanced spectrum to detect 
band edges). point well noted though.

You mentioned M&M for timing recovery, have you tried the Polyphase  block?  
without passing tags, I had better results with the latter for whatever reason. 
 MM is more efficient though as I read.

Just to clarify, were you capturing the time_est tags, or just relying on a 
combination of phase_est for costas and MM converging fast enough ahead of 
payload?

finally, would you know of any good references for passing tags in gnuradio? I 
will certainly search around, but in case anything comes to mind (?)

Best Regards,
Arik



P.S. - In case it helps future causes - see "Phase-ambiguity resolution for 
QPSK modulation systems" by Nguyen, Tien Manh, NASA, 1989. Part1 outlines the 
basic two approaches for correcting phase, which are diff encoding or preamble 
correlation. The preamble algorithm there is very much similar to the one Andy 
describes, although likely implemented as an IC (aka ASSP). In this case the 
author suggests diff encoding for burst transmissions, since bits are wasted on 
a preamble (which theoretically has 2x BER compared to diff encoding).

That said, if phase rotation occurs in mid-payload the full packet is lost, 
unless some form of post-processing is used to recover - so at higher SNR diff 
encoding is possibly better. But I am yet to find a publication that compares 
real data on the topic.

http://ntrs.nasa.gov/search.jsp?N=0&Ntk=All&Ntt=Phase-ambiguity%20resolution%20for%20QPSK%20modulation%20systems&Ntx=mode%20matchallpartial



 ________________________________________
From: Andy Walls address@hidden
Sent: Sunday, March 13, 2016 8:51 AM
To: address@hidden
Cc: Landsman, Arik
Subject: Re: [Discuss-gnuradio] costas ambiguity and correlate-and-sync block 
in qpsk

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