Help with QAM demodulation

GNU Radio
1

Does anyone know if the QAM demodulator code is working properly? I
would
like to get a QAM demodulator working for a symbol rate of 300ksym/s. I
don’t know whether I am just using the wrong parameters or if the blocks
do
not work properly, but I am not getting the results I expect.

To test the code out I am using the GRC. I have a vector source with a
known data sequence running into the qam mod block and then the output
of
that into a QAM demod block. The output of the QAM demod is running into
a
Uchar to Float, and I am plotting the results on a WX GUI Scope. I have
the exact same settings on both the QAM mod and demod blocks. The
output I
am seeing on the scope looks completely random. (I also tried other
vector
source data: When the input is 0x0F, repeating, the output I see is
00001010 repeating. But when I use 0x0E, the results are random again.)

I have also tried demodulating a real QAM signal with a known data
sequence, also to no avail.

I have been working on this for about a month now and haven’t had any
success. I have examined the underlying QAM.py and generic_mod,
generic_demod codes, and they seem to be written properly. But I am not
getting the expected results.

Any help with this problem or advice you can give will be greatly
appreciated, and I will return the favor by helping out in any way that
I
can.

Thank you very much in advance,

Jeff

2

On Mon, Feb 27, 2012 at 9:36 AM, Jeff H. [email protected]
wrote:

am seeing on the scope looks completely random. (I also tried other vector

Any help with this problem or advice you can give will be greatly
appreciated, and I will return the favor by helping out in any way that I
can.

Thank you very much in advance,

Jeff

Jeff,
It’s been a while since I used the QAM mod/demod blocks. They are
definitely not complete since there’s no synchronization for them, yet,
but
since you are just working in simulation, this shouldn’t be a problem.

What alphabet (M) size are you using with the QAM module? And the
results
for 0x0F look like the data is differentially encoded, so that might
just
be your problem there.

Have you looked at the constellation? Does it look ok?

Tom

3

On Mon, Feb 27, 2012 at 7:36 AM, Jeff H. [email protected]
wrote:

on the scope looks completely random. (I also tried other vector source

[email protected]
Discuss-gnuradio Info Page

If it’s not working it’s probably my fault, so I’ll do some tests
myself today and get back to you.

Cheers,
Ben

4

On Mon, Feb 27, 2012 at 10:00 AM, Ben R. [email protected] wrote:

same settings on both the QAM mod and demod blocks. The output I am seeing
getting the expected results.
Discuss-gnuradio mailing list
[email protected]
Discuss-gnuradio Info Page

If it’s not working it’s probably my fault, so I’ll do some tests
myself today and get back to you.

Cheers,
Ben

I found a bug in the xml file for the demodulator that would cause
problems if you requested no gray-coding.
It cause gnuradio-companion to pass an incorrect parameter name.
A fix is at

In case that wasn’t your problem I’ll post an example that works for me:

from gnuradio import gr, digital

class qam_mod_demod(gr.top_block):

def __init__(self):
    super(qam_mod_demod, self).__init__()
    src = gr.vector_source_b([1, 1, 1, 0, 1, 0, 0, 1, 1, 0, 1, 0,

0, 0]*1000)
packer = gr.unpacked_to_packed_bb(1, gr.GR_MSB_FIRST)
self.snk = gr.vector_sink_b()
mod = digital.qam.qam_mod(constellation_points=16,
mod_code=“gray”,
differential=True,
samples_per_symbol=2,
excess_bw=0.35)
demod = digital.qam.qam_demod(constellation_points=16,
mod_code=“gray”,
differential=True,
samples_per_symbol=2,
excess_bw=0.35,
freq_bw=6.28/100.0,
timing_bw=6.28/100.0,
phase_bw=6.28/100.0)
unpacker = gr.packed_to_unpacked_bb(8, gr.GR_MSB_FIRST)
self.connect(src, packer, mod, demod, unpacker, self.snk)

if name == ‘main’:
qmd = qam_mod_demod()
qmd.run()
data = qmd.snk.data()
print(data)

5

Thanks Ben and Tom, you two have been very helpful.

The code Ben provided does work, and adjusting my GRC program to use the
same parameters, I was able to achieve the expected results.

However, it appears there are two issues:

(1) When differential encoding is set to off for both mod/demod blocks,
the
output data becomes invalid
(2) When the samples per symbol is above 10 the output also becomes
invalid.

Any ideas on what may be causing these discrepancies?

In response to Tom’s questions, I am using 16-QAM and the constellation
does look very noisy (both phase and amplitude) coming out of the QAM
mod
and being observed on the WX GUI Constellation Sink. But then again,
there
a lot of parameters on that signal processing block, so maybe I do not
have
the proper values set.

Thanks,

Jeff

6

On Mon, Feb 27, 2012 at 4:51 PM, Jeff H. [email protected]
wrote:

Thanks Ben and Tom, you two have been very helpful.

The code Ben provided does work, and adjusting my GRC program to use the
same parameters, I was able to achieve the expected results.

However, it appears there are two issues:

(1) When differential encoding is set to off for both mod/demod blocks,
the output data becomes invalid

I’m not sure the differential en/decoder works for QAM. I suggested it
before because of the bits that you sent us, but the gray coding was the
problem, which makes more sense.

(2) When the samples per symbol is above 10 the output also becomes
invalid.

I’m not sure why you would want to run it with that many sps, anyway.
I’d
probably have to dive back into the code to see what might be the
problem
there. Theoretically, it should be doable, but since I’ve never run it
with
that many, it’s probably never been exercised.

Jeff
The noise might be due to ISI since you’re just coming out of a RRC
filter
at that point. Unless the constellation sink has another RRC in it.
Also,
that sink tries to do some synchronization designed for PSK signals, so
it
won’t work great and might be causing some of your error. Try just using
an
oscope and plottng x verus y.

Tom

7

On Mon, Feb 27, 2012 at 2:57 PM, Tom R. [email protected] wrote:

the output data becomes invalid

I’m not sure the differential en/decoder works for QAM. I suggested it
before because of the bits that you sent us, but the gray coding was the
problem, which makes more sense.

Could this be simply because of the rotational symmetry of the QAM
constellation. There’s only a 25% chance that the receiver will lock
onto the constellation in the correct orientation so unless you’re
using differential encoding it’ll only work one quarter of the time.

(2) When the samples per symbol is above 10 the output also becomes
invalid.

I’m not sure why you would want to run it with that many sps, anyway. I’d
probably have to dive back into the code to see what might be the problem
there. Theoretically, it should be doable, but since I’ve never run it with
that many, it’s probably never been exercised.

I had this same problem a while back and found that for high values of
samples-per-symbol I needed different parameters. Try twiddling with
freq_bw.