## OFDM Cyclic Prefix Understanding

Started by 4 years ago●11 replies●latest reply 4 years ago●259 viewsI am going thru wlanOFDMDemodulate.m (script used by MATLAB to demodulate 802.11g OFDM symbols)

wlanOFDMDemodulate(x, cfgOFDM, ofdmSymOffset)

x is the array of received samples, cfgOFDM is the OFDM configuration file containing empirical details of 802.11g.

ofdmSymOffset is set to 0.75 (default). This is my "second" concern, what is this ofdmSymOffset actually.

This is how ofdmSymOffset is used further.

**symOffset = round(ofdmSymOffset * CPLen);**

Suppose x has 80 samples (64 plus 16 cyclic prefix)

postCPRemoval = x([CPLen+1:FFTLen+symOffset, symOffset+1:CPLen]);

So I couldnt understand this postCPRemoval step. I expanded [CPLen+1:FFTLen+symOffset, symOffset+1:CPLen] and for symOffset = 0.75, I got

Columns 1 through 18

17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34

Columns 19 through 36

35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52

Columns 37 through 54

53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70

Columns 55 through 64

71 72 73 74 75 76 13 14 15 16

This seems like First 16 samples from x are neglected (which I understand as they are cyclic prefix), but at the end, why the samples 13, 14, 15 and 16 are copied back ?

Not sure I quite understand the situation.

If symOffset is set to 0.75, how can it be used as an index into an array in the line: postCPRemoval = x([CPLen+1:FFTLen+symOffset, symOffset+1:CPLen]);?

Doesn't it have to be an integer?

The other thing that is confusing, is that the total length of the concatenated data appears to be the full 80 samples. The code steps over the CP at the beginning and then picks it up again at the back. I think this is right is FFTLen is 64 and CPLen is 16.

Yes the FFT length is 64 and CPlen is 16.

**symOffset = round(ofdmSymOffset * CPLen);**

That makes sense now.

However, the code looks wrong now. What you really need is the last part of the FFT segment rather than the earlier part of the cyclic prefix.

You want samples 17-80, so the equation you gave should have 77-80 instead of 13-16.

Is this code something that comes from MatLab?

Yes, if you have MATLAB with WLAN Tool Box, you can find this code in wlanOFDMDemodulate.m

In your case there might be a different definition. I expect with a cp offset of 0.75 of 16(=12) cp samples be ignored from beginning so symbol starts from 13 and for 64 samples to sample 76 but in your case it seems still correct. you started instead from 17 (the actual start of symbol) then until 76 but reinserted samples 13,14,15,16 instead of 77,78,79,80.

CP offset is allowed i.e. you might capture anywhere on cp+symbol without crossing to next symbol. You get same frequency domain result but with change of phase. In your example they are taking cp from front to the end of section. Looks to me still legal. My understanding is that cp offset (phase offset) may help QAM demodulation or uncertainty of start location.

Notice also that samples 77,78,79,80 are repeat copies of 13,14,15,16 ??

But first 16 samples, i.e., CP may get corrupted due to ISI (right ?). Why do we use them to append :-/

My guess is that from ISI perspective the optimum section is the middle as both ends are too close to noisy neighbours.

Ok I think I got the point!. Thanks

I disagree slightly here.

The dispersion of the channel is alway causal, so that the ISI from one symbol to the next (if there is any) will always creep into the beginning of the CP of the next symbol and taper off before the end of the CP if it is not too long. I cannot see any circumstance where the ISI from the current symbol can pollute itself.

I believe that the best sampling instant is right at the beginning of the current symbol's FFT time, right at the end of its CP.

The way I see it is that the issue is about multipath. If we can identify and grab the main signal then yes all other signal paths are delayed. But we can't and it is likely that there is too much power in a secondary reflected path thus we are receiving the main signal as advanced relatively. This means that both ends of cp+symbol might not be clean.

I understand exactly what you are saying, and you make a completely valid point.

Thanks.