discuss-gnuradio
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Unforgiven11 dreams
Subject: Re: [Discuss-gnuradio] Channel Response in OFDM with MIMO USRP
Date: Sun, 13 Jan 2013 12:33:34 -0600

Thanks for the reply. 

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? 

PS: If I offset the detection by ~20 samples, the resulting signal after acquisition is messed up. Also, earlier when I demodulate the signal, it happens correctly, after this huge an offset the demodulation fails. The FFT happens after the preamble detection, and it appears that the detection is accurate since the interval between consecutive preamble spikes (packets) corresponds to the interval I maintain at the transmitter.

Further, I thought that having a common clk-ref/pps, should sync up the DAC and ADC running the sender and the receiver? Is that not a correct assumption? Or could this small a timing offset result because of the inaccuracy of the clock-ref/pps?

-jack


On Sun, Jan 13, 2013 at 6:45 AM, Paul Fuxjaeger <address@hidden> wrote:
On 13.01.13 08:04, Jack wrote:

As far as I know only sampling offset should be the reason for the
same, but since these 2 USRPs now share the external clock, can this
still be a problem?

10MHz/PPS syncing seems to work, because otherwise you wouldn't see this slope to be _identical_ over all frames.

I think you are right: timing offset. Maybe because of the total delay between those two synced baseband-in to baseband-out reference planes. So, some basic "timing synchronization" is still needed, every time after you have modified the "channel".

IRRC phaseshift(n) = delta*2*pi*n/N_subcarrier

The current delta seems to be around 0.25 in your plot, so maybe a offsetting your RX fft window by 80*0.25 = 20 samples helps reducing slope.


-paul


reply via email to

[Prev in Thread] Current Thread [Next in Thread]