RuntimeError: b200: 2 RX 1 TX and 1 RX 2 TX configurations not possible

Hello,

I have a B210 and I am trying to transmit and receive from all it’s
channels simultaneously. My setup is a macmini late 2012 with Ubuntu
12.04
install. I compiled and installed gnuradio from source using the
gnuradio
build script. I have developed the attached very simple GRC script that
looks like this

signal_source@1khz --> USRP_sink_channel1
signal_source@2khz --> USRP_sink_channel2

USRP_source_channel1 --> WX_GUI_scope_channel1
USRP_source_channel2 --> WX_GUI_scope_channel2

The problem I have is that I get the following message at random times
and
on average on 1/3 executions of the GRC script.

linux; GNU C++ version 4.6.3; Boost_104800; UHD_003.008.000-18-g864f84b5

Using Volk machine: avx_64_mmx_orc
– Operating over USB 3.
– Initialize CODEC control…
– Initialize Radio control…
– Performing register loopback test… pass
– Performing register loopback test… pass
– Performing CODEC loopback test… pass
– Performing CODEC loopback test… pass
– Asking for clock rate 32.000000 MHz
– Actually got clock rate 32.000000 MHz
– Performing timer loopback test… pass
– Performing timer loopback test… pass
– Asking for clock rate 28.000000 MHz
– Actually got clock rate 28.000000 MHz
– Performing timer loopback test… pass
– Performing timer loopback test… pass
– Tune Request: 915.000000 MHz
– The RF LO does not support the requested frequency:
– Requested LO Frequency: 915.000000 MHz
– RF LO Result: 914.999999 MHz
– Attempted to use the DSP to reach the requested frequency:
– Desired DSP Frequency: -0.000001 MHz
– DSP Result: -0.000001 MHz
– Successfully tuned to 915.000000 MHz

– Tune Request: 915.000000 MHz
– The RF LO does not support the requested frequency:
– Requested LO Frequency: 915.000000 MHz
– RF LO Result: 914.999999 MHz
– Attempted to use the DSP to reach the requested frequency:
– Desired DSP Frequency: -0.000001 MHz
– DSP Result: -0.000001 MHz
– Successfully tuned to 915.000000 MHz

– Asking for clock rate 28.000000 MHz
– Actually got clock rate 28.000000 MHz
– Performing timer loopback test… pass
– Performing timer loopback test… pass
– Tune Request: 915.000000 MHz
– The RF LO does not support the requested frequency:
– Requested LO Frequency: 915.000000 MHz
– RF LO Result: 914.999999 MHz
– Attempted to use the DSP to reach the requested frequency:
– Desired DSP Frequency: 0.000001 MHz
– DSP Result: 0.000001 MHz
– Successfully tuned to 915.000000 MHz

– Tune Request: 915.000000 MHz
– The RF LO does not support the requested frequency:
– Requested LO Frequency: 915.000000 MHz
– RF LO Result: 914.999999 MHz
– Attempted to use the DSP to reach the requested frequency:
– Desired DSP Frequency: 0.000001 MHz
– DSP Result: 0.000001 MHz
– Successfully tuned to 915.000000 MHz

thread[thread-per-block[2]: <block gr uhd usrp sink (24)>]:
RuntimeError:
b200: 2 RX 1 TX and 1 RX 2 TX configurations not possible

It is obvious that I have all channels activated and that this message
shouldn’t be appearing in the first place, let alone, appearing in a
non-deterministic manner.

Any ideas?

Thank you in advance
Lefteris

Hello,

FYI I am having problems even with a simpler configuration like this:

USRP_source_channel1 → USRP_sink_channel1
USRP_source_channel2 → USRP_sink_channel2

Does anyone face the same issue? It is really frustrating because 1/3
executions are wasted and this causes problems with later design, that
has
to have an execution rate of > 1Hz

Thank you in advance
Lefteris

On Fri, Nov 14, 2014 at 6:32 PM, Lefteris Kampianakis <
[email protected]> wrote:

– Initialize CODEC control…
– Actually got clock rate 28.000000 MHz

– Actually got clock rate 28.000000 MHz

b200: 2 RX 1 TX and 1 RX 2 TX configurations not possible*


Eleftherios(Lefteris) Kampianakis
Electronics and Computer Engineer
PHD Candidate and Researcher at Sensing Computing Communications Group
(SGCC)
Department of Electrical Engineering
University of Washington
3927 Adams Lane, NE, Mercer Court D805B, 98105
website: http://staff.washington.edu/ekampian/
http://users.isc.tuc.gr/~ekabianakis/
mail: [email protected]

On 11/17/2014 05:15 PM, Lefteris Kampianakis wrote:

