[Discuss-gnuradio] OFDM Receiver

[MUHAMMAD AHMAD]

Hi,

I am referring the built in  example of gnuradio companion  ( rx_ofdm.grc).
In which I replace random source with usrp source.
on Transmetter side I am sending some bits and in receiver flow graph
(rx_ofdm ) I am facing problem where I have to attach file sink to get
 these bits.

I attached *File sink block* after *bits repack* block but I did not
get any data in file.
I also have attached *File sink after stream CRC32 block but*  I did not
get data in file.

Kindly inform if possible where I have to attach file sink in flow graph to
get receiving bits.

Here is an Attached flow graph modified form of (rx_ofdm)

Thanks in anticipation.


finaloftm_rx.grc
Description: Binary data
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] OFDM receiver

[Marcus Müller]

Hi Muhammad,

sadly, it's not very clear what you're asking about.

* Which flow graph are you referring to?
* What is your precise problem, and what have you tried to solve it so
far? How can we help you with that?

Best regards,

Marcus

On 02/22/2017 02:05 PM, MUHAMMAD AHMAD wrote:
> How can I receive  bits using file sink in ofdm receiver.
> where I have to connect  file sink in flow graph of ofdm receiver?
> either bits repack block output can give bits?
>
>
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] OFDM receiver

[MUHAMMAD AHMAD]

How can I receive  bits using file sink in ofdm receiver.
where I have to connect  file sink in flow graph of ofdm receiver?
either bits repack block output can give bits?
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] OFDM receiver error, FATAL: Missing a required length tag on port 0 at item #0

[Wafa Elhajhmida]

Hi, thank you for your response.

In fact, I still have the same error:
 FATAL: Missing a required length tag on port 0 at item #0
 thread[thread-per-block[21]: ]: Missing length
tag.
and UOO
I put the usrp sink and usrp source 's sample rate to 1M.

What is the suitable sampling rate to put ?

Thanks in advance




2014-06-30 16:36 GMT+02:00 Philip Balister :

> On 06/30/2014 09:20 AM, Wafa Elhajhmida wrote:
> > Hi,
> >
> > I implemented OFDM receiver on USRP E110 using the OFDM receiver in
> > examples in gnuradio's files 3.7
> >
> > and I added to it a chain to create OFDM transmitter: random source, OFDM
> > transmitter, channel model,  throttle, USRP sink
> >
> > But when I executed the flow graph. It generated "UOO"
> and
> > I got an error :
>
> Slow the data rate until this message stops. Then worry about the next
> message.
>
> Philip
>
> >
> > FATAL: Missing a required length tag on port 0 at item #0
> >  thread[thread-per-block[21]: ]: Missing length
> > tag.
> >
> > and tag debug didn't show anything.
> >
> > Have you an idea how to fix this error ?
> >
> > Thanks in advance
> >
> >
> >
> > ___
> > Discuss-gnuradio mailing list
> > Discuss-gnuradio@gnu.org
> > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
> >
>
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] OFDM receiver error, FATAL: Missing a required length tag on port 0 at item #0

[Martin Braun]

On 06/30/2014 03:20 PM, Wafa Elhajhmida wrote:
> FATAL: Missing a required length tag on port 0 at item #0 
> thread[thread-per-block[21]: ]: Missing length tag. 

Add a stream to tagged stream converter.

M


___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] OFDM receiver error, FATAL: Missing a required length tag on port 0 at item #0

[Philip Balister]

On 06/30/2014 09:20 AM, Wafa Elhajhmida wrote:
> Hi,
> 
> I implemented OFDM receiver on USRP E110 using the OFDM receiver in
> examples in gnuradio's files 3.7
> 
> and I added to it a chain to create OFDM transmitter: random source, OFDM
> transmitter, channel model,  throttle, USRP sink
> 
> But when I executed the flow graph. It generated "UOO" and
> I got an error :

Slow the data rate until this message stops. Then worry about the next
message.

Philip

> 
> FATAL: Missing a required length tag on port 0 at item #0
>  thread[thread-per-block[21]: ]: Missing length
> tag.
> 
> and tag debug didn't show anything.
> 
> Have you an idea how to fix this error ?
> 
> Thanks in advance
> 
> 
> 
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
> 

___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] OFDM receiver error, FATAL: Missing a required length tag on port 0 at item #0

[Wafa Elhajhmida]

Hi,

I implemented OFDM receiver on USRP E110 using the OFDM receiver in
examples in gnuradio's files 3.7

and I added to it a chain to create OFDM transmitter: random source, OFDM
transmitter, channel model,  throttle, USRP sink

