Re: [Discuss-gnuradio] OFDM receiver on USRP2

[Tuan Ta]

Sorry for bringing up an old thread. I was having the same problem of not receiving packets using benchmark_ofdm_* and changing the receiver frequency to tune to the transmitter frequency indeed solved the problem. 

However, if I have to manually do it every time, I don't see how I can get ofdm tunnel to work. In tunnel, each USRP is both transmitter and receiver. The frequency offset of one USRP (A) transmitting to the other (B) will be different than B transmitting to A. Since the frequency offset can't be set at run time, I don't see how to manually tune after running tunnel on both USRPs.

Can anyone show me how to make tunnel work?

Thank you very much,

Tuan

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> wrote:

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