Re: Error in RFNOC blocks in CPP ?? Cannot create! Property already exists at: /blocks/0/DUC#0/noc_id

[sp h]

Finally, my code worked correctly. I share it for future use.

 gr::top_block_sptr tb = gr::make_top_block("receiver");

 gr::ettus::rfnoc_graph::sptr rfnoc_graph_ctrl;


 const::uhd::device_addr_t device("addr=192.168.10.2");

rfnoc_graph_ctrl=gr::ettus::rfnoc_graph::make(device);

uhd::stream_args_t stream_arg=uhd::stream_args_t("fc32","sc16");

gr::ettus::rfnoc_rx_streamer::sptr
rx_streamer=gr::ettus::rfnoc_rx_streamer::make(rfnoc_graph_ctrl,1,stream_arg,1,true);

gr::ettus::rfnoc_rx_radio::sptr
rx_radio=gr::ettus::rfnoc_rx_radio::make(rfnoc_graph_ctrl,device,-1,-1);

rx_radio->set_rate(stod(sampleRateRX) * 1000);

rx_radio->set_antenna(rxAntenna, 0);

rx_radio->set_frequency(stod(frequencyRX) * 100, 0);

rx_radio->set_gain(rfGain, 0);

//rx_radio->set_bandwidth(0, 0);

rx_radio->set_dc_offset(false, 0);

rx_radio->set_iq_balance(false, 0);


gr::ettus::rfnoc_ddc::sptr
ddc_0=gr::ettus::rfnoc_ddc::make(rfnoc_graph_ctrl,device,-1,-1);

gr::blocks::null_sink::sptr
null_sink=gr::blocks::null_sink::make(sizeof(gr_complex));

ddc_0->set_freq(0, 0);

ddc_0->set_output_rate(0, 0);




//Connections

rfnoc_graph_ctrl->connect(ddc_0->get_unique_id(),
0,rx_streamer->get_unique_id(), 0,false);

rfnoc_graph_ctrl->connect(rx_radio->get_unique_id(),
0,ddc_0->get_unique_id(), 0, false);

tb->connect(rx_streamer, 0,tsnk_c , 0);

tb->connect(rx_streamer, 0,fsnk_c , 0);


   tb->start();


On Tue, Jan 25, 2022 at 11:02 AM sp h  wrote:

> The source code also warns me time out blocks and after it, the program
> crashes...
>
> when I disabled connect for rx_streamer block, the software has not any
> error but I can not see outputs...
>
> still, I am working on the problem to solve it.
>
>
> *[WARNING] [RFNOC::GRAPH] One or more blocks timed out during flush!*
>
> [ERROR] [RFNOC::GRAPH] Caught exception while initializing graph:
> RuntimeError: Cannot create! Property already exists at:
> /blocks/0/DUC#0/noc_id
>
> terminate called after throwing an instance of 'uhd::runtime_error'
>
> what(): RuntimeError: Failure to create rfnoc_graph.
>
> On Mon, Jan 24, 2022 at 11:05 AM sp h  wrote:
>
>> when I want to convert a GRC python code to CPP code I am faced with NOC
>> graph error?
>> any idea for solving the problem...?  I too attached python code...
>>
>> [ERROR] [RFNOC::GRAPH] Caught exception while initializing graph:
>> RuntimeError: Cannot create! Property already exists at:
>> /blocks/0/DUC#0/noc_id
>>
>> terminate called after throwing an instance of 'uhd::runtime_error'
>>
>> what(): RuntimeError: Failure to create rfnoc_graph.
>>
>>
>>
>>  const::uhd::device_addr_t device("addr=192.168.10.2");
>>
>> gr::ettus::rfnoc_graph::sptr 
>> rfnoc_graph_ctrl=gr::ettus::rfnoc_graph::make(device);
>>
>> uhd::stream_args_t stream_arg=uhd::stream_args_t("fc32","sc16");
>>
>> gr::ettus::rfnoc_rx_streamer::sptr 
>> rx_streamer=gr::ettus::rfnoc_rx_streamer::make(rfnoc_graph_ctrl,1,stream_arg,1,true);
>>
>> gr::ettus::rfnoc_rx_radio::sptr 
>> rx_radio=gr::ettus::rfnoc_rx_radio::make(rfnoc_graph_ctrl,device,-1,-1);
>>
>> rx_radio->set_rate(2000);
>>
>> rx_radio->set_antenna("AB", 0);
>>
>> rx_radio->set_frequency(25e6, 0);
>>
>> rx_radio->set_gain(10, 0);
>>
>> rx_radio->set_bandwidth(0, 0);
>>
>> rx_radio->set_dc_offset(false, 0);
>>
>> rx_radio->set_iq_balance(false, 0);
>>
>>
>> gr::ettus::rfnoc_ddc::sptr  
>> ddc=gr::ettus::rfnoc_ddc::make(rfnoc_graph_ctrl,device,-1,-1);
>>
>>
>> ddc->set_freq(0, 0);
>>
>> ddc->set_output_rate(0, 0);
>>
>>
>> //Connections
>>
>> rfnoc_graph_ctrl->connect(ddc->get_unique_id(), 
>> 0,rx_streamer->get_unique_id(), 0, false);
>>
>> rfnoc_graph_ctrl->connect(rx_radio->get_unique_id(), 
>> 0,ddc->get_unique_id(), 0, false);
>>
>>
>> tb->connect(rx_streamer, 0,tsnk_c , 0);
>>
>> tb->connect(rx_streamer, 0,fsnk_c , 0);
>>
>> tb->start();
>>
>>
>>