But when I executed the flow graph. It generated "UOO" and
I got an error :

FATAL: Missing a required length tag on port 0 at item #0
 thread[thread-per-block[21]: ]: Missing length
tag.

and tag debug didn't show anything.

Have you an idea how to fix this error ?

Thanks in advance
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] OFDM receiver on USRP2

[Tom Rondeau]

On Mon, Jan 17, 2011 at 7:58 PM, Guanbo  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 >> > wrote:
>>>
>>>     On Thu, Feb 18, 2010 at 12:49 AM, Srinivas >>     > wrote:
>>>     > Hi Tom, Matt
>>>     >
>>>     > replied inline:
>>>     >
>>>     > On Wed, Feb 17, 2010 at 10:26 AM, Tom Rondeau
>>>     mailto:trondeau1...@gmail.com>>
>>>     > wrote:
>>>     >>
>>>     >> On Tue, Feb 16, 2010 at 5:45 PM, Srinivas
>>>     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 possib

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

Re: [Discuss-gnuradio] OFDM receiver on USRP2

[Guanbo]

Thanks Tom. I tried to see how much the carrier frequency offset would be. 
As you suggested above, I output the coarse freq offset bins, which was
similar as Srinivas's result. It is constant "-2". 

Does it means the carrier offset can be computed as: ADC rate /( Decim_rate
* FFT_len) * 2  ?
If so, in my case, it is around 4KHz. From my knowledge, it seems too good
to be true. 

>From your reference, I put on the channel filter code:
--
bw = (float(occupied_tones) / float(fft_length)) / 2.0
tb = bw*0.08
chan_coeffs = gr.firdes.low_pass (1.0, # gain
  1.0, #
sampling rate
  bw+tb,   #
midpoint of trans. band
  tb,  # width
of trans. band
  gr.firdes.WIN_HAMMING)   # filter
type
self.chan_filt = gr.fft_filter_ccc(1, chan_coeffs)

win = [1 for i in range(fft_length)]

--
Also, my hardware is USRP2+ XCVR2450.
$ sudo python benchmark_ofdm_tx_new.py --mac-addr=  -f 2.462G -m qpsk -i
100 --tx-gain=30 -M 8 -s 1000
FFT_len = 512 (default)
occupie_tones=200






Tom Rondeau wrote:
> 
> On Wed, Jan 12, 2011 at 7:36 PM, Guanbo  wrote:
>>
>> Hi, Tom
>>
>> I am not quite understand the ofdm_sync_xx.cc in
>> python/gnuradio/blks2impl/.
>>
>> What is the difference between frequency synchronization and carrier
>> frequency offset.
>> Why we have to do the timing and frequency synchronization before it?
>>
>> Thanks,
>> Guanbo
> 
> There is the difference between the fine frequency tuning (centering
> the signal inside of a subcarrier) and coarse frequency tunning
> (making sure that subcarrier 0 is at the correct location). The
> ofdm_sync_xx blocks perform the timing and fine frequency calculations
> (the self.nco in ofdm_receiver.py is generated from the fine frequency
> offset from the sync block). This is required before being able to
> perform the FFT demo, or else you'll get inter-carrier interference.
> 
> We can then go into the frequency domain (after the FFT) and work on
> the subcarrier bins to handle the coarse frequency offset, since it is
> easier to do in this domain.
> 
> Tom
> 
> 
> 
>> Tom Rondeau wrote:
>>>
>>> On Tue, Feb 16, 2010 at 5:45 PM, Srinivas  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.
>>>
>>>
 - locking the usrps to a common reference
 My usrp2s are located wide apart so I guess this solution is not
 practical.

 Besides, this confirms that the problem is somewhere in the USRP2
 board,
 right ? (as I tried swapping the daughter cards & firmware with the
 working
 pair)

 Thanks,
 Srinivas
>>>
>>> Nope, this is typical of radio hardware. They are always off
>>> frequency. If two oscillators are off frequency and then multiplied up
>>> to another frequency, the difference will also be magnified. So a 2.4
>>> GHz board will have a larger frequency offset than if you ran it just
>>> through the BasicTx/Rx boards (even though the ratios should be the
>>> same).
>>>
>>> Tom
>>>
>>>
>>> ___
>>> 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-tp27557644p30658514.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
>>
> 
> ___
> 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-tp27557644p30669471.html
Sent from the GnuRadio mailing list archive at Nabble.com.

Re: [Discuss-gnuradio] OFDM receiver on USRP2

[Tom Rondeau]

