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

[Tom Rondeau]

On Wed, Jun 8, 2011 at 9:51 PM, Morgan Redfield <address@hidden> wrote:

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

Ah, yes, that last picture definitely looks like OFDM. The SNR isn't great, so you might want to try playing with the gain a bit more on either the transmitter and receiver.

The signal in the center is pretty ugly. If you are not transmitting, what do you see? Also, try changing frequency to see if this is a signal your seeing coming in that could be avoided. You can also try to change the LO frequency of the USRP through the UHD interface (see the UHD documentation for how to do this).

With that level of signal right in the middle of the spectrum, there's no way you're going to see the two unused subcarriers in the middle.

You're getting close, though!

Tom

 

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
>