[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Discuss-gnuradio] costas ambiguity and correlate-and-sync block in
From: |
Landsman, Arik |
Subject: |
Re: [Discuss-gnuradio] costas ambiguity and correlate-and-sync block in qpsk |
Date: |
Sun, 13 Mar 2016 00:02:49 +0000 |
quick update - thinking about it a bit more thoroughly, the up-sampling
approach I considered below won't likely correlate as well as picking a
preamble such that its real portion is the same in both bpsk and qpsk.
________________________________________
From: Landsman, Arik
Sent: Saturday, March 12, 2016 4:34 PM
To: address@hidden
Subject: costas ambiguity and correlate-and-sync block in qpsk
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?
Thank you in advance,
Arik