Hi, I feel like the output of coarse frequency offset is very inaccurate. Or probably it is not directly related.
For best test, I tried higher resolution of subcarrier bandwidth by selecting the large FFT length, high Interp/decim rate, as follows: @TX: $ sudo python benchmark_ofdm_tx_new.py --mac-addr=ADD -m qpsk -f 2.462G -i 512 --tx-gain=30 --fft-length=2048 --occupied-tones=200 @RX: $ sudo python benchmark_ofdm_rx_new.py --mac-addr=ADD -m qpsk -f 2.462G -d 512 --rx-gain=30 --fft-length=2048 --occupied-tones=200 >From ofdm_frame_acquisition.cc, I can output d_coarse_freq. Therefore, I can calculate the coarse frequency offset by: (ADC rate / Decim rate / FFT_len) * d_coarse_freq But the results I have obtained does not match the real frequency offset. >From the command above, I obtained the d_coarse_freq = 2 --> 190 Hz By moving the RX center frequency to 2.46202G (20KHz offset), the output d_coarse_freq is -64 --> -6103Hz I tried to look into the problem by changing the filter BW line 66-68 of ofdm_receiver.py, as well as shift length at line 109. But they does not work out. Would anyone can help to explain the problem here? Really appreciate :) Thanks, Guanbo Tom Rondeau wrote: > > On 2/20/2010 7:43 PM, Srinivas wrote: >> Hi Tom, >> >> I tried increasing the bandwidth of the filter and also tried changing >> the window type to KAISER, but it didn't improve on the offset error. >> I am getting a constant frequency offset value "-10". Currently, I am >> just compensating for the offset at the receiver or specifying a >> minimum BW to be used for that pair of USRP2s. >> >> Thanks a lot for your time. >> >> Srinivas > > Changing the window type isn't going to help much with this problem. > What I was suggesting was that the filter is too small, not the wrong > type. Also, the only way to change the offset value is to actually move > the frequency. I was just suggesting that you see what that value is to > see how many bins you are off by (i.e., calculate the bandwidth of a > subcarrier and multiply that by 10; that's you're coarse offset). You > can use that to see how much bigger to make the channel filter's > bandwidth. > > Tom > > >> >> On Thu, Feb 18, 2010 at 9:45 AM, Tom Rondeau <trondeau1...@gmail.com >> <mailto:trondeau1...@gmail.com>> wrote: >> >> On Thu, Feb 18, 2010 at 12:49 AM, Srinivas <psriniva...@gmail.com >> <mailto:psriniva...@gmail.com>> wrote: >> > Hi Tom, Matt >> > >> > replied inline: >> > >> > On Wed, Feb 17, 2010 at 10:26 AM, Tom Rondeau >> <trondeau1...@gmail.com <mailto:trondeau1...@gmail.com>> >> > wrote: >> >> >> >> On Tue, Feb 16, 2010 at 5:45 PM, Srinivas >> <psriniva...@gmail.com <mailto: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. >> >> >> > I added this extra argument and tried changing the values from >> 10 to 100. I >> > also tried with "int(0.5*occupied_tones) " as the argument, but >> it doesn't >> > receive for lower data rates (< 1M). Only when I increase the >> data rate > >> > 1.2M, I start receiving some pkts. >> > >> > As mentioned before, when I compensate for the frequency offset >> at the >> > receiver it starts receiving packets successfully too. >> >> For small bandwidths, it's possible that the frequency offset has >> pushed you outside of the channel filter. The filter is probably >> specified too tight and is really supposed to cover only the occupied >> tones, so if you're too far away from the center frequency, the >> filter's already hitting it and no amount of frequency correction >> after that will work. >> >> In ofdm_receiver.py, try making the bandwidth term (bw on line 66) >> wider and see what that does for you. >> >> Also, you can print out d_coarse_freq calculated on line 130 in >> gr_ofdm_frame_acquisition.cc. This is the number of bins you're off >> by >> that you can use to get a feel for how far away in frequency you are. >> >> If opening up the filter works for you, please let us know. We might >> want to either parameterize the bandwidth or just set it wider by >> default. >> >> Tom >> >> >> >> >> -- >> Srinivas >> WINLAB, Rutgers University >> New Jersey > > > _______________________________________________ > 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-tp27557644p30676780.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
