I have been reading about QAM modulation and wondering when I gray code what advantage is that for my BER as the SNR increases Is there much difference for a 16 QAM system or this effect does not help at all at 16 QAM system. Any reference would be appreciated.
Advantages of Gray Coding for QAM
Started by ●January 6, 2011
Reply by ●January 6, 20112011-01-06
On Thu, 06 Jan 2011 10:15:00 -0800, Deamon wrote:> I have been reading about QAM modulation and wondering when I gray code > what advantage is that for my BER as the SNR increases Is there much > difference for a 16 QAM system or this effect does not help at all at 16 > QAM system. Any reference would be appreciated.The idea behind the Gray coding is that you are minimizing bit errors by causing adjacent words to only be one bit off from their neighbors. That way, a bit of noise that's only enough to push the received signal over by one spot in the constellation only causes a single bit error. Contrast that with what would happen if you put '0111' next to '1000', '0000' next to '1111', '0011' next to '1100', etc. -- www.wescottdesign.com
Reply by ●January 6, 20112011-01-06
On Jan 6, 6:35�pm, Tim Wescott <t...@seemywebsite.com> wrote:> On Thu, 06 Jan 2011 10:15:00 -0800, Deamon wrote: > > I have been reading about QAM modulation �and wondering when I gray code > > what advantage is that for my BER �as the SNR increases Is there much > > difference for a 16 QAM system or this effect does not help at all at 16 > > QAM system. Any reference would be appreciated. > > The idea behind the Gray coding is that you are minimizing bit errors by > causing adjacent words to only be one bit off from their neighbors. �That > way, a bit of noise that's only enough to push the received signal over > by one spot in the constellation only causes a single bit error. � > Contrast that with what would happen if you put '0111' next to '1000', > '0000' next to '1111', '0011' next to '1100', etc. > > --www.wescottdesign.comthanks . does it mean If I draw graph of a 16QAM gray coded and uncoded Probability of error of a 16 QAM against the SNR in dB then the curves will be sperate then with gray coding having a very low probaility of error . Will this seperation be very significant for a 16 QAM system Please correct me if I am wrong
Reply by ●January 6, 20112011-01-06
On 01/06/2011 10:44 AM, Deamon wrote:> On Jan 6, 6:35 pm, Tim Wescott<t...@seemywebsite.com> wrote: >> On Thu, 06 Jan 2011 10:15:00 -0800, Deamon wrote: >>> I have been reading about QAM modulation and wondering when I gray code >>> what advantage is that for my BER as the SNR increases Is there much >>> difference for a 16 QAM system or this effect does not help at all at 16 >>> QAM system. Any reference would be appreciated. >> >> The idea behind the Gray coding is that you are minimizing bit errors by >> causing adjacent words to only be one bit off from their neighbors. That >> way, a bit of noise that's only enough to push the received signal over >> by one spot in the constellation only causes a single bit error. >> Contrast that with what would happen if you put '0111' next to '1000', >> '0000' next to '1111', '0011' next to '1100', etc. >> >> --www.wescottdesign.com > > thanks . does it mean If I draw graph of a 16QAM gray coded and > uncoded Probability of error of a 16 QAM against the SNR in dB then > the curves will be sperate then with gray coding having a very low > probaility of error . Will this seperation be very significant for a > 16 QAM system > > Please correct me if I am wrongI think it would be a good exercise for you to go through the math yourself. There's nothing to give you a lasting feeling for this stuff than to grind it into your skin. If you assume that all errors are one constellation point off, then the BER is going to be equal to the probability that the constellation is one point off times the average number of bit changes when you go from point to point. So for low BER, you can just multiply the Gray-code BER by the average number of bit changes from point to point in your other coding to get an idea of the new BER. At higher noise the probability that the constellation decisions will be more than one point off is greater, so you would have to take _that_ effect into account, too, if you really wanted to chase things that far. Note that if you do your Gray coding right, all the diagonal point errors are just two bits, so you get an advantage there, too. 0000 0001 0011 0010 0100 0101 0111 0110 1100 1101 1111 1110 1000 1001 1011 1010 -- Tim Wescott Wescott Design Services http://www.wescottdesign.com Do you need to implement control loops in software? "Applied Control Theory for Embedded Systems" was written for you. See details at http://www.wescottdesign.com/actfes/actfes.html
Reply by ●January 6, 20112011-01-06
Thanks . What you are saying does makes sense and it has occured to me too . But I was writting a code for Gray coding and non -Gray coding in a 16 QAM systems and after plotting the graph I was suprised to see that They were very close to each other except at high SNR where there is a little bit of discrepancy. Is it my code that is wrong or my knowledge is missing somwhere.
Reply by ●January 6, 20112011-01-06
On 01/06/2011 11:02 AM, Deamon wrote:> Thanks . What you are saying does makes sense and it has occured to me > too . But I was writting a code for Gray coding and non -Gray coding > in a 16 QAM systems and after plotting the graph I was suprised to see > that They were very close to each other except at high SNR where > there is a little bit of discrepancy. Is it my code that is wrong or > my knowledge is missing somwhere.Wow -- I'd assume that there's something wrong with the code, one way or another. You might try hand-feeding it constellation points, and see what decisions come out. -- Tim Wescott Wescott Design Services http://www.wescottdesign.com Do you need to implement control loops in software? "Applied Control Theory for Embedded Systems" was written for you. See details at http://www.wescottdesign.com/actfes/actfes.html
Reply by ●January 6, 20112011-01-06
On Jan 6, 1:02�pm, Deamon <persistence...@gmail.com> stated:> But I was writting a code for Gray coding and non -Gray coding > in a 16 QAM systemsThere is NO Gray coding necessary in a QAM system unless one insists on using a linear modulator, in which case, the inverse of Gray coding is needed. Some time back, I wrote in comp.dsp as given below. --Dilip Sarwate ========================================== 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.
Reply by ●January 6, 20112011-01-06
On 01/06/2011 05:50 PM, dvsarwate wrote:> On Jan 6, 1:02 pm, Deamon<persistence...@gmail.com> stated: > >> But I was writting a code for Gray coding and non -Gray coding >> in a 16 QAM systems > > There is NO Gray coding necessary in a QAM system > unless one insists on using a linear modulator,Dilip, What other kind of modulator could there possibly be, other than a "linear modulator," for QAM? QAM is a linear modulation, is it not? -- Randy Yates % "My Shangri-la has gone away, fading like Digital Signal Labs % the Beatles on 'Hey Jude'" yates@digitalsignallabs.com % http://www.digitalsignallabs.com % 'Shangri-La', *A New World Record*, ELO
Reply by ●January 6, 20112011-01-06
On Jan 6, 6:13�pm, Randy Yates <ya...@ieee.org> asked:> What other kind of modulator could there possibly be, other than > a "linear modulator," for QAM? QAM is a linear modulation, is it > not?QAM is just the sum of two orthogonal ASK signals, and so for simplicity, let's talk only of Amplitude Shift Keying (ASK), and 4-ASK in particular. ... In the analog way of thinking about these matters, ASK (more generally AM) is a linear modulation meaning that the output scales as a linear function of the input. For example, x(t) is mapped to x(t)cos(wt) by the modulator, and 2x(t) is mapped to [2x(t)]cos(wt). So, skipping the cos(wt) etc, we have in particular, a 4-ASK linear modulator with analog input A that can take on one of 4 values 0, 1, 2, 3 and MATLABi folks can express the output as -3 + 2A to get that the corresponding outputs are -3, -1, +1, +3. To put Descartes before the horse, remember that -3+2A is a linear function of A. But, since this *is* comp.dsp and both computers and dspissers use bits, suppose that we have the linear modulator described above, but have available as input two data bits (b0, b1). So we need to have a D/A converter to map the four possible bit values 00, 01, 10, 11 to 0, 1, 2, 3 which would then be the input to our 4-ASK linear modulator. Easy peasy! The two bits are a binary number, and we are done! But this is the wrong thing to do. What we really ought to be doing is map b0b1 A -3+2A 0 0 --> 0 --> -3 0 1 --> 1 --> -1 1 1 --> 2 --> +1 1 0 --> 3 --> +3 OK, so this is Gray coding according to every one. But, is it? I claim that what we are essentially doing, without actually doing it, is the *inverse* of Gray coding. Corresponding to 00, 01, 11, and 10, the D/A converter must produce numbers 0, 1, 2, 3. That is, the D/A converter that produces A from b0b1 necessarily assumes that the bit pair is ALREADY Gray-coded, and produces the correct number A corresponding to the presumed Gray-coded bit pair. NOBODY said that b0b1 are already Gray-coded; they are just two bits we got from the data source. We DON'T convert b0b1 from a presumed standard binary encoding to a Gray encoding. We TREAT the given data bits b0b1 as a Gray-coded pair and use the value that would be assigned to this bit pair by Gray coding as the number A. In effect, we are inverting a presumed Gray code to get A, and all this because the powers that be insist that ASK (and QAM) is a *linear* modulation. In fact, ASK (and QAM) are properly designed linear modulations only if the D/A converters *assume* that their data inputs are already Gray-coded, and produce the corresponding integers as inputs to the modulators. No explicit Gray coding is required in ASK or QAM; only *inverting* a (presumed) Gray coding to get the linearity so highly prized by textbook authors and manual writers. What we ought to be doing is not futz around with words and concepts like Gray code and linear modulation, but simply use a LUT to map data inputs 00, 01, 11, 10 to -3, -1, +1, +3 in a DSP processor (avoiding MATLAB like the plague it is) and go from there to the QAM constellation -3 -1 +1 +3 +3 0010 0110 1110 1010 +1 0011 0111 1111 1011 -1 0001 0101 1101 1001 -3 0000 0100 1100 1000 Hope this helps --Dilip Sarwate
Reply by ●January 7, 20112011-01-07
dvsarwate <dvsarwate@yahoo.com> wrote: (snip)> But, since this *is* comp.dsp and both computers and > dspissers use bits, suppose that we have the linear > modulator described above, but have available as input > two data bits (b0, b1). So we need to have a D/A > converter to map the four possible bit values 00, 01, > 10, 11 to 0, 1, 2, 3 which would then be the input to > our 4-ASK linear modulator.In many cases the bits come out of a scrambler, and so have no relation to the actual data bits. That would seem to me to remove any possible value in discussing gray code. -- glen
