On Sat, Apr 7, 2012 at 6:19 PM, Alex Zhang <[email protected]> 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 <[email protected]> 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 <[email protected]> wrote: >>> >>> On Tue, Mar 27, 2012 at 10:29 PM, Alex Zhang <[email protected]> >>> 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 <[email protected]> wrote: >>> >> >>> >> On Sat, Mar 24, 2012 at 8:52 PM, Alex Zhang <[email protected]> >>> >> 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. > _______________________________________________ Discuss-gnuradio mailing list [email protected] https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