AW: Building packages for GnuRadio 3.8 and UHD 4.1.0: Circular dependency?

[Schütz , Katja]

Hi Markus and Jeff,

Thank you both for your answers.
I successfully built and deployed both packages now by building UHD first and 
then installing libuhd-dev without recommends. Then I was able to build and 
install Gnuradio, just as you said.

Anyway, I learned that packages can work very well without the recommended 
dependencies!

Best Regards,
Katja

Von: Martin Braun 
Gesendet: Dienstag, 25. Januar 2022 11:04
An: Schütz, Katja 
Cc: discuss-gnuradio@gnu.org
Betreff: Re: Building packages for GnuRadio 3.8 and UHD 4.1.0: Circular 
dependency?

Hi Katja,

I was trying to figure out where that comes from. Maybe this is the key: 
https://packages.ubuntu.com/jammy/libuhd-dev

This page is telling me that libuhd-dev recommends gnuradio-dev (not that it 
depends on it). Maybe your script is also working on recommended dependencies? 
Have you tried --no-install-recommends (in step 4)?

--M

On Fri, Jan 21, 2022 at 5:42 PM Schütz, Katja 
mailto:katja.schu...@iis.fraunhofer.de>> wrote:
Hello there,

I’m building packages for internal use:  GnuRadio 3.8.5 and UHD 4.1.0.5 and 
noticed that each seems to have the other as dependency. Is this correct? How 
to deal with that? Build and install them alternating?

Background: We have a fairly complicated flowgraph which we don’t want to 
convert to GnuRadio3.9. On the other hand we enjoy and use features and bug 
fixed from UHD 4.1.0.5. Our server runs Ubuntu 20.04 (Focal) and that won’t 
change soon. Until now we used a script to download both, GnuRadio and UHD, as 
archives and build them directly on the machine. The package is meant to save 
time when installing a new server and guarantee the specific versions. Also we 
could then directly work on the code.

What I did:

1.   Download sources with apt. For UHD I used the jammy repo as focal only 
provides 3.15

2.   Install UHD build dependencies (sudo apt-get build-dep) for uhd

3.   Build UHD package (dpkg-buildpackage –b)

4.   Try to install:

a.   libuhd4.1.0 installs fine including dependencies

b.   libuhd-dev_4.1.0.5 depends on gnuradio, gnuradio-dev and several 
libgnuradio packages

5.   Try to install gnuradio build dependencies
-> build depends on libuhd-dev

Does this really mean to install libuhd-dev I need to install gnuradio, but to 
build gnuadio (with UHD support) I need to install libuhd-dev?
Again my question: Where do I even start? Is this intended?

Thanks for looking into this!
Best Regards,
Katja

Re: [USRP-users] Re: N321 LO sharing between RF 0/1

[Paul Atreides]

Daniel,
I have added the UHD API calls necessary to turn the transmit LO Distribution 
board ports on and off through python snippets. I did this in a way that does 
not require modifying UHD itself, only gr-uhd. I’ll send more details later 
when I’m in front of that machine. 





> On Jan 18, 2022, at 17:07, Daniel Estévez  wrote:
> 
> Hi Paul,
> 
> Would this work if you run these calls before the gr-uhd code in the 
> flowgraph instances the device? This can be tested by inserting the code 
> manually. It could be a solution, but I'm not even sure if you can insert a 
> Python snippet in that location. However, if gr-uhd resets these settings 
> when initializing the device, then this approach won't work.
> 
> Best,
> Daniel.
> 
>> El 18/1/22 a las 22:59, Paul Atreides escribió:
>> wow, thanks Daniel!
>> I just bumped an issue on the GNURadio github here 
>>  I've cross-linked my 
>> comments to gr-ATA as well.
>> 
>> the python code i'm using to enable the LO distro in the UHD python API is:
>> import uhd
>> import numpy as np
>> usrp = uhd.usrp.MultiUSRP()
>> usrp.get_tree().access_bool("/blocks/0/Radio#0/dboard/tx_frontends/0/los/lo1/lo_distribution/LO_OUT_0/export").set(True)
>> usrp.get_tree().access_bool("/blocks/0/Radio#0/dboard/tx_frontends/0/los/lo1/lo_distribution/LO_OUT_1/export").set(True)
>> usrp.get_tree().access_bool("/blocks/0/Radio#0/dboard/tx_frontends/0/los/lo1/lo_distribution/LO_OUT_2/export").set(True)
>> i'm not sure how to work that into a python snippet yet as I think gr-uhd 
>> will claim the radio once the graph is started.

