Monday, January 31, 2022

Question about Packet Length in OFDM transmission

Hello Everyone,
I was trying to simulate an OFDM transmission using OFDM Tx and Rx files given in the example folder. I added both tx and rx part in same flowgraph. I added a ".txt" file size of 100 bytes as source and wanted to receive it at the sink. In my case, If I set packet length to only 1 then full bytes are received at the Rx end. I saw few others example from different sources who used different packet lengths for packet transmission and getting their outputs. 

In my case, what am I missing? Would appreciate, if anyone explain to me. I added my flowgraph in attachment.

Thanks in advance.
--


Regards,
Rupak Paul 

Re: Trouble with OOT modules on Windows with Conda

Hi Florian,

I'm not sure if you're who I figured this out with on the Matrix chat, but it's worth documenting for the mailing list anyway.

I think the issue here is that CMake on Windows defaults to building the OOT in the "Debug" configuration, and this creates pybind11 bindings that are incompatible with a non-Debug build of GNU Radio. The solution is to specify "-DCMAKE_BUILD_TYPE=Release" when running cmake. I have already updated the CondaInstall guide to reflect this.

Longer-term, it would be good if the build defaulted to the "Release" configuration. The CMake code already attempts to do this, but it doesn't work on Windows in the same way it does on Linux/macOS. I think I have a solution for that and will be submitting a pull request shortly.

Cheers,
Ryan

On 1/23/22 2:32 PM, Florian Euchner wrote:
> Hello everyone,
>
> I am having trouble compiling OOT modules on Windows (Windows 10, Visual Studio 2017 14.16.27023).
> As far as I can tell, my problems affect any OOT module, so I will just use gr-correctiq [1] as an example.
>
> I am inside a Conda environment as detailed in the CondaInstall guide [2] and my GNURadio has been built from the sources following the instructions in [3].
> I can compile and install OOT modules just fine, but after installation, they fail to import with the following error:
>
> # python
>>>> import correctiq
> Traceback (most recent call last):
>   File "<stdin>", line 1, in <module>
>   File "C:\Users\florian\.conda\envs\grdev\lib\site-packages\correctiq\__init__.py", line 18, in <module>
>     from .correctiq_python import *
> ImportError: generic_type: type "correctiq" referenced unknown base type "gr::sync_block"
>
> The same error occurs when executing a flowgraph with any block from the correctiq module inside GNURadio companion.
>
> I have seen a similar question on the mailing list recently [4], where the issue turned out to be different pybind versions.
> However, this can't be the case for me, since I have compiled GNURadio from source inside the same Conda environment (GNURadio version is latest master as of today, but also occurs for 3.9.5 and 3.10).
> Also, my problem appears to specifically occur on Windows and not on Linux.
>
> Any idea on how to solve or debug it? Any help is greatly appreciated!
>
> Kind regards,
> Florian
>
> [1]: https://github.com/ghostop14/gr-correctiq
> [2]: https://wiki.gnuradio.org/index.php?title=CondaInstall
> [3]: https://wiki.gnuradio.org/index.php?title=CondaInstall#Building_GNU_Radio_from_source_within_a_conda_environment
> [4]: https://lists.gnu.org/archive/html/discuss-gnuradio/2021-05/msg00056.html
>

Sunday, January 30, 2022

Re: DVB-T transmit question

Seems fine here. Can you try the unmodified example flow graph? The
example Transport Stream can be downloaded here:

https://www.w6rz.net/adv8dvbt23qam64.ts

Also, which version of GNU Radio are you using?

Ron

