Re: Why is OFDM_loopback slow with Random Source

Thanks for biting, I actually had a lot of luck getting it to run a bit faster but it seems to perform quite badly on the B205 and X310, as timing still was an issue. I have since moved into a much simpler design as I am not in the field of signal processing. I hope you have a good day!

On Sun, Mar 27, 2022 at 5:11 PM Cinaed Simson <cinaed.simson@gmail.com> wrote:

On 3/23/22 13:10, Taylor Clark wrote:
> Good evening,
> I have been doing some work with packet modulation and I ran
> across the OFDM_Loopback.grc file. I initially did some test with my
> ZMQ Server and the data rate was terrible. Thinking it was my
> datasource, I did some other test until I decided to use GNU Radios
> random Source block as an input. To my surprise, it was just as slow
> and I really can't figure out why. My CPU isnt terrible, is this
> GNURADIOS internal data processing at work or am I not understanding
> how it was meant to be used?
>
> Any feedback would be greatly appreciated!
>
> Respectfully,
> Taylor Clark

Okay, I'll bite.

Please post the GRC file you're currently running - not the one you
downloaded -  the devil is in the details.

Please post the version of your the gnuradio and the OS - and model of
the machine since you suspect it might be a problem.

-- Cinaed

Re: Conda package for gr-sdrplay3 OOT module for Windows

Hi Franco,

This is great! You're right that I don't think there's any way to get this on conda-forge, but I'd be happy to include it in radioconda (with the proprietary bits still needing external installation) if we can figure out a good way.

The easiest thing to do would be to create an account at anaconda.org and upload any packages you build there. Then people could install them with conda through the command line by specifying your channel. If you put the instructions for manually copying the proprietary DLL into the package description in the recipe, then it will also be shown on its anaconda.org page and we'll have something to refer people to for instructions.

Beyond that, I think the next best thing is to make your recipe publicly accessible. Then anyone should be able to build the package themselves if they have the SDDplay sources installed already. Best would probably be to incorporate it into the gr-sdrplay3 repository like I've tried out here in my fork of gr-paint:

https://github.com/ryanvolz/gr-paint/tree/conda/.conda

The next best thing would be to just publish the recipe in its own repository; no need for it to be a conda-forge-style "feedstock" since automatic builds will be impossible.

Then if there is a set of built packages somewhere that I can pull in via "conda install", I can add gr-sdrplay3 to radioconda and point people to the manual instructions for getting it working.

Cheers,
Ryan

