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

[Andy Walls]

On Fri, 2016-03-25 at 22:14 +0000, Landsman, Arik wrote:
> 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. 

That doesn't seem right.


> 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?

No.

The idea with corr_est is to give it exactly the reference samples that
you are looking to match against.

That usually means building them with one of the gnuradio modulator
blocks *and* discarding the the initial samples which are a transient
emitted during the initial delay of the gnuradio particular modulator.

Look at the GRC file I just posted to the list regarding "GMSK 9600
baud".  I had a modulator build the preamble samples. I had to add in a
few flush/fill bits at the end of the preamble, which never get emitted
by the modulator. I had to discard the initial transient emitted by the
modulator.

>  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 use sps=10 with low data rate stuff.

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

If you have a flowgraph that you could share that simulates the input,
I'd would probably be easier for me to see what's wrong about the
corr_est process.

Regards,
Andy

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