On Wed, Jan 12, 2011 at 7:36 PM, Guanbo  wrote:
>
> Hi, Tom
>
> I am not quite understand the ofdm_sync_xx.cc in python/gnuradio/blks2impl/.
>
> What is the difference between frequency synchronization and carrier
> frequency offset.
> Why we have to do the timing and frequency synchronization before it?
>
> Thanks,
> Guanbo

There is the difference between the fine frequency tuning (centering
the signal inside of a subcarrier) and coarse frequency tunning
(making sure that subcarrier 0 is at the correct location). The
ofdm_sync_xx blocks perform the timing and fine frequency calculations
(the self.nco in ofdm_receiver.py is generated from the fine frequency
offset from the sync block). This is required before being able to
perform the FFT demo, or else you'll get inter-carrier interference.

We can then go into the frequency domain (after the FFT) and work on
the subcarrier bins to handle the coarse frequency offset, since it is
easier to do in this domain.

Tom



> Tom Rondeau wrote:
>>
>> On Tue, Feb 16, 2010 at 5:45 PM, Srinivas  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.
>>
>>
>>> - locking the usrps to a common reference
>>> My usrp2s are located wide apart so I guess this solution is not
>>> practical.
>>>
>>> Besides, this confirms that the problem is somewhere in the USRP2 board,
>>> right ? (as I tried swapping the daughter cards & firmware with the
>>> working
>>> pair)
>>>
>>> Thanks,
>>> Srinivas
>>
>> Nope, this is typical of radio hardware. They are always off
>> frequency. If two oscillators are off frequency and then multiplied up
>> to another frequency, the difference will also be magnified. So a 2.4
>> GHz board will have a larger frequency offset than if you ran it just
>> through the BasicTx/Rx boards (even though the ratios should be the
>> same).
>>
>> Tom
>>
>>
>> ___
>> 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-tp27557644p30658514.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
>

___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] OFDM receiver on USRP2

[Guanbo]

Hi, Tom

I am not quite understand the ofdm_sync_xx.cc in python/gnuradio/blks2impl/.

What is the difference between frequency synchronization and carrier
frequency offset. 
Why we have to do the timing and frequency synchronization before it?

Also, 

Thanks,
Guanbo


Tom Rondeau wrote:
> 
> On Tue, Feb 16, 2010 at 5:45 PM, Srinivas  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.
> 
> 
>> - locking the usrps to a common reference
>> My usrp2s are located wide apart so I guess this solution is not
>> practical.
>>
>> Besides, this confirms that the problem is somewhere in the USRP2 board,
>> right ? (as I tried swapping the daughter cards & firmware with the
>> working
>> pair)
>>
>> Thanks,
>> Srinivas
> 
> Nope, this is typical of radio hardware. They are always off
> frequency. If two oscillators are off frequency and then multiplied up
> to another frequency, the difference will also be magnified. So a 2.4
> GHz board will have a larger frequency offset than if you ran it just
> through the BasicTx/Rx boards (even though the ratios should be the
> same).
> 
> Tom
> 
> 
> ___
> 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-tp27557644p30658519.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

Re: [Discuss-gnuradio] OFDM receiver on USRP2

[Guanbo]

Hi, Tom

I am not quite understand the ofdm_sync_xx.cc in python/gnuradio/blks2impl/.

What is the difference between frequency synchronization and carrier
frequency offset. 
Why we have to do the timing and frequency synchronization before it?

Thanks,
Guanbo


Tom Rondeau wrote:
> 
> On Tue, Feb 16, 2010 at 5:45 PM, Srinivas  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.
> 
> 
>> - locking the usrps to a common reference
>> My usrp2s are located wide apart so I guess this solution is not
>> practical.
>>
>> Besides, this confirms that the problem is somewhere in the USRP2 board,
>> right ? (as I tried swapping the daughter cards & firmware with the
>> working
>> pair)
>>
>> Thanks,
>> Srinivas
> 
> Nope, this is typical of radio hardware. They are always off
> frequency. If two oscillators are off frequency and then multiplied up
> to another frequency, the difference will also be magnified. So a 2.4
> GHz board will have a larger frequency offset than if you ran it just
> through the BasicTx/Rx boards (even though the ratios should be the
> same).
> 
> Tom
> 
> 
> ___
> 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-tp27557644p30658514.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

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

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

Re: [Discuss-gnuradio] OFDM receiver on USRP2

[Tom Rondeau]

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


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

Re: [Discuss-gnuradio] OFDM receiver on USRP2

[Srinivas]

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

On Thu, Feb 18, 2010 at 9:45 AM, Tom Rondeau  wrote:

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

