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
