Re: [Discuss-gnuradio] Channel Response in OFDM with MIMO USRP

[Jack M]

I see.

Well, I'm running the regular OFDM rx-chain which includes preamble detection->sampler->fft->so on. On the transmitter, each frame (preamble[1 OFDM symbol] + data[multiple OFDM symbols]) acts as a burst which includes the required timestamps and the burst tags.

I was just somehow hoping to get a flat channel for some analysis which otherwise is a pain, since I have to do it without channel equalization. This phase change results in symbols rotating in the I/Q domain. :) 

-jack

On Sun, Jan 13, 2013 at 2:49 PM, Paul Fuxjaeger <address@hidden> wrote:

On 13.01.13 19:33, Unforgiven11 dreams wrote:

Based on your suggestion and some reading, could it be due to the
'fractional' timing offset or not 'integer' timing offset. On the first
glance it appears that the preamble detection was delayed - since any
delay in the time domain results in the phase shift in the frequency
domain (which is reflected in the channel response calculated from the
preamble). So, I just 'pre-pone' the preamble detection by 1 sample, and
interestingly the slope just inverted. On the other hand if I
'post-pone' it by 1 sample, the slope increased. So could it be that the
0<offset<1?

That sounds reasonable, the value I quickly calculated seemed much too big for me too. What I do know is that the relation between delay and linear phase is super simple. Look it up in a textbook and calculate the time that corresponds to the slope you showed earlier. It should be smaller than the sampling clock interval then.

I didn't realize that you do preamble detection already, I thought since you are using the PPS all your samples are timestamped and you basically _know_ when the OFDM symbol starts. Are you transmitting frames with one preamble and multiple OFDM symbols each?

+-1 slope inversion means for me that your pre-fft timing synchronization is already working and your fft window is placed correctly. That would mean the estimates indeed are correct and reflect the characteristics of the channel - i.e. all the stuff between DAC and ADC ;) - and those introduce some (albeit small) delay.


-paul