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

[Morgan Redfield]

Ok. I found another problem in my code. The transmit_path has a
multiplier in it that was set to 200 (it could go up to 32768). This
was for the original USRP, but I think UHD needs a signal with
magnitude <=1. It seems like the signal was probably clipping. I
changed the magnitude of the multiplier and fiddled with the gain
parameters a bit. I'm now able to get the standard boxcar that I
expect for OFDM. There's still a spike at the center frequency though,
I don't see a gap.

Thanks,
Morgan

On Wed, Jun 8, 2011 at 11:30 AM, Morgan Redfield <address@hidden> wrote:
> On Tue, Jun 7, 2011 at 6:03 PM, Tom Rondeau <address@hidden> wrote:
>> On Tue, Jun 7, 2011 at 5:31 PM, Morgan Redfield <address@hidden> wrote:
>>>
>>> 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
>>
>> I'm not entirely sure what I'm seeing in that picture. It looks like we're
>> seeing 200 kHz of bandwidth in that scope view. What bandwidth are you
>> transmitting at? That should give some indication of what we should be
>> seeing.
>> If it's working correctly, you should see a flat-top signal out of the noise
>> floor that has a very sharp rolloff. You should be able to see the notch
>> around DC, as well, but you could see it distorted by the DC offset, which I
>> think is part of what I'm seeing in that picture.
>> Tom
>>
>
> I'm currently transmitting with a sample rate of 1MHz. I was looking
> at only 200kHz to try and get a good view of the center frequency.
>
> I'm including a couple of screenshots of the FFT with 1MHz and 2MHz
> bandwidth. The signal doesn't seem to look like what you've described.
> Could I have broken something when I converted it to use UHD?
>
> The code that I'm using to transmit is here:
> https://github.com/mogar/uhd_ofdm/blob/master/benchmark_ofdm_tx.py
> I invoked it with: python benchmark_ofdm_tx.py -f 650M -v --rate=1M
>
> Thanks,
> Morgan
>

ofdm_fft_boxcar.tiff
Description: TIFF image