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

[Tom Rondeau]

On Sat, Apr 7, 2012 at 6:19 PM, Alex Zhang <address@hidden> wrote:
> Hi Tom,
>
> Just correct my mail.
> I retest the case, it is found that my matlab code has some errors which
> cause this confusion. Sorry for the incorrect result.

Alex,
Thanks for getting back in touch about this. I wasn't sure how to
answer your last question. Good to hear you've got things worked out.

Tom


> On Tue, Apr 3, 2012 at 12:43 AM, Alex Zhang <address@hidden> wrote:
>>
>> 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.
>>
>
>
>
> --
>
> Alex,
> Dreams can come true – just believe.
>