On Mon, Feb 27, 2012 at 2:57 PM, Tom Rondeau <t...@trondeau.com> wrote: > On Mon, Feb 27, 2012 at 4:51 PM, Jeff Hodges <jeffhodg...@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 <b...@reynwar.net> wrote: >>> >>> On Mon, Feb 27, 2012 at 10:00 AM, Ben Reynwar <b...@reynwar.net> wrote: >>> > On Mon, Feb 27, 2012 at 7:36 AM, Jeff Hodges <jeffhodg...@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