On 3/30/22 9:40 PM, Franco VENTURI wrote:
> Good news - with Ryan's help a few days ago I was able to create a recipe and a conda package for the gr-sdrplay3 OOT module for Windows.
>
> For those not familiar with it, the gr-sdrplay3 OOT module adds support for the SDRplay RSP devices as native GNU Radio sources, using directly the SDRplay APIs (i.e. without going through SoapySDR).
> Up to now it was only available on Linux (and probably Mac), but with this conda package it is possible to run it on Windows (it requires the most current GNU Radio installation using conda - see here: https://wiki.gnuradio.org/index.php/CondaInstall <https://wiki.gnuradio.org/index.php/CondaInstall>).
>
> For those interested in trying it out, this is the link to the conda package on my Google Drive: https://drive.google.com/file/d/1ZTUeYyOpms0rx7yU2Q5fOqElKIKgyJwK/view?usp=sharing <https://drive.google.com/file/d/1ZTUeYyOpms0rx7yU2Q5fOqElKIKgyJwK/view?usp=sharing> (the conda recipe is in the package).
>
> One important notice - conda's Python on Windows loads any dependent DLL from a limited set of folders (i.e. it does not use the %PATH% environment variable to search for dependent DLLs, as I think most of the other Windows applications do).
> This means that the proprietary DLL for the SDRplay API 'sdrplay_api.dll' (which is typically installed under 'C:\Program Files\SDRplay\API\x64\') needs to be copied to one of these folders for things to work:
>
> - %CONDA_PREFIX%\Lib\site-packages\gnuradio\sdrplay3
> - %CONDA_PREFIX%
> - %CONDA_PREFIX%\Library\mingw-w64\bin
> - %CONDA_PREFIX%\Library\bin
> - %CONDA_PREFIX%\Scripts
> - C:\Windows\System32
>
> Alternatively setting the environment variable CONDA_DLL_SEARCH_MODIFICATION_ENABLE to '1' makes conda Python look into all the folders listed in %PATH%, and it should work too.
>
> If conda Python is not able to find the 'sdrplay_api.dll' file, it will throw an 'ImportError' exception for the line 'from gnuradio import sdrplay3'.
>
> I am not sure of the best way to distribute this package after this initial 'beta' version, since it is not straightforward to build it automatically on conda-forge because of its dependence on SDRplay proprietary DLL and include files.
> I am open to ideas and suggestions on how to find a good long-term solution (also, if this is not the best forum to discuss this specific conda related topic, please let me know, and we can continue this conversation elsewhere).
>
> Franco

CtrlPort Monitor / Performance Monitor Runtime Failure in 3.11

Hello,

My team is running into an issue when trying to utilize the CtrlPort Monitor or Performance Monitor in our flowgraph.  This issue arose after updating GNURadio to 3.11.

1. We are running GNURadio 3.11, installed from source, on Ubuntu 20.04.3 LTS.  The CPU is a i7-7700. After some initial debugging, we noticed that Apache Thrift was closely tied to the Control Port, and we are running Thrift 0.13.

2. The errors arise when the CtrlPort Monitor or Performance Monitor are enabled, and I run any simple flowgraph where CtrlPort Monitor or Performance monitor are enabled.  Initially, we received an invalid pointer error shown in the error message here:

https://drive.google.com/file/d/1mITUMdVtjpcci6kZYyT2O2Q6RMy0WSa1/view?usp=sharing

But after commenting out the block of code in the ctrl denoted by the red arrow 1, the invalid pointer error goes away.  The snippet is from: 

gnuradio/gnuradio-runtime/python/gnuradio/ctrlport/monitory.py

https://drive.google.com/file/d/1FhAF9lnnXuOmgmURuQ-FDLPPFK_xDfj7/view?usp=sharing

However, we are now prompted with "Initiate try" followed by the error thrown in arrow 2 under the exception in the above screenshot. 

3. We have tried uninstalling and reinstalling GNURadio on two separate machines (with identical specifications) and continue to run into the same issue.  We have also reinstalled Thrift, but the issue still hasn't been resolved.

4. There is a relatively small amount of related issues found in our research, but there are a few issues such as #292, #2739 (further thrift investigation), and #3673 (the seemingly closest related issue) on the GNURadio GitHub (links below).  However, they involve older versions of GNURadio and do not help with 3.11.  Any help would be greatly appreciated! Thank you so much!

Best,
Miles

Issue Links:

#292: https://github.com/bastibl/gr-ieee802-11/issues/292

#2739: https://github.com/gnuradio/gnuradio/pull/2739

#3673: https://github.com/gnuradio/gnuradio/issues/3673

Conda package for gr-sdrplay3 OOT module for Windows

Good news - with Ryan's help a few days ago I was able to create a recipe and a conda package for the gr-sdrplay3 OOT module for Windows.

For those not familiar with it, the gr-sdrplay3 OOT module adds support for the SDRplay RSP devices as native GNU Radio sources, using directly the SDRplay APIs (i.e. without going through SoapySDR).

Up to now it was only available on Linux (and probably Mac), but with this conda package it is possible to run it on Windows (it requires the most current GNU Radio installation using conda - see here: https://wiki.gnuradio.org/index.php/CondaInstall).

For those interested in trying it out, this is the link to the conda package on my Google Drive: https://drive.google.com/file/d/1ZTUeYyOpms0rx7yU2Q5fOqElKIKgyJwK/view?usp=sharing (the conda recipe is in the package).

One important notice - conda's Python on Windows loads any dependent DLL from a limited set of folders (i.e. it does not use the %PATH% environment variable to search for dependent DLLs, as I think most of the other Windows applications do).

This means that the proprietary DLL for the SDRplay API 'sdrplay_api.dll' (which is typically installed under 'C:\Program Files\SDRplay\API\x64\') needs to be copied to one of these folders for things to work:

- %CONDA_PREFIX%\Lib\site-packages\gnuradio\sdrplay3
- %CONDA_PREFIX%
- %CONDA_PREFIX%\Library\mingw-w64\bin
- %CONDA_PREFIX%\Library\bin
- %CONDA_PREFIX%\Scripts
- C:\Windows\System32

Alternatively setting the environment variable CONDA_DLL_SEARCH_MODIFICATION_ENABLE to '1' makes conda Python look into all the folders listed in %PATH%, and it should work too.

If conda Python is not able to find the 'sdrplay_api.dll' file, it will throw an 'ImportError' exception for the line 'from gnuradio import sdrplay3'.

I am not sure of the best way to distribute this package after this initial 'beta' version, since it is not straightforward to build it automatically on conda-forge because of its dependence on SDRplay proprietary DLL and include files.

I am open to ideas and suggestions on how to find a good long-term solution (also, if this is not the best forum to discuss this specific conda related topic, please let me know, and we can continue this conversation elsewhere).

Franco

Re: Removing Python Bindings from 3.9 OOT

I figured you'd be asking that's why I am working on it. idk if I can access IRC from the office. Time to check!

- Brandon Smith

On Wed, Mar 30, 2022 at 11:52 AM Jim Melton <jim.melton@sncorp.com> wrote:

As you have probably figured out by now, I don't have experience with GRC. Your best answer will be to ask in the Matrix channel (or IRC if you are old-school).

 

I'm guessing your question is related to the change in how the Python bindings are done? I think that was 3.9 and not 3.10…

 

In the next few months I'm looking to upgrade my GNU Radio version, so I'm glad you are on top of this :P

 

 

---

Jim Melton

Sr Principal Software Engineer

Sierra Nevada Corporation

303.566.9582 (o) | 303.862.2459 (m)

jim.melton@sncorp.com | sncorp.com

 

 

From: Discuss-gnuradio <discuss-gnuradio-bounces+jim.melton=sncorp.com@gnu.org> On Behalf Of Brandon Smith
Sent: Wednesday, March 30, 2022 07:26
To: discuss-gnuradio@gnu.org
Subject: [EXTERNAL] Removing Python Bindings from 3.9 OOT

 

Hello,

 

I am porting our GNURadio OOT from 3.8 to 3.9, and I have a block that we utilize only in C++ and do not expose in GRC/Python. What would be the correct method for removing it from the pybind process? I am hesitant to start removing it from the new bindings dir for fear of breaking the build. but from what I can gather:
1. remove block_python.cc
2. Remove block_python.cc from bindings/CMakeLists.txt
3. Remove mentions from python_bindings.cc

 

Any other tips?

 

Thank you!

 

- Brandon Smith

CONFIDENTIALITY NOTICE - SNC EMAIL: This email and any attachments are confidential, may contain proprietary, protected, or export controlled information, and are intended for the use of the intended recipients only. Any review, reliance, distribution, disclosure, or forwarding of this email and/or attachments outside of Sierra Nevada Corporation (SNC) without express written approval of the sender, except to the extent required to further properly approved SNC business purposes, is strictly prohibited. If you are not the intended recipient of this email, please notify the sender immediately, and delete all copies without reading, printing, or saving in any manner. --- Thank You.

Finding the GPS seconds time from GPSDO

Hello

I'm Isaac. As it is said in this web: https://files.ettus.com/manual/page_gpsdo.html , get_mboard_sensor("gps_time") gives us the seconds since January 1, 1970 (so UTC seconds).

What I'm looking for is that GNU Radio gives me the GPS seconds directly (GPS time is ahead 18 seconds from UTC). Is there a method that gives us the GPS seconds?

Regards

Isaac T.

RE: Removing Python Bindings from 3.9 OOT

As you have probably figured out by now, I don't have experience with GRC. Your best answer will be to ask in the Matrix channel (or IRC if you are old-school).

 

I'm guessing your question is related to the change in how the Python bindings are done? I think that was 3.9 and not 3.10…

 

In the next few months I'm looking to upgrade my GNU Radio version, so I'm glad you are on top of this :P

 

 

---

Jim Melton

Sr Principal Software Engineer

Sierra Nevada Corporation

303.566.9582 (o) | 303.862.2459 (m)

jim.melton@sncorp.com | sncorp.com

 

 

From: Discuss-gnuradio <discuss-gnuradio-bounces+jim.melton=sncorp.com@gnu.org> On Behalf Of Brandon Smith
Sent: Wednesday, March 30, 2022 07:26
To: discuss-gnuradio@gnu.org
Subject: [EXTERNAL] Removing Python Bindings from 3.9 OOT

 

Hello,

 

I am porting our GNURadio OOT from 3.8 to 3.9, and I have a block that we utilize only in C++ and do not expose in GRC/Python. What would be the correct method for removing it from the pybind process? I am hesitant to start removing it from the new bindings dir for fear of breaking the build. but from what I can gather:
1. remove block_python.cc
2. Remove block_python.cc from bindings/CMakeLists.txt
3. Remove mentions from python_bindings.cc

 

Any other tips?

 

Thank you!

 

- Brandon Smith

CONFIDENTIALITY NOTICE - SNC EMAIL: This email and any attachments are confidential, may contain proprietary, protected, or export controlled information, and are intended for the use of the intended recipients only. Any review, reliance, distribution, disclosure, or forwarding of this email and/or attachments outside of Sierra Nevada Corporation (SNC) without express written approval of the sender, except to the extent required to further properly approved SNC business purposes, is strictly prohibited. If you are not the intended recipient of this email, please notify the sender immediately, and delete all copies without reading, printing, or saving in any manner. --- Thank You.

Removing Python Bindings from 3.9 OOT

Hello,

I am porting our GNURadio OOT from 3.8 to 3.9, and I have a block that we utilize only in C++ and do not expose in GRC/Python. What would be the correct method for removing it from the pybind process? I am hesitant to start removing it from the new bindings dir for fear of breaking the build. but from what I can gather:
1. remove block_python.cc
2. Remove block_python.cc from bindings/CMakeLists.txt
3. Remove mentions from python_bindings.cc

Any other tips?

Thank you!

- Brandon Smith

Re: First tutorial

Hi Alexander,

that is obviously a "problem" in gnu radio ;)
It depends on the window chosen and if it is normalized or not. The
problem with the window functions in an FFT is, that you spread the
power of the signal over multiple bins (which also happens when you have
spectral leakage). You can either normalize the window so that the peak
power will be correct (what you would like to see) or that the total
mount of power/energy in the complete spectrum is preserved (what gnu
radio is probably doing).
You can choose a rectangular window, make the fft length an exact
multiple of the signal period and you will get a perfect peak at a
single bin with the correct amplitude. But rectangular windows suffer
from a lot of spectral leakage.

Best,
Fabian

PS: Please always (also) respond to the mailing list, so that others can
find the discussion as well :)

Am 30.03.22 um 09:47 schrieb Alexander Plotnikov:
> Greetings Fabian!
>
> Thank you very much for your response.
> I was talking about the main harmonic - the one I am generating with sin
> source.
> I have attached a screen to be more exact.
>
> What I am expecting is to get the spectrum of a pure sin with the Qt
> Freq Sink,
> For now the problem seems to be due to Qt Freq Sink small number of FFT
> points.
>
> Maybe you can advice me with any other Gui spectrum block? As you have
> probably noticed - I am very new to GNU Radio.
>
> Thanks in advance,
>
> Alexander
>
> On 30.03.2022 10:19, Fabian Schwartau wrote:
>> Hi Alexander,
>>
>> I see exactly what is shown in the tutorial and I don't see any
>> harmonics. There are a two "shoulders" left and right to the signal,
>> which are caused by the window function, which is applied by the
>> Frequency sink to reduce spectral leakage. When I increase the lower
>> boundary of the Frequency sink I can also see a lot of "noise" around
>> -180dB, which is caused by numerical instability. Everything as
>> expected... or did I get your question wrong?
>>
>> Best,
>> Fabian
>>
>> Am 30.03.22 um 08:19 schrieb Alexander Plotnikov:
>>> Greetings everyone!
>>>
>>> Can anybody please explain to me why in this example
>>> (https://wiki.gnuradio.org/index.php?title=Your_First_Flowgraph) the
>>> spectrum graph shows a harmonic far below 0dB?
>>>
>>> Thanks everyone in advance!
>>> Alexander
>>>
>>>
>>
>>

Re: First tutorial

Hi Alexander,

I see exactly what is shown in the tutorial and I don't see any
harmonics. There are a two "shoulders" left and right to the signal,
which are caused by the window function, which is applied by the
Frequency sink to reduce spectral leakage. When I increase the lower
boundary of the Frequency sink I can also see a lot of "noise" around
-180dB, which is caused by numerical instability. Everything as
expected... or did I get your question wrong?

Best,
Fabian

Am 30.03.22 um 08:19 schrieb Alexander Plotnikov:
> Greetings everyone!
>
> Can anybody please explain to me why in this example
> (https://wiki.gnuradio.org/index.php?title=Your_First_Flowgraph) the
> spectrum graph shows a harmonic far below 0dB?
>
> Thanks everyone in advance!
> Alexander
>
>

First tutorial

Greetings everyone!

Can anybody please explain to me why in this example
(https://wiki.gnuradio.org/index.php?title=Your_First_Flowgraph) the
spectrum graph shows a harmonic far below 0dB?

Thanks everyone in advance!
Alexander

Waterfall sink does not have 'Control panel' in the 'Config' tab

Hi

The problem is that waterfall sink does not have the option 'Control panel' in the 'Config' tab.

One should be able to toggle the control panel on and off.

The control panel can be seen e.g. in the figure at

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

This problem is similar to

https://stackoverflow.com/questions/69413916/how-to-expose-the-control-panel-of-the-qt-gui-time-sink

I have Ubuntu 20.04.4 LTS and GRC 3.8.1.0 (Python 3.8.10)

cheers, Kimmo

Re: Help on

"Any sufficiently advanced technology is indistinguishable from magic." 

— A. C. Clarke

@(^.^)@ Ed

Sent from my iPhone

On Mar 28, 2022, at 9:25 AM, Robert McGwier <rwmcgwier@gmail.com> wrote:



GnuRadio is so good it can even do magic.  🤓

On Mon, Mar 28, 2022, 2:01 AM Lorenzo Mainardi <lormayna@gmail.com> wrote:

As last resource I tried to update the libraries and the problem is magically solved.

Thank you everyone for the support. 

Il dom 27 mar 2022, 18:46 Lorenzo Mainardi <lormayna@gmail.com> ha scritto:

Hello everyone, I am trying to make a cheap USB dongle working with
gnuradio and gnuradio-companion.
I just tried to use a source block and link to a waterfall sink.
This is the error that I got:

<<< Welcome to GNU Radio Companion 3.10.1.1 >>>

Block paths:
/usr/share/gnuradio/grc/blocks

Loading: "/home/lorenzo/Scaricati/fm_demod_mono.grc"
>>> Converting from XML
>>> Done

Generating: '/home/lorenzo/Scaricati/top_block.py'

Executing: /usr/bin/python3 -u /home/lorenzo/Scaricati/top_block.py

gr-osmosdr 0.2.0.0 (0.2.0) gnuradio 3.10.0.0
built-in source types: file fcd rtl rtl_tcp uhd hackrf bladerf rfspace
airspy airspyhf soapy redpitaya freesrp
Using device #0 Realtek RTL2838UHIDIR SN: 00000001
Found Rafael Micro R820T tuner
[R82XX] PLL not locked!
[R82XX] PLL not locked!

>>> Done (return code -11)

What does this mean? How can solve this problem?
The dongle is working fine with SDRSharp or rtl_fm.

Thank you

--
LORENZO MAINARDI

Re: Help on

GnuRadio is so good it can even do magic.  🤓

On Mon, Mar 28, 2022, 2:01 AM Lorenzo Mainardi <lormayna@gmail.com> wrote:

As last resource I tried to update the libraries and the problem is magically solved.

Thank you everyone for the support. 

Il dom 27 mar 2022, 18:46 Lorenzo Mainardi <lormayna@gmail.com> ha scritto:

Hello everyone, I am trying to make a cheap USB dongle working with
gnuradio and gnuradio-companion.
I just tried to use a source block and link to a waterfall sink.
This is the error that I got:

<<< Welcome to GNU Radio Companion 3.10.1.1 >>>

Block paths:
/usr/share/gnuradio/grc/blocks

Loading: "/home/lorenzo/Scaricati/fm_demod_mono.grc"
>>> Converting from XML
>>> Done

Generating: '/home/lorenzo/Scaricati/top_block.py'

Executing: /usr/bin/python3 -u /home/lorenzo/Scaricati/top_block.py

gr-osmosdr 0.2.0.0 (0.2.0) gnuradio 3.10.0.0
built-in source types: file fcd rtl rtl_tcp uhd hackrf bladerf rfspace
airspy airspyhf soapy redpitaya freesrp
Using device #0 Realtek RTL2838UHIDIR SN: 00000001
Found Rafael Micro R820T tuner
[R82XX] PLL not locked!
[R82XX] PLL not locked!

>>> Done (return code -11)

What does this mean? How can solve this problem?
The dongle is working fine with SDRSharp or rtl_fm.

Thank you

--
LORENZO MAINARDI

Re: Help on

On 2022-03-27 15:32, Marcus Müller wrote:
> Is 32k a supported sampling rate? Sounds two orders of magnitude too low.
The lowest RTL supported sampling rate is 250K, and then there's a jump
with no supported
  rates until something like 900K.

For a single WBFM channel, you need the 250K sampling rate.

The -11 error return is "LIBUSB_NO_MEM" coming from the within LIBUSB.

Not sure how to fix that, since I've never actually received that error.


>
> On 27.03.22 21:22, Lorenzo Mainardi wrote:
>> The error about PLL should be just "cosmetic" and not have any impact.
>> Anyway, I think I setup correctly both the correct frequency (I would
>> like to test the broadband FM, so 100e6) both the sampling frequency
>> (32k).
>> The real issue is the "Return code -11" error, I cannot find anything
>> about that.
>>
>> Il giorno dom 27 mar 2022 alle ore 18:52 Fabian Schwartau
>> <fabian@opencode.eu> ha scritto:
>>>
>>> Hi,
>>> did you set the correct frequency? If it is outside the allowed range,
>>> it is expected that the PLL cannot lock.
>>>
>>> Best,
>>> Fabian
>>>
>>> Am 27.03.22 um 18:46 schrieb Lorenzo Mainardi:
>>>> Hello everyone, I am trying to make a cheap USB dongle working with
>>>> gnuradio and gnuradio-companion.
>>>> I just tried to use a source block and link to a waterfall sink.
>>>> This is the error that I got:
>>>>
>>>> <<< Welcome to GNU Radio Companion 3.10.1.1 >>>
>>>>
>>>> Block paths:
>>>> /usr/share/gnuradio/grc/blocks
>>>>
>>>> Loading: "/home/lorenzo/Scaricati/fm_demod_mono.grc"
>>>>>>> Converting from XML
>>>>>>> Done
>>>>
>>>> Generating: '/home/lorenzo/Scaricati/top_block.py'
>>>>
>>>> Executing: /usr/bin/python3 -u /home/lorenzo/Scaricati/top_block.py
>>>>
>>>> gr-osmosdr 0.2.0.0 (0.2.0) gnuradio 3.10.0.0
>>>> built-in source types: file fcd rtl rtl_tcp uhd hackrf bladerf rfspace
>>>> airspy airspyhf soapy redpitaya freesrp
>>>> Using device #0 Realtek RTL2838UHIDIR SN: 00000001
>>>> Found Rafael Micro R820T tuner
>>>> [R82XX] PLL not locked!
>>>> [R82XX] PLL not locked!
>>>>
>>>>>>> Done (return code -11)
>>>>
>>>> What does this mean? How can solve this problem?
>>>> The dongle is working fine with SDRSharp or rtl_fm.
>>>>
>>>> Thank you
>>>>
>>>
>>>
>>
>>
>

Re: Help on

Is 32k a supported sampling rate? Sounds two orders of magnitude too low.

On 27.03.22 21:22, Lorenzo Mainardi wrote:
> The error about PLL should be just "cosmetic" and not have any impact.
> Anyway, I think I setup correctly both the correct frequency (I would
> like to test the broadband FM, so 100e6) both the sampling frequency
> (32k).
> The real issue is the "Return code -11" error, I cannot find anything
> about that.
>
> Il giorno dom 27 mar 2022 alle ore 18:52 Fabian Schwartau
> <fabian@opencode.eu> ha scritto:
>>
>> Hi,
>> did you set the correct frequency? If it is outside the allowed range,
>> it is expected that the PLL cannot lock.
>>
>> Best,
>> Fabian
>>
>> Am 27.03.22 um 18:46 schrieb Lorenzo Mainardi:
>>> Hello everyone, I am trying to make a cheap USB dongle working with
>>> gnuradio and gnuradio-companion.
>>> I just tried to use a source block and link to a waterfall sink.
>>> This is the error that I got:
>>>
>>> <<< Welcome to GNU Radio Companion 3.10.1.1 >>>
>>>
>>> Block paths:
>>> /usr/share/gnuradio/grc/blocks
>>>
>>> Loading: "/home/lorenzo/Scaricati/fm_demod_mono.grc"
>>>>>> Converting from XML
>>>>>> Done
>>>
>>> Generating: '/home/lorenzo/Scaricati/top_block.py'
>>>
>>> Executing: /usr/bin/python3 -u /home/lorenzo/Scaricati/top_block.py
>>>
>>> gr-osmosdr 0.2.0.0 (0.2.0) gnuradio 3.10.0.0
>>> built-in source types: file fcd rtl rtl_tcp uhd hackrf bladerf rfspace
>>> airspy airspyhf soapy redpitaya freesrp
>>> Using device #0 Realtek RTL2838UHIDIR SN: 00000001
>>> Found Rafael Micro R820T tuner
>>> [R82XX] PLL not locked!
>>> [R82XX] PLL not locked!
>>>
>>>>>> Done (return code -11)
>>>
>>> What does this mean? How can solve this problem?
>>> The dongle is working fine with SDRSharp or rtl_fm.
>>>
>>> Thank you
>>>
>>
>>
>
>

Re: Help on

The error about PLL should be just "cosmetic" and not have any impact.
Anyway, I think I setup correctly both the correct frequency (I would
like to test the broadband FM, so 100e6) both the sampling frequency
(32k).
The real issue is the "Return code -11" error, I cannot find anything
about that.

Il giorno dom 27 mar 2022 alle ore 18:52 Fabian Schwartau
<fabian@opencode.eu> ha scritto:
>
> Hi,
> did you set the correct frequency? If it is outside the allowed range,
> it is expected that the PLL cannot lock.
>
> Best,
> Fabian
>
> Am 27.03.22 um 18:46 schrieb Lorenzo Mainardi:
> > Hello everyone, I am trying to make a cheap USB dongle working with
> > gnuradio and gnuradio-companion.
> > I just tried to use a source block and link to a waterfall sink.
> > This is the error that I got:
> >
> > <<< Welcome to GNU Radio Companion 3.10.1.1 >>>
> >
> > Block paths:
> > /usr/share/gnuradio/grc/blocks
> >
> > Loading: "/home/lorenzo/Scaricati/fm_demod_mono.grc"
> >>>> Converting from XML
> >>>> Done
> >
> > Generating: '/home/lorenzo/Scaricati/top_block.py'
> >
> > Executing: /usr/bin/python3 -u /home/lorenzo/Scaricati/top_block.py
> >
> > gr-osmosdr 0.2.0.0 (0.2.0) gnuradio 3.10.0.0
> > built-in source types: file fcd rtl rtl_tcp uhd hackrf bladerf rfspace
> > airspy airspyhf soapy redpitaya freesrp
> > Using device #0 Realtek RTL2838UHIDIR SN: 00000001
> > Found Rafael Micro R820T tuner
> > [R82XX] PLL not locked!
> > [R82XX] PLL not locked!
> >
> >>>> Done (return code -11)
> >
> > What does this mean? How can solve this problem?
> > The dongle is working fine with SDRSharp or rtl_fm.
> >
> > Thank you
> >
>
>


--
LORENZO MAINARDI

Re: GNURadio 3.7.14.0 Building gr-video-sdl

Hi Mitja,

there's more going on here, gr-video-sdl has been part of GNU Radio for a long, long time.
Since at least GNU Radio 3.3, in fact; some 15, 16 years.

So, your version of 3.7 would definitely also include it, and you should not try to
backport a more modern version to it.

So, we need to solve your actual problem than you trying to backport gr-video-sdl from
3.7.14 to a different version of GNU Radio.

So, what *is* your current version of GNU Radio, where does it come from, why does it not
contain gr-video-sdl?

Note that as maintainers, we'll have a really hard time helping you with GNU Radio 3.7;
it's end-of-life, so most of us aren't even trying to build it on our machines.

You also seem to be mixing PothosSDR stuff with GNU Radio includes, and I don't know
whether that is just meaningless paths or whether you're actually confusinge something?

Best regards,
Marcus

PS: Others might have told you that already, but it might really be worth pointing out
that living in the 3.7 world might be increasingly hard, and we're sorry about that, but
it's just technologically mostly obsolescence why we're not able to support it anymore.
Instead of sticking to 3.7 due to "some legacy blocks" it might be worth to forward-port
these missing blocks to GNU Radio 3.10 or 3.9, and work with a modern version of GNU Radio
– honestly, GNU Radio has gotten *a lot* better to install under practically all operating
systems in later versions.


On 27.03.22 17:32, Mitja kocjančič wrote:
> Hello there, for few reasons I am still using GNURadio 3.7 which doesn't come buindled
> with gr-video-sdl (at least the installation I am using doesn't) (I know 3.9 comes with it
> but right now I have some legacy blocks that are not uvailable for 3.9 so I am stuck using
> 3.7)
>
> So I tried building gr-video-sdl separatly, and then installing it into existing gnuradio
> distribution like this:
>
> 1. Downloaded GNURadio 3.7.10:
> https://github.com/gnuradio/gnuradio/releases/download/v3.7.14.0/gnuradio-3.7.14.0.tar.gz
> <https://github.com/gnuradio/gnuradio/releases/download/v3.7.14.0/gnuradio-3.7.14.0.tar.gz>
>     * extraxted gr-video-sdl
> 2. Installed SDL1.2 from here:
> http://web.archive.org/web/20191227232250if_/http://libsdl.org/release/SDL-devel-1.2.15-VC.zip
> <http://web.archive.org/web/20191227232250if_/http://libsdl.org/release/SDL-devel-1.2.15-VC.zip>
> (since gr-video-sdl uses SDL1.2 not SDL2 I assume)
> 3. trying to cmake like this: cmake ../ -DSDL_LIBRARY="C:\Program
> Files\PothosSDR\libsdl\lib\x64" -DSDL_INCLUDE_DIR="C:\Program Files\PothosSDR\libsdl\include"
>
> I copied sdl include and lib files to this place
>
> but I get some errors: https://pastebin.com/1RjmG1zj <https://pastebin.com/1RjmG1zj>
>
> It aphears GrBoost and GrComponent are missing and there is some unknown command: Unknown
> CMake command "GR_REGISTER_COMPONENT".
>
> Now I think GrBoost is boost but I am not sure, cmake doesn't tell me that Boost is
> missing, but what is GrComponent (what include and lib prefix do I need to set to include
> this?)
>
> Thanks for Anwsering and Best Regards

Re: Help on

Hi,
did you set the correct frequency? If it is outside the allowed range,
it is expected that the PLL cannot lock.

Best,
Fabian

Am 27.03.22 um 18:46 schrieb Lorenzo Mainardi:
> Hello everyone, I am trying to make a cheap USB dongle working with
> gnuradio and gnuradio-companion.
> I just tried to use a source block and link to a waterfall sink.
> This is the error that I got:
>
> <<< Welcome to GNU Radio Companion 3.10.1.1 >>>
>
> Block paths:
> /usr/share/gnuradio/grc/blocks
>
> Loading: "/home/lorenzo/Scaricati/fm_demod_mono.grc"
>>>> Converting from XML
>>>> Done
>
> Generating: '/home/lorenzo/Scaricati/top_block.py'
>
> Executing: /usr/bin/python3 -u /home/lorenzo/Scaricati/top_block.py
>
> gr-osmosdr 0.2.0.0 (0.2.0) gnuradio 3.10.0.0
> built-in source types: file fcd rtl rtl_tcp uhd hackrf bladerf rfspace
> airspy airspyhf soapy redpitaya freesrp
> Using device #0 Realtek RTL2838UHIDIR SN: 00000001
> Found Rafael Micro R820T tuner
> [R82XX] PLL not locked!
> [R82XX] PLL not locked!
>
>>>> Done (return code -11)
>
> What does this mean? How can solve this problem?
> The dongle is working fine with SDRSharp or rtl_fm.
>
> Thank you
>

Help on

Hello everyone, I am trying to make a cheap USB dongle working with
gnuradio and gnuradio-companion.
I just tried to use a source block and link to a waterfall sink.
This is the error that I got:

<<< Welcome to GNU Radio Companion 3.10.1.1 >>>

Block paths:
/usr/share/gnuradio/grc/blocks

Loading: "/home/lorenzo/Scaricati/fm_demod_mono.grc"
>>> Converting from XML
>>> Done

Generating: '/home/lorenzo/Scaricati/top_block.py'

Executing: /usr/bin/python3 -u /home/lorenzo/Scaricati/top_block.py

gr-osmosdr 0.2.0.0 (0.2.0) gnuradio 3.10.0.0
built-in source types: file fcd rtl rtl_tcp uhd hackrf bladerf rfspace
airspy airspyhf soapy redpitaya freesrp
Using device #0 Realtek RTL2838UHIDIR SN: 00000001
Found Rafael Micro R820T tuner
[R82XX] PLL not locked!
[R82XX] PLL not locked!

>>> Done (return code -11)

What does this mean? How can solve this problem?
The dongle is working fine with SDRSharp or rtl_fm.

Thank you

--
LORENZO MAINARDI

GNURadio 3.7.14.0 Building gr-video-sdl

Hello there, for few reasons I am still using GNURadio 3.7 which doesn't come buindled with gr-video-sdl (at least the installation I am using doesn't) (I know 3.9 comes with it but right now I have some legacy blocks that are not uvailable for 3.9 so I am stuck using 3.7)

So I tried building gr-video-sdl separatly, and then installing it into existing gnuradio distribution like this:

1. Downloaded GNURadio 3.7.10: https://github.com/gnuradio/gnuradio/releases/download/v3.7.14.0/gnuradio-3.7.14.0.tar.gz

    * extraxted gr-video-sdl

2. Installed SDL1.2 from here: http://web.archive.org/web/20191227232250if_/http://libsdl.org/release/SDL-devel-1.2.15-VC.zip (since gr-video-sdl uses SDL1.2 not SDL2 I assume)

3. trying to cmake like this: cmake ../ -DSDL_LIBRARY="C:\Program Files\PothosSDR\libsdl\lib\x64" -DSDL_INCLUDE_DIR="C:\Program Files\PothosSDR\libsdl\include"

I copied sdl include and lib files to this place

but I get some errors: https://pastebin.com/1RjmG1zj

It aphears GrBoost and GrComponent are missing and there is some unknown command: Unknown CMake command "GR_REGISTER_COMPONENT".

Now I think GrBoost is boost but I am not sure, cmake doesn't tell me that Boost is missing, but what is GrComponent (what include and lib prefix do I need to set to include this?)

Thanks for Anwsering and Best Regards

[GRCon'22] Call for Participation for the GNU Radio Conference 2022 is open! || Call for Sponsorship

Dear Community,

Submission for talks, papers, workshops, and other contributions are now being accepted
through the GRCon'22 website.

https://events.gnuradio.org/event/18/page/56-call-for-participation-guidelines

This call for participation closes on 27 June 2022, so remember to send in your Abstract
till then.

A tiny bit about the GNU Radio conference:

GRCon is GNU Radio's annual conference, being held in changing cities in the U.S., and
also live-streamed and chat-interacted online. Online watching and interaction are free
(in terms of the talks). Registration for the in-person event starts in April.

GRCon'22 happens 26 – 30 September in Washington, DC.

What GRCon offers is a main track of presentations with topics on GNU Radio, applications
of SDR / high-rate signal processing, computational radio science, scientific and industry
developments, policy and technological breakthroughs.

Next to that, there's tutorials on specific topics, a poster session, Special Interest
Groups and the developer's summit, which is the get-together for the project developers.
Oh, and of course, there's social events, happening at local highlight locations.

If you have *any* question (and I mean that – we're trying to make GRCon as accommodating
as possible) about GRCon, be it about attendance, online participation, content submission
or other problems related to the conference, we want you to reach out: Here on the mailing
list, on the chat (https://chat.gnuradio.org), or in a private email to the GRCon
organizers (grcon@gnuradio.org).



Now, clearly, this all requires significant funds to set up – with a history of more than
300 in-person attendees prior to covid, and the live video streams hitting beyond 3400
views last year, venue search is complicated, video, audio and online infrastructure
quality and stability is of utmost importance.
As in previous years, we do not intend to push all these costs onto the attendees alone;
instead, it has proven mutually advantagous to have sponsors contribute to the conference,
and be present in various forms to the audience. If your company is interested in reaching
a high-profile, technical and social audience, please do see
https://events.gnuradio.org/event/18/page/49-sponsorship-opportunities and reach out to
sponsor@gnuradio.org .

Best regards, and: see you in person in DC or online end of September,
Marcus

Re: [USRP-users] 2 rx antennas + USRP B210 + GNU radio

On 2022-03-25 11:20, Jumana via USRP-users wrote:
>
> I want to capture Lora trace using 2 antennas that located in port
> A:RX2 and B:RX2 then save the date in a file.
>
> I created a simple Gnu Radio flow-graph. In USRP source, i add serial
> + 2 channel + freq + gain.
>
> The problem that i can not save the data in a file.
>
> I got error "Port is not connected"
>
> Can any one help me?
>
> I
I've cross-posted to discuss-gnuradio, since this isn't really the
"teach myself gnuradio" mailing list.

You've disabled your USRP source, the "real" output of your
complex-to-real is going to a file sink that is configured for
complex-float.  Your source refers to a variable,
  "gain" that doesn't exist within your graph.

You should probably spend a bit more time with Gnu Radio tutorials.

Why is OFDM_loopback slow with Random Source

Good evening,

I have been doing some work with packet modulation and I ran across the OFDM_Loopback.grc file. I initially did some test with my ZMQ Server and the data rate was terrible. Thinking it was my datasource, I did some other test until I decided to use GNU Radios random Source block as an input. To my surprise, it was just as slow and I really can't figure out why. My CPU isnt terrible, is this GNURADIOS internal data processing at work or am I not understanding how it was meant to be used?

Any feedback would be greatly appreciated!

Respectfully,

Taylor Clark

Re: conda build fails with: ImportError: generic_type: type "square_ff" referenced unknown base type "gr::block"

Hi Franco,

Thanks for trying this out! The more people that use it, the better we can make it work.

What you've run into is indeed a pybind11 incompatibility. It's happening not because the pybind11 version has changed between building GNU Radio and the OOT, but because the version of GCC has changed between the two builds. Conda-forge has recently migrated from GCC 9 to 10, the existing `gnuradio` packages were built with GCC 9, and your fresh OOT build from a recipe is using GCC 10. It works the "normal" way without a recipe because `gnuradio-build-deps` installs GCC 9.

I was hoping that no one would run into this until the next releases of GNU Radio, at which time I could upgrade to GCC 10 and not break existing OOT packages built with GCC 9. As a temporary fix until that time, you can add the following lines to a `conda_build_config.yaml` file in the same directory as `meta.yaml` in your OOT recipe:

c_compiler_version:
- 9 # [linux]
cxx_compiler_version:
- 9 # [linux]

That will override conda-forge's global compiler settings and use GCC 9, which will give you compatible Python bindings.

Cheers,
Ryan

P.S.

As it so happens, I have just started playing around with adding a conda recipe to the gr-newmod OOT template created by gr_modtool:

https://github.com/ryanvolz/gnuradio/tree/05568f8f2937f9fc613cc9d518a771dd0f06a5ae/gr-utils/modtool/templates/gr-newmod/.conda

You could copy that whole .conda directory into a module's source tree, modify the .conda/recipe/meta.yaml, and get results very similar to what you've shared at the Google drive link. Of course, this still also needs the GCC version fix described above!

On 3/22/22 9:52 PM, Franco VENTURI wrote:
> In order to learn how conda recipes and conda build work, I did the following steps on my computer:
>
> - created a VM running the latest version of Ubuntu (21.10); I did all the remaining steps inside this VM
> - installed conda (miniforge3), created the 'gnuradio' environment, installed the latest version of gnuradio from conda (3.10.1.1), ran 'conda upgrade -all', ran a quick check with 'gnuradio-compantion' - for this part I followed the instructions in the GNU Radio Wiki (https://wiki.gnuradio.org/index.php/CondaInstall <https://wiki.gnuradio.org/index.php/CondaInstall>)
> - ran 'conda install gnuradio-build-deps' and 'conda activate $CONDA_DEFAULT_ENV' as per the instructions here: https://wiki.gnuradio.org/index.php/CondaInstall#Building_OOT_modules_to_use_with_conda-installed_GNU_Radio <https://wiki.gnuradio.org/index.php/CondaInstall#Building_OOT_modules_to_use_with_conda-installed_GNU_Radio>
> - followed the GNU Radio OOT Modules tutorial (https://wiki.gnuradio.org/index.php/OutOfTreeModules <https://wiki.gnuradio.org/index.php/OutOfTreeModules>) to create the sample 'gr-howto' OOT module with the two blocks 'square_ff' and 'square2_ff'
> - in the sample OOT howto module I ran the commands:
>     mkdir build
>     cd build
>     cmake -G Ninja -DCMAKE_INSTALL_PREFIX=$CONDA_PREFIX -DCMAKE_PREFIX_PATH=$CONDA_PREFIX -DLIB_SUFFIX="" ..
>     cmake --build .
>     cmake --build . --target install
> and I was able to build the sample 'gr-howto' module, and ran the QA tests without any errors
> - I then created a conda recipe following the steps in Ryan Volz template (https://github.com/ryanvolz/gnuradio-oot-template-feedstock <https://github.com/ryanvolz/gnuradio-oot-template-feedstock>); modified the meta.yaml file, and the build.sh file (didn't touch bld.bat since my build/host environment is Ubuntu)
> - I installed conda-build and ran the command 'conda build .' in the directory with the recipe
> - After a few minutes the compile/link part ran without errors, however the QA tests failed with the error message:
>
>     ImportError: generic_type: type "square_ff" referenced unknown base type "gr::block"
>
> For those interested in seeing all the files (howto module, meta.yaml, build.sh), I uploaded them to my Google drive and this is the link: https://drive.google.com/file/d/1rkMcrsF9jLxUvgOU1F3kpbCRij4e9qa-/view?usp=sharing
>
> I know that error message is due to pybind11 and I saw it was mentioned in this mailing list before (https://lists.gnu.org/archive/html/discuss-gnuradio/2021-05/msg00056.html <https://lists.gnu.org/archive/html/discuss-gnuradio/2021-05/msg00056.html> and https://github.com/gnuradio/gnuradio/issues/4841 <https://github.com/gnuradio/gnuradio/issues/4841>), but in this case the module does work with the conda gnuradio environment if built the 'normal' way using the 'cmake' commands above; it fails when run inside a 'conda build' recipe.
>
> Thanks in advance,
> Franco
>
>
>
>
>
>

Trying to understand simple example

Greetings to all!

I am a very new GNU Radio user.

For now I am trying to get simple example with spectrum analyzer.

I am encountering problems with understanding the result of the results
I get. I am attaching to screens - one for the schematic and one for Qt
FFT block result.

As for now I do not understand - why do I get some strange -15dB value
on spectrum for I am using a simple gen with 1 volt amplitude. And how
to customize the y-scale correctly.

I hope if anybody can help me with this and clarify those questions.

Thank everyone in advance.

Alex

RE: gr_modtool rm in v3.9

Thanks, Josh.  Nice to confirm.  I was having some trouble finding what I was looking for in the change history, so I thought I'd just ask.

 

Jeff

 

From: Josh Morman <jmorman@gnuradio.org>
Sent: Wednesday, March 23, 2022 4:35 AM
To: Jeff S <e070832@hotmail.com>
Cc: discuss-gnuradio@gnu.org
Subject: Re: gr_modtool rm in v3.9

 

Jeff,

 

I'm guessing the issue is with the tool.  Modtool went through some changes 3.8-->3.9 as Swig was removed and the extra step of `modtool bind` was added. 

 

Josh

 

On Tue, Mar 22, 2022 at 11:28 AM Jeff S <e070832@hotmail.com> wrote:

I tried using gr_modtool in v3.9.5.0 to add a block, including python and C++ QA code.  I then did a gr_modtool rm on that block, but the C++ QA code file was not removed, and the file shows up in the lib/CMakeLists.txt file.

 

I tried a test with the same thing in v3.8.5.0, and it seems like the C++ file and reference were removed.  I couldn't find any reference to it being changed, so I guess I'm just checking to see if there is an issue with me, or the tool.

 

Regards,

Jeff

Re: gr_modtool rm in v3.9

Jeff,

I'm guessing the issue is with the tool.  Modtool went through some changes 3.8-->3.9 as Swig was removed and the extra step of `modtool bind` was added. 

Josh

On Tue, Mar 22, 2022 at 11:28 AM Jeff S <e070832@hotmail.com> wrote:

I tried using gr_modtool in v3.9.5.0 to add a block, including python and C++ QA code.  I then did a gr_modtool rm on that block, but the C++ QA code file was not removed, and the file shows up in the lib/CMakeLists.txt file.

 

I tried a test with the same thing in v3.8.5.0, and it seems like the C++ file and reference were removed.  I couldn't find any reference to it being changed, so I guess I'm just checking to see if there is an issue with me, or the tool.

 

Regards,

Jeff

conda build fails with: ImportError: generic_type: type "square_ff" referenced unknown base type "gr::block"

In order to learn how conda recipes and conda build work, I did the following steps on my computer:

- created a VM running the latest version of Ubuntu (21.10); I did all the remaining steps inside this VM

- installed conda (miniforge3), created the 'gnuradio' environment, installed the latest version of gnuradio from conda (3.10.1.1), ran 'conda upgrade -all', ran a quick check with 'gnuradio-compantion' - for this part I followed the instructions in the GNU Radio Wiki (https://wiki.gnuradio.org/index.php/CondaInstall)

- ran 'conda install gnuradio-build-deps' and 'conda activate $CONDA_DEFAULT_ENV' as per the instructions here: https://wiki.gnuradio.org/index.php/CondaInstall#Building_OOT_modules_to_use_with_conda-installed_GNU_Radio

- followed the GNU Radio OOT Modules tutorial (https://wiki.gnuradio.org/index.php/OutOfTreeModules) to create the sample 'gr-howto' OOT module with the two blocks 'square_ff' and 'square2_ff'

- in the sample OOT howto module I ran the commands:

    mkdir build

    cd build

    cmake -G Ninja -DCMAKE_INSTALL_PREFIX=$CONDA_PREFIX -DCMAKE_PREFIX_PATH=$CONDA_PREFIX -DLIB_SUFFIX="" ..

    cmake --build .

    cmake --build . --target install

and I was able to build the sample 'gr-howto' module, and ran the QA tests without any errors

- I then created a conda recipe following the steps in Ryan Volz template (https://github.com/ryanvolz/gnuradio-oot-template-feedstock); modified the meta.yaml file, and the build.sh file (didn't touch bld.bat since my build/host environment is Ubuntu)

- I installed conda-build and ran the command 'conda build .' in the directory with the recipe

- After a few minutes the compile/link part ran without errors, however the QA tests failed with the error message:

    ImportError: generic_type: type "square_ff" referenced unknown base type "gr::block"

For those interested in seeing all the files (howto module, meta.yaml, build.sh), I uploaded them to my Google drive and this is the link: https://drive.google.com/file/d/1rkMcrsF9jLxUvgOU1F3kpbCRij4e9qa-/view?usp=sharing

I know that error message is due to pybind11 and I saw it was mentioned in this mailing list before (https://lists.gnu.org/archive/html/discuss-gnuradio/2021-05/msg00056.html and https://github.com/gnuradio/gnuradio/issues/4841), but in this case the module does work with the conda gnuradio environment if built the 'normal' way using the 'cmake' commands above; it fails when run inside a 'conda build' recipe.

Thanks in advance,

Franco

   

 

gr_modtool rm in v3.9

I tried using gr_modtool in v3.9.5.0 to add a block, including python and C++ QA code.  I then did a gr_modtool rm on that block, but the C++ QA code file was not removed, and the file shows up in the lib/CMakeLists.txt file.

 

I tried a test with the same thing in v3.8.5.0, and it seems like the C++ file and reference were removed.  I couldn’t find any reference to it being changed, so I guess I’m just checking to see if there is an issue with me, or the tool.

 

Regards,

Jeff

Re: wrong antenna mode

Salut JM,

Thank you. This was as simple as that. Problem solved.

See you,
Maxime

Le 22/03/2022 à 11:45, jmfriedt a écrit :
> Salut Maxime,
> a lot of arguments seem to have changed with UHD4. In the
> UHD: USRP Source, go to RF Options and for each board define
> Ch i: Antenna
> manually, replacing the TX/RX tab entry with your own.
> I use "A" setting.
>
> Probably your Subdev Spec that might have been defined with UHD3
> is no longer valid as well: in the General menu of UHD Source I had
> to set
> A:0 B:0
> under Mb0: Subdev Spec.
> Not sure how this setting relates to
> https://files.ettus.com/manual/page_dboards.html
> and the description that
> Antenna Mode A: real signal from antenna RXA
> Antenna Mode B: real signal from antenna RXB
> for the BasicRX.
>
> Best, JM
>
>> I am using a X310 under uhd4.1.0.5, gnuradio 3.8 and rfnoc.
>> Whenever I use an antenna mode with either usrp sink or source, I get
>> an error stating: invalid antenna mode: RX/TX
>>
>> python error is:
>> return_uhd_swig.usrp_source_sptr_set_antenna(self, ant, chan)
>>
>> How to solve this?
>>
>> Thanks in advance,
>> Maxime DUPONT
>>
>>
>
>

Software Defined Radio Academy 2022 && European GNURadio Days

Call for Contributions: SDRA-2022 Online and Friedrichshafen

HAMRADIO Friedrichshafen Software Defined Radio Academy 2022 (SDRA-
2022)

Date: Friday 24.06.2022, Saturday 25.06.2022 (and Sunday 26.06.2022)

Conference Websites:

https://www.hamradio-friedrichshafen.de
https://2022.sdra.io

SDRA-2022 invites radio amateurs and researchers from acadaemia and
industry to submit papers for oral and poster presentations on recent
research that addresses theoretical aspects, algorithms, applications,
hardware and software architectures for applied Software Defined Radio
systems and resources and other aspects of SDR, as well as survey and
discussion papers. The invitation particularly addresses open source
research and projects. We also particularly invite specialists giving
introductory talks and tutorials on SDR technologies.
European GNURadio Days

We point out that we are co-operating closely with the European
GNURadio Days.

GNU Radio related contributions will be provided as tutorials recorded
by the European GNU Radio Days organizers aimed at illustrating digital
signal processing and communication techniques demonstrated with our
favorite processing framework. European GNU Radio Days organizers
remain open to all sorts of proposals, including tutorial contributions
and experimental demonstrations using GNU Radio.

SDRA Topics:

Advances in GNURadio related projects and research
Algorithms, applications, architectures in SDR systems
Real Time signal processing
Innovative applications using modern ADC/DAC environments

Submission Information

How to submit: Please send an abstract of approximately 250 words to:

sdra@darc.de

Please include the following information:

Paper title
Author's name (and callsign). Names and callsigns of all authors if
multiple authors.
Author's affiliation
Country
Email address of the main author

All accepted papers will be published. Publication details will be
available at a later point of time.

We ask authors to keep a limit of 6 pages. If there is a reason why the
paper should be longer, please contact us.

We also solicit Posters and Demo papers: Poster/Demo papers describe a
small focused result, a negative result, or a late-breaking result, or
a description of a system that can be demonstrated on-site at the
conference.

Papers should be formatted using the IEEE A4 templates:
https://www.ieee.org/conferences_events/conferences/publishing/templates.html
Organization

Prof. Dr. Michael Hartje, DK5HH
Markus Heller, M.A., DL8RDS

Senior Programme Committee

Prof. Dr. Michael Hartje, HS Bremen, DK5HH
Prof. Dr. Michael Niemetz, OTH Regensburg, DG2RAM
Prof. Dr. Michael Mächtel, HTWG Konstanz, DL2SBS

Important Dates:

Please note that we welcome earlier recordings. The earlier you can
submit and arrange the recording with our video team, the better.

Abstract Submission: 30.04.2022
Acceptance Notification: 15.05.2022
Presentation Recording: 15.05.2022 - 15.06.2022
PlayOut Date and Live Event: 24/25/26.06.2022

Contact

For enquiries and paper submission details please do not hesitate to
contact us:

Email: sdra@darc.de Tel.: +49.89.420956305-0

Re: wrong antenna mode

Salut Maxime,
a lot of arguments seem to have changed with UHD4. In the
UHD: USRP Source, go to RF Options and for each board define
Ch i: Antenna
manually, replacing the TX/RX tab entry with your own.
I use "A" setting.

Probably your Subdev Spec that might have been defined with UHD3
is no longer valid as well: in the General menu of UHD Source I had
to set
A:0 B:0
under Mb0: Subdev Spec.
Not sure how this setting relates to
https://files.ettus.com/manual/page_dboards.html
and the description that
Antenna Mode A: real signal from antenna RXA
Antenna Mode B: real signal from antenna RXB
for the BasicRX.

Best, JM

> I am using a X310 under uhd4.1.0.5, gnuradio 3.8 and rfnoc.
> Whenever I use an antenna mode with either usrp sink or source, I get
> an error stating: invalid antenna mode: RX/TX
>
> python error is:
> return_uhd_swig.usrp_source_sptr_set_antenna(self, ant, chan)
>
> How to solve this?
>
> Thanks in advance,
> Maxime DUPONT
>
>



--
JM Friedt, FEMTO-ST Time & Frequency, 26 rue de l'Epitaphe, 25000
Besancon, France

wrong antenna mode

Hi,

I am using a X310 under uhd4.1.0.5, gnuradio 3.8 and rfnoc.
Whenever I use an antenna mode with either usrp sink or source, I get an
error stating: invalid antenna mode: RX/TX

python error is:
return_uhd_swig.usrp_source_sptr_set_antenna(self, ant, chan)

How to solve this?

Thanks in advance,
Maxime DUPONT

Re: Python problem..

David,

Your code is not available anymore.

What you want to achieve?

I don't understand your problem. 

Marcin

On Sat, Mar 19, 2022, 12:49 tech k1ng <tkng874@gmail.com> wrote:

Hello Marcin,

Thanks for getting back to me. Sorry for the last response!!

I tried to do it another way using basic block, but this time just checking condition over thresh, and between other up and low. I tried to graph it and it doesn't seem to show anything. I got no errors. Any ideas what I may have done wrong?

https://pastebin.com/w7uZyQjE

tir. 15. mar. 2022 kl. 14:19 skrev Marcin Puchlik <m.puchlik@is-wireless.com>:

Hi David,

Problem is in the line: 

output_items[0] = outvec

There is a type mismatch here, you cannot write a list of tuples (outvec) to the numpy array.

BR,

Marcin

wt., 15 mar 2022 o 00:28 tech k1ng <tkng874@gmail.com> napisał(a):

Hello again.

Here is the python code: https://pastebin.com/waUMgRSD

I patiently await your response. By the way, this is my first time using a mailing list:)

Regards,

David.

tir. 15. mar. 2022 kl. 00:15 skrev tech k1ng <tkng874@gmail.com>:

Hi there,

This is my first mailing post, so please excuse me if there are any errors.

I'm trying to make a block that gives me the bins with corresponding its energy ([bins, energy]) when over a thresh, so input vector is from "log power fft" block. With the output, I'm hoping to store it as a file for further use, or perhaps use it to visualize it. Marcus Müller has already proposed something similar while describing a technique to another person: here 

The python code is shown here: The output does not seem to represent it properly. I'm lost right now, and I'm not sure how to proceed. I've attempted to troubleshoot it and experiment with other things before coming here to ask for help.

Thank you; I'm hoping that someone can check into this and give me some advice on what I can do.

Best Regards,

David