Forums

Convert demodulation I/Q to soft Data

Started by Robert August 25, 2005
I found the signal after demodulation module are Data_I[q:0] and
Data_Q[q:0].
How to convert Data_I[q:0] and Data_Q[q:0] to soft information
Data[q:0]?
May you please recommend some references?

Any suggestions will be appreciated! 

Best regards,
Robert

"Robert" <zhushenli@gmail.com> wrote in message
news:1124943731.859440.84990@o13g2000cwo.googlegroups.com...
> I found the signal after demodulation module are Data_I[q:0] and > Data_Q[q:0]. > How to convert Data_I[q:0] and Data_Q[q:0] to soft information > Data[q:0]? > May you please recommend some references? > > Any suggestions will be appreciated!
I'm assuming that by 'demodulation' you mean that it's been downconverted to baseband. This reference http://www.dspguru.com/info/tutor/QuadSignals.pdf is the best one I've seen on quadrature signals. Kind Regards, Howard
Hi Howard,
Thank you for your help!

 I am designing ECC(LDPC) encoder/decoder. And I find a reference
design's datasheet. It's ECC decoder have two digital input Data_I and
Data_Q. Someone tell me it related to demodulation, but I am new to
this area.

And is it related to downconverted to
baseband.

Is it hard to convert Data_I and Data_Q to Data? 

Best regards,
Robert

On 25 Aug 2005 07:00:46 -0700, "Robert" <zhushenli@gmail.com> wrote:

>Hi Howard, >Thank you for your help! > > I am designing ECC(LDPC) encoder/decoder. And I find a reference >design's datasheet. It's ECC decoder have two digital input Data_I and >Data_Q. Someone tell me it related to demodulation, but I am new to >this area. > >And is it related to downconverted to >baseband. > >Is it hard to convert Data_I and Data_Q to Data?
Robert, If I understand correctly you need the soft log-likelihood values generated somehow from the input I and Q values. This needs to be done in the demodulator since it will be dependant on the constellation of the signalling used at the time. e.g., generating soft decision values for QPSK is different than it is for 64QAM. Hope that helps a little bit... Cheers, Eric Jacobsen Minister of Algorithms, Intel Corp. My opinions may not be Intel's opinions. http://www.ericjacobsen.org
Hi Eric,

Thank you for your help!
So if I get Data_I[q:1] and Data_Q[q:1], they shall be converted back
to singal based on modulation type. Is it right? And if so, is it
difficult to convert QPSK demodulation to soft LLR for my LDPC decoder?

BTW, I am a graduate student and want to do a better work ;-)

Best regards,
Robert

On 26 Aug 2005 07:40:27 -0700, "Robert" <zhushenli@gmail.com> wrote:

>Hi Eric, > >Thank you for your help! >So if I get Data_I[q:1] and Data_Q[q:1], they shall be converted back >to singal based on modulation type. Is it right? And if so, is it >difficult to convert QPSK demodulation to soft LLR for my LDPC decoder? > >BTW, I am a graduate student and want to do a better work ;-)
Robert, QPSK is the most straightforward since the error vector in each dimension (I and Q) determines the soft decision value for the associated bit. Many texts and papers exist that describe the relationship between the received signal and the LLR for BPSK and QPSK, so I won't belabor that. It _may_ even depend on how the rest of the decoder is constructed (i.e., assumes log or linear processing). The problem with the higher order modulations is that the error vector causes more uncertainty with some bits in the constellation than others. Specifically, the bits associated with the sign changes in each dimension are not very sensitive to noise, and the bits associated with the finest point selection in the constellation are the most sensitive. This complicates the LLR generation for each bit since it is done somewhat differently depending on which bit in the symbol is being processed. There are a number of ways to handle this but the easiest way, imho, to see this is to study the constellations and constellation diagrams with noise. It isn't too hard to come up with schemes that work well, and sometimes the empirically determined schemes work quite well. Cheers, Eric Jacobsen Minister of Algorithms, Intel Corp. My opinions may not be Intel's opinions. http://www.ericjacobsen.org
Hi Eric,

Thank you for your help.

I understand what you mean about the constellation diagrams.
BUT YOU SAY "bits associated with the finest point selection in the
constellation are
the most sensitive". Do you mean the bit not near I and Q axes??

BTW, I have read your proposal of LDPC for 802. It's interesting ;-)

All the best,
Robert

On 28 Aug 2005 02:11:18 -0700, "Robert" <zhushenli@gmail.com> wrote:

>Hi Eric, > >Thank you for your help. > >I understand what you mean about the constellation diagrams. >BUT YOU SAY "bits associated with the finest point selection in the >constellation are >the most sensitive". Do you mean the bit not near I and Q axes?? > >BTW, I have read your proposal of LDPC for 802. It's interesting ;-) > >All the best, >Robert
Robert, No, I mean the LSB being the bit associated with the last selection of constellation point. Typically the bits associated with each axis are divided into subsets with one bit selecting which half of the axis, and the last bit selecting the smallest element of the subsets, being the specific dot in the constellation. Sometimes this is complicated by certain grey coding schemes, but in general in order to simplify the decoding hardware there are logical groups of bits with each bit selecting a smaller and smaller set of possible constellation points, until the last bit selects the specific constellation point transmitted. That bit is more susceptible to noise than the rest. Eric Jacobsen Minister of Algorithms, Intel Corp. My opinions may not be Intel's opinions. http://www.ericjacobsen.org
Hi Eric,

Oh, I see. You mean the bit near the boundary of the decision area of
the sub-constellation graph. Thank you for your help!

All the best,
Robert

On 29 Aug 2005 19:13:51 -0700, "Robert" <zhushenli@gmail.com> wrote:

>Hi Eric, > >Oh, I see. You mean the bit near the boundary of the decision area of >the sub-constellation graph. Thank you for your help!
Yes, sorry I wasn't more articulate but sometimes these things aren't easy to describe in text-only. Eric Jacobsen Minister of Algorithms, Intel Corp. My opinions may not be Intel's opinions. http://www.ericjacobsen.org