has to have an execution rate of > 1Hz
<[email protected] mailto:[email protected]> wrote:
signal_source@2khz → USRP_sink_channel2
Using Volk machine: avx_64_mmx_orc
– Performing timer loopback test… pass
– DSP Result: -0.000001 MHz

– DSP Result: 0.000001 MHz

(SGCC)
[email protected]
Discuss-gnuradio Info Page
We shall probably need a more-detailed description of what you’re
doing. Like the actual .grc files, etc.

From your description, I think you’re wanting to:

bring up flow-graph, exchange a very small number of samples, and then
exit the flow-graph, and do this in a loop?

That seems horribly inefficient, quit distinct from it perhaps
uncovering possible bugs in the latest UHD.

But providing more information will help those who can help you.

Hi all,

I think what Lefteris tries to implement is a 2x2 loopback with a
USRP-B210.

At least this is what I can see from the flowgraph attached in the first
email.
Is that possible with B210?

Best,
George

Hi Lefteris -

We recently added that warning. We think we got it right, but it’s
possible
something is wrong with the logic that makes it fire.

Can you share your GRC flowgraph?

Cheers,
Ben

On 11/17/2014 08:46 PM, George S. wrote:

George
Yes, that should easily be possible.

But some checking code was added in UHD 3.8.0 which apparently gets
inappropriately triggered sometimes, which is what is causing this
issue.

There was also talk about running and executing the entire flow-graph at
a cadence of faster than 1Hz, which suggested some design issues
in the intended application not related to the bug in UHD.

Hello again,

It seems that the patch fixed the problem! Thanks Julian!

For installing the patch with build-gnuradio script:

  1. download patch
  2. open a terminal at the folder where your uhd files are saved. By
    default
    this is in the folder uhd, inside the folder where you executed
    ./build-gnuradio
  3. follow instructions here:
    How to create and apply a patch with Git · devroom.io
    or if you are lazy execute:
    git am --signoff < patch_file_name
  4. execute ./build-gnuradio uhd_build to rebuild all UHD
  5. done

I still have issues that are described here
http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/2014-November/011247.html
But this is for another thread.

Nonetheless, any suggestions for improving my setup are welcome.

Thank you
Lefteris

On Tue, Nov 18, 2014 at 2:27 PM, Lefteris Kampianakis <
[email protected]> wrote:

  1. Produce samples using MATLAB, not python, not C++. Application
    )
    the data through sockets.
    http://www.ettus.com/content/files/kb/mimo_and_sync_with_usrp_updated.pdf

The code attached achieves a refresh rate of 0.5Hz when not receiving the

http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/2014-November/011247.html

Byte Order: Little Endian
CPU MHz: 1200.000
Oct 29 09:56:49 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux
Device Address:

FYI I am having problems even with a simpler configuration like this:
Lefteris

USRP_source_channel2 → WX_GUI_scope_channel2
– Performing register loopback test… pass
– Performing timer loopback test… pass
– The RF LO does not support the requested frequency:
– Performing timer loopback test… pass
– The RF LO does not support the requested frequency:

http://users.isc.tuc.gr/~ekabianakis/
Department of Electrical Engineering
University of Washington
3927 Adams Lane, NE, Mercer Court D805B, 98105
website: http://staff.washington.edu/ekampian/
http://users.isc.tuc.gr/~ekabianakis/
mail: [email protected]


Eleftherios(Lefteris) Kampianakis
Electronics and Computer Engineer
PHD Candidate and Researcher at Sensing Computing Communications Group
(SGCC)
Department of Electrical Engineering
University of Washington
3927 Adams Lane, NE, Mercer Court D805B, 98105
website: http://staff.washington.edu/ekampian/
http://users.isc.tuc.gr/~ekabianakis/
mail: [email protected]

Hello all and thank you for your replies.
Sorry for my delayed answer

First of, I am completely new to USRP, gnuradio and uhd so excuse my
inability to address the issue myself and point out possible reasons for
the error.

The overview of what I want to do is this:

while(1){

  1. Produce samples using MATLAB, not python, not C++. Application
    specific,
    cann’t change that.
  2. Write the samples to a vector/file.
  3. Transfer the data to the corresponding gnuradio program written in
    python. This can be done using either files or TCP sockets
  4. The samples must be transmitted from one of B210’s channels (the
    other
    is 50Ohms terminated) while the two RX channels sample at the same time.
    That is, the transmission and reception must be executed at the same
    time.
  5. Measure and compensate the phase between TX and RX which changes in
    every session. (see here:
    http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/2014-October/011140.html
    )
  6. Stop the gnuradio script in a way that a) no more samples are written
    to
    memory/disk b) restart is posssible without errors. For details see
    here:
    http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/2014-October/011242.html
    and here
    GNURADIO and USRP: Start(), Stop(), run(), wait() in GNURADIO : top_block
    and here
    [Discuss-gnuradio] how to stop the top_block and restart signal transmis
    7)Process samples in MATLAB by ‘freading’ the written files or by
    getting
    the data through sockets.
    }