On 1/30/22 08:40, Szilassi Andras wrote:
> Hello,
>
> I am currently working on a dvb-t remodulator for our passive radar at
> my university.
> With the available example IQ file, I was able to get the receiving
> example program running, but I ran into some problems with the
> transmit example.
>
> When I run a .ts mpeg stream through the example, for some reason in
> the place where the cyclic prefix should appear, the output is
> constant zero.
> The reason I think that something is wrong with the prefixing is that
> the output signal is periodic in the time domain ( for around ~ 200 us
> there is no signal, then for ~ 800 us there is and so on). The CP
> length is set at 1/4 so that confirms that.
>
> I dont have enough in-depth knowledge yet to find the answer in the
> source files, so if anyone could help me I would really appreciate it.
>
> Thanks is advance,
> András
> Technical University of Budapest

DVB-T transmit question

Hello,

I am currently working on a dvb-t remodulator for our passive radar at my university.
With the available example IQ file, I was able to get the receiving example program running, but I ran into some problems with the transmit example.

When I run a .ts mpeg stream through the example, for some reason in the place where the cyclic prefix should appear, the output is constant zero.
The reason I think that something is wrong with the prefixing is that the output signal is periodic in the time domain ( for around ~ 200 us there is no signal, then for ~ 800 us there is and so on). The CP length is set at 1/4 so that confirms that.

I dont have enough in-depth knowledge yet to find the answer in the source files, so if anyone could help me I would really appreciate it.

Thanks is advance,
AndrĂ¡s
Technical University of Budapest

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

Hello Ron,

thank you very much.

I have walked right into the trap a second time :-( I should attach a
Post-It to my monitor screen to remind me that I might need to adapt the
CMakeLists.txt files when I change something...

Long story short, it works now :-)

Regards,

Ralf

Am 29.01.2022 um 23:54 schrieb Ron Economos:
> Ralf,
>
> Yes, I  was thinking about how I had done things in my 3.8 OOT's where
> I had used this syntax instead:
>
> fft::fft_complex *ofdm_fft;
>
> and
>
> ofdm_fft = new fft::fft_complex(ofdm_fft_size, false, 1);
>
> The other thing to check is the linking. Like so.
>
> https://github.com/drmpeg/gr-paint/blob/master/CMakeLists.txt#L78
>
> and
>
> https://github.com/drmpeg/gr-paint/blob/master/lib/CMakeLists.txt#L25
>
> Ron
>
> On 1/29/22 14:24, Ralf Gorholt wrote:
>> Hello Ron,
>>
>> d_fft_calculator is (and was in the 3.8 version) an object and not a
>> pointer. That's why I already use the . and not the ->
>>
>> Regards,
>>
>> Ralf
>>
>> Am 29.01.2022 um 21:35 schrieb 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
>>>>
>>>
>>

Saturday, January 29, 2022

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

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
>

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

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

Release v3.10.1.0

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.

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

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
> <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/uhd/commit/0a6da1a3fd5839b862cac740ed702923ed21b096>
> https://github.com/daniestevez/gnuradio/commit/f9909bade86045f379f83001de27317cc261807f
> <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<bool>("/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");
>

Friday, January 28, 2022

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

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<bool>("/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");

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

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.



<end transmission>

> On Jan 18, 2022, at 17:07, Daniel Estévez <daniel@destevez.net> 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 <https://github.com/gnuradio/gnuradio/issues/5104> I've cross-linked my comments to gr-ATA as well.
>> <https://github.com/gnuradio/gnuradio/issues/5104>
>> 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.

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

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 <martin.braun@ettus.com>
Gesendet: Dienstag, 25. Januar 2022 11:04
An: SchĂ¼tz, Katja <katja.schuetz@iis.fraunhofer.de>
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 <katja.schuetz@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: Error in RFNOC blocks in CPP ?? Cannot create! Property already exists at: /blocks/0/DUC#0/noc_id

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) * 1000000, 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 <stackprogramer@gmail.com> 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 <stackprogramer@gmail.com> 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();

Thursday, January 27, 2022

Re: wiki for Guided Tutorial on PSK demodulation

Further to my query, i updated to 3.10.0. Now, the settings are working. Thank you