Re: Opinions on running GNU Radio 3.9+ on Windows

[Derek Kozel]

Hello Franco,

Thank you for your work supporting the SDRplay receivers in GNU Radio!

I would recommend using the Anaconda based approach. Here is a direct 
link to the page that covers it in more detail. This is the current best 
method to get a fully native setup on Windows that supports developing 
out of tree modules. I run and develop with GNU Radio on a daily (or at 
least weekly) basis and this approach does work fairly well.

https://wiki.gnuradio.org/index.php/CondaInstall

If you have any questions or hit issues I'm happy to help and the chat 
channels are quite active and include Ryan Volz, the main packager for 
GNU Radio in Conda and author of that guide.


Regards,
Derek


On 1/15/2022 3:10 AM, Franco VENTURI wrote:
I am the developer of the GNU Radio OOT module 'gr-sdrplay3' to 
support the SDRplay RSPs as native GNU Radio sources, and I received 
some inquiries about running it on Windows (I run Linux here and 
that's what I use for GNU Radio and other SDR applications).


Since I wrote that OOT module for GNU Radio 3.9+ (i.e. 3.9 and 3.10) 
because of the pybind11 bindings (no SWIG), I took a quick look at 
this page in the Wiki 
(https://wiki.gnuradio.org/index.php/WindowsInstall), and I see that 
there are a few options:
- Geof Nieboer's binary installer for Windows (but it looks like 
there's only a version 3.9.0.0 beta, and the last commit to that 
GitHub repo was from about a year and a half ago)
- radioconda (latest release October of last year, GNU Radio version 
3.9.3.0)
- Pothos SDR development environment (not sure of the version of GNU 
Radio there)

- various ways of building from source (MSYS, Cygwin, WSL)

Since I would like to give it a try and see if the 'gr-sdrplay3' OOT 
module can run on Windows (and perhaps package it somehow), I was 
wondering for those of you who are running on a daily basis a recent 
version (3.9+) of GNU Radio on Windows, what is the preferred option 
both in terms of day-to-day usage and development?


Thanks in advance,
Franco Venturi

Here's how to get the N321's LO sharing to work in GNURadio 3.9 with UHD4.1.0.5

[Paul Atreides]

Currently there's no way to use LO sharing with the N321 in gr-uhd.
The N321 uses an RF Distribution board which has port terminations that
need to be switched to active outputs when the LO is exported. This isn't
accessible in gr-uhd.

In order to access the LO distribution enable commands shown here:
https://kb.ettus.com/USRP_N320/N321_LO_Distribution#UHD_LO_Distribution_Commands
a function needs to be added to gr-uhd
All this code below is taken from here:
https://github.com/daniestevez/uhd/commit/0a6da1a3fd5839b862cac740ed702923ed21b096
https://github.com/daniestevez/gnuradio/commit/f9909bade86045f379f83001de27317cc261807f
with the rx switched for tx and source switched for sink
i also did not modify any UHD code making this a fix that requires ONLY
modifying gr-uhd

usrp_sink_impl.cc
void usrp_sink_impl::set_tx_lo_dist(bool enabled,
const std::string& name,
size_t chan)

{
#ifdef UHD_USRP_MULTI_USRP_TX_LO_CONFIG_API
_dev->get_tree()->access(
"/blocks/0/Radio#0/dboard/tx_frontends/0/los/lo1/lo_distribution"/ ::uhd::
fs_path(name) / "export").set(enabled);

#else
throw std::runtime_error("not implemented in this version");
#endif
}
usrp_sink_impl.h
void set_tx_lo_dist(bool enabled,
const std::string &name, size_t chan = 0) override;
usrp_sink.h
virtual void set_tx_lo_dist(bool enabled, const std::string &name, size_t
chan =0) = 0;

usrp_sink_python.cc
.def("set_tx_lo_dist",
&usrp_sink::set_tx_lo_dist,
py::arg("enabled"),
py::arg("name"),
py::arg("chan") = 0,
D(usrp_sink, set_tx_lo_dist))
usrp_sink_pydoc_template.h
static const char* __doc_gr_uhd_usrp_sink_set_tx_lo_dist = R"doc()doc";



Assuming the sink block is "usrp_sink_0"

snippet_0 code
'Main-After Init'
# Turn on the ports
self.usrp_sink_0.set_tx_lo_dist(True,"LO_OUT_0",0)
# repeat the above for all ports needed "LO_OUT_"

snippet_1
'Main-After Stop'
# Turn off the ports
self.usrp_sink_0.set_tx_lo_dist(False,"LO_OUT_0",0)
# repeat for all ports you enabled "LO_OUT_"

The other settings i found were needed in the gr-uhd block included:
Setting the start time to 1
Setting the Master Clock rate to 200MHz
CH0:
  LO Source = external
  LO Export = True
CH1:
  LO Source = external
  LO Export = False


I'd like to thank the community of users for doing all of this work,
especially Marcus Leech, Rob Kossler and Daniel Estevez