UHD disable receive

I just got my shiny new N210’s last week. I’ve setup UHD and GnuRadio
from GIT. I’ve done some simple tests and have been able to transmit
data from one N210 to the other. Today I started working on
bidirectional communication. For my simple setup I’ve got 2 N210’s
each with an RFX2400 (using TX/RX for receive). I created a python
file with two top-blocks. In one top-block I have the transmit path
setup (Message Source -> Packet Encoder -> GMSK mod -> UHD USRP Sink),
and the receive is in the other (UHD USRP Source -> GMSK demod ->
Packet Decoder -> Message Sink). Then my main main code creates the
two top_blocks, and calls start on each. I then simply add messages to
the message source and read messages off of the message sink.

When sending from A to B, I receive A’s message on B. The problem is I
also receive A’s message on A. Same happens when going from B to A. Is
this normal? I know the RFX2400 is full duplex, but this was not what
I was expecting. Is there any way to disable the receive path while
transmitting?

After digging around I found a set_auto_tr function that sounded like
it would fix this problem, but for some reason it looks like that is
not implemented for gr-uhd. Any suggestions on how to fix this?

Thanks!

When sending from A to B, I receive A’s message on B. The problem is I
also receive A’s message on A. Same happens when going from B to A. Is
this normal? I know the RFX2400 is full duplex, but this was not what
I was expecting. Is there any way to disable the receive path while
transmitting?

I might suggest:

  1. shut off the demodulation in software when transmitting.
  2. transmit and receive on different frequencies.
  3. reject the received packet at the mac layer

In any case, you can shutoff the rx mixer in full duplex mode with this
little change:

 //set some default values
 set_rx_lo_freq((_freq_range.start() + _freq_range.stop())/2.0);

After digging around I found a set_auto_tr function that sounded like
it would fix this problem, but for some reason it looks like that is
not implemented for gr-uhd. Any suggestions on how to fix this?

The auto tr is always enabled on uhd. What it does is set antenna
switches and mixers based on the state of the device. I don’t think its
what you are looking for. This might be relevant:
http://www.ettus.com/uhd_docs/manual/html/dboards.html#rfx-series

-Josh

For my simple setup I’ve got 2 N210’s each with an RFX2400 (using TX/RX for
receive).

Are you sure you’re really using TX/RX for receive? As the link Josh
supplied says “The user may set the receive antenna to be TX/RX or RX2.
However, when using an RFX board in full-duplex mode, the receive
antenna
will always be set to RX2, regardless of the settings.”

Steve

Are you sure you’re really using TX/RX for receive? As the link Josh
supplied says “The user may set the receive antenna to be TX/RX or RX2.
However, when using an RFX board in full-duplex mode, the receive antenna
will always be set to RX2, regardless of the settings.”

As far as I know, yes. I built the initial code using
gnuradio-companion and specified in the uhd source and sink blocks to
use TX/RX as the antenna.

I might suggest:

  1. shut off the demodulation in software when transmitting.
  2. transmit and receive on different frequencies.
  3. reject the received packet at the mac layer

Thanks for the info. I wasn’t sure how to shut off demodulation in
software. I ended up finding the “valve” block and using that to
inbetween the USRP source and the Demod. The sender then sets it to
bool(1) right before transmitting and bool(0) afterwards. That seems
to have fixed it. Eventually I’ll build up a MAC layer and that won’t
be necessary. Works for now though.

Thanks again for the info.

On 04/20/2011 03:03 PM, Feng Andrew Ge wrote:

Josh,

When you say " In any case, you can shutoff the rx mixer in full duplex
mode with this little change:", is it true that this radio, once started
with the changed code, cannot receive anymore at it runtime?

No: When, and only when, the device is simultaneously transmitting and
receiving (full duplex mode); the change will cause the rx mixer to be
turned off. This effectively feeds noise into the ADC.