On Fri, Jan 28, 2022 at 9:26 AM vempati Sarma <vsrksiva@gmail.com> wrote:
Hi,
I am trying to learn from the wiki. In the illustrations, taps mentioned for block Decimating FIR filter are -1, 0, 1   simulating difference filter ....These values are not accepted while running the flowgraph. Program seems to expect single value. I am using Gnuradio 3.8.1.0 on Ubuntu 20.04.3LTS. What am i missing?

--
Best Regards,
vsrk sarma


--
Best Regards,
vsrk sarma

wiki for Guided Tutorial on PSK demodulation

Hi,
I am trying to learn from the wiki. In the illustrations, taps mentioned for block Decimating FIR filter are -1, 0, 1   simulating difference filter ....These values are not accepted while running the flowgraph. Program seems to expect single value. I am using Gnuradio 3.8.1.0 on Ubuntu 20.04.3LTS. What am i missing?

--
Best Regards,
vsrk sarma

Re: Signal Capture and Playback Noise

I think you would need your SDR and signal generator phase locked to get a perfect frequency measurement. Windowed measurements aren't perfect. 

Your signal generator probably has a 10MHz reference input and perhaps output on the back. I don't know about the SDR. 

From: nickrestivo@cornictech.com
Sent: January 27, 2022 2:34 PM
To: discuss-gnuradio@gnu.org
Subject: Signal Capture and Playback Noise

Hi GNU Radio users,

 

I am experiencing some interesting noise captured on a signal analyzer when trying to playback a captured signal using an Ettus B200 with both GNU Radio blocks and UHD example code. The UHD example code I am using is:

  • "rx_samples_to_file --rate 5000000 --freq 500000000" for capture
  • "tx_samples_from_file --rate 5000000 --freq 500000000 --file /home/path/usrp_samples.dat --gain 30" for playback

The GNU Radio blocks I am using are simply a USRP Source into File Sink for capture and a File Source into USRP Sink for playback (both programs operating at a 10M sample rate).

 

The signal I am capturing is a 500MHz pure sine wave fed directly out of a signal generator into the TX/RX port of the B200. The playback with noise I am receiving is directly out of the B200 TX/RX port into a signal analyzer and is pictured here:

 

 

Is this peak 1kHz from the carrier expected? Could this be the LO or some other noise on the board leaking through due to a lack of filtering? Is this re-creatable on other hardware? I can send the captured data if there isn't an obvious answer to why there is a signal at 499.999MHz.

 

Another piece to the puzzle I feel like I should mention is that when running "tx_waveforms –rate 10000000 –freq 500000000" and feed it directly into signal analyzer the output is only a peak at 499.999MHz…

 

Is this offset within tolerance of B200 hardware, or is there a bigger issue happening here?

 

Thanks in advance for any help,

Nick Restivo

 

Re: Signal Capture and Playback Noise

On 2022-01-27 17:30, nickrestivo@cornictech.com wrote:

Hi GNU Radio users,

 

I am experiencing some interesting noise captured on a signal analyzer when trying to playback a captured signal using an Ettus B200 with both GNU Radio blocks and UHD example code. The UHD example code I am using is:

  • "rx_samples_to_file --rate 5000000 --freq 500000000" for capture
  • "tx_samples_from_file --rate 5000000 --freq 500000000 --file /home/path/usrp_samples.dat --gain 30" for playback

The GNU Radio blocks I am using are simply a USRP Source into File Sink for capture and a File Source into USRP Sink for playback (both programs operating at a 10M sample rate).

 

The signal I am capturing is a 500MHz pure sine wave fed directly out of a signal generator into the TX/RX port of the B200. The playback with noise I am receiving is directly out of the B200 TX/RX port into a signal analyzer and is pictured here:

 

 

Is this peak 1kHz from the carrier expected? Could this be the LO or some other noise on the board leaking through due to a lack of filtering? Is this re-creatable on other hardware? I can send the captured data if there isn't an obvious answer to why there is a signal at 499.999MHz.

 

