discuss-gnuradio
[Top][All Lists]
Advanced
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Discuss-gnuradio] RuntimeError: b200: 2 RX 1 TX and 1 RX 2 TX confi

From: Lefteris Kampianakis
Subject: Re: [Discuss-gnuradio] RuntimeError: b200: 2 RX 1 TX and 1 RX 2 TX configurations not possible
Date: Tue, 18 Nov 2014 18:36:37 -0800
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: https://ariejan.net/2009/10/26/how-to-create-and-apply-a-patch-with-git/
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 <address@hidden> wrote:
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
http://sumitgnuradio.blogspot.com/2012/10/either-you-can-use-tb.html
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 <address@hidden> wrote:
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 <address@hidden> wrote:
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

address@hidden --> USRP_sink_channel1
address@hidden --> 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



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



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



--
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
reply via email to
[Prev in Thread] Current Thread [Next in Thread]