I’ve been attempting to do a full duplex send/recv using UHD on a USRP2
with an XCVR2450.
The major problem I had was that issue_stream_cmd nearly always resulted
in a runtime error of “usrp2 no control response”. It worked fine if I
transmitted w/o receiving or received w/o transmitting. The same code
also worked when using a 2nd USRP2 for receiving.
After a session with Wireshark and the UHD host source, I had my “Well,
duh” moment. When you call send, the data starts streaming to the USRP2
right away – even if you specify a timestamp in the future. The USRP2
starts sending back PAUSE frames almost immediately, which throttles not
only additional send data, but also any commands to the control port.
The solution is to call issue_stream_cmd first (and start the recv
thread), then start the send thread. This was simple enough in my app
because I was specifying start times in the future anyway. It does
prevent a method I was going to use on a WBX where I start the send
thread once and scan through several receive frequencies before stoping
the send thread.
Perhaps most of you knew about this gotcha already, but I hope this will
help someone else who encounters the problem. Anyway, it was fun
investigating and I learned a lot more about the UHD host code and
protocols
Just saw this thread now… I’m seeing this problem with my USRP2s and
the
WBX board. However, I’m not using UHD. Do you know a fix for this
outside
of UHD?
On Mar 14, 2011, at 8:53 AM, Marcus D. Leech wrote:
On 14/03/2011 9:42 AM, Scott Johnston wrote:
Does anybody have an example of how to setup a full duplex app?
I am using the uhd with the USRP n210.
Marc E. wrote:
I’ve been attempting to do a full duplex send/recv using UHD on a USRP2 with
an XCVR2450.
The XCVR2450 hardware doesn’t support full-duplex at all, so no amount of
cleverness on the software side can change that.
Although the XCVR2450 doesn’t do full duplex, the WBX does, and current
UHD avoids the problem I described in my previous message. However, the
WBX has enough internal leakage between tx and rx that we gave up on
single-daughterboard full duplex. We now use a USRP2 with a WBX for tx
and a USRP N210 with a DBSRX2 for rx.
As for examples, I’ll try to clean up my C++ app and post it later this
week. GRC works fine full-duplex, too, I believe.
However, the WBX has enough internal leakage between tx and rx that we gave up
on single-daughterboard full duplex.
Just a heads up, you had not tried WBX without C1 installed on the
grand-daughterboard, or even without the grand-daughterboard at all,
just using J202 and J201 on the main WBX board, you might see if one
of those scenarios could meet your tx-rx isolation requirements.
From: Marc E. [email protected]
Subject: Re: [Discuss-gnuradio] UHD USRP2 full duplex mystery solved
To: “Scott Johnston” [email protected]
Cc: “discuss-gnuradio Discussion Group” [email protected]
Date: Monday, March 14, 2011, 12:12 PM
On Mar 14, 2011, at 8:53 AM, Marcus D. Leech wrote:
On 14/03/2011 9:42 AM, Scott Johnston wrote:
Does anybody have an example of how to setup a full duplex app?
I am using the uhd with the USRP n210.
Marc E. wrote:
I’ve been attempting to do a full duplex send/recv using UHD on a USRP2 with
an XCVR2450.
The XCVR2450 hardware doesn’t support full-duplex at all, so no amount of
cleverness on the software side can change that.
Although the XCVR2450 doesn’t do full duplex, the WBX does, and current
UHD avoids the problem I described in my previous message. However, the
WBX has enough internal leakage between tx and rx that we gave up on
single-daughterboard full duplex. We now use a USRP2 with a WBX for tx
and a USRP N210 with a DBSRX2 for rx.
As for examples, I’ll try to clean up my C++ app and post it later this
week. GRC works fine full-duplex, too, I believe.
However, the WBX has enough internal leakage between tx and rx that we
gave up on single-daughterboard full duplex.
Just a heads up, you had not tried WBX without C1 installed on the
grand-daughterboard, or even without the grand-daughterboard at all,
just using J202 and J201 on the main WBX board, you might see if one
of those scenarios could meet your tx-rx isolation requirements.
Sorry, missing and if in there ( … Just a heads up, if you have not
… )
Basically, C1 allows for reception on the TX/RX antenna port, it
connects the two T/R switches.
However, if you are looking to do full-duplex, you will not be
receiving on the TX/RX port anyhow, just RX2. So rather than having
an implicit leakage path through the T/R switches (RF switches rarely
give more than 20-30dB isolation, depending on frequency), you can
remove C1 on the grand-daughterboard and improve isolation at the
expense of not being able to receive on the TX/RX port.
If you want to go even further, you can remove the grand-daughterboard
entirely and install SMA connectors in J201 and J202. You will also
need to move a capacitor to AC couple J201 and J202 to the circuit.
Although the XCVR2450 doesn’t do full duplex, the WBX does, and current UHD
avoids the problem I described in my previous message. However, the WBX has enough
internal leakage between tx and rx that we gave up on single-daughterboard full
duplex. We now use a USRP2 with a WBX for tx and a USRP N210 with a DBSRX2 for rx.
As for examples, I’ll try to clean up my C++ app and post it later this week.
GRC works fine full-duplex, too, I believe.
-Marc
Saw XCVR2450, and assumed you were using it.
How much isolation does your application need? The HMC174-series
switches in the WBX are roughly 26dB isolation each, and there should be
two such paths
between transmit and receive when using RX2 and TX/RX, giving roughly
52dB isolation (at least from the switches–circuit paths may make this
number worse).
It doesn’t use gnu-radio, but uses UHD directly. (We should move to
the usrp-users list if you want to continue the discussion.)
It can do two UHD transmits and one receive at the same time.
It transmits and receives from RAM. It loads the transmit files into
RAM first, then does simultaneous tx and rx, storing the received data
in RAM, and finally stores the received data in a file. This makes it
immune to disk performance issues, but limits the amount of data you can
send and receive.
It can be invoked multiple times simultaneously and uses a lock file
to arbitrate access to the radios. You’ll need to pre-create the lock
file as described in a comment in the code.
It can run in standalone, client, or server modes. The client-server
scheme saves time when doing a bunch of operations in a row by not
having to reconfigure everything about the radios every time. One
instance of the server and multiple clients can run at the same time.
Access to the server’s fifos is controlled by the lock file.
All of this is because we do our signal processing offline in normal,
single-threaaded MATLAB. To keep our hefty Ubuntu box and the USRPs
busy, we create multiple instance of MATAB each with a list of tx/rx
tasks to perform. They each use MATLAB’s unix() function to invoke
uhd_streamer, which serializes access to the radios. We tune the number
of instances to keep the radios busy, but not overflow main memory.
Can you post a GRC file with full-duplex configuration? I have the
XCVR2450
board so I know I can only get half-duplex. Does the GRC full-duplex
flow
graph for the WBX board achieve half-duplex for the XCVR2450 board?
Dear All,
I would like to request you you that now a days, I am doing a
assignment for transferring and receiving a sine wave of 10KHz through
USRP N210 by using WBX daughter board.
The sine wave is transferring through GRC of GNUradio block. and same i
wave a receiving as per WI GUI SCOPE SINK SHOWING. but when we removed
both Antenna.
Still sine wave is appearing in WX GUI SCOPE SINK. in transmitting and
receiving wave.
It’s means that SINE wave is neither transferring nor receiving.
I am using TX/RX for transmuting. and for RX2 for receiving.
I am not getting where I am wrong.
Also I am getting following waring…
Generating: “/home/dsplab/Desktop/BRIJENDRA/top_block.py”
Generating: “/home/dsplab/Desktop/BRIJENDRA/top_block.py”
Generating: “/home/dsplab/Desktop/BRIJENDRA/top_block.py”
Executing: “/home/dsplab/Desktop/BRIJENDRA/top_block.py”
linux; GNU C++ version 4.8.2; Boost_105400; UHD_003.005.005-0-unknown
fft_impl_fftw: /home/dsplab/.gr_fftw_wisdom: Permission denied
Using Volk machine: sse4_2_32_orc
– Opening a USRP2/N-Series device…
– Current recv frame size: 1472 bytes
– Current send frame size: 1472 bytes
UHD Warning:
The recv buffer could not be resized sufficiently.
Target sock buff size: 50000000 bytes.
Actual sock buff size: 163840 bytes.
See the transport application notes on buffer resizing.
Please run: sudo sysctl -w net.core.rmem_max=50000000
UHD Warning:
The recv buffer could not be resized sufficiently.
Target sock buff size: 50000000 bytes.
Actual sock buff size: 163840 bytes.
See the transport application notes on buffer resizing.
Please run: sudo sysctl -w net.core.rmem_max=50000000
UHD Warning:
The send buffer could not be resized sufficiently.
Target sock buff size: 1048576 bytes.
Actual sock buff size: 163840 bytes.
See the transport application notes on buffer resizing.
Please run: sudo sysctl -w net.core.wmem_max=1048576
UHD Warning:
Unable to set the thread priority. Performance may be negatively
affected.
Please see the general application notes in the manual for
instructions.
EnvironmentError: OSError: error in pthread_setschedparam
len(audio_taps) = 1267
I am also attaching .grc file whatever i am using for this application.
Please help me.
I am looking forwards.