My goal is to conduct channel measurements. Therefore, in order to
compensate for the TX/RX phase that changes in every session in B210 I
have
splitted the signal using a power splitter with known phase and send one
port to RX1. Since RX1, RX2 phase is constant in every session, I can
then
calculate the phase difference between TX and RX and do my channel
measurements.

In other words, I want to implement a setup like the one depicted here
http://www.ettus.com/content/files/kb/mimo_and_sync_with_usrp_updated.pdf
in figure 1 in order to acquire knowledge of the phase between the RF
inputs and outputs of the B210.

Now, as to what I have developed so far. I have attached a grc flowgraph
that is as simple as it gets. It consists of 2 signal sources and a
scope
connected to a usrp sink and source respectively. This setup produces
the
aforementioned error. I also noticed that whenever I receive this error,
either only TX works or only RX, never both and this is done randonly.
An
example of series of executions that I monitored is the following:

OK (both transmitting)
OK (both transmitting)
Error, Only RX works
OK (both transmitting)
OK (both transmitting)
OK (both transmitting)
Error, Only RX works
Error, Only TX works
OK (both transmitting)
Error, Only TX works

and it continues randomly

That was a first indication that something is wrong in the first place.

I proceeded with the development of a simple flowgraph that utilizes
file
sinks and sources as well as head blocks to stop the execution of the
flowgraph after a specifica mount of samples. This is attached too.

Finally, I edited the python code, so that endless loop of flowgraphs
restarting is conducted. (also attached).
The code attached achieves a refresh rate of 0.5Hz when not receiving
the
error, which is acceptable for my application.

I know this is completely inefficient and please share any ideas on the
subject. However, this is not my primary concern at this point. My main
objective now is to have a viable demonstration and not a fast refresh
rate. 0.5 Hz is barely enough.

At this point my 2 major issues are the following:

  1. The error/warning that this thread discusses
  2. The problem described here:
    http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/2014-November/011247.html
    which is being addressed.

Any advice on any subject from the ones mentioned here are extremely
welcome.

My setup is the following
lscpu:
Architecture: x86_64
CPU op-mode(s): 32-bit, 64-bit
Byte Order: Little Endian
CPU(s): 4
On-line CPU(s) list: 0-3
Thread(s) per core: 2
Core(s) per socket: 2
Socket(s): 1
NUMA node(s): 1
Vendor ID: GenuineIntel
CPU family: 6
Model: 58
Stepping: 9
CPU MHz: 1200.000
BogoMIPS: 4988.84
Virtualization: VT-x
L1d cache: 32K
L1i cache: 32K
L2 cache: 256K
L3 cache: 3072K
NUMA node0 CPU(s): 0-3

uname -a:
Linux kampianakis-Macmini 3.13.0-39-generic #66~precise1-Ubuntu SMP Wed
Oct
29 09:56:49 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux

lshw output, attached.

Gnuradio version 3.7.5.1

uhd_find_devices:
linux; GNU C++ version 4.6.3; Boost_104800; UHD_003.008.000-18-g864f84b5

– UHD Device 0

Device Address:
type: b200
name:
serial: F50007
product: B210

Thank you in advance
Lefteris

PS sorry for the long post.

On Mon, Nov 17, 2014 at 2:15 PM, Lefteris Kampianakis <
[email protected]> wrote:

to have an execution rate of > 1Hz
[email protected]> wrote:

signal_source@2khz → USRP_sink_channel2
– Operating over USB 3.
– Asking for clock rate 28.000000 MHz
– Successfully tuned to 915.000000 MHz
– Asking for clock rate 28.000000 MHz
– Successfully tuned to 915.000000 MHz
*thread[thread-per-block[2]: <block gr uhd usrp sink (24)>]:
Lefteris
University of Washington
3927 Adams Lane, NE, Mercer Court D805B, 98105
website: http://staff.washington.edu/ekampian/
http://users.isc.tuc.gr/~ekabianakis/
mail: [email protected]


Eleftherios(Lefteris) Kampianakis
Electronics and Computer Engineer
PHD Candidate and Researcher at Sensing Computing Communications Group
(SGCC)
Department of Electrical Engineering
University of Washington
3927 Adams Lane, NE, Mercer Court D805B, 98105
website: http://staff.washington.edu/ekampian/
http://users.isc.tuc.gr/~ekabianakis/
mail: [email protected]