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/(PiT) + 2z/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?

Phi/(Pi*T). In this situation, the even PN sequencies of the second training
Is the current implementation assuming that the frequency is less than PI?
Or anything I missed?

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.

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?

When, estimating the carrier frequency offset at the receiver, if the
and the z can be estimated by some optimization algorithm, using both of
Or anything I missed?
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.

cp_length minus the channelimpulseresponse length. I am thinking, without
counting the channel response length, can we get the peak accurately,
especially in multipath environment?

It’s been so long since I’ve looked closely at that. You could be
right. Test it and see and let us know the results.

To dig the details of the current ofdm receiver synchronization, i did
some
experiments by the benchmark_rx.py. But I see something strange
regarding
the Preamble correlation plateau width, although the data packet is
communicated as expected.

Please see the attached pictures, I analyzed the data file
“ofdm_sync_pn-theta_f.dat” which is generated by ofdm_sync_pn.py. But I
found the plateau width is half of the cp length(128), which is shown in
1.jpg.
So I continue to analyze the data file “ofdm_sync_pn-input_c.dat”
generated
in the same time, by manually doing the correlation on the input data of
the ofdm_sync_pn.py and find that the plateau is correct as cp_length
(128), which is shown in 2.jpg.
So I guess, are there any operations like the decimation to decrease the
sample number by half, when generating the normalized metric for the
preamble correlation plateau in ofdm_sync_pn.py.

I know it is long time for you to have looked this piece of code. But it
is
really appreciated if you can give a help.

plateau of the metric and get the smooth peak. But I am a little confused
right. Test it and see and let us know the results.

to be less than PI, then the frequency offset estimate can derived by
frequencies
Or anything I missed?
Take a look at the presentation we put together here: