QAM, carrier tracking and clock recovery

Hi All,
I am trying to build a working QAM modulator/demodulator, based on the
existing BPSK/QPSK code.

Is the Mueller and Muller clock-recovery as used in the current QPSK
examples also usable for QAM?

I couldn’t find a good description of the algorithm or the parameters.

For clock recovery the only options I found on the net which are
supposed to work for QAM are modified early/late tracking and modified
zero-crossing.
Has anybody any info on this?

I am also looking for the best option for carrier-tracking.
For QAM there are special requirements for carrier-tracking and
clock-recovery.
A simple costas loop will not do for carrier tracking.

This is what I have so far:

For now I implemented a to-the fourth-power PLL for carrier tracking.
(PLL locks to the fourth power of the input, output is divided by four)
This is supposed to work for all QAM versions and should NOT suffer from
catastrophic collaps when the BER gets too high.
(The other option. Decision based carrier-tracking does suffer from
catastrophic collaps.)
The disadvantage is the long time before lock.

For clock-recovery I am trying to use the existing clock-recovery.

I am fiddling with the parameters and I do get a non-very-stable but
recognisable QAM constellation as output of the clock-recovery when I
use a
very slow timeconstant for my PLL.
No packets get through yet, I think because the PLL only locks after a
lot of symbols are missed and the constellation is not very stable.

The output constellation of the output of the clock-recovery now can be
seen in:
http://www.olifantasia.com/projects/gnuradio/QAM/screenshots/
The output files (–log) before and after clock-recovery is in
http://www.olifantasia.com/projects/gnuradio/QAM/

greetings,
Martin

