discuss-gnuradio
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Discuss-gnuradio] OFDM receiver on USRP2


From: Tom Rondeau
Subject: Re: [Discuss-gnuradio] OFDM receiver on USRP2
Date: Tue, 18 Jan 2011 10:08:42 -0500

On Mon, Jan 17, 2011 at 7:58 PM, Guanbo <address@hidden> wrote:
>
> 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


I know this doesn't directly answer your question, but I know that
Matt and I performed the exact same tests when we developed the OFDM
code to make sure that the coarse frequency offset followed the input
frequency offset that we used. So if one subcarrier in your case is
~95 Hz, we could easily track the coarse frequency offset output and
match up our results.

One problem that you seem to have is that a 20 kHz is completely
outside your channel. If I've done my math correctly, 20 kHz is almost
210 subcarriers and you are only using 200, so you are out of the
receiver's channel by about 110 bins.

Tom

>
> 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.
>
>
> _______________________________________________
> Discuss-gnuradio mailing list
> address@hidden
> http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>



reply via email to

[Prev in Thread] Current Thread [Next in Thread]