Re: [Discuss-gnuradio] [discuss-gnuradio]ofdm sync using only one preamble in gnuradio example benchmark_tx.py and benchmark_rx.py

[Alex Zhang]

Hi Tom,

Thanks for the reply.

In the ofdm_sync_pn.py, I see that a matched filter is used, after the timing metric is obtained based on the correlation of the two halves of the preamble. I understand this matched filter is trying to find the end of the plateau of the metric and get the smooth peak. But I am a little confused with the length of this matched filter. 

In the code, the length of this matched filter is set as equal to cp_length. But in T.M.Schmidl's paper(page 1615), the plateau length is equal to the cp_length minus the channel impulse response length. I am thinking, without counting the channel response length, can we get the peak accurately, especially in multipath environment? 

On Sun, Mar 25, 2012 at 12:40 PM, Tom Rondeau <address@hidden> wrote:

On Sat, Mar 24, 2012 at 8:52 PM, Alex Zhang <address@hidden> wrote:
> Hi Gurus,
>
> I just want to make sure how the current gnuradio ofdm exampel is
> doing synchronization.
> According to T. M. Schmidl and D. C. Cox, "Robust Frequency and
> Timing  Synchonization for OFDM," IEEE Trans. Communications, vol. 45, no.
> 12, 1997.
> When, estimating the carrier frequency offset at the receiver, if the phase
> difference between the two halves of the 1st training symbol is guaranteed
> to be less than PI, then the frequency offset estimate can derived by
> Phi/(Pi*T). In this situation, the even PN sequencies of the second training
> symbol would not be needed. Otherwise, the actual frequency offset would be
>
> Phi/(Pi*T)  + 2*z/T
>  and the z can be estimated by some optimization algorithm, using both of
> the training symbols. Also, the paper mentioned that the odd frequencies of
> the second training symbol can be used to measure the sub-channels.
>
> However, I find that only one training symbol is generated to act as
> preamble at the ofdm transmitter. And on the receiver, it seems that only
> one preamble is used to estimate the timing peak and the frequency offset.
> Is the current implementation assuming that the frequency is less than PI?
> Or anything I missed?
>
> Looking forward to your input!
> --
>
> Alex,
> Dreams can come true – just believe.

Alex,

Take a look at the presentation we put together here:
http://gnuradio.org/redmine/projects/gnuradio/wiki/Wireless

It explains the synchronization process. Basically, the single
preamble is made up of two identical sections, so the correlation is
done between those two sections to get the timing and fine frequency
estimate. Since this preamble is known, we also use it to handle the
coarse frequency (number of bins) offset.

Tom

--

Alex,

Dreams can come true – just believe.