Re: [Discuss-gnuradio] problems with benchmark_ofdm and N210

[Morgan Redfield]

On Tue, Jun 7, 2011 at 1:50 PM, Tom Rondeau <address@hidden> wrote:
> On Tue, Jun 7, 2011 at 3:24 PM, Morgan Redfield <address@hidden> wrote:
>>
>> On Tue, Jun 7, 2011 at 7:38 AM, Tom Rondeau <address@hidden>
>> wrote:
>> > On Mon, Jun 6, 2011 at 8:33 PM, Morgan Redfield <address@hidden>
>> > wrote:
>> >>
>> >> Hi Everyone,
>> >>
>> >> I've been playing around with GNURadio and a couple of USRPs lately,
>> >> but I've run into some problems. I'm using a modified version of the
>> >> benchmark_ofdm_tx.py and benchmark_ofdm_rx.py scripts. I updated them
>> >> to use uhd, and I'm using them with two N210s. Each N210 has a WBX
>> >> daughterboard, and they're placed about a meter apart right now.
>> >>
>> >> I'm attempting to send data from one USRP to the other, but using
>> >> tunnel.py or the benchmark_ofdm files doesn't seem to work. I never
>> >> receive any packets correctly.
>> >>
>> >> With the benchmark_ofdm files, if I start receiving before I start
>> >> transmitting then I just get TIMEOUTs. If I start transmitting before
>> >> I start receiving, I get the following:
>> >>
>> >> $ python benchmark_ofdm_rx.py -f 650M -v --rate=1M
>> >> Mac OS; GNU C++ version 4.0.1 (Apple Inc. build 5490); Boost_104601;
>> >> UHD_003.001.000-4eb4025
>> >>
>> >> -- Opening a USRP2/N-Series device...
>> >> -- Current recv frame size: 1472 bytes
>> >> -- Current send frame size: 1472 bytes
>> >> -- mboard0 is MIMO master
>> >> >>> gr_fir_ccf: using SSE
>> >> >>> gr_fir_fff: using SSE
>> >>
>> >> OFDM Demodulator:
>> >> Modulation Type: bpsk
>> >> FFT length:      512
>> >> Occupied Tones:  200
>> >> CP length:       128
>> >> ok: False        pktno: 21611    n_rcvd: 1       n_right: 0
>> >> ok: False        pktno: 43626    n_rcvd: 2       n_right: 0
>> >> ok: False        pktno: 21611    n_rcvd: 3       n_right: 0
>> >> ok: False        pktno: 37548    n_rcvd: 4       n_right: 0
>> >> ok: False        pktno: 21909    n_rcvd: 5       n_right: 0
>> >> ok: False        pktno: 4473     n_rcvd: 6       n_right: 0
>> >> ok: False        pktno: 27253    n_rcvd: 7       n_right: 0
>> >> ok: False        pktno: 38378    n_rcvd: 8       n_right: 0
>> >> ok: False        pktno: 21909    n_rcvd: 9       n_right: 0
>> >> ok: False        pktno: 38486    n_rcvd: 10      n_right: 0
>> >> ok: False        pktno: 54634    n_rcvd: 11      n_right: 0
>> >> ok: False        pktno: 21909    n_rcvd: 12      n_right: 0
>> >> ok: False        pktno: 39158    n_rcvd: 13      n_right: 0
>> >> ok: False        pktno: 27237    n_rcvd: 14      n_right: 0
>> >> ok: False        pktno: 42410    n_rcvd: 15      n_right: 0
>> >> ok: False        pktno: 21909    n_rcvd: 16      n_right: 0
>> >> ok: False        pktno: 21994    n_rcvd: 17      n_right: 0
>> >> ok: False        pktno: 21652    n_rcvd: 18      n_right: 0
>> >> ok: False        pktno: 21097    n_rcvd: 19      n_right: 0
>> >> ok: False        pktno: 43626    n_rcvd: 20      n_right: 0
>> >> ok: False        pktno: 21909    n_rcvd: 21      n_right: 0
>> >> TIMEOUT
>> >> TIMEOUT
>> >>
>> >> I think those timeouts at the end there are from when the transmitter
>> >> stopped transmitting data. It looks like I'm receiving a few packets
>> >> (far fewer than I should), and all the packets I do receive are not
>> >> correct.
>> >>
>> >> Does anyone have any idea what's causing this?
>> >>
>> >> Thanks
>> >> Morgan
>> >
>> > TIMEOUTs occur when a preamble has been detected, but then the signal is
>> > lost.
>> > My thinking is that you are too far off frequency and so the received
>> > signal
>> > is outside the bandwidth of the receiver. Look at the signal in a FFT
>> > plot
>> > and see if you can adjust the transmitter's frequency to close the gap.
>> > Tom
>> >
>>
>> I tried measuring the frequency offset of the USRPs by generating a
>> 100KHz sine wave and mixing it up to my rf frequency (650MHz). When I
>> used uhd_fft.py to look at the signal at the receiving N210, I see the
>> peak pretty close to where it should be at 650.1MHz. I doubt the
>> signal is off by more than 3KHz. Could such a small frequency offset
>> really be causing me so many problems?
>>
>> I also tried looking at my OFDM signal in uhd_fft.py, but it was
>> pretty messy and bounced around a lot as packets were transmitted. I'm
>> not sure how I would go about adjusting the transmitter's frequency
>> from just looking at that. Could you please give me a few more
>> details?
>>
>> Morgan
>
> You can use the averaging in the uhd_fft plot to help smooth out the signal
> to see if it's centered. The OFDM transmitter we have notches out the center
> two subcarriers, so you will hopefully be able to see a small gap in the
> middle of the signal.
> You might have the transmitter power set too high. OFDM really needs to
> operate in the linear range of the transmitter, so keeping the power down
> helps. I thought of this when you said "messy," which could be influenced by
> this factor.
> In general, though, no, 3 kHz offset should not be a problem for this.
> Tom
>
Hi Tom,

The transmitter power was one of my problems. I had it set to the max.
I've adjusted it to be about a quarter of the range, and I'm looking
at the FFT of the OFDM signal. I'm seeing a spike that's significantly
higher than the rest of the carriers right at my center frequency. It
looks like there may be a small gap in it, but I'm not sure if that's
what I'm supposed to be getting. I'm attaching a screenshot of the FFT
so you can see what I mean.

Thanks for your help,
Morgan

ofdm_fft_note_center_carriers.tiff
Description: TIFF image