Forum: GNU Radio UHD USRP2 full duplex mystery solved

Announcement (2017-05-07): www.ruby-forum.com is now read-only since I unfortunately do not have the time to support and maintain the forum any more. Please see rubyonrails.org/community and ruby-lang.org/en/community for other Rails- und Ruby-related community platforms.
3528214f0cd5bd10657cc21b096888f1?d=identicon&s=25 Marc Epard (Guest)
on 2010-09-14 22:59
(Received via mailing list)
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

-Marc
4252201ac30d6dd44d8090ce1070e35f?d=identicon&s=25 Josh Blum (Guest)
on 2010-09-14 23:30
(Received via mailing list)
FYI - in the future this will go away in the future when tx flow control
becomes host-based (and away from ethernet pause frames). -Josh
Ac73d95c8ccddff9ecae369bcb80a923?d=identicon&s=25 George Nychis (Guest)
on 2010-09-23 08:48
(Received via mailing list)
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?
Ac73d95c8ccddff9ecae369bcb80a923?d=identicon&s=25 George Nychis (Guest)
on 2010-09-23 09:19
(Received via mailing list)
To elaborate more on my issue... I see the USRP2 send mac pause frames,
and
then no new data is sent over the interface for 5-10 seconds.
999c924041c4fe16f9415a0b95a45368?d=identicon&s=25 Scott Johnston (Guest)
on 2011-03-14 14:43
(Received via mailing list)
Hello Mark,

Is there anyway you could post your code or a link to it on the forum? I
am interested in full duplex communications.

Rest of the gnuradio world,

Does anybody have an example of how to setup a full duplex app?

I am using the uhd with the USRP n210.

TIA

Scott


Marc Epard wrote:
> -Marc
>
>
> _______________________________________________
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>

--
Scott Johnston
MIT Lincoln Laboratory
244 Wood Street, Lexington, MA 02420-9108
(781) 981-8196
scott.johnston@LL.mit.edu
558c40b97bd1af8d912424757714bda9?d=identicon&s=25 Marcus D. Leech (Guest)
on 2011-03-14 14:57
(Received via mailing list)
On 14/03/2011 9:42 AM, Scott Johnston wrote:
>
>> resulted in a runtime error of "usrp2 no control response". It worked
>> The solution is to call issue_stream_cmd first (and start the recv
>>
>> -Marc
>>
Marc:

The XCVR2450 *hardware* doesn't support full-duplex at all, so no amount
of cleverness on the software side can change that.
3528214f0cd5bd10657cc21b096888f1?d=identicon&s=25 Marc Epard (Guest)
on 2011-03-14 17:14
(Received via mailing list)
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 Epard 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.

-Marc
Db2ce03cdf91a098ab749342748d322f?d=identicon&s=25 Vijay Pillai (Guest)
on 2011-03-14 17:39
(Received via mailing list)
Hi Marc,

How much leakage are you seeing between TX and RX on a WBX board?

Yeah, GRC works fine for full duplex and it is very easy to set it up.

Best regards,
-Vijay

--- On Mon, 3/14/11, Marc Epard <mepard@me.com> wrote:

From: Marc Epard <mepard@me.com>
Subject: Re: [Discuss-gnuradio] UHD USRP2 full duplex mystery solved
To: "Scott Johnston" <scott.johnston@ll.mit.edu>
Cc: "discuss-gnuradio Discussion Group" <discuss-gnuradio@gnu.org>
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 Epard 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.

-Marc
93d90393e6a06dea948671110f6810a8?d=identicon&s=25 Jason Abele (Guest)
on 2011-03-14 17:53
(Received via mailing list)
> 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.

Jason
999c924041c4fe16f9415a0b95a45368?d=identicon&s=25 Scott Johnston (Guest)
on 2011-03-14 18:19
(Received via mailing list)
Jason,

Could you elaborate on this? I don't follow what you are talking about.

Thanks

Scott

Jason Abele wrote:
> _______________________________________________
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>

--
Scott Johnston
MIT Lincoln Laboratory
244 Wood Street, Lexington, MA 02420-9108
(781) 981-8196
scott.johnston@LL.mit.edu
93d90393e6a06dea948671110f6810a8?d=identicon&s=25 Jason Abele (Guest)
on 2011-03-14 18:31
(Received via mailing list)
>>> 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.

Jason
558c40b97bd1af8d912424757714bda9?d=identicon&s=25 Marcus D. Leech (Guest)
on 2011-03-14 18:38
(Received via mailing list)
On 14/03/2011 12:12 PM, Marc Epard wrote:
>
> 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).
3528214f0cd5bd10657cc21b096888f1?d=identicon&s=25 Marc Epard (Guest)
on 2011-03-14 18:58
(Received via mailing list)
Thanks, Jason. I should have posted our observations back when we made
them. We're doing okay with the two-USRP setup, but it's good to have
options.

-Marc
3528214f0cd5bd10657cc21b096888f1?d=identicon&s=25 Marc Epard (Guest)
on 2011-03-14 23:15
(Received via mailing list)
Hi Scott,

You'll find uhd_streamer.cpp at <https://public.me.com/mepard>.

Some things you should know:

* 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.

HTH.

-Marc
03dbae1b48ed399cf53367175ea73526?d=identicon&s=25 Tuan (Johnny) Ta (Guest)
on 2011-10-14 16:19
(Received via mailing list)
Vijay,

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?

Thanks,
Johnny
F150fb457eaea25cfc28afd97da277cb?d=identicon&s=25 BRIJENDRA SHARMA (brijendrash)
on 2016-07-06 14:18
Attachment: SIN_TX_RX_30JUNE2016_4.grc.png (90 KB)
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.

with best regards.

Brijendra Sharma
Project Scientist@IIT Kanpur.
brijendrash@gmail.com
This topic is locked and can not be replied to.