Re: OOT tests failing in GNU Radio 3.9.2.0, Ubuntu 20.04.2 LTS

[Vasil Velichkov]

Hi Anton,

On Tue, Jun 29, 2021, 21:04 Anton Ottosson  wrote:

1: Traceback (most recent call last):
> 1:   File "/home/antonott/gr-howto/python/qa_square_ff.py", line 50, in
> test_002_square2_ff
> 1: sqr = howto.square2_ff()
> 1: NameError: name 'howto' is not defined
>

First you need to import square2_ff from howto similar to line 13 and then
you can use square2_ff directly without howto infront.

  from howto import square_ff, square2_ff
  sqr = square2_ff()


> 1: --
> 1: Ran 3 tests in 0.003s
> 1:
> 1: FAILED (errors=1)
> 1: DEPRECATED: Using filename with gr_unittest does no longer have any
> effect.
> 1/1 Test #1: qa_square_ff .***Failed0.22 sec
>

Usually you would add a separate qa_* class for each block you have.

Though I guess since the unit tests are executed with reflection anything
> is possible.
>

Not sure what you mean by "reflection" here.

Regards,
Vasil

Re:Re: The error happened when a OOT modulus was 'sudo make install'.

[fan]

The problem has been solved.Thank you friend!!!
At 2021-06-29 17:26:36, "Vasil Velichkov"  wrote:
>Hi fan,
>
>Welcome to GNU Radio!
>
>On 29/06/2021 11.44, fan wrote:
>> I have installed gnuradio 3.8.1.0 in Ubuntu 20.04, and I am using gr_ 
>> modtool to write the OOT module. However, when I execute the sudo make 
>> install command in the build directory of the module, the system reports an 
>> error as follows:
>> 
>> make[2]: *** No rule to make target “/usr/lib/x86_ 
>> 64-linux-gnu/liborc-0.4.so” needed by 
>> “lib/libgnuradio-corr.so.v1.0-compat-xxx-xunknown”，stop.
>
>> Then I'm at / usr / lib / x86_ I found the liborc-0.4. So. 0 and liborc-0.4. 
>> So. 0.31.0 files in the 64 Linux GNU / directory, and then I didn't know 
>> what else to do. Can someone help me?
>
>The easiest solution is to install liborc-0.4-dev package as this package 
>contains this file.
>
>  sudo apt-get install liborc-0.4-dev
>
>Regards,
>Vasil

Re: N310 phase sync issue with antenna array

[Marcus D. Leech]

On 06/29/2021 04:51 PM, Larry wrote:

Hello everyone,

I am having an issue with achieving a phase-synchronous RF 
configuration using an N310 with an Octoclock and a linear antenna 
array. What I believe should be the expected results of this setup is 
that each AD9371 should receive synchronous signals aligned in phase, 
with a random 180 degree offset between each AD9371 transceiver 
(please correct me if this assumption if wrong). Here is a summary of 
my setup, issues, and outcomes:


1)  Hardware/software setup: Using an N310 running HG image at 
1-gigabit network connection on UHD version 3.15 on Ubuntu 18.04. This 
is supported by an Octoclock-G serving as the 10MHz reference and PPS 
source for the N310. Equal length cables are used between all channels 
of the N310, to facilitate better phase synchronization. My GnuRadio 
flowgraph consists of a USRP source into a simple squelch, feed 
forward AGC, frequency xlating fir filter, and then converted from 
complex to real going into a QT time sink.


2) Testing & results: I am attempting to receive a bursty signal using 
a four element linear dipole antenna array, with the elements spaced 
slightly under lambda/2 distance apart. Two main tests have been 
performed; one with the N310 directly wired to another SDR that is 
injecting a generated sine wave into the N310, and another test over 
the air using a radio transmitter.


i. Testing with a wired connection results in the correct expected 
results - phase-aligned signals, with the channel pairs on each AD9371 
transceiver offset by presumably + or - 180 degrees. I can then align 
using simple delays to achieve phase alignment between all channels. 
This works with 2, 3, or 4 channels used.


