Re: [Discuss-gnuradio] OFDM receiver on USRP2

[Guanbo]

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 <address@hidden 
>> <mailto:address@hidden>> wrote:
>>
>>     On Thu, Feb 18, 2010 at 12:49 AM, Srinivas <address@hidden
>>     <mailto:address@hidden>> wrote:
>>     > Hi Tom, Matt
>>     >
>>     > replied inline:
>>     >
>>     > On Wed, Feb 17, 2010 at 10:26 AM, Tom Rondeau
>>     <address@hidden <mailto:address@hidden>>
>>     > wrote:
>>     >>
>>     >> On Tue, Feb 16, 2010 at 5:45 PM, Srinivas
>>     <address@hidden <mailto:address@hidden>> 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
> address@hidden
> 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.