Answered by:
Question about ChannelEstimate and ChannelComp
Question

Hi, everyone! I have a question about channel estimation and channel compensation. I have looked into the file "achannel.h" and could out figure out the shift operation in this file. Here is a segment of the file.
//
// Compute factor Re and Im that will normalize it pilot to 100 * 2^13
//
#define NORM_ONE (100*8*2)
#define NORM_SHIFT (61)
#define CH_SHIFT 3
#define COMP_SHIFT (8+3) // COMP_SHIFT = LOG2(NORM_ONE / 100) + NORM_SHIFT + CH_SHIFT  1I find that when doing channel estimation, the factors Re and Im have been multiplied by 100*2^12 according to the parameters above, but the notation says that they are normalized to 100*2^13. How to explain this?
What's more, since the factors Re and Im have been multiplied by 100*2^12 and normalized to 100 when doing channel compensation, we should divide them by 2^12, i.e. 11 bits right shift. But they are right shift by 11 bits (COMP_SHIFT) actually, why do this? Or how to get the following equation
COMP_SHIFT = LOG2(NORM_ONE / 100) + NORM_SHIFT + CH_SHIFT  1?
Why should it subtract 1?
Wait for your answer. Thank you!
 Edited by ychm Monday, June 4, 2012 6:11 AM
Answers

Hi,
The equalization tries to get the output sample to have a norm of 100.
However, in order to preserve the precision, the calculation in between keeps more bits. And that is why these righ shifts are needed.
You are a very careful reader.
This substract 1 is artificial. The reason is the implementation of FreqComp64 will automatically do a right shift one already.
Please refer to the function called rotate.
It uses mul_high function defined in Viterbi128.h. This function preserves only the high word of the multiple results (effectively shift 16bits). However, since the number is signed, the modulus should be 2^15. Then, you can see the mul_high performs one extra right shift that needs to be compensated.
Thanks,
 Kun
 Marked as answer by Jiansong zhangMicrosoft employee Monday, July 9, 2012 2:41 AM
All replies

Hi,
The equalization tries to get the output sample to have a norm of 100.
However, in order to preserve the precision, the calculation in between keeps more bits. And that is why these righ shifts are needed.
You are a very careful reader.
This substract 1 is artificial. The reason is the implementation of FreqComp64 will automatically do a right shift one already.
Please refer to the function called rotate.
It uses mul_high function defined in Viterbi128.h. This function preserves only the high word of the multiple results (effectively shift 16bits). However, since the number is signed, the modulus should be 2^15. Then, you can see the mul_high performs one extra right shift that needs to be compensated.
Thanks,
 Kun
 Marked as answer by Jiansong zhangMicrosoft employee Monday, July 9, 2012 2:41 AM
