On Mon, Feb 27, 2012 at 2:57 PM, Tom Rondeau <
tom@trondeau.com> wrote:
> On Mon, Feb 27, 2012 at 4:51 PM, Jeff Hodges <
jeffhodges2@gmail.com> 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.
>
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.
>>
>> 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
>
>
> 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
>
>
>>
>> On Mon, Feb 27, 2012 at 12:50 PM, Ben Reynwar <ben@reynwar.net> wrote:
>>>
>>> On Mon, Feb 27, 2012 at 10:00 AM, Ben Reynwar <ben@reynwar.net> wrote:
>>> > On Mon, Feb 27, 2012 at 7:36 AM, Jeff Hodges <jeffhodges2@gmail.com>
>>> > wrote:
>>> >> 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
>>> >>
>>> >> _______________________________________________
>>> >> Discuss-gnuradio mailing list
>>> >> Discuss-gnuradio@gnu.org
>>> >> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>>> >>
>>> >
>>> > 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
>>> https://github.com/benreynwar/gnuradio/commit/e68ab8589ca235563f8c061fbb79d13793d1f21f
>>>
>>> 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)
>>
>>
>
_______________________________________________
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
