What's wrong with this constellation?

Howdy list,
My partner and I have been working on getting a QAM demodulator
working on the gnuradio; the current patch, with lots of debugging
spew still present, is located at
http://www.cae.wisc.edu/~masond/gr-qam-patch-rev7.diff .

 The current problem: When the constellation 'locks', it looks

like the following:
http://www.cae.wisc.edu/~masond/figure3.png
(for qam16)
http://www.cae.wisc.edu/~masond/figure4.png
http://www.cae.wisc.edu/~masond/figure4.png
(for qam8)

 The red Xes are the true constellation points, and the black dots

are the output of the receiver. The amplitude of the receiver output
seems to spray out pretty widely from the constellation point
intended. Any ideas what could be causing this amplitude distortion?
I’ve tried increasing the number of stages in the feedforward AGC to
40 or 60 (as many as my receiver can bear without underruns) and it
doesn’t seem to impact it. The amplitude noise is present with a
variety of mus and costas alphas (the ones used in those figures were
alpha~.015 and gain-mu~.05-.075). I’ve also tried with several
different --tx-amplitudes to see if it was a matter of some clipping
or other artifact to no luck.

 I know that for digital radio purposes the constellation doesn't

have to be perfect, but rather ‘good enough’, so I would be inclined
to let this go except for point 2:
–The receiver frequently cycle-slips, with the longest string of
un-slipped packets somewhere in the 2000 range on our USRPs. I think
that this is being hurt by the amplitude noise pushing received points
into neighboring constellation points and causing the receiver to
correct for that.

 I'm running out of ideas (I've tried only using the corner points

as the patch does, using all points with weighting based on distance,
weighting only the costas loop portion, weighting only the m&m timing
portion…) and could use some suggestions or obvious things I may
have overlooked.

–Mason

Hi Mason,

… The amplitude of the receiver output seems to spray out pretty
widely from the constellation point intended.

It could be an AGC issue—is the AGC time constant long compared with a
symbol?
Is the distribution of constellation points uniform (each is picked with
equal
probability)?

One thing you could try, if the channel permits, is to temporarily hold
the AGC
fixed to see if that gives a better constellation (perhaps at the wrong
size;
or if you’re using decision feedback, try to get it to the right size
:slight_smile: ).

Cheers,
Peter M.

Peter M. wrote:

One thing you could try, if the channel permits, is to temporarily hold
the AGC
fixed to see if that gives a better constellation (perhaps at the wrong
size;
You should indeed try this.
Do you sent (short) bursts of QAM or is it a continuous stream?
If they are bursts then all loops (carrier recovery, AGC,
clock-recovery) can behave strangely.

If it is a continuous stream you could also try a feedback-AGC in stead
of a forward AGC which should give much less gain noise (after it has
settled)

It is also possible that the amplitude noise comes from the analoge
components in your TX-path or your RX-path.
If you have noise or hum on the supply voltage of any gain or mixer
stage then this will result in amplitude noise.

You could figure this out by sending out a single carrier (no
modulation, use ) and receive it with an SSB-receiver script or just
usrp_fft.py.
generate carrier:
usrp_siggen.py -R B --const -i 128 -f rffreq -a amplitude -g rfgain
look at spectrum:
usrp_fft.py -R A -d 64 -f rffreq -g rfgain
look at oscope:
usrp_fft.py -R A -d 64 -f rffreq -g rfgain -S

(Use the same analog signal path as you use for QAM)
Now you can look at the spectrum, listen to it and look at it with an
oscope.

If the signal is clean, your QAM-TX script or QAM-RX script is to blame.
Make sure you also look at LF noise or hum, like 50 Hz or even lower.
If you see noise, then there is something wrong with your setup.

greetings,
Martin