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,

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. 

My command is as:

./benchmark_tx.py -f 1.4G --fft 256 --occ 240 --log

./benchmark_rx.py -f 1.4G --fft 256 --occ 240 --log

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.

On Sat, Mar 31, 2012 at 9:36 AM, Tom Rondeau <address@hidden> wrote:

On Tue, Mar 27, 2012 at 10:29 PM, Alex Zhang <address@hidden> wrote:
> 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?

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.

Tom

> 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.
>

--

Alex,

Dreams can come true – just believe.

1.jpg
Description: JPEG image

2.jpg
Description: JPEG image