ii. Testing over the air results in very unsynchronized signals among 
all four channels. These results tend to be repeatable and consistent 
in their behavior, but the channels all are received both wildly out 
of phase (even channels on the same AD9371 transceiver), and even 
(depending on location of the transmitter relative to the antenna 
array) inverted in amplitude relative to other channels (particularly 
interesting was that the imaginary component of one channel would 
match the inverse of a different channel's real component). This test 
has been performed at ranges exceeding 75~ feet, and as near as 5 feet 
away. The results are similar in either situation. It is also worth 
noting that varying the transmitter's location parallel to the antenna 
array (finding a 'sweet spot', so to speak) resulted in at most 2, 
possibly 3 of the channels to align properly in phase without 
calibrating using delays (at least one channel would always stay 
wildly different). Testing over the air using fewer than 4 channels 
yields marginally improved, but overall similarly poor results.


I have tried using an external LO source for the N310 as well as 
operating the Octoclock with and without GPS functionality enabled. I 
have varied the sample rates, distances, and testing environments as 
well as changing cables and splitters to try to rule out any hardware 
component errors. These seem to have no real impact on the strange 
results I get with the over the air RF configuration. Any help to 
sanity check or troubleshoot my issues would be greatly appreciated. 
Thank you!



Given that the N310 has NO WAY of distinguishing between signals 
arriving from some wired emitter and those arriving from an antenna
  array, I can't for the life of me see how this could be N310/GnuRadio 
related.  How would it know?

N310 phase sync issue with antenna array

[Larry]

Hello everyone,

I am having an issue with achieving a phase-synchronous RF configuration using 
an N310 with an Octoclock and a linear antenna array. What I believe should be 
the expected results of this setup is that each AD9371 should receive 
synchronous signals aligned in phase, with a random 180 degree offset between 
each AD9371 transceiver (please correct me if this assumption if wrong). Here 
is a summary of my setup, issues, and outcomes:

1) Hardware/software setup: Using an N310 running HG image at 1-gigabit network 
connection on UHD version 3.15 on Ubuntu 18.04. This is supported by an 
Octoclock-G serving as the 10MHz reference and PPS source for the N310. Equal 
length cables are used between all channels of the N310, to facilitate better 
phase synchronization. My GnuRadio flowgraph consists of a USRP source into a 
simple squelch, feed forward AGC, frequency xlating fir filter, and then 
converted from complex to real going into a QT time sink.

2) Testing & results: I am attempting to receive a bursty signal using a four 
element linear dipole antenna array, with the elements spaced slightly under 
lambda/2 distance apart. Two main tests have been performed; one with the N310 
directly wired to another SDR that is injecting a generated sine wave into the 
N310, and another test over the air using a radio transmitter.

i. Testing with a wired connection results in the correct expected results - 
phase-aligned signals, with the channel pairs on each AD9371 transceiver offset 
by presumably + or - 180 degrees. I can then align using simple delays to 
achieve phase alignment between all channels. This works with 2, 3, or 4 
channels used.

ii. Testing over the air results in very unsynchronized signals among all four 
channels. These results tend to be repeatable and consistent in their behavior, 
but the channels all are received both wildly out of phase (even channels on 
the same AD9371 transceiver), and even (depending on location of the 
transmitter relative to the antenna array) inverted in amplitude relative to 
other channels (particularly interesting was that the imaginary component of 
one channel would match the inverse of a different channel's real component). 
This test has been performed at ranges exceeding 75~ feet, and as near as 5 
feet away. The results are similar in either situation. It is also worth noting 
that varying the transmitter's location parallel to the antenna array (finding 
a 'sweet spot', so to speak) resulted in at most 2, possibly 3 of the channels 
to align properly in phase without calibrating using delays (at least one 
channel would always stay wildly different). Testing over the air using fewer 
than 4 channels yields marginally improved, but overall similarly poor results.

I have tried using an external LO source for the N310 as well as operating the 
Octoclock with and without GPS functionality enabled. I have varied the sample 
rates, distances, and testing environments as well as changing cables and 
splitters to try to rule out any hardware component errors. These seem to have 
no real impact on the strange results I get with the over the air RF 
configuration. Any help to sanity check or troubleshoot my issues would be 
greatly appreciated. Thank you!

Multiple GNU Radio versions installed in parallel. Viable?

[Anton Ottosson]

Hi,


I have been using (or learning to use) GNU Radio 3.9.2 for a couple of weeks 
now, and for the last few days I've had some trouble with it (specifically 
https://lists.gnu.org/archive/html/discuss-gnuradio/2021-06/msg00106.html). For 
this reason I am thinking about trying the 3.8 version instead. I also intend 
to be using the extension https://github.com/bastibl/gr-ieee802-11 and I think 
that might go smoother with 3.8 as well. Now, the best thing would be if I 
could have both versions installed in parallel, so here are a few questions 
about that:


- Is it viable to run both 3.9 and 3.8 on the same machine (without using 
virtual machines), or will it be more trouble than it is worth?

