UHD USRP sink does not react to gain changes (gr-ieee802-11: between two usrp devices)

Dear All,

I need your help. May be any of you had such a problem before:

I use ‘IEEE 802.11 a/g/p OFDM Transceiver’ project, Ubuntu 13.04,
GNURADIO 3.7 and (USRP N200 + XCVR 2450 + VERT2450 antenna).
I start the transmission using the first laptop and USRP N200 device by
running the ./ofdm_tx.py.
Meanwhile I use the second laptop and USRP N200 device as the receiver
by running the ./ofdm_rx.py. The error rate is very high.

The problem is that when I change gain in the USRP sink nothing changes
(i tested it using ‘wxgui_fftsink’).
(I think it is a software problem since I tested it with another
project. There it changes when I change gain.)

Do you know what can cause this?
Why transmission side (USRP sink) does not change according to the gain
at all?

Thanks in advance!

On 12 Dec 2013, at 11:31, Nasi [email protected] wrote:

Meanwhile I use the second laptop and USRP N200 device as the receiver by
running the ./ofdm_rx.py. The error rate is very high.

So you receive some packets or none?

The problem is that when I change gain in the USRP sink nothing changes (i
tested it using ‘wxgui_fftsink’).
(I think it is a software problem since I tested it with another project. There
it changes when I change gain.)

Can you please be a litte bit more verbose? Where do you plug in the FFT
sink? What do you see? What did you expect to see.

If you plug it in after the USRP block it is not a problem of the
receiver, but here the actual signal might be hard to spot. In that case
I would try gr-fosphor. If it is after the signal has been normalised it
is obviously independent from the gain setting. I started a readme file
with some tips (see github) maybe you find something interesting in
there.

Bastian

Meanwhile I use the second laptop and USRP N200 device as the receiver by
running the ./ofdm_rx.py. The error rate is very high.

So you receive some packets or none? Yes, I receive hopefully. But the packer
error rate is too high. I went through different configurations and gains. And
finally I see that the problem is the transmission side. The gain does not have
any influence on the error rate.

The problem is that when I change gain in the USRP sink nothing changes (i
tested it using ‘wxgui_fftsink’).

(I think it is a software problem since I tested it with another project. There
it changes when I change gain.)

Can you please be a litte bit more verbose? Where do you plug in the FFT sink?
What do you see? What did you expect to see. Yes, sure. So I attach FFT sink to
the USRP source in the ofdm_rx.grc. You should see an FFT plot like a normal FFT
block. I set FFT size to 64 and frequency to the frequency which I transmit or
receive. Ok. lets say we do not care what we see, but when I change the gain in
the transmitter nothing changes in the plot. You know that the curve dB should go
higher, isn’t it? However in this case the receiver signal dB is below -80 dB
which showa that there is very low signal.
Even I detach the antenna it works, funnily. I testet this with
benchmarks to see if it is a hardware problem or not. It seems like smt.
is wrong in the transmission side. Do you have any idea what can cause
it?

On 12 Dec 2013, at 15:26, Nasi [email protected] wrote:

Yes, I receive hopefully. But the packer error rate is too high. I went through
different configurations and gains. And finally I see that the problem is the
transmission side. The gain does not have any influence on the error rate.

Just to be sure: do you have the current version? (some weeks ago I
normalized the signal power to 1 without pushing updates of the flow
graphs. That lead to distorted signals. In that case, changing the gain
does not help.)

Can you please be a litte bit more verbose? Where do you plug in the FFT sink?
What do you see? What did you expect to see.
Yes, sure. So I attach FFT sink to the USRP source in the ofdm_rx.grc. You
should see an FFT plot like a normal FFT block. I set FFT size to 64 and frequency
to the frequency which I transmit or receive. Ok. lets say we do not care what we
see, but when I change the gain in the transmitter nothing changes in the plot.
You know that the curve dB should go higher, isn’t it? However in this case the
receiver signal dB is below -80 dB which showa that there is very low signal.
Even I detach the antenna it works, funnily. I testet this with benchmarks to
see if it is a hardware problem or not. It seems like smt. is wrong in the
transmission side. Do you have any idea what can cause it?

Thanks, I guess the problem is that just very few samples of your
incoming stream belong to WiFi frames. So chances are that the frame is
not visualised at all (I think that the FTT sink uses a subset of the
samples based on the sample rate and the update rate of the GUI). If you
really want to stick to this approach I would recommend to checkout
gr-fosphor. I found it really helpful.

https://www.youtube.com/watch?v=mjD-l3GAghU

Best,
Bastian

Just to be sure: do you have the current version? (some weeks ago I normalized
the signal power to 1 without pushing updates of the flow graphs. That lead to
distorted signals. In that case, changing the gain does not help.) I reinstalled
it previous week, I guess on Saturday. Before it was not working at all. I think
this can cause a problem… Where do you normalize that?

Thanks, I guess the problem is that just very few samples of your incoming stream
belong to WiFi frames. So chances are that the frame is not visualised at all (I
think that the FTT sink uses a subset of the samples based on the sample rate and
the update rate of the GUI). If you really want to stick to this approach I would
recommend to checkout gr-fosphor. I found it really helpful. No, I changed the
transmission frequency to smt. different 5.94. If I don’t run tx, rx receives
nothing. When I start tx rx starts to receive smt.
Another thing I think the frame is visualized since when I increase rx
gain in receiver side the curve goes higher.

This forum is not affiliated to the Ruby language, Ruby on Rails framework, nor any Ruby applications discussed here.

| Privacy Policy | Terms of Service | Remote Ruby Jobs