I am using a Costas loop for carrier recovery with QAM16 data. The
carrier is only 2khz. The I/Q output of the Costas loop seems to track
(the original sin/cos of the modulating carrier’s Frequency & Phase)
steadily for a long period (minutes) and then the Phase moves off,
normally in +/- 45 or 90 degrees in one or both of the phases. Any
thoughts on why this occurs or how I can fix this issue?
Thanks…Tom
On Thu, Oct 10, 2013 at 9:30 PM, tom sutherland [email protected]
wrote:
I am using a Costas loop for carrier recovery with QAM16 data. The carrier
is only 2khz. The I/Q output of the Costas loop seems to track (the original
sin/cos of the modulating carrier’s Frequency & Phase) steadily for a long
period (minutes) and then the Phase moves off, normally in +/- 45 or 90
degrees in one or both of the phases. Any thoughts on why this occurs or
how I can fix this issue?
Thanks…Tom
Tom,
The Costas loop is not designed to handle QAM16. It only works for
BPSK, QPSK, and 8PSK. My guess is that you are using an order 4 loop?
What’s probably happening is that the symbols at the four corners of
the constellation are dominating the error calculations because they
have the highest energy. But the loop can get biased by another symbol
in the constellation that turns it to another phase lock. The Costas
loop has no idea what the right constellation is; it’s just minimizing
an error function and has probably gotten trapped in a local minimum
that your constellation presents to it.
I would suggest turning instead to the constellation_receiver block.
This allows you to specify the constellation you want it to handle.
The constellation objects
(http://jenkins.gnuradio.org/manual/doxygen/page_digital.html) allow
you to specify a symbol mapping to a set of complex points. There are
specialized forms of the constellations for certain known types (BPSK,
QPSK, etc.) that have more computationally efficient decision making
functions. But for any given constellation, it will at least be able
to calculate the minimum Euclidean distance between each point. Slow
but reliable.
Tom
On Fri, Oct 25, 2013 at 4:56 PM, tom sutherland [email protected]
wrote:
Tom,
I don’t quite understand the use of the “Constellation Receiver” block. I
have transmitter and receiver and I was trying to use the Costas Loop to
replace the mixer section in the receiver to produce the I/Q signals needed
by the16QAM demodulator. Since the signal I am wanting to demodulate is a
real-signal and the Constellation Receiver accepts complex input, where does
that signal come from? I have attached a simple diagram without filters.
Tom
The image didn’t really come through on your email.
I’m confused how you can do 16QAM with a real signal? You need phase
information for that.
Tom
Tom,
I don’t quite understand the use of the “Constellation Receiver” block.
I have transmitter and receiver and I was trying to use the Costas Loop
to replace the mixer section in the receiver to produce the I/Q signals
needed by the16QAM demodulator. Since the signal I am wanting to
demodulate is a real-signal and the Constellation Receiver accepts
complex input, where does that signal come from? I have attached a
simple diagram without filters.
Tom
On Wednesday, October 23, 2013 10:37 AM, Tom R. [email protected]
wrote:
On Thu, Oct 10, 2013 at 9:30 PM, tom sutherland [email protected]
wrote:
I am using a Costas loop for carrier recovery with QAM16 data. The carrier
is only 2khz. The I/Q output of the Costas loop
seems to track (the original
BPSK, QPSK, and 8PSK. My guess is that you are using an order 4 loop?
What’s probably happening is that the symbols at the four corners of
the constellation are dominating the error calculations because they
have the highest energy. But the loop can get biased by another symbol
in the constellation that turns it to
another phase lock. The Costas
QPSK, etc.) that have more computationally efficient decision making
functions. But
for any given constellation, it will at least be able