On Wed, Jan 12, 2011 at 7:36 PM, Guanbo <gbzh...@gmail.com> wrote: > > Hi, Tom > > I am not quite understand the ofdm_sync_xx.cc in python/gnuradio/blks2impl/. > > What is the difference between frequency synchronization and carrier > frequency offset. > Why we have to do the timing and frequency synchronization before it? > > Thanks, > Guanbo
There is the difference between the fine frequency tuning (centering the signal inside of a subcarrier) and coarse frequency tunning (making sure that subcarrier 0 is at the correct location). The ofdm_sync_xx blocks perform the timing and fine frequency calculations (the self.nco in ofdm_receiver.py is generated from the fine frequency offset from the sync block). This is required before being able to perform the FFT demo, or else you'll get inter-carrier interference. We can then go into the frequency domain (after the FFT) and work on the subcarrier bins to handle the coarse frequency offset, since it is easier to do in this domain. Tom > Tom Rondeau wrote: >> >> On Tue, Feb 16, 2010 at 5:45 PM, Srinivas <psriniva...@gmail.com> wrote: >>> Matt, >>> >>> Thanks for verifying the data rate calculation! >>> >>> I tried the other solutions that you suggested, namely, >>> >>> - increasing the data rate by a factor of 2 or 4 >>> It works. >>> >>> - modifying the OFDM code to widen the search range - How do I widen the >>> search range ? >>> Should I be looking in the "ofdm_sync_" blocks in "blks2impl" folder ? If >>> yes, which synchronizer is currently used with ofdm_examples ? >> >> You need to add an argument to gr.ofdm_frame_acquisition in >> ofdm_receiver.py (in python/gnuradio/blks2impl). >> >> In the current Git master, this is located on line 109 of >> ofdm_receiver.py. After the "ks[0]" argument, you can put in an >> integer. This is the maximum number of bins the receiver will search >> over for correlation. It defaults to 10. >> >> >>> - locking the usrps to a common reference >>> My usrp2s are located wide apart so I guess this solution is not >>> practical. >>> >>> Besides, this confirms that the problem is somewhere in the USRP2 board, >>> right ? (as I tried swapping the daughter cards & firmware with the >>> working >>> pair) >>> >>> Thanks, >>> Srinivas >> >> Nope, this is typical of radio hardware. They are always off >> frequency. If two oscillators are off frequency and then multiplied up >> to another frequency, the difference will also be magnified. So a 2.4 >> GHz board will have a larger frequency offset than if you ran it just >> through the BasicTx/Rx boards (even though the ratios should be the >> same). >> >> Tom >> >> >> _______________________________________________ >> Discuss-gnuradio mailing list >> Discuss-gnuradio@gnu.org >> http://lists.gnu.org/mailman/listinfo/discuss-gnuradio >> >> > > -- > View this message in context: > http://old.nabble.com/OFDM-receiver-on-USRP2-tp27557644p30658514.html > Sent from the GnuRadio mailing list archive at Nabble.com. > > > _______________________________________________ > Discuss-gnuradio mailing list > Discuss-gnuradio@gnu.org > http://lists.gnu.org/mailman/listinfo/discuss-gnuradio > _______________________________________________ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio