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

2022-01-29 Thread Daniel Estévez

Hi,

Thanks! That seems very nice. Could we try upstreaming this? I don't see 
any obvious drawbacks to having this in-tree, particularly since your 
approach doesn't require modifying UHD.


Best,
Daniel.

El 28/1/22 a las 23:55, Paul Atreides escribió:

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
voidusrp_sink_impl::set_tx_lo_dist(boolenabled,
conststd::string&name,
size_tchan)

{
#ifdefUHD_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
throwstd::runtime_error("not implemented in this version");
#endif
}
usrp_sink_impl.h
voidset_tx_lo_dist(boolenabled,
conststd::string&name, size_tchan= 0) override;
usrp_sink.h
virtualvoidset_tx_lo_dist(boolenabled, conststd::string&name, 
size_tchan=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
staticconstchar* __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








OpenPGP_signature
Description: OpenPGP digital signature


Release v3.10.1.0

2022-01-29 Thread Jeff Long
The rc1 was fairly small, and no problems reported in the last few days, so
we'll call it final.

https://github.com/gnuradio/gnuradio/releases/tag/v3.10.1.0

>From the CHANGELOG ...

This is mostly a bug fix release. It is API compatible with 3.10.X.Y
releases. Code built against GNU Radio libraries (including OOTs) will
likely need to be recompiled, as ABI compatibility is not guaranteed.

Runtime
- Add ownership and locking to hier_block2 to avoid crash/freeze after
disconnect.

gr-analog
- Fix C++ code generation for random_uniform_source

gr-blocks
- Minimal implementation of a SigMF Sink, allowing users to easily try out
generation SigMF output. SigMF uses a raw data file and a separate JSON
metadata file. A SigMF Source is also provided. At this time, it is a
wrapper around a File Source (the data files are compatible), but metadata
is not processed.

gr-filter
- Bug fix: buses should now work with PFB channelizer and synthesizer.

gr-iio
- Various fixes for fmcomms2/3/4.

gr-uhd
- Bug fix: overflow count was uninitialized.
- Correct descriptor names in uhd_fpga_ddc/duc.

GRC
- Bug fix: initialize value for "priority" parameter in Python Snippets.
- Show blocks with "deprecated" flags as deprecated.


Problem migrating an OOT module that uses FFT from 3.8 to 3.9

2022-01-29 Thread Ralf Gorholt

Hello all,

I am currently trying to migrate an OOT module that uses an FFT object
internally from  GNU Radio version 3.8 to 3.9.

In my .h file I have got this:

    //old: gr::fft::fft_complex d_fft_calculator;
    gr::fft::fft_complex_fwd d_fft_calculator;

and in the constructor member initializer list this:

  //old: d_fft_calculator(gr::fft::fft_complex(pow(2.0, 10 + mode),
true, 1)),
  d_fft_calculator(pow(2.0, 10 + mode), 1),

The module compiles without a problem but when I start the flowgraph I
get the message "ImportError: /usr/local/lib/libgnuradio-dl5eu.so.1.0.0:
undefined symbol: _ZN2gr3fft3fftISt7complexIfELb1EED1Ev". It looks to me
that somewhere "fft_complex" is still called behind the scenes but I
can't see where.

Can anyone tell me how I need to correct this?

FYI, I have recreated the module and the blocks with gr_modtool and then
copied the relevant code from the old to the new version.

Thank you very much and kind regards,

Ralf



Re: Problem migrating an OOT module that uses FFT from 3.8 to 3.9

2022-01-29 Thread Ron Economos

Ralf,

I'm not sure if you've done this already, but when you use 
d_fft_calculator, you need to change from -> to . to access it.


Ron

On 1/29/22 12:24, Ralf Gorholt wrote:

Hello all,

I am currently trying to migrate an OOT module that uses an FFT object
internally from  GNU Radio version 3.8 to 3.9.

In my .h file I have got this:

    //old: gr::fft::fft_complex d_fft_calculator;
    gr::fft::fft_complex_fwd d_fft_calculator;

and in the constructor member initializer list this:

  //old: d_fft_calculator(gr::fft::fft_complex(pow(2.0, 10 + mode),
true, 1)),
  d_fft_calculator(pow(2.0, 10 + mode), 1),

The module compiles without a problem but when I start the flowgraph I
get the message "ImportError: /usr/local/lib/libgnuradio-dl5eu.so.1.0.0:
undefined symbol: _ZN2gr3fft3fftISt7complexIfELb1EED1Ev". It looks to me
that somewhere "fft_complex" is still called behind the scenes but I
can't see where.

Can anyone tell me how I need to correct this?

FYI, I have recreated the module and the blocks with gr_modtool and then
copied the relevant code from the old to the new version.

Thank you very much and kind regards,

Ralf