Re: [Discuss-gnuradio] OFDM receiver on USRP2

[Tom Rondeau]

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


___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] OFDM receiver on USRP2

[Srinivas]

Hi Tom, Matt

replied inline:

On Wed, Feb 17, 2010 at 10:26 AM, Tom Rondeau wrote:

> On Tue, Feb 16, 2010 at 5:45 PM, Srinivas  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.



> - locking the usrps to a common reference
> My usrp2s are located wide apart so I guess this solution is not
practical.
>
> Besides, this confirms that the problem is somewhere in the USRP2 board,
> right ? (as I tried swapping the daughter cards & firmware with the
working
> pair)
>
> Thanks,
> Srinivas

Nope, this is typical of radio hardware. They are always off
> frequency. If two oscillators are off frequency and then multiplied up
> to another frequency, the difference will also be magnified. So a 2.4
> GHz board will have a larger frequency offset than if you ran it just
> through the BasicTx/Rx boards (even though the ratios should be the
> same).
>
> Tom
>

Thanks! I understand this now.

-- 
Srinivas
WINLAB, Rutgers University
New Jersey
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] OFDM receiver on USRP2

[Tom Rondeau]

On Tue, Feb 16, 2010 at 5:45 PM, Srinivas  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.


> - locking the usrps to a common reference
> My usrp2s are located wide apart so I guess this solution is not practical.
>
> Besides, this confirms that the problem is somewhere in the USRP2 board,
> right ? (as I tried swapping the daughter cards & firmware with the working
> pair)
>
> Thanks,
> Srinivas

Nope, this is typical of radio hardware. They are always off
frequency. If two oscillators are off frequency and then multiplied up
to another frequency, the difference will also be magnified. So a 2.4
GHz board will have a larger frequency offset than if you ran it just
through the BasicTx/Rx boards (even though the ratios should be the
same).

Tom


___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] OFDM receiver on USRP2

[Matt Ettus]

On 02/16/2010 02:45 PM, Srinivas 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 ?

*- locking the usrps to a common reference
*My usrp2s are located wide apart so I guess this solution is not practical.

Besides, this confirms that the problem is somewhere in the USRP2 board,
right ? (as I tried swapping the daughter cards & firmware with the
working pair)



No, this confirms that there is no problem.  Frequency offset is a 
natural part of radio systems.  The software needs to handle it properly.


Matt


___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] OFDM receiver on USRP2

[Srinivas]

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 ?

*- locking the usrps to a common reference
*My usrp2s are located wide apart so I guess this solution is not practical.

Besides, this confirms that the problem is somewhere in the USRP2 board,
right ? (as I tried swapping the daughter cards & firmware with the working
pair)

Thanks,
Srinivas

On Sun, Feb 14, 2010 at 3:25 AM, Matt Ettus  wrote:

>
>  That formula will give you the number of occupied tones per second. You
>> need to multiply by the number of bits per tone to get bps. If you are
>> using BPSK, multiply by 1. If using QPSK, you'll need to multiply by 3,
>> 8PSK by 3, etc.
>>
>
>
> I meant to say:
>
> BPSK - multiply by 1
> QPSK - mult by 2 (not 3 like I said above)
> 8PSK - mult by 3
>
> sorry for the confusion.
>
> Matt
>



-- 
Srinivas
WINLAB, Rutgers University
New Jersey
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] OFDM receiver on USRP2

[Matt Ettus]

That formula will give you the number of occupied tones per second. You
need to multiply by the number of bits per tone to get bps. If you are
using BPSK, multiply by 1. If using QPSK, you'll need to multiply by 3,
8PSK by 3, etc.



I meant to say:

BPSK - multiply by 1
QPSK - mult by 2 (not 3 like I said above)
8PSK - mult by 3

sorry for the confusion.

Matt


___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] OFDM receiver on USRP2

[Matt Ettus]

On 02/12/2010 03:53 PM, Srinivas wrote:

Matt,

There was a frequency offset of ~30 KHz at the Rx w.r.t Tx so I
compensated for it and it worked!.

The settings I am using is as follows:

./benchmark_ofdm_tx.py -f 2.45G --tx-amplitude 0.9 -M 8 -s 200 -m bpsk
--fft-length=512 --occupied-tones=80 -i 64 --tx-gain=10 --cp-length=128
./benchmark_ofdm_rx.py -f 2.45G -m bpsk --fft-length=512
--occupied-tones=80 -d 64 --rx-gain=20 --cp-length=128