- What is the best way to do this? PyBOMBS 
(https://github.com/gnuradio/pybombs) looks promising, because it installs 
"into a specified user directory rather than in the system files" (from the 
README). But I notice that the repo has not seen any action in the last few 
years, so maybe PyBOMBS is dead?

- If I use PyBOMBS, can I keep my current 3.9 installation (installed "in the 
system files" by package manager, via PPA) and additionally install 3.8 with 
PyBOMBS? Or will this be a mess?


Best regards,

Anton

Re: OOT tests failing in GNU Radio 3.9.2.0, Ubuntu 20.04.2 LTS

[Anton Ottosson]

Hi Vasil,


I did indeed not have `square2_ff_pydoc.h` in `build/python/bindings`. Running 
`make clean` and `make` did resolve that, though. Thank you for telling me 
about `make clean`.


But then, when I attempt to continue the tutorial by running the tests, I get 
the following:


~/gr-howto/build$ ctest -V
UpdateCTestConfiguration  from 
:/home/antonott/gr-howto/build/DartConfiguration.tcl
UpdateCTestConfiguration  from 
:/home/antonott/gr-howto/build/DartConfiguration.tcl
Test project /home/antonott/gr-howto/build
Constructing a list of tests
Done constructing a list of tests
Updating test list for fixtures
Added 0 tests to meet fixture requirements
Checking test dependency graph...
Checking test dependency graph end
test 1
Start 1: qa_square_ff

1: Test command: /usr/bin/sh 
"/home/antonott/gr-howto/build/python/qa_square_ff_test.sh"
1: Test timeout computed to be: 1000
1: .E.
1: ==
1: ERROR: test_002_square2_ff (__main__.qa_square_ff)
1: --
1: Traceback (most recent call last):
1:   File "/home/antonott/gr-howto/python/qa_square_ff.py", line 50, in 
test_002_square2_ff
1: sqr = howto.square2_ff()
1: NameError: name 'howto' is not defined
1:
1: --
1: Ran 3 tests in 0.003s
1:
1: FAILED (errors=1)
1: DEPRECATED: Using filename with gr_unittest does no longer have any effect.
1/1 Test #1: qa_square_ff .***Failed0.22 sec

0% tests passed, 1 tests failed out of 1

Total Test time (real) =   0.22 sec

The following tests FAILED:
  1 - qa_square_ff (Failed)
Errors while running CTest

This is a failure in the test for the new block (see the OOT tutorial). It is 
quite similar to the original error that we have talked about, but this time 
the workaround of installing the module does not help. It is surprising that 
this test can fail despite the first one, also dependent on `howto` and in the 
same python class, succeeding. Though I guess since the unit tests are executed 
with reflection anything is possible.


Best regards,

Anton


From: Vasil Velichkov 
Sent: Tuesday, June 29, 2021 6:33:42 PM
To: Anton Ottosson; discuss-gnuradio@gnu.org
Subject: Re: OOT tests failing in GNU Radio 3.9.2.0, Ubuntu 20.04.2 LTS

Hi Anton,


On 29/06/2021 19.07, Anton Ottosson wrote:
> Thank you for so generously taking time out of your day to look at this. I 
> agree with your analysis and have now submitted an issue 
> (https://github.com/gnuradio/gnuradio/issues/4825) about this to the GNU 
> Radio GitHub repository.

Nice. Thanks for opening an issue.

> However, it seems like I might have found an additional issue, possibly 
> related. I wanted to make progress with the OOT tutorial 
> (https://wiki.gnuradio.org/index.php/OutOfTreeModules), so i used Ron's 
> suggested workaround with installing the module to get the tests to work. The 
> new issue appears a bit later in the tutorial, when we attempt to add another 
> block to the module. Instead of me describing it here, I have once again set 
> up a GitHub repository (https://github.com/antonott/oot_tutorial_issue) to 
> illustrate the problem. The README describes the process, and of course the 
> rest of the repo contains the state of the module.

First check that you have `square2_ff_pydoc.h` file in `build/python/bindings` 
directory and if not run `make clean` and `make`. But if there is a 
`square2_ff_pydoc.h` then run `make VERBOSE=1` and check that an include flag 
(`-I`) that contains the full path to `build/python/bindings` is present.

I'm able to successfully build your oot_tutorial_issue on Fedora 35 with 
gnuradio 3.9.2.0 and pybind 2.6.2-3. Here is the relevant part of `make 
VERBOSE=1`

[ 70%] Building CXX object 
python/bindings/CMakeFiles/howto_python.dir/square2_ff_python.cc.o
cd /home/test/oot_tutorial_issue/build/python/bindings && /usr/bin/c++ 
-DGR_MPLIB_GMP -DGR_PERFORMANCE_COUNTERS -Dhowto_python_EXPORTS 
-I/home/test/oot_tutorial_issue/build/python/bindings 
-I/home/test/oot_tutorial_issue/python/bindings/../../lib 
-I/home/test/oot_tutorial_issue/python/bindings/../../include 
-I/home/test/oot_tutorial_issue/lib/../include -isystem 
/usr/lib64/python3.10/site-packages/numpy/core/include -isystem 
/usr/include/python3.10 -O3 -DNDEBUG -fPIC -fvisibility=hidden   
-fvisibility=hidden -Wno-unused-variable -flto -fno-fat-lto-objects 
-std=gnu++14 -MD -MT 
python/bindings/CMakeFiles/howto_python.dir/square2_ff_python.cc.o -MF 
CMakeFiles/howto_python.dir/square2_ff_python.cc.o.d -o 
CMakeFiles/howto_python.dir/square2_ff_python.cc.o -c 
/home/test/oot_tutorial_issue/python/bindings/square2_ff_python.cc

Regards,
Vasil

Re: USRP - N300 RunTimeError

[Marcus D Leech]

Indeed when you update your UHD install, you’ll have to rebuild Gnu Radio 
against the updated library. 

Sent from my iPhone

> On Jun 29, 2021, at 12:31 PM, Niels van Etten  wrote:
> 
> 
> Hi Marcus,
> 
> The device arguments are as following:
> 
> 
> 
> Executing: /usr/bin/python3.6 -u /home/niels/top_block.py
> 
> [INFO] [UHD] linux; GNU C++ version 7.5.0; Boost_106501; 
> UHD_3.15.0.0-62-g7a3f1516
> [INFO] [MPMD] Initializing 1 device(s) in parallel with args: 
> mgmt_addr=192.168.1.5,type=n3xx,product=n300,serial=320C34D,claimed=False,addr=192.168.10.2,master_clock_rate=125.0e6
> Traceback (most recent call last):
>   File "/home/niels/top_block.py", line 189, in 
> main()
>   File "/home/niels/top_block.py", line 165, in main
> tb = top_block_cls()
>   File "/home/niels/top_block.py", line 84, in __init__
> channels=list(range(0,1)),
>   File 
> "/home/niels/prefix-3.8/lib/python3/dist-packages/gnuradio/uhd/__init__.py", 
> line 125, in constructor_interceptor
> return old_constructor(*args)
>   File 
> "/home/niels/prefix-3.8/lib/python3/dist-packages/gnuradio/uhd/uhd_swig.py", 
> line 3298, in make
> return _uhd_swig.usrp_source_make(device_addr, stream_args, 
> issue_stream_cmd_on_start)
> RuntimeError: rpc::timeout: Timeout of 2000ms while calling RPC function 
> 'get_num_xbars'
> 
> >>> Done (return code 1)
> 
> Note that I found out that GNU Radio executed UHD_3.15.0.0 instead of 
> UHD_4.0.0.0.
> I did update GNU radio, maybe the UHD of GNU radio is out of date?
> 
>> On Tue, 29 Jun 2021 at 16:01, Marcus D Leech  wrote:
>> What was the exact device argument you used in the GR case?
>> 
>> Sent from my iPhone
>> 
 On Jun 29, 2021, at 9:36 AM, Niels van Etten  wrote:
 
>>> 
>>> Dear all,
>>> I'm trying to run the Ettus N300 on GNU radio.
>>> When I'm running GNU radio via: pybombs run gnuradio-companion, I get the 
>>> following error when trying to run the USRP Source block:
>>> 
>>> [INFO] [UHD] linux; GNU C++ version 7.5.0; Boost_106501; 
>>> UHD_3.15.0.0-62-g7a3f1516
>>> [INFO] [MPMD] Initializing 1 device(s) in parallel with args: 
>>> mgmt_addr=192.168.10.2,type=n3xx,product=n300,serial=320C34D,claimed=False,addr=192.168.10.2
>>> Traceback (most recent call last):
>>>   File "/home/niels/top_block.py", line 187, in 
>>> main()
>>>   File "/home/niels/top_block.py", line 163, in main
>>> tb = top_block_cls()
>>>   File "/home/niels/top_block.py", line 84, in __init__
>>> channels=list(range(0,1)),
>>>   File 
>>> "/home/niels/prefix-3.8/lib/python3/dist-packages/gnuradio/uhd/__init__.py",
>>>  line 125, in constructor_interceptor
>>> return old_constructor(*args)
>>>   File 
>>> "/home/niels/prefix-3.8/lib/python3/dist-packages/gnuradio/uhd/uhd_swig.py",
>>>  line 3298, in make
>>> return _uhd_swig.usrp_source_make(device_addr, stream_args, 
>>> issue_stream_cmd_on_start)
>>> RuntimeError: rpc::timeout: Timeout of 2000ms while calling RPC function 
>>> 'get_num_xbars'
>>> 
>>> Note that uhd_usrp_probe works without warnings and also the UHD example:
>>> /usr/local/lib/uhd/examples/rx_ascii_art_dft --args 
>>> "master_clock_rate=125e6,mgmt_addr=192.168.1.151,addr=192.168.10.2" --freq 
>>> 98.5e6 --rate 2.5e6 --gain 50 --ref-lvl="-50" --dyn-rng 90 --ant "RX2" 
>>> --subdev "A:0", runs like a charm.
>>> 
>>> Anyone knows how to fix this?
>>> 
>>> Thanks in advance
>>> 
>>> -- 
>>> 
>>> Niels van Etten
>>> 
>>> 
>>> 
>>> 
> 
> 
> -- 
> Niels van Etten
> +31 6 11731360| niels@hiber.global| 
> 
> Please note that we've moved to a new office.
> Moermanskkade 600, 1013 BC Amsterdam, The Netherlands   | +31 20 244 0420| 
> hiber.global

Re: OOT tests failing in GNU Radio 3.9.2.0, Ubuntu 20.04.2 LTS

[Vasil Velichkov]

Hi Anton,


On 29/06/2021 19.07, Anton Ottosson wrote:
> Thank you for so generously taking time out of your day to look at this. I 
> agree with your analysis and have now submitted an issue 
> (https://github.com/gnuradio/gnuradio/issues/4825) about this to the GNU 
> Radio GitHub repository.

Nice. Thanks for opening an issue.

> However, it seems like I might have found an additional issue, possibly 
> related. I wanted to make progress with the OOT tutorial 
> (https://wiki.gnuradio.org/index.php/OutOfTreeModules), so i used Ron's 
> suggested workaround with installing the module to get the tests to work. The 
> new issue appears a bit later in the tutorial, when we attempt to add another 
> block to the module. Instead of me describing it here, I have once again set 
> up a GitHub repository (https://github.com/antonott/oot_tutorial_issue) to 
> illustrate the problem. The README describes the process, and of course the 
> rest of the repo contains the state of the module.

First check that you have `square2_ff_pydoc.h` file in `build/python/bindings` 
directory and if not run `make clean` and `make`. But if there is a 
`square2_ff_pydoc.h` then run `make VERBOSE=1` and check that an include flag 
(`-I`) that contains the full path to `build/python/bindings` is present.

I'm able to successfully build your oot_tutorial_issue on Fedora 35 with 
gnuradio 3.9.2.0 and pybind 2.6.2-3. Here is the relevant part of `make 
VERBOSE=1`

[ 70%] Building CXX object 
python/bindings/CMakeFiles/howto_python.dir/square2_ff_python.cc.o
cd /home/test/oot_tutorial_issue/build/python/bindings && /usr/bin/c++ 
-DGR_MPLIB_GMP -DGR_PERFORMANCE_COUNTERS -Dhowto_python_EXPORTS 
-I/home/test/oot_tutorial_issue/build/python/bindings 
-I/home/test/oot_tutorial_issue/python/bindings/../../lib 
-I/home/test/oot_tutorial_issue/python/bindings/../../include 
-I/home/test/oot_tutorial_issue/lib/../include -isystem 
/usr/lib64/python3.10/site-packages/numpy/core/include -isystem 
/usr/include/python3.10 -O3 -DNDEBUG -fPIC -fvisibility=hidden   
-fvisibility=hidden -Wno-unused-variable -flto -fno-fat-lto-objects 
-std=gnu++14 -MD -MT 
python/bindings/CMakeFiles/howto_python.dir/square2_ff_python.cc.o -MF 
CMakeFiles/howto_python.dir/square2_ff_python.cc.o.d -o 
CMakeFiles/howto_python.dir/square2_ff_python.cc.o -c 
/home/test/oot_tutorial_issue/python/bindings/square2_ff_python.cc

Regards,
Vasil

Re: OOT tests failing in GNU Radio 3.9.2.0, Ubuntu 20.04.2 LTS

[Anton Ottosson]

Hi Vasil,


Thank you for so generously taking time out of your day to look at this. I 
agree with your analysis and have now submitted an issue 
(https://github.com/gnuradio/gnuradio/issues/4825) about this to the GNU Radio 
GitHub repository.


However, it seems like I might have found an additional issue, possibly 
related. I wanted to make progress with the OOT tutorial 
(https://wiki.gnuradio.org/index.php/OutOfTreeModules), so i used Ron's 
suggested workaround with installing the module to get the tests to work. The 
new issue appears a bit later in the tutorial, when we attempt to add another 
block to the module. Instead of me describing it here, I have once again set up 
a GitHub repository (https://github.com/antonott/oot_tutorial_issue) to 
illustrate the problem. The README describes the process, and of course the 
rest of the repo contains the state of the module.


Regards,

Anton



From: Vasil Velichkov 
Sent: Tuesday, June 29, 2021 10:57:42 AM
To: Anton Ottosson; discuss-gnuradio@gnu.org
Subject: Re: OOT tests failing in GNU Radio 3.9.2.0, Ubuntu 20.04.2 LTS

Hi Anton,

On 28/06/2021 22.12, Anton Ottosson wrote:
> It indeed seems like the tests only work if I first install the module. I 
> have set up a GitHub with the full source at 
> https://github.com/antonott/oot_tests_failing. The README outlines the 
> procedure used to build, test (and fail), install, and finally test again 
> (and succeeding).

Look at 
https://github.com/antonott/oot_tests_failing/blob/main/build/python/qa_iqlevels_test.sh#L8-L9

  export PYTHONPATH=$PYTHONPATH
  /usr/bin/python3 /home/antonott/gr-iqlevels/python/qa_iqlevels.py

As suspected "/home/antonott/gr-iqlevels/python/" is not added to PYTHONPATH 
and when you run the tests it can't find your module. This seems to be broken 
since the migration from swig to pybind. Previously when swig was used the 
import statements in the python/qa_*.py files looked like this

   import oot_swig as oot

and build/swig was added to the PYTHONPATH in build/python/qa_*_test.sh

   export PYTHONPATH=/home/user/src/gr-oot/build/swig:$PYTHONPATH

Not sure how to fix this but I my option this needs to be fixed/improved.

Regards,
Vasil

Re: UHD 4.1 and support for the NI Ettus USRP X410

[Alex Humberstone]

Haydn, thanks for the announcement. X410 looks awesome, the 400 MHZ channel
bandwidth is incredible. Spoke to my advisor about it. Perfect fit for some
of our 5G and spectrum monitoring work. But we're not sure we can afford
the $20,000 price tag. We have some sticker shock here to be honest. Do you
guys at NI offer any academic discounts? All the work in our lab is non
profit and non commercial. Kevin in the previous post might have the same
question, it looks like he's at CU Boulder. I'm thinking about coming to
GNU Radio Conference. Will you guys have an X410 there?

Sincerely,
Alex-M-Humberstone
PhD Student
Klipsch School of Electrical Engineering
New Mexico State University (NMSU)
Las Cruces, New Mexico, USA



On Mon, 28 Jun 2021 at 11:56, Kevin K Gifford 
wrote:

> Hi Hayden -
>
> Is the cost for the X410 really $20,000 (
> https://www.ettus.com/all-products/usrp-x410/)?
>
> Kevin
> --
> *From:* Discuss-gnuradio  colorado@gnu.org> on behalf of Haydn Nelson 
> *Sent:* Monday, June 28, 2021 10:08 AM
> *To:* discuss-gnuradio@gnu.org 
> *Subject:* UHD 4.1 and support for the NI Ettus USRP X410
>
>
> Hello GNU Radio Community!
>
>
>
> We at NI & Ettus Research have been hard at work advancing the USRP to the
> next level. We recently released the NI Ettus USRP X410.
> 
>
>
>
> Perhaps you saw that UHD 4.1 was merged to the UHD GitHub repository
>  with support for a new USRP, the
> NI Ettus USRP X410, and that release 4.1.0.0rc1 was tagged? Release 4.1.0.0
> is imminent!
>
>
>
> This USRP is a new generation of radio, combining features of both the N-
> and the X-series USRPs, and is fully supported by UHD, RFNoC, and GNU
> Radio. It provides the highest performance of any USRP to date:
>
>- More channels: 4x4 TX/RX
>- More instantaneous bandwidth per channel: 400 MHz
>- Greater tunable RF range: from 1 MHz to 7.2 GHz … pssst … it
>will actually tune up to 8 GHz
>- Larger FPGA: the Xilinx ZU28DR RFSoC
>- Higher bandwidth data connectivity: dual QSFP28 ports
>
>
>
> Resources
>
>- Read more on the Ettus Research website
>
> 
>- Check out 3dB Labs using the USRP X410
>
>
>
>
> If you have interest in the USRP X410 please feel to reach out to us
>  on the Ettus Research website.
>
>
>
> We look forward to seeing you either physically or virtually at
> this year’s GNU Radio Conference in September
> .
>
>
>
> Stay Safe
>
> *Haydn Nelson*
>
> Ettus Research Marketing Manager
>
> [image: Timeline Description automatically generated]
>
>
>

Re: USRP - N300 RunTimeError

[Marcus D Leech]

What was the exact device argument you used in the GR case?

Sent from my iPhone

> On Jun 29, 2021, at 9:36 AM, Niels van Etten  wrote:
> 
> 
> Dear all,
> I'm trying to run the Ettus N300 on GNU radio.
> When I'm running GNU radio via: pybombs run gnuradio-companion, I get the 
> following error when trying to run the USRP Source block:
> 
> [INFO] [UHD] linux; GNU C++ version 7.5.0; Boost_106501; 
> UHD_3.15.0.0-62-g7a3f1516
> [INFO] [MPMD] Initializing 1 device(s) in parallel with args: 
> mgmt_addr=192.168.10.2,type=n3xx,product=n300,serial=320C34D,claimed=False,addr=192.168.10.2
> Traceback (most recent call last):
>   File "/home/niels/top_block.py", line 187, in 
> main()
>   File "/home/niels/top_block.py", line 163, in main
> tb = top_block_cls()
>   File "/home/niels/top_block.py", line 84, in __init__
> channels=list(range(0,1)),
>   File 
> "/home/niels/prefix-3.8/lib/python3/dist-packages/gnuradio/uhd/__init__.py", 
> line 125, in constructor_interceptor
> return old_constructor(*args)
>   File 
> "/home/niels/prefix-3.8/lib/python3/dist-packages/gnuradio/uhd/uhd_swig.py", 
> line 3298, in make
> return _uhd_swig.usrp_source_make(device_addr, stream_args, 
> issue_stream_cmd_on_start)
> RuntimeError: rpc::timeout: Timeout of 2000ms while calling RPC function 
> 'get_num_xbars'
> 
> Note that uhd_usrp_probe works without warnings and also the UHD example:
> /usr/local/lib/uhd/examples/rx_ascii_art_dft --args 
> "master_clock_rate=125e6,mgmt_addr=192.168.1.151,addr=192.168.10.2" --freq 
> 98.5e6 --rate 2.5e6 --gain 50 --ref-lvl="-50" --dyn-rng 90 --ant "RX2" 
> --subdev "A:0", runs like a charm.
> 
> Anyone knows how to fix this?
> 
> Thanks in advance
> 
> -- 
> 
> Niels van Etten
> 
> 
> 
> 

ofdm transceiver causes GRC freeze to forcibly exit

[????????]

Hi,guys.
I am using ofdm transceiver to send text or video. I use "ZMQ" to connect the 
two flow graphs. When I run the receiving program, I can get the sent text 
string from the "file sink", although it is It is repeated continuously. But 
the problem is that every time I can't manually terminate the receiving 
program, it will cause the GRC to freeze, and the terminal will continue to 
display the received packets. May i know what is this all about?

The more serious problem is: when I do not use the "ZMQ" block, but replace it 
with USRP source and USRP Sink, the receiving end cannot receive the signal 
correctly, and the character content in the sending end text cannot be 
obtained. An unknown error occurred in the transmission! Where is my problem?

Hope someone can help me, thanks!My flow chart is in the attachment.
 

Sincerely
liumaolin

vedio_tx.pdf
Description: Binary data


video_rx.pdf
Description: Binary data

USRP - N300 RunTimeError

[Niels van Etten]

Dear all,

I'm trying to run the Ettus N300 on GNU radio.
When I'm running GNU radio via: pybombs run gnuradio-companion, I get the
following error when trying to run the USRP Source block:
[INFO] [UHD] linux; GNU C++ version 7.5.0; Boost_106501;
UHD_3.15.0.0-62-g7a3f1516
[INFO] [MPMD] Initializing 1 device(s) in parallel with args:
mgmt_addr=192.168.10.2,type=n3xx,product=n300,serial=320C34D,claimed=False,addr=192.168.10.2
Traceback (most recent call last):
  File "/home/niels/top_block.py", line 187, in 
main()
  File "/home/niels/top_block.py", line 163, in main
tb = top_block_cls()
  File "/home/niels/top_block.py", line 84, in __init__
channels=list(range(0,1)),
  File
"/home/niels/prefix-3.8/lib/python3/dist-packages/gnuradio/uhd/__init__.py",
line 125, in constructor_interceptor
return old_constructor(*args)
  File
"/home/niels/prefix-3.8/lib/python3/dist-packages/gnuradio/uhd/uhd_swig.py",
line 3298, in make
return _uhd_swig.usrp_source_make(device_addr, stream_args,
issue_stream_cmd_on_start)
RuntimeError: rpc::timeout: Timeout of 2000ms while calling RPC function
'get_num_xbars'

Note that uhd_usrp_probe works without warnings and also the UHD example:
/usr/local/lib/uhd/examples/rx_ascii_art_dft --args
"master_clock_rate=125e6,mgmt_addr=192.168.1.151,addr=192.168.10.2" --freq
98.5e6 --rate 2.5e6 --gain 50 --ref-lvl="-50" --dyn-rng 90 --ant "RX2"
--subdev "A:0", runs like a charm.

Anyone knows how to fix this?

Thanks in advance
-- 

Niels van Etten

Re: The error happened when a OOT modulus was 'sudo make install'.

[Vasil Velichkov]

Hi fan,

Welcome to GNU Radio!

On 29/06/2021 11.44, fan wrote:
> I have installed gnuradio 3.8.1.0 in Ubuntu 20.04, and I am using gr_ modtool 
> to write the OOT module. However, when I execute the sudo make install 
> command in the build directory of the module, the system reports an error as 
> follows:
> 
> make[2]: *** No rule to make target “/usr/lib/x86_ 
> 64-linux-gnu/liborc-0.4.so” needed by 
> “lib/libgnuradio-corr.so.v1.0-compat-xxx-xunknown”，stop.

> Then I'm at / usr / lib / x86_ I found the liborc-0.4. So. 0 and liborc-0.4. 
> So. 0.31.0 files in the 64 Linux GNU / directory, and then I didn't know what 
> else to do. Can someone help me?

The easiest solution is to install liborc-0.4-dev package as this package 
contains this file.

  sudo apt-get install liborc-0.4-dev

Regards,
Vasil

The error happened when a OOT modulus was 'sudo make install'.

[fan]

Hi，everyone. I have installed gnuradio 3.8.1.0 in Ubuntu 20.04, and I am using 
gr_ modtool to write the OOT module. However, when I execute the sudo make 
install command in the build directory of the module, the system reports an 
error as follows:

make[2]: *** No rule to make target “/usr/lib/x86_ 64-linux-gnu/liborc-0.4.so” 
needed by “lib/libgnuradio-corr.so.v1.0-compat-xxx-xunknown”，stop.
make[1]: *** [CMakeFiles/Makefile2:272：lib/CMakeFiles/gnuradio-corr.dir/all]
error 2.
make: *** [M akefile:141 ：all] error 2.
I'm new to Linux, so I can't get rid of this obstacle myself. I checked line 
272 of the cmakefiles / makefile2 file as follows:
$(MAKE) -f lib/CMakeFiles/gnuradio-corr.dir/build.make 
lib/CMakeFiles/gnuradio-corr.dir/build
So I found the build. Make file and found the following lines in the code:
# External object files for target gnuradio-corr
gnuradio__ corr_ EXTERNAL_ OBJECTS =
lib/libgnuradio-corr.so.v1.0-compat-xxx-xunknown: 
lib/CMakeFiles/gnuradio-corr.dir/corr_ impl.cc.o
lib/libgnuradio-corr.so.v1.0-compat-xxx-xunknown: 
lib/CMakeFiles/gnuradio-corr.dir/build.make
lib/libgnuradio-corr.so.v1.0-compat-xxx-xunknown: /usr/lib/x86_ 
64-linux-gnu/libgnuradio-runtime.so.3.8.1.0
lib/libgnuradio-corr.so.v1.0-compat-xxx-xunknown: /usr/lib/x86_ 
64-linux-gnu/libgnuradio-pmt.so.3.8.1.0
lib/libgnuradio-corr.so.v1.0-compat-xxx-xunknown: /usr/lib/x86_ 
64-linux-gnu/libvolk.so.2.2
lib/libgnuradio-corr.so.v1.0-compat-xxx-xunknown: /usr/lib/x86_ 
64-linux-gnu/liborc-0.4.so
Then I'm at / usr / lib / x86_ I found the liborc-0.4. So. 0 and liborc-0.4. 
So. 0.31.0 files in the 64 Linux GNU / directory, and then I didn't know what 
else to do. Can someone help me?

Re: OOT tests failing in GNU Radio 3.9.2.0, Ubuntu 20.04.2 LTS

[Vasil Velichkov]

Hi Anton,

On 28/06/2021 22.12, Anton Ottosson wrote:
> It indeed seems like the tests only work if I first install the module. I 
> have set up a GitHub with the full source at 
> https://github.com/antonott/oot_tests_failing. The README outlines the 
> procedure used to build, test (and fail), install, and finally test again 
> (and succeeding).

Look at 
https://github.com/antonott/oot_tests_failing/blob/main/build/python/qa_iqlevels_test.sh#L8-L9

  export PYTHONPATH=$PYTHONPATH
  /usr/bin/python3 /home/antonott/gr-iqlevels/python/qa_iqlevels.py 

As suspected "/home/antonott/gr-iqlevels/python/" is not added to PYTHONPATH 
and when you run the tests it can't find your module. This seems to be broken 
since the migration from swig to pybind. Previously when swig was used the 
import statements in the python/qa_*.py files looked like this

   import oot_swig as oot

and build/swig was added to the PYTHONPATH in build/python/qa_*_test.sh

   export PYTHONPATH=/home/user/src/gr-oot/build/swig:$PYTHONPATH

Not sure how to fix this but I my option this needs to be fixed/improved.

Regards,
Vasil