Another piece to the puzzle I feel like I should mention is that when running "tx_waveforms –rate 10000000 –freq 500000000" and feed it directly into signal analyzer the output is only a peak at 499.999MHz…

 

Is this offset within tolerance of B200 hardware, or is there a bigger issue happening here?

 

Thanks in advance for any help,

Nick Restivo

 

Working backwards here, an offset of 1kHz in 500MHz is about 2PPM, which is easily within the bounds of what is to be expected from a device with
  a 2.5PPM master oscillator.  Don't know what the specs are of your analyser, either.

What amplitude level are you feeding into the B200 from your signal generator?  Anything significantly higher than what you'd expect from an
  antenna can lead to non-linearities.

If you take your capture file, and "play" it in a Gnu Radio flow-graph, do you see the spectral artifacts or not?


Signal Capture and Playback Noise

Hi GNU Radio users,

 

I am experiencing some interesting noise captured on a signal analyzer when trying to playback a captured signal using an Ettus B200 with both GNU Radio blocks and UHD example code. The UHD example code I am using is:

  • “rx_samples_to_file --rate 5000000 --freq 500000000” for capture
  • “tx_samples_from_file --rate 5000000 --freq 500000000 --file /home/path/usrp_samples.dat --gain 30” for playback

The GNU Radio blocks I am using are simply a USRP Source into File Sink for capture and a File Source into USRP Sink for playback (both programs operating at a 10M sample rate).

 

The signal I am capturing is a 500MHz pure sine wave fed directly out of a signal generator into the TX/RX port of the B200. The playback with noise I am receiving is directly out of the B200 TX/RX port into a signal analyzer and is pictured here:

 

 

Is this peak 1kHz from the carrier expected? Could this be the LO or some other noise on the board leaking through due to a lack of filtering? Is this re-creatable on other hardware? I can send the captured data if there isn’t an obvious answer to why there is a signal at 499.999MHz.

 

Another piece to the puzzle I feel like I should mention is that when running “tx_waveforms –rate 10000000 –freq 500000000” and feed it directly into signal analyzer the output is only a peak at 499.999MHz…

 

Is this offset within tolerance of B200 hardware, or is there a bigger issue happening here?

 

Thanks in advance for any help,

Nick Restivo

 

Closing: GNU Radio 3.9.3.0 Python basic block - issues with, forecast and produce

Hello Johannes and hello Marcus,

thank you both for the suggestions and explanations, it really helps a
lot and is much appreciated!
With your explanations, I was able to produce my minimal working
example, which I have linked below.

> The best place to check for specifics about Python blocks is here:
> https://github.com/gnuradio/gnuradio/blob/main/gnuradio-runtime/python/gnuradio/gr/gateway.py
>
> This is the interface that is implemented. The `forecast` method is
> implemented in L153ff. It is different from the C++ version.
Thanks for this hint, I've taken a look at the implementation. Also
thanks for the suggestion with `bpython3` it is a really nice tool. For
now my block works without the `forecast` method so I won't bother
implementing it for now. I think it makes more sense to implement
`forecast` if I should decide to work with a C++ block.


> The mechanism is that the scheduler asks forecast what it needs to produce the largest
> amount of output that the output buffer can deal with, then it halves the amount until it
> hits the minimum number. If none of these requests yield a fulfillable input requirement,
> the block is permanently input-blocked.
Also thanks for clearing this up and explaining it Marcus!


> First off, the `consume_each` call needs to go behind any read on the
> input buffer. You really tell the system at this point: I'm finally done
> with these items, do whatever. Since GR is a multi-threaded system, this
> may cause trouble because the samples you want to read are already
> overwritten.
>
>
> So let's comment on your `general_work`.
>
> > def general_work(self, input_items, output_items):
> > # Firstly check, if input_items has a sufficient amount of items
> > if len(input_items[0]) >= self.buffer_len:
> > # Then consume exactly self.buffer_len items
> > self.consume_each(self.buffer_len)
> `consume_each` should go after the last use of `input_items`.
The comment, together with your explanation makes perfect sense, I have
changed it accordingly.


> > # Now only output a fraction of the input items, say the first
> > self.out_items, on output port[0]
> > output_items[0] = input_items[0][:self.out_items]
> This is probably the line causing issues. Try
> `output_items[0][0:self.out_items] = input_items[0][0:self.out_items]`
> The difference is the left hand indexing. Now, you write items to
> positions in an array. Previously, you overwrote the array and replaced
> it with a new one. Thus, the output buffer was still full of zeros.

Changing this line was the last missing piece, the minimal example now
works! I have posted my working minimal example here:
https://pastebin.com/qxgnPcpL


And with that I would like to close this problem, thanks again for the
feedback!


Kind regards,
Patric

Wednesday, January 26, 2022

Re: How to model class-B distortion of a complex signal

I think perhaps reversing the phase (when negative) and adding/subtracting it from the original (equivalent of rail) might create a class-B type distortion perhaps?

Documented my experiments with a grc flowgraph and video..

Thoughts?


2 grc files are hierarchical blocks and one is the actual flowgraph

On Wed, Jan 26, 2022 at 2:31 AM Anish Mangal <anishmg@umich.edu> wrote:
Hi. Yes. I am just looking at modeling a class-B distortion at the moment, but could someone guide on how to convert between quadrature signals and real signals. Because the rail (or the other one I was trying .. abs, only work on real signals)

The simple example im trying to shoot for is create a wbfm waveform, "clip/distort" it, and demodulate it and see the noise in the spectrum.

Thanks for the replies!! :)

On Wed, Jan 26, 2022 at 1:55 AM Nick Foster <bistromath@gmail.com> wrote:
Anish,

If you really just want to model crossover distortion in a class-B amplifier, you could use a pair of Rail blocks:


If you're trying to model the distortion created by a real solid-state amplifier, and not trying to correct it with predistortion, there are a million different models which attempt to accurately characterize distortion in SSPAs: Rapp, Saleh, and Ghorbani seem to be most widely used. They're all pretty simple.

Here's a very simple, memoryless model (Ghorbani) implemented as an embedded Python block:

Some basic information about the model can be found here:

Nick

On Tue, Jan 25, 2022 at 12:03 PM Wheberth Damascena Dias <wheberth@gmail.com> wrote:
Hello Anish,

Non-linear  power amplifier modeling and pre-distortion is a vast subject.

If you want to go deep in this matter I would suggest you to take a look at Baseband polinomial models.
 Here a reference I have used some time ago:

If you just need something quick, you may want to lookout for AM/PM models, such as the Saleh model.

Good luck!

Best Regards
Wheberth Dias




On Tue, Jan 25, 2022, 20:44 Anish Mangal <anishmg@umich.edu> wrote:
Hi,

How should I go about modeling the distortion introduced by a class-B amplifier stage that clips the signal when its value is below zero?

Example:

I want to combine two FM modulated signals, pass them through this "class-B distorter", demodulate them, and analyze the quality of the signal produced (compared with the undistorted one).

How should I go about doing it.

Created the flowgraph attached, but this is obviously wrong. :)

--
Anish






--
Anish





--
Anish



Re: Output Issue in example_corr_est_and_clock_sync.grc

Hi Mubashira,

I have created https://github.com/gnuradio/gnuradio/issues/5528 (Some gr-digital/examples/packet do not produce expected tags) to address your problem. I think that if you change the trigger to 'Auto' on those two QT GUI Time Sinks, you will see the data (but no tags).

You can track the progress on that issue by clicking the link above.

The decision to "backport" a fix to older versions is made by the maintainers. However, note that version 3.7 is no longer being maintained.

Be safe,
---
Barry Duggan KV4FV

P.S. When replying to an email from the newsletter, please Cc discuss-gnuradio@gnu.org



---- On Tue, 25 Jan 2022 23:38:09 -0600 Mobi Zaman <mobizmn@yahoo.com> wrote ----


Hi Barry,

I was actually following the Packet Communications tutorial, when I came across those example flowgraphs.

Are the older GNU Radio actually being worked on now? Or are the bugs/issues in them just being fixed in the more recent versions?

Regards,
Mubashira Zaman

On Wednesday, January 26, 2022, 12:30:29 AM GMT+5, Barry Duggan <barry@dcsmail.net> wrote:


Hi Mubashira,

When I was writing the https://wiki.gnuradio.org/index.php?title=Packet_Communications tutorial, I remember having some problems with the gr-digital/packet examples. If you haven't already done so, you might like to look at that tutorial.

I don't have my GR 3.8 computer up right now, but when I get back to it, I will look into those examples again.

Best wishes,
---
Barry Duggan KV4FV

On Tue, 25 Jan 2022 06:51:56 +0000 (UTC), Mobi Zaman wrote:

Hi,
I am trying to run this flowgraph in gr-digital/packet examples on GNU Radio 3.8. When I run the flowgraph, the output shows a flat line (amplitude is a constant zero).
I do not have enough understanding of these blocks yet to determine what is the problem here.
Can anyone please mention how the output can be corrected?
Regards,Mubashira Zaman




Re: Problems with the Frequency Xlating FIR Filter

Also, after running python3, you'll likely need to run

from gnuradio.filter import firdes

before running the firdes.low_pass(... instruction.

El 26/1/22 a las 15:27, Marcus Müller escribió:
> Hi Michelle,
>
> https://en.wikipedia.org/wiki/REPL : What Martin means is simply the
> Python language shell you get when you run `python3` in a console.
>
> Best regards,
> Marcus
>
> On 26.01.22 14:24, Michelle wrote:
>> Good morning Martin,
>>
>> please can you explain to me what you mean by REPL?
>>
>> Thank you have a good day
>>
>> On 2022-01-25 05:04, Martin Braun wrote:
>>> Can you try running this in a REPL to see what the return value of
>>> firdes.lowpass(...) is?
>>>
>>> --M
>>>
>>> On Tue, Jan 25, 2022 at 2:03 AM Michelle <mkprojects731@gmail.com>
>>> wrote:
>>>
>>>     hello,
>>>
>>>     I'm using a FIR filter and I have the error : "Param - Taps(taps):
>>>     Expression None is invalid for type'complex_vector'."
>>>
>>>     my taps is : firdes.low_pass ( 1, samp_rate, frec_carrier,
>>>     25000,firdes.WIN_HAMMING )
>>>
>>>     samp_rate and  frec_carrier are both variables in my graph.
>>>
>>>     I don't understand why I have an error. Please could you tell me
>>> what I
>>>     am doing wrong?
>>>
>>>
>>>     Thank you.
>>>

Re: Problems with the Frequency Xlating FIR Filter

Hi Michelle,

https://en.wikipedia.org/wiki/REPL : What Martin means is simply the Python language shell
you get when you run `python3` in a console.

Best regards,
Marcus

On 26.01.22 14:24, Michelle wrote:
> Good morning Martin,
>
> please can you explain to me what you mean by REPL?
>
> Thank you have a good day
>
> On 2022-01-25 05:04, Martin Braun wrote:
>> Can you try running this in a REPL to see what the return value of firdes.lowpass(...) is?
>>
>> --M
>>
>> On Tue, Jan 25, 2022 at 2:03 AM Michelle <mkprojects731@gmail.com> wrote:
>>
>> hello,
>>
>> I'm using a FIR filter and I have the error : "Param - Taps(taps):
>> Expression None is invalid for type'complex_vector'."
>>
>> my taps is : firdes.low_pass ( 1, samp_rate, frec_carrier,
>> 25000,firdes.WIN_HAMMING )
>>
>> samp_rate and  frec_carrier are both variables in my graph.
>>
>> I don't understand why I have an error. Please could you tell me what I
>> am doing wrong?
>>
>>
>> Thank you.
>>