I calculate the data-rate for OFDM as follows Data rate R = (ADC
sampling rate x Occupied Tones) / (Nfft x Decimation)
For the above setting it is 244 KHz.

Am I right with the data rate calculation ?


That formula will give you the number of occupied tones per second.  You 
need to multiply by the number of bits per tone to get bps.  If you are 
using BPSK, multiply by 1.  If using QPSK, you'll need to multiply by 3, 
8PSK by 3, etc.


Matt


___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] OFDM receiver on USRP2

[Srinivas]

Matt,

There was a frequency offset of ~30 KHz at the Rx w.r.t Tx so I compensated
for it and it worked!.

The settings I am using is as follows:

./benchmark_ofdm_tx.py -f 2.45G --tx-amplitude 0.9 -M 8 -s 200 -m bpsk
--fft-length=512 --occupied-tones=80 -i 64 --tx-gain=10 --cp-length=128
./benchmark_ofdm_rx.py -f 2.45G -m bpsk --fft-length=512 --occupied-tones=80
-d 64 --rx-gain=20 --cp-length=128

I calculate the data-rate for OFDM as follows Data rate R = (ADC sampling
rate x Occupied Tones) / (Nfft x Decimation)
For the above setting it is 244 KHz.

Am I right with the data rate calculation ?

Thanks very much for your time,



On Thu, Feb 11, 2010 at 10:26 PM, Matt Ettus  wrote:

> On 02/11/2010 04:45 PM, Srinivas wrote:
>
>> Hi All,
>>
>> I have 2 pairs of USRP2s with GNURadio-3.2 installed on their hosts. On
>> one pair I am able to successfully run OFDM (benchmark_ofdm_tx & rx)
>> with almost 95+% packet success rate. However on the other pair I am not
>> receiving even 1 packet!
>>
>> I am using the same host machines and scripts. I also tried swapping the
>> daughtercards (XCVR2450) and the firmwares with the working pair, but
>> the problem remains.
>>
>> Does any one have a clue of where the problem might be ?
>>
>> PS: The received signal spectrum (usrp2_fft.py) on one of the
>> non-working USRP2s is attached herewith. Besides this I plotted the
>> spectrum of the received data from usrp2_rx_cfile.py at the receiver
>> using MATLAB. The spectrum is of the same shape and strength as
>> usrp2_fft.py displays.
>>
>
>
> Srinivas,
>
> It looks like you are using a very narrow signal.  The frequency offset of
> the USRP2s giving you trouble may be enough that you are outside of the
> search range of the OFDM receiver (which is a percentage of the bandwidth of
> the signal).
>
> You could try any or all of the following:
>
> - increasing the data rate by a factor of 2 or 4
> - modifying the OFDM code to widen the search range
> - locking the usrps to a common reference
> - measure the frequency offset of the transmitter, and run the receiver
> with the actual frequency.  For example, if the receiver sees the signal 30
> kHz high using usrp2_fft.py, call the ofdm receiver with
>
>-f 2.450030G
> on the command line
>
>
> Matt
>



-- 
Srinivas
WINLAB, Rutgers University
New Jersey
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] OFDM receiver on USRP2

[Matt Ettus]

On 02/11/2010 04:45 PM, Srinivas wrote:

Hi All,

I have 2 pairs of USRP2s with GNURadio-3.2 installed on their hosts. On
one pair I am able to successfully run OFDM (benchmark_ofdm_tx & rx)
with almost 95+% packet success rate. However on the other pair I am not
receiving even 1 packet!

I am using the same host machines and scripts. I also tried swapping the
daughtercards (XCVR2450) and the firmwares with the working pair, but
the problem remains.

Does any one have a clue of where the problem might be ?

PS: The received signal spectrum (usrp2_fft.py) on one of the
non-working USRP2s is attached herewith. Besides this I plotted the
spectrum of the received data from usrp2_rx_cfile.py at the receiver
using MATLAB. The spectrum is of the same shape and strength as
usrp2_fft.py displays.



Srinivas,

It looks like you are using a very narrow signal.  The frequency offset 
of the USRP2s giving you trouble may be enough that you are outside of 
the search range of the OFDM receiver (which is a percentage of the 
bandwidth of the signal).


You could try any or all of the following:

- increasing the data rate by a factor of 2 or 4
- modifying the OFDM code to widen the search range
- locking the usrps to a common reference
- measure the frequency offset of the transmitter, and run the receiver 
with the actual frequency.  For example, if the receiver sees the signal 
30 kHz high using usrp2_fft.py, call the ofdm receiver with


-f 2.450030G
on the command line


Matt


___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio