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
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.
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.
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?
to use uhd, and I’m using them with two N210s. Each N210 has a WBX
$ python benchmark_ofdm_rx.py -f 650M -v --rate=1M
OFDM Demodulator:
ok: False pktno: 27253 n_rcvd: 7 n_right: 0
ok: False pktno: 21652 n_rcvd: 18 n_right: 0
plot
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.
TIMEOUTs occur when a preamble has been detected, but then the signal
from just looking at that. Could you please give me a few more
You might have the transmitter power set too high. OFDM really needs to
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.
I’m attempting to send data from one USRP to the other, but using
UHD_003.001.000-4eb4025
FFT length: 512
ok: False pktno: 21909 n_rcvd: 9 n_right: 0
ok: False pktno: 43626 n_rcvd: 20 n_right: 0
Does anyone have any idea what’s causing this?
plot
really be causing me so many problems?
signal
In general, though, no, 3 kHz offset should not be a problem for this.
so you can see what I mean.
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:
I invoked it with: python benchmark_ofdm_tx.py -f 650M -v --rate=1M
but I’ve run into some problems. I’m using a modified version of the
I start receiving, I get the following:
gr_fir_fff: using SSE
ok: False pktno: 21909 n_rcvd: 5 n_right: 0
ok: False pktno: 21909 n_rcvd: 16 n_right: 0
(far fewer than I should), and all the packets I do receive are not
signal
signal is off by more than 3KHz. Could such a small frequency offset
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.
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.
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.
On Wed, Jun 8, 2011 at 7:20 PM, Marcus D. Leech [email protected]
wrote:
Marcus L.
When I’m not transmitting, I don’t really see anything above the noise
at the center frequency of 650MHz. There is a small spike (a few dB or
so) right at the center frequency, but I think that’s due to the USRP.
Other messages on this list seem to indicate that it isn’t abnormal.
That spike is only very noticeable when I’m transmitting. I’ll try
changing the tx frequency and playing around with the gain tomorrow
and let you know how that goes.
I found that centering my FFT on a frequency that’s offset from what
I’m transmitting at will remove that central spike. I was able to
finally see the gap in the center of the OFDM boxcar and adjust that.
It looks like in my setup I have an offset of about 6kHz.
My OFDM signal never seems to be more than about 10 dB above the noise
floor though. When I bump up the gain or tx-amplitude, everything gets
raised by the same amount. I’m still not able to demodulate packets,
and I think this is why. Do you have any advice about this?
If changing the TX amplitude doesn’t improve things, then perhaps the
frequency offset is the problem.
I’m not much of an OFDM guy, but it seems to me if your OFDM “bins”
aren’t where they’re supposed to be,
to less than a fraction of a bin-width, then there could be problems.
Also, to confirm that your RX is sensitive enough, if there’s a way you
could generate a single-tone signal at
about -110dBm, directly connected to the RX, and see if you can see
the tone in an FFT display. If not then
you have RX sensitivity issues.
–
Marcus L.
Principal Investigator
Shirleys Bay Radio Astronomy Consortium
I finally got this working. One of the machine’s I was using was
running Windows with the gnuradio port from Josh Knows | CMake GNU Radio Port. When I switched to Ubuntu the
majority of my problems went away. I’ve got no idea what was going on
with the Windows machine, but I never got any errors from it. The
transmitted signal was just never very clean.
I’m now able to use the benchmark_ofdm_tx and benchmark_ofdm_rx
scripts to send packets between my N210s. While I was playing with the
settings to get better throughput, I noticed that the SNR setting in
benchmark_ofdm_rx.py seems to break things. As long as I don’t use the
–snr flag, everything works ok. If I use --snr with any value, I
receive no packets. I can’t even use --snr=30 (the default) without
breaking things. Does anyone know why that would be?
On Thu, Jun 9, 2011 at 3:01 PM, Marcus D. Leech [email protected]
wrote:
and I think this is why. Do you have any advice about this?
Thanks,
Morgan
Try changing the receiver gain instead. If the noise floor is moving
with
changes in the transmitter, then you are seeing non-linear effects in
the
transmit chain, which is bad. This is the chief problem of OFDM in that
you
need a good, linear PA to transmit with higher power for greater
distance
(which is one reason LTE is using SC-FDMA in the handsets).
If changing the TX amplitude doesn’t improve things, then perhaps the
frequency offset is the problem.
I’m not much of an OFDM guy, but it seems to me if your OFDM “bins” aren’t
where they’re supposed to be,
to less than a fraction of a bin-width, then there could be problems.
The synchronization algorithms in OFDM correct for both fractional
(inner
subcarrier) offset and integer (greater than a subcarrier) offset, but
only
to an extent. So you can be off by a few subcarriers from the desired
frequency and have those corrected (I think we put in +/- 5 or 10), and
the
fractional offset is also taken care of. The analysis of this shows that
you
get a significant increase in BER if you are even slightly off carrier
after
sync, so it’s a very important part of the process (since OFDM depends
on
things being orthogonal, any frequency offset destroys the
orthogonality).
Tom
Also, to confirm that your RX is sensitive enough, if there’s a way you
Actually, it looks like it doesn’t. It messes things up when I call it
from my Mac, but on my ubuntu machine it just has no effect. I’ll just
ignore it for now.
benchmark_ofdm_rx.py seems to break things. As long as I don’t use the
–snr flag, everything works ok. If I use --snr with any value, I
receive no packets. I can’t even use --snr=30 (the default) without
breaking things. Does anyone know why that would be?
Thanks for all your help,
Morgan
Glad you got it working!
As for the SNR setting, I’d have to look back at the code. I thought it
was
just for one of the sync methods that we aren’t using, so I didn’t think
it
mattered. Must be being used somewhere that I can’t recall just now.
Tom
This forum is not affiliated to the Ruby language, Ruby on Rails framework, nor any Ruby applications discussed here.