# 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 (6-1)
#define CH_SHIFT   3
#define COMP_SHIFT (8+3) // COMP_SHIFT = LOG2(NORM_ONE / 100) + NORM_SHIFT + CH_SHIFT - 1

I 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?

• Edited by Monday, June 4, 2012 6:11 AM
Monday, June 4, 2012 6:06 AM

• 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

Tuesday, July 3, 2012 9:49 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

Tuesday, July 3, 2012 9:49 AM
• Thanks.

- yaochm

Wednesday, July 4, 2012 2:12 AM