I am also looking for the best option for carrier-tracking.
(The other option. Decision based carrier-tracking does suffer from
of symbols are missed and the constellation is not very stable.

The output constellation of the output of the clock-recovery now can be
seen in:
http://www.olifantasia.com/projects/gnuradio/QAM/screenshots/
The output files (–log) before and after clock-recovery is in
http://www.olifantasia.com/projects/gnuradio/QAM/

greetings,
Martin

Martin,

I’ve been doing a bit of work on this problem and have two developer
branches open for this. In branches/developers/trondeau/digital-wip you
will
find QAM modulator code; I have transmitted this and received it on my
Signature signal analyzer and see the perfect constellations. The code
also
performs Gray coding on the constellation. This code only has the QAM
modulator side and no demodulator. This should be very quick to work up,
and
it sounds like you might already have it.

In branches/developers/trondeau/digital-wip2, I’ve been doing
modifications
on the MPSK receiver and implementing D8PSK. This work is almost
complete
and will be merged into the branch soon. I would look the
‘gr_mpsk_receiver’
block code from now on. It’s decision-aided and does the Costas loop and
M&M
(a modified version) at the same time and improves the DQPSK reception.

The mpsk_receiver should be fairly easily extended to work for QAM, too,
with improved decision making on the quadrant and “shell” the symbols
are
in. It’s similar to what you said, except it does joint estimation of
the
timing.

I’m swamped with other responsibilities right now, so I won’t have time
to
hack on the QAM work, although I really want to get the 8PSK code into
the
trunk, so expect that soon. If this code helps you in working on your
QAM
solutions, please use it, and we can hopefully work together to get this
done and part of the release.

Tom

Tom R. wrote:

I am also looking for the best option for carrier-tracking.
(The other option. Decision based carrier-tracking does suffer from
of symbols are missed and the constellation is not very stable.

Martin,

I’ve been doing a bit of work on this problem and have two developer
branches open for this. In branches/developers/trondeau/digital-wip you will
find QAM modulator code; I have transmitted this and received it on my
Signature signal analyzer and see the perfect constellations. The code also
performs Gray coding on the constellation. This code only has the QAM
modulator side and no demodulator. This should be very quick to work up, and
it sounds like you might already have it.
Yes, I already have similar working code.

In branches/developers/trondeau/digital-wip2, I’ve been doing modifications
on the MPSK receiver and implementing D8PSK. This work is almost complete
and will be merged into the branch soon. I would look the ‘gr_mpsk_receiver’
block code from now on. It’s decision-aided and does the Costas loop and M&M
(a modified version) at the same time and improves the DQPSK reception.
Do you have any links for a desciption of the MM algorithm and its
parameters and/or performance.

done and part of the release.
I will have a look at it.
Thanks.

I am also swamped with other work but I would really like to get QAM
working to get DVB-C working.
(It will eventually need a lot of tuning to get >40 Mbit/sec working in
realtime)

Martin

Sent: Sunday, January 28, 2007 6:15 PM
I couldn’t find a good description of the algorithm or the parameters.
A simple costas loop will not do for carrier tracking.

Martin,
it sounds like you might already have it.
(a modified version) at the same time and improves the DQPSK reception.

Do you have any links for a desciption of the MM algorithm and its
parameters and/or performance.

Yep, and it’s in the code :wink: If you look at gr_clock_recovery_mm_cc.h,
there’s a reference to a good receiver book that goes over the basic M&M
loop. In my developer branch, gr_mpsk_receiver_cc.h has a link to a
paper
with a modified M&M loop implemented here.

Tom

Tom R. wrote:

[email protected]] On Behalf Of Martin D.

I am also looking for the best option for carrier-tracking.
(The other option. Decision based carrier-tracking does suffer from
a
The output files (–log) before and after clock-recovery is in

and

(a modified version) at the same time and improves the DQPSK reception.

Do you have any links for a desciption of the MM algorithm and its
parameters and/or performance.

Yep, and it’s in the code :wink: If you look at gr_clock_recovery_mm_cc.h,
there’s a reference to a good receiver book that goes over the basic M&M
loop. In my developer branch, gr_mpsk_receiver_cc.h has a link to a paper
with a modified M&M loop implemented here.
Thanks, but I was hoping for some info which doesn’t require an IEEE
subscription or buying a book.
(Free as in Beer)

But I will just try to grasp it by staring at the code a little longer.
That usually has on of two results:
I get it
I don’t get it. I start writing my own algorithm. After much tweaking I
end up with the original algorithm, but now I know why.

Greetings,
Martin

Martin D. wrote:

to work for QAM are modified early/late tracking and modified
For now I implemented a to-the fourth-power PLL for carrier tracking.
recognisable QAM constellation as output of the clock-recovery when I

complete

Thanks, but I was hoping for some info which doesn’t require an IEEE subscription or buying a book.
(Free as in Beer)

But I will just try to grasp it by staring at the code a little longer.
That usually has on of two results:
I get it
I don’t get it. I start writing my own algorithm. After much tweaking I end up with the original algorithm, but now I know why.

Greetings,
Martin

Ah, sorry, life a the university spoils me sometimes. I don’t have a
good one to recommend off hand, but here’s Mathwork’s man page:
http://www.mathworks.com/access/helpdesk/help/toolbox/commblks/ref/index.html?/access/helpdesk/help/toolbox/commblks/ref/muellermullertimingrecovery.html&http://www.google.com/search?q=mueller+and+muller&start=0&ie=utf-8&oe=utf-8&client=firefox-a&rls=org.mozilla:en-US:official

Hopefully, it’s a place to start, though it gives you very little
insight.

Tom

Eric B. wrote:

Can you say Cell Processor? :wink:
Yes please, send me a dozen :wink:

I have been dreaming about an USRP version 2 with a few Cell processors,
1 GB RAM and an FPGA with 256 embedded multipliers and 10 Gbit ethernet
interface and 16 ADC/DAC channels running at 1 GSPS.

But for the short time:
Cell processor
or
GPGPU
and/or
FPGA (just put it in the USRP verilog)

will probably do.

I already succeeded in implementing a big FIR filter running at full
speed (64 MSPS) in the usrp, so I might even be able to put in a
complete
QAM demododulator one day.

Martin

On Mon, Jan 29, 2007 at 10:36:31PM +0100, Martin D. wrote:

Tom R. wrote:

I am also swamped with other work but I would really like to get QAM working to get DVB-C working.
(It will eventually need a lot of tuning to get >40 Mbit/sec working in realtime)

Martin

Can you say Cell Processor? :wink:

Eric

Tom R. wrote:

recovery

To: gnuradio mailing list
I couldn’t find a good description of the algorithm or the
zero-crossing.
For now I implemented a to-the fourth-power PLL for carrier tracking.

No packets get through yet, I think because the PLL only locks
can be

Signature signal analyzer and see the perfect constellations. The code

complete

block code from now on. It’s decision-aided and does the Costas

Greetings,
Tom

You might find my benchmark_rx_oscopy.py and kinda working qam16 code
interesting.
they are in branches/developers/nldudok1/digital-wip3 which is a
branched version of your digital-wip2
look in
branches/developers/nldudok1/digital-wip3/gnuradio-examples/python/digital/
and
branches/developers/nldudok1/digital-wip3/gnuradio-core/src/lib/general/gr_mpsk_receiver_cc
and
branches/developers/nldudok1/digital-wip3/gnuradio-core/src/python/blksimpl

benchmark_rx_oscopy.py gives you a live constellation view (put it at
X-Y mode manually with the rightmost pulldown)
and live tweaking of parameters

greetings,
Martin

version of your digital-wip2
benchmark_rx_oscopy.py gives you a live constellation view (put it at X-Y
mode manually with the rightmost pulldown)
and live tweaking of parameters

greetings,
Martin

I just saw the commit now. I’ll check it out tomorrow and see what it
looks
like. You guys are my new heroes; I wouldn’t have been able to touch
this
for a while yet :wink:

How’s it working with the AGC loop?

Tom

Tom R. wrote:

version of your digital-wip2
benchmark_rx_oscopy.py gives you a live constellation view (put it at X-Y
for a while yet :wink:

How’s it working with the AGC loop?
The agc2 seems to work.
The feedforward agc only works when manually compensating for the noise
(1.0 + noise as reference)
This would need an error loopback from the gr_mspk receiver

I think my main problem now is detecting of which quadrant we are in.
Or use the right kind of differential coding.
(I just used the gr.diff_decoder_bb and gr.diff_encoder_bb)

I have also strugled with the right formulation for the phase_detector
error signal.
(conj or not, pos or neg sign) But I think I got it now.

I send the complete constellation as list from python to the
mpsk_receiver as vector.
For some reason I had to reverse this list to get it to work.
This could also mean I needed to solve this in a different way and it
just accidently now sometimes works. (mirror the constellation, add pi,
something like that)

Greetings,
Martin

On Thu, Feb 01, 2007 at 11:02:54PM +0100, Martin D. wrote:

How’s it working with the AGC loop?
The agc2 seems to work.
The feedforward agc only works when manually compensating for the noise (1.0 + noise as reference)
This would need an error loopback from the gr_mspk receiver

I think my main problem now is detecting of which quadrant we are in.

I believe that V.32bis differentially encodes the quadrant rotation to
avoid this problem.

This forum is not affiliated to the Ruby language, Ruby on Rails framework, nor any Ruby applications discussed here.

| Privacy Policy | Terms of Service | Remote Ruby Jobs