So if you are always receiving, the mixer will only turn off when you
pass samples into the usrp sink block (which causes a transmission to
occur). Once all samples have been transmitted, the mixer will come back
on.

The change is a “quick hack” and is not the recommended way to do
things.

-Josh

Josh,

When you say " In any case, you can shutoff the rx mixer in full duplex
mode with this little change:", is it true that this radio, once started
with the changed code, cannot receive anymore at it runtime?

Andrew

On 04/20/2011 03:24 PM, Feng Andrew Ge wrote:

Josh,

Thanks for the clarification.

Does it mean that, by this hacked code, turning off RX mixer at
transmitting time happens on FPGA? Or does it happen at UHD on the host
side?

In this case the mixer is controlled by FPGA GPIOs that automatically
change state when the streaming mode in the FPGA changes state (RX only,
TX only, full duplex). The effect is instantaneous with some small lag
time for the mixer.

-Josh

Sorry to resurrect this somewhat old thread, but I’m mightily confused
by
something. Mike originally said:

“For my simple setup I’ve got 2 N210’s each with an RFX2400 (using TX/RX
for
receive).”

The Ettus website says:

“The user may set the receive antenna to be TX/RX or RX2. However, when
using an RFX board in full-duplex mode, the receive antenna will always
be
set to RX2, regardless of the settings.”

So it seems that his radio is operating in “full-duplex mode” even
though
this is not what Mike wants when setting it to receive on TX/RX, yes? I
can’t seem to find anything in gr-uhd to disable “full-duplex mode”, and
can’t really figure out where this mode is set in the UHD driver,
either.
My true motivation for asking is that I’m having this same problem with
my
N210s and RFX1800s. What I really want is to have TX/RX port switch
between
transmit and receive.

Steve

On 05/02/2011 08:16 AM, Steve P. wrote:

set to RX2, regardless of the settings."

That is a more verbose way to say that “you cant receive from TX/RX when
you are transmitting”. It just so happens that the antenna switch gets
moved to RX2. I will think about adjusting the language.

So it seems that his radio is operating in “full-duplex mode” even though
this is not what Mike wants when setting it to receive on TX/RX, yes? I
can’t seem to find anything in gr-uhd to disable “full-duplex mode”, and
can’t really figure out where this mode is set in the UHD driver, either.
My true motivation for asking is that I’m having this same problem with my
N210s and RFX1800s. What I really want is to have TX/RX port switch between
transmit and receive.

Just set the receive antenna to TX/RX. The switching is automatic.
However, do not transmit when you want to receive.

To use the board in full duplex mode (simultaneous receive and
transmit), set the receive antenna to RX2.

-Josh

Josh,

Thanks for the clarification.

Does it mean that, by this hacked code, turning off RX mixer at
transmitting time happens on FPGA? Or does it happen at UHD on the host
side?

Andrew

Josh,

I applied your changes below for WBX. Yes, a transmitter doesn’t see
packets from itself anymore. However, in my experiment, two nodes using
tunnel.py could not talk to each other anymore. So I changed the code
back and two nodes resumed their communication channel.

Your description of the effect of this code change sounds OK, what
problems might not be revealed. For example, how quick does it take for
the mixer switching between TX and RX, a few micro-seconds or at the
scale of milli-seconds?

/ - this->get_iface()->set_atr_reg(dboard_iface::UNIT_RX,/
/ dboard_iface::ATR_REG_FULL_DUPLEX, _power_up | ANT_RX2| MIXER_ENB);/
/ + this->get_iface()->set_atr_reg(dboard_iface::UNIT_RX,/
/ dboard_iface::ATR_REG_FULL_DUPLEX, _power_up | ANT_RX2| MIXER_DIS);/
/ /
/ //set some default values/
/ set_rx_lo_freq((_freq_range.start() + _freq_range.stop())/2.0);/

hi Mike C.,

could you send me the python file that you mentioned?

Thank you very much in advance.