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 < e.kampianakis...@ieee.org> 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 > and here > http://lists.gnu.org/archive/html/discuss-gnuradio/2011-02/msg00300.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 < > e.kampianakis...@ieee.org> 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 < >> e.kampianakis...@ieee.org> 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 >>> >>> 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 >>> >> >> >> >> -- >> 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: e.kampianakis...@ieee.org >> > > > > -- > 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: e.kampianakis...@ieee.org > -- 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: e.kampianakis...@ieee.org
_______________________________________________ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
