On Mon, 12 May 2008 11:50:48 -0700 (PDT), "sarwate@YouEyeYouSee.edu"
<dvsarwate@gmail.com> wrote:
>On May 12, 12:12 am, Eric Jacobsen <eric.jacob...@ieee.org> wrote:
>
>> >Jerry
>>
>> Yes, and if the constellation were strictly PSK, i.e., traced a
>> circle, that would be all you'd need. With a QAM grid, though, one
>> constellation point has potentially eight neighbors (not just two,
>> like on a line or in a circle), and, ideally, you'd like only one bit
>> to differ with each of them. With low-order QAM (e.g., 16-QAM),
>> that's not possible, so one tries to manage the decision regions to
>> maximize the Euclidean distance while minimizing the Hamming distance.
>>
>> Eric Jacobsen
>> Minister of Algorithms
>> Abineau Communicationshttp://www.ericjacobsen.org
>
>In all the messages in this thread with splendid examples
>of MATLAB code and snippets of C operators and so on,
>there has been little attention paid to the specific application
>to QAM, and I think that Eric's comment about low-order QAM
>is misleading in some respects. My response discusses only
>M-QAM where M = 2^{2n} as opposed to the general M-QAM
>desired by the OP, with 16-QAM as an example.
>
>An 2^{2n}-QAM signal is the sum of two 2^n-ASK signals transmitted
>on the I and Q channels, with each channel carrying n bits. The
>mapping of data bits to signal constellation point on each channel
>must correspond to Gray coding, but the Gray coding is not
>explicit. For example, in 16-QAM with 4 data bits (b_3,b_2,b_1,b_0),
>one could send b_3 and b_2 using 4-ASK on the I channel and
>b_1 and b_0 using 4-ASK on the Q channel. (Some might prefer
>to send the odd-numbered bits on the I channel and the even-
>numbered bits on the Q channel instead). The mapping of
>data bits to signal point is *effectively* Gray coding, with (for
>example) 00, 01, 11, and 10 corresponding to signal levels
>-3, -1, +1, and +3 respectively. The DATA bits themselves
>don't need to be transformed to Gray code explicitly because if
>I give you bits 11, you cannot say whether I mean 3 (standard
>binary coding) or 2 (Gray coding) UNLESS I tell you what
>coding I was using when I produced the 11. All the modulator
>needs to know is that if the modulator input is 11, it needs to
>produce output +1 and if the input is 10, it needs to produce
>+3 etc. Now, those who want to implement the modulator as
>a LINEAR modulator can write code which says that my input
>can take on values 00, 01, 11, and 10 which is Gray-coded
>(actually it isn't Gray-coded or anything: it is raw data) which
>thus represents 0, 1, 2, and 3 respectively, The output I have
>to produce is -3 + 2A where A is the integer value of my
>Gray-coded data input. But remember that the data source
>just handed the modulator two bits without saying anything
>about whether the bits are Gray-coded or not. It is the LINEAR
>modulator which is treating these bits as Gray-coded and
>converting them to standard binary representation (that is,
>applying the inverse Gray-code mapping!) so as to be able to
>use its magic formula -3+2A to produce the output. A
>modulator that is not quite as anal-retentive might just use
>a LUT to translate data bits 00, 01, 11, and 10 into signal levels
>-3, -1, +1, and +3 which uses Gray coding implicitly but not
>explicitly.
>
>Returning to 16-QAM, the 4-bit nybble (0111) is split into 01 and
>11, and mapped to the signal constellation point (-1, +1) via
>two modulators. The 16-QAM constellation thus looks like
>
> -3 -1 +1 +3
>
>+3 0010 0110 1110 1010
>
>+1 0011 0111 1111 1011
>
>-1 0001 0101 1101 1001
>
>-3 0000 0100 1100 1000
>
>where each constellation point differs from its 4 NEAREST
>neighbors (distance 2) in one bit and from its 4 NEXT
>NEAREST neighbors by 2 bits. The latter have less effect
>on the overall BER as compared to the 4 NEAREST neighbors
>and so it matters less that the difference is two bits.
>
>If the signal point (-1, +1) is transmitted and (X, Y) received,
>then X and Y are each quantized into 4 levels
>(-3, -1, +1, +3) and if the quantized X and Y are -1 and +1
>respectively, then the demodulator output is 0111. There
>is no need for the demodulator to do do anything else, or
>to translate the bits from Gray code back to standard binary
>representation etc. All that is built in to the demodulator
>LUTs. The harder way of doing this is to remember that
>the modulator used the formula -3+2A to get +1, and so
>A is given by (+1 + 3)/2 = 2, but since Gray coding is
>being used, the output should be the Gray-coded version
>of 2, viz. 11.
>
>--Dilip Sarwate
Thanks, Dilip. That says pretty much what I was trying to say (not
sure where I became misleading, but it's all good). I think you've
hit the points of potential ambiguity pretty well.
Eric Jacobsen
Minister of Algorithms
Abineau Communications
http://www.ericjacobsen.org