Re: CGRAN issues (empty page)

[Cinaed Simson]

The web site is NOT maintained by gnuradio - it is maintained by CGRAN.

OOT denotes  "Out Of Tree Module", i.e., they use gnuradio software but 
they are NOT maintained by gnuradio.


If you have a problem with an OOT you need to contact the author of the OOT.

Unless you have the email address of maintainer of website,  then you 
need to submit an issue here


https://github.com/gnuradio/cgran

 -- Cinaed


On 1/21/23 21:58, Aditya Arun Kumar wrote:

Hi Cinaed,
But the entire CGRAN page is empty. Like no OOT's are listed.

On Sun, Jan 22, 2023 at 6:20 AM Cinaed Simson 
 wrote:


Hi Rick - all the gnuradio links at the top of the page work.

For gnuradio, try

www.gnuradio.org <http://www.gnuradio.org>
wiki.gnuradio.org <http://wiki.gnuradio.org>
github.com/gnuradio <http://github.com/gnuradio>

For cgran, try

https://github.com/gnuradio/cgran

and open an issue.

-- Cinaed



On 1/21/23 10:32, aardric wrote:
> I receive a static page at https://www.cgran.org/
> but all links seem to go nowhere. Perhaps the page is under
construction.
>
> Rick
>
> On 2023-01-21 09:18, Aditya Arun Kumar wrote:
>> Hi,
>> I’ve been trying to access CGRAN for sometime now and the site
is empty.
>> Is it moved elsewhere?
>> --
>> S. Aditya Arun Kumar
>> +919123517465
>




--
S. Aditya Arun Kumar
+919123517465

Re: CGRAN issues (empty page)

[Cinaed Simson]

Hi Rick - all the gnuradio links at the top of the page work.

For gnuradio, try

   www.gnuradio.org
   wiki.gnuradio.org
   github.com/gnuradio

For cgran, try

   https://github.com/gnuradio/cgran

and open an issue.

-- Cinaed



On 1/21/23 10:32, aardric wrote:

I receive a static page at https://www.cgran.org/
but all links seem to go nowhere. Perhaps the page is under construction.

Rick

On 2023-01-21 09:18, Aditya Arun Kumar wrote:

Hi,
I’ve been trying to access CGRAN for sometime now and the site is empty.
Is it moved elsewhere?
--
S. Aditya Arun Kumar
+919123517465

Re: Performance issue in gnuradio version 3.10.1

[Cinaed Simson]

Please do not send me images.

Instead,  when the system slows down, open a cmd windows and type

  systeminfo | find "Available Physical Memory"

-- Cinaed

On 1/19/23 05:48, SHAKTHIVEL S 2021 Batch,PES University wrote:
I am running the flowgraph graph on Windows10 Anaconda 3 GNURADIO 
3.10. As it was not even running in my dual booted DragonOS 20.04 
gnuradio version 3.8.1.I thought of trying in windows then it worked 
but not decoding the symbols. It is throwing some  pagesize error. But 
the symbols are overlapping on one another.Below I combined both 
transmission and reception to decrease latency but no use.

Thanks
I have attached few screen shots

On Thu, Jan 19, 2023, 11:22 Cinaed Simson  wrote:

Hi - are you running running under Windows or Linux on the PC.

And are you running a virtual machine?

Check memory usage.

It's possible your using  swap as memory-and are constantly
swapping the memory to disk - which will slow you to crawl.

-- Cinaed


On 1/18/23 15:52, SHAKTHIVEL S 2021 Batch,PES University wrote:

It is an adaptive site I changed the blocks accordingly to 3.10 .
I am simulating this on my PC. It is lagging like a hell. Can
anyone give some tips to increase speed? Or I have to bear with
this? The symbols are not getting decided other side due to this

On Thu, Jan 19, 2023, 00:44 Aditya Arun Kumar
 wrote:

In 3.10 blocks got moved around right? To symbol sync and
linear eq stuff?

On Thu, Jan 19, 2023, 00:04 Marcus Müller
 wrote:

Bit confused; you're using GNU Radio 3.10, but you
specifically read a version of the
tutorial that is marked as *not* applying to 3.10?

On 18.01.23 17:13, SHAKTHIVEL S 2021 Batch,PES University
wrote:
> I tried running the Packet Commication example given in
gnuradio documentation using gr38
> embedded block. It throwed me this error
> "pagesize :error: no info; setting pagesize = 4096"
> Although this is not an error strictly it reduced the
performance of the flowgraph
> drastically and I couldn't decode the message on the
receiver side.The constellation are
> overlapping and trying to move away slowly. Any help
would be appreciated
> Link to the

site:https://wiki.gnuradio.org/index.php/Packet_Communications?ver1=3.8

>
<https://wiki.gnuradio.org/index.php/Packet_Communications?ver1=3.8>
>
>
>

Re: Performance issue in gnuradio version 3.10.1

[Cinaed Simson]

Hi - are you running running under Windows or Linux on the PC.

And are you running a virtual machine?

Check memory usage.

It's possible your using  swap as memory-and are constantly swapping the 
memory to disk - which will slow you to crawl.


-- Cinaed


On 1/18/23 15:52, SHAKTHIVEL S 2021 Batch,PES University wrote:
It is an adaptive site I changed the blocks accordingly to 3.10 . I am 
simulating this on my PC. It is lagging like a hell. Can anyone give 
some tips to increase speed? Or I have to bear with this? The symbols 
are not getting decided other side due to this


On Thu, Jan 19, 2023, 00:44 Aditya Arun Kumar 
 wrote:


In 3.10 blocks got moved around right? To symbol sync and linear
eq stuff?

On Thu, Jan 19, 2023, 00:04 Marcus Müller 
wrote:

Bit confused; you're using GNU Radio 3.10, but you
specifically read a version of the
tutorial that is marked as *not* applying to 3.10?

On 18.01.23 17:13, SHAKTHIVEL S 2021 Batch,PES University wrote:
> I tried running the Packet Commication example given in
gnuradio documentation using gr38
> embedded block. It throwed me this error
> "pagesize :error: no info; setting pagesize = 4096"
> Although this is not an error strictly it reduced the
performance of the flowgraph
> drastically and I couldn't decode the message on the
receiver side.The constellation are
> overlapping and trying to move away slowly. Any help would
be appreciated
> Link to the
site:https://wiki.gnuradio.org/index.php/Packet_Communications?ver1=3.8

>

>
>
>

Re: gnuradio permission problems?

[Cinaed Simson]

Hi Niklas - type

  groups

Typically you need to be in groups

  dialout netdev

If you're not in those groups, add yourself in

  /etc/groups

And then logout and login to see if the problem goes away.

-- Cinaed

On 1/18/23 05:03, Beckmann, Niklas wrote:


Hi everybody,


I have somehow a general question, and even after days of trying (and 
also googling), I did not found a solution for my problem. So maybe 
anyone here can help me out. Im on Ubuntu 20.04 and gnuradio 3.10, 
python 3.8.


I am working with an evaluation kit antenna, which is controlled via 
the python OOT block, that I wrote. In gnuradio, during the antenna 
initialization process, my python block tells me, that the connection 
to the eval-kit failed:



  Connecting ...
  MB1 device channel connection failed!
  Make sure the device cable is connected.
  Make sure you run the connection script with sudo.
  Make sure the MB1 has been programmed with the correct descriptor.
  Device initialization failed!

On the other hand, when I open sudo python in a terminal, give the 
same commands as in the python block, the initialization process ends 
sucessfully.
So my guess was, that it has something to do with the permissions of 
gnuradio (even tho I do not get an Errno13). Am I on the right track? 
And if so, how can I give gnuradio the needed permissions to connect 
with the eval-kit or let it run the scripts with higher permissions 
without using sudo gnuradio?


Since the question is pretty general, I did not provide anything 
of code. If certain parts of the code or something else is needed, I 
can give it.


Thank you very much, I hope someone here has an idea and is willing to 
help 


Best,
Niklas

Re: Error in gnu radio documentation

[Cinaed Simson]

Hi - it worked correctly for me using

  gnuradio-config-info -v
  v3.8.5.0-6-g57bd109d

-- Cinaed

On 1/15/23 03:04, SHAKTHIVEL S 2021 Batch,PES University wrote:
I used the same grc file given in the gnu radio packet communication 
documentation.

I got the following error while running the transmit file.
Generating: 
'/media/shakthivel/Workspace/capstone/SatelliteSDR/pkt_xmt_gr38.py'


Executing: /usr/bin/python3 -u 
/media/shakthivel/Workspace/capstone/SatelliteSDR/pkt_xmt_gr38.py


handler caught exception:
Traceback (most recent call last):
  File "/usr/lib/python3/dist-packages/gnuradio/gr/gateway.py", line 
78, in eval

    try: self._callback(arg)
  File 
"/media/shakthivel/Workspace/capstone/SatelliteSDR/packet_format_gr38.py", 
line 22, in handle_msg

    inMsg = pmt.to_python (msg)
  File "/usr/lib/python3/dist-packages/pmt/pmt_to_python.py", line 
126, in pmt_to_python

    return to_python(p)
  File "/usr/lib/python3/dist-packages/pmt/pmt_to_python.py", line 57, 
in pmt_to_dict

    for i in range(pmt.length(items)):
  File "/usr/lib/python3/dist-packages/pmt/pmt_swig.py", line 2647, in 
length

    return _pmt_swig.length(v)
RuntimeError
thread[thread-per-block[12]: ]: SWIG 
director method error. Error detected when calling 'feval_p.eval'


Link to the 
site:https://wiki.gnuradio.org/index.php/Packet_Communications?ver1=3.8


Link to grc: https://wiki.gnuradio.org/images/3/37/Pkt_xmt_gr38.grc

Re: Constellation Modulator delay calculation

[Cinaed Simson]

Hi Ali - your flowchart has no device and no throttle. You need to add a 
throttle.


And I don't the expertise or the time to look at the source code.

So I'm punting back to the list.

-- Cinaed


On 1/10/23 03:10, Ali G. Dezfuli wrote:

Hi everybody,expertise

I just want to know how the delay of the "Constellation Modulator" 
block in GRC is calculated.
In fact, whether you set the block's last parameter "truncate filter 
transient" or not, a delay of 86 samples could be generated, no matter 
how many points are in the constellation.


This magic number (i.e. 86) also appears in 
"linear_equalizer_compare.grc" example (in 
gr-digital/examples/equalizers in modulated_sync_word variable).


I know this delay depends on the "samples per symbol" (sps) parameter 
and comes from the built-in pulse shaping with its default taps equal:

       firdes.root_raised_cosine(32, 32, 1.0, exess_bw, 32*11*sps)
and with the following sps to delay relation:
(sps=2, delay=21)
(sps=4, delay=86)
(sps=8, delay=348)
etc.

my GR version is:   v3.11.0.0git-316-gc11667ef
thank you all!

Re: DQPSK constellation

[Cinaed Simson]

Hi Ali - please state the version of gnuardio you're using and post the 
flowgraph used to generate your problem.


-- Cinaed

On 1/8/23 23:56, Ali G. Dezfuli wrote:

Hi all,
I've managed to get to the same signal of the block "Constellation 
Modulator" by using these blocks in concatenation:


{  --> repack bits --> differential encoder --> constellation encoder 
(or: chunks to symbols) --> polyphase arbitrary resampler --> }


and tried them for bpak, qpsk, 8psk, and 16qam, and all OK.

This command digital.constellation_dqpsk().points() gets the following 
points:


[(1.4142135381698608+1.4142135381698608j), 
(-1.4142135381698608+1.4142135381698608j), 
(-1.4142135381698608-1.4142135381698608j), 
(1.4142135381698608-1.4142135381698608j)]


which is different from the documentation of DQPSK which says:
01 | 00 --- 11 | 10
I wonder how I can get the same result for DQPSK by using the above 
series of blocks.


thanks

Re: sndfile::sndfile again

[Cinaed Simson]

The

  libsndfile1-dev

installs the header files.

In general, the -dev extension installs the header files and sometimes the 
static libraries.

It most likely crashed because of the lack of header files - it found the 
dynamic libraries which where installed with gnuradio - but no header files.

Since you're building from source, you need to supply the header files.

- Cinaed


On 12/29/22 21:19, Larry Doolittle wrote:

Cinaed -

On Wed, Dec 28, 2022 at 06:31:17PM -0800, Cinaed Simson wrote:

Hi Larry - try
   apt install libsndfile1-dev

Yes, I confirm that is the solution.  Thanks!
Although it's more practical to
   apt-get install --no-install-recommends libsndfile1-dev
to keep xtrx-dkms out of it.  Both specifically because of
   https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1012616
   xtrx-dkms: DKMS build fails with implicit declaration of functions
and philosophically to keep unused dependencies out of my system.


Since you installed gnuradio form Debian, you can always install gr-osmosdr
from Debian and it will match your gnuradio install.

True!  Although I then needed libsndfile1-dev for the next
builds on my list,
   gr-pdu_utils
   gr-sandia_utils
   gr-timing_utils
   gr-fhss_utils

I also admit I'm still baffled how this missing dependency caused
cmake to crash trying to link (g++) with -l sndfile::sndfile.

   - Larry

Re: sndfile::sndfile again

[Cinaed Simson]

Hi Larry - try

  apt install libsndfile1-dev

If it installs, blow away the build directory and try to build it again.

Since you installed gnuradio form Debian, you can always install 
gr-osmosdr from Debian and it will match your gnuradio install.


And just to be clear, you need to install gnuradio before you install 
gr-osmosdr.


-- Cinaed


On 12/28/22 14:15, Larry Doolittle wrote:

gnuradio gurus -

I just hit a problem with symptoms that precisely match
https://lists.gnu.org/archive/html/discuss-gnuradio/2020-09/msg00055.html

This is while attempting to build gr-osmosdr, basically the first
real step in the instructions at
https://wiki.recessim.com/view/Gr-smart_meters_Setup_Guide

I read Chris Gorman's patch, and it makes sense, but I couldn't find
a way to apply it to my situation.  I'm (attempting to) use gnuradio 3.10.4.0
as supplied in Debian testing (bookworm).  I couldn't find a CMakeLists.txt
file in that gnuradio install that mentions sndfile.

My closest hit was /usr/lib/x86_64-linux-gnu/cmake/gnuradio/FindSNDFILE.cmake
which I don't really understand.  I tried hacking on it anyway, but never
found a change that fixed my problem.

Any hints or ideas?  Am I stuck installing gnuradio from source?
Should I file a Debian bug report?

   - Larry

Re: GNU-Radio Clean Install

[Cinaed Simson]

Hi Yotam - please state your OS and version, how gnuradio was installed, 
i.e., from source code or using apt, and which libaries are broken.


Also, did you upgrade your OS before installing 3.10?

-- Cinaed

On 12/15/22 03:25, Yotam Rabin wrote:

Hi everyone!
I upgraded gnuradio to version 3.10 from 3.8 which seems to have 
broken some libraries which I can't uninstall via make because I'm 
missing swig.

Is there a way to clean install gnuradio without any of the OOT modules?
I tried "apt purge" doesn't seem to solve the problem

Any help would be greatly appreciated
Yotam

Re: Import error using an OOT

[Cinaed Simson]

I'm not surprised the OOT doesn't work.

When running

  run_response.py

using python2 (or python), it tries to run swig which won't work under 
gnuradio 3.9 on bullseye.


Here's the error from running

   run_response.py

running under python2:

   from .runtime_swig import *
   File 
"/opt/gnuradio/lib/python3/dist-packages/gnuradio/gr/runtime_swig.py", 
line 117

   def value(self) -> "PyObject *":
   SyntaxError: invalid syntax

The OOT source code needs to be to ported gnuradio 3.9 and python3.

-- Cinaed


On 12/12/22 16:54, Elmore Family wrote:

I changed the line as you requested. No difference.
*From:* Cinaed Simson
*Sent:* Monday, December 12, 2022 5:44 PM
*To:* Elmore Family
*Cc:* discuss-gnuradio@gnu.org
*Subject:* Re: Import error using an OOT
No I'm not.

The ft8_qso.conf.is a data input file - or a yaml file - it is read by 
the python code.


If there's a problem with the python code, the application will crash 
and burn regardless of the content of ft8_qso.conf.


If you change the the top line in the file

  run_response.py code

from

  #!/usr/bin/env python

to

  #!/usr/bin/env python3

it should work.

-- Cinaed



On 12/12/22 06:27, Elmore Family wrote:
You are confusing main() in run_response.py with the ‘main’ section 
in ft8_qso.conf.
parser.get in line 36 is looking for the ‘main’ section but throws 
the NoSectionError.

Why can’t the parser see the ‘main’ section?
When I said I have run an OOT before, I meant another OOT which runs 
well in this same app. However, this is irrelevant since we are not 
talking about the same problem.

Jim
*From:* Cinaed Simson
*Sent:* Monday, December 12, 2022 12:57 AM
*To:* Elmore Family
*Cc:* discuss-gnuradio@gnu.org
*Subject:* Re: Import error using an OOT
The main method is defined beginning on line 216 and called 4 times 
on lines 36-39.


And it appears the configparser is throwing the NoSectionError.

Try commenting out line 36 to see if line 37 throws the same exception.

When you said is has run before, did it run under python3.9?

-- Cinaed


On 12/11/22 19:11, Elmore Family wrote:
I have attached the 2 files in question. Look at the beginning of 
run_response.py. It uses ConfigParser to access the ft8_qso.conf 
configuration file.
This line seems to be the problem: my_call = str(parser.get('main', 
'my_call_sign')).
But ‘main’ is a section in the ft8_qso.conf file. Why can’t it find 
‘main’?

Jim
*From:* Cinaed Simson
*Sent:* Sunday, December 11, 2022 8:52 PM
*To:* Elmore Family
*Cc:* discuss-gnuradio@gnu.org
*Subject:* Re: Import error using an OOT
The problem appears to be in the python code

  response.py

- there is no 'main()' method.

-- Cinaed

On 12/11/22 09:48, Elmore Family wrote:

Here is the result:

pi@raspberrypi:~ $ python3
Python 3.9.2 (default, Mar 12 2021, 04:06:34)
[GCC 10.2.1 20210110] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import ft8
Traceback (most recent call last):
File "", line 1, in 
File "/usr/local/lib/python3.9/dist-packages/ft8/__init__.py", line 
23, in 

from .run_response import run_response
File "/usr/local/lib/python3.9/dist-packages/ft8/run_response.py", 
line 36, in 

my_call = str(parser.get('main', 'my_call_sign'))
File "/usr/lib/python3.9/configparser.py", line 781, in get
d = self._unify_values(section, vars)
File "/usr/lib/python3.9/configparser.py", line 1149, in _unify_values
raise NoSectionError(section) from None
configparser.NoSectionError: No section: 'main'

Jim

*From:* Cinaed Simson
*Sent:* Sunday, December 11, 2022 12:15 AM
*To:* discuss-gnuradio@gnu.org
*Subject:* Re: Import error using an OOT
Type

   python3

then enter

  import ft8

and see if it works.

-- Cinaed


On 12/9/22 18:33, Elmore's wrote:
I have created an OOT which when I incorporate it in my flowgraph 
shows the following error:

Failed to evaluate import expression ‘import ft8’
The yaml file is:
id: ft8_run_response
label: ft8
category: '[ft8]'
templates:
imports: import ft8
make: ft8.run_response(${ft8_button})
callbacks:
  - set_ft8(${ft8_button})
# Make one 'parameters' list entry for every parameter you want 
settable from the GUI.

# Keys include:
# * id (makes the value accessible as keyname, e.g. in the make entry)
# * label (label shown in the GUI)
# * dtype (e.g. int, float, complex, byte, short, xxx_vector, ...)
# * default
parameters:
- id: ft8_button
label: ft8_button
dtype: raw
default: 0
# 'file_format' specifies the version of the GRC yml format used 
in the file

# and should usually not be changed.
file_format: 1
I have developed and used an OOT before without an issue. I looked 
at the previous OOT and reviewed the GNU Radio docs on OOTs 
without seeing anything different.

I am using Python 3.92 with GNU radio 3.9.4.0 on a Raspberry Pi.
I hope someone can show me the error of my ways.
Jim

<http://www.avg.com/email-signa

Re: Import error using an OOT

[Cinaed Simson]

Opps - ft8_qso.conf is not a yaml file - it's just a  nonexcutable data 
file which the python code parses.


-- Cinaed


On 12/12/22 14:44, Cinaed Simson wrote:

No I'm not.

The ft8_qso.conf.is a data input file - or a yaml file - it is read by 
the python code.


If there's a problem with the python code, the application will crash 
and burn regardless of the content of ft8_qso.conf.


If you change the the top line in the file

  run_response.py code

from

  #!/usr/bin/env python

to

  #!/usr/bin/env python3

it should work.

-- Cinaed



On 12/12/22 06:27, Elmore Family wrote:
You are confusing main() in run_response.py with the ‘main’ section 
in ft8_qso.conf.
parser.get in line 36 is looking for the ‘main’ section but throws 
the NoSectionError.

Why can’t the parser see the ‘main’ section?
When I said I have run an OOT before, I meant another OOT which runs 
well in this same app. However, this is irrelevant since we are not 
talking about the same problem.

Jim
*From:* Cinaed Simson
*Sent:* Monday, December 12, 2022 12:57 AM
*To:* Elmore Family
*Cc:* discuss-gnuradio@gnu.org
*Subject:* Re: Import error using an OOT
The main method is defined beginning on line 216 and called 4 times 
on lines 36-39.


And it appears the configparser is throwing the NoSectionError.

Try commenting out line 36 to see if line 37 throws the same exception.

When you said is has run before, did it run under python3.9?

-- Cinaed


On 12/11/22 19:11, Elmore Family wrote:
I have attached the 2 files in question. Look at the beginning of 
run_response.py. It uses ConfigParser to access the ft8_qso.conf 
configuration file.
This line seems to be the problem: my_call = str(parser.get('main', 
'my_call_sign')).
But ‘main’ is a section in the ft8_qso.conf file. Why can’t it find 
‘main’?

Jim
*From:* Cinaed Simson
*Sent:* Sunday, December 11, 2022 8:52 PM
*To:* Elmore Family
*Cc:* discuss-gnuradio@gnu.org
*Subject:* Re: Import error using an OOT
The problem appears to be in the python code

  response.py

- there is no 'main()' method.

-- Cinaed

On 12/11/22 09:48, Elmore Family wrote:

Here is the result:

pi@raspberrypi:~ $ python3
Python 3.9.2 (default, Mar 12 2021, 04:06:34)
[GCC 10.2.1 20210110] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import ft8
Traceback (most recent call last):
File "", line 1, in 
File "/usr/local/lib/python3.9/dist-packages/ft8/__init__.py", line 
23, in 

from .run_response import run_response
File "/usr/local/lib/python3.9/dist-packages/ft8/run_response.py", 
line 36, in 

my_call = str(parser.get('main', 'my_call_sign'))
File "/usr/lib/python3.9/configparser.py", line 781, in get
d = self._unify_values(section, vars)
File "/usr/lib/python3.9/configparser.py", line 1149, in _unify_values
raise NoSectionError(section) from None
configparser.NoSectionError: No section: 'main'

Jim

*From:* Cinaed Simson
*Sent:* Sunday, December 11, 2022 12:15 AM
*To:* discuss-gnuradio@gnu.org
*Subject:* Re: Import error using an OOT
Type

   python3

then enter

  import ft8

and see if it works.

-- Cinaed


On 12/9/22 18:33, Elmore's wrote:
I have created an OOT which when I incorporate it in my flowgraph 
shows the following error:

Failed to evaluate import expression ‘import ft8’
The yaml file is:
id: ft8_run_response
label: ft8
category: '[ft8]'
templates:
imports: import ft8
  make: ft8.run_response(${ft8_button})
callbacks:
  - set_ft8(${ft8_button})
#  Make one 'parameters' list entry for every parameter you want 
settable from the GUI.

# Keys include:
# * id (makes the value accessible as keyname, e.g. in the 
make entry)

# * label (label shown in the GUI)
# * dtype (e.g. int, float, complex, byte, short, xxx_vector, ...)
# * default
parameters:
- id: ft8_button
  label: ft8_button
  dtype: raw
default: 0
# 'file_format' specifies the version of the GRC yml format used 
in the file

#  and should usually not be changed.
file_format: 1
I have developed and used an OOT before without an issue. I looked 
at the previous OOT and reviewed the GNU Radio docs on OOTs 
without seeing anything different.

I am using Python 3.92 with GNU radio 3.9.4.0 on a Raspberry Pi.
I hope someone can show me the error of my ways.
Jim

<http://www.avg.com/email-signature?utm_medium=email_source=link_campaign=sig-email_content=emailclient> 
	Virus-free.www.avg.com 
<http://www.avg.com/email-signature?utm_medium=email_source=link_campaign=sig-email_content=emailclient> 

Re: Import error using an OOT

[Cinaed Simson]

No I'm not.

The ft8_qso.conf.is a data input file - or a yaml file - it is read by 
the python code.


If there's a problem with the python code, the application will crash 
and burn regardless of the content of ft8_qso.conf.


If you change the the top line in the file

  run_response.py code

from

  #!/usr/bin/env python

to

  #!/usr/bin/env python3

it should work.

-- Cinaed



On 12/12/22 06:27, Elmore Family wrote:
You are confusing main() in run_response.py with the ‘main’ section in 
ft8_qso.conf.
parser.get in line 36 is looking for the ‘main’ section but throws the 
NoSectionError.

Why can’t the parser see the ‘main’ section?
When I said I have run an OOT before, I meant another OOT which runs 
well in this same app. However, this is irrelevant since we are not 
talking about the same problem.

Jim
*From:* Cinaed Simson
*Sent:* Monday, December 12, 2022 12:57 AM
*To:* Elmore Family
*Cc:* discuss-gnuradio@gnu.org
*Subject:* Re: Import error using an OOT
The main method is defined beginning on line 216 and called 4 times on 
lines 36-39.


And it appears the configparser is throwing the NoSectionError.

Try commenting out line 36 to see if line 37 throws the same exception.

When you said is has run before, did it run under python3.9?

-- Cinaed


On 12/11/22 19:11, Elmore Family wrote:
I have attached the 2 files in question. Look at the beginning of 
run_response.py. It uses ConfigParser to access the ft8_qso.conf 
configuration file.
This line seems to be the problem: my_call = str(parser.get('main', 
'my_call_sign')).
But ‘main’ is a section in the ft8_qso.conf file. Why can’t it find 
‘main’?

Jim
*From:* Cinaed Simson
*Sent:* Sunday, December 11, 2022 8:52 PM
*To:* Elmore Family
*Cc:* discuss-gnuradio@gnu.org
*Subject:* Re: Import error using an OOT
The problem appears to be in the python code

  response.py

- there is no 'main()' method.

-- Cinaed

On 12/11/22 09:48, Elmore Family wrote:

Here is the result:

pi@raspberrypi:~ $ python3
Python 3.9.2 (default, Mar 12 2021, 04:06:34)
[GCC 10.2.1 20210110] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import ft8
Traceback (most recent call last):
File "", line 1, in 
File "/usr/local/lib/python3.9/dist-packages/ft8/__init__.py", line 
23, in 

from .run_response import run_response
File "/usr/local/lib/python3.9/dist-packages/ft8/run_response.py", 
line 36, in 

my_call = str(parser.get('main', 'my_call_sign'))
File "/usr/lib/python3.9/configparser.py", line 781, in get
d = self._unify_values(section, vars)
File "/usr/lib/python3.9/configparser.py", line 1149, in _unify_values
raise NoSectionError(section) from None
configparser.NoSectionError: No section: 'main'

Jim

*From:* Cinaed Simson
*Sent:* Sunday, December 11, 2022 12:15 AM
*To:* discuss-gnuradio@gnu.org
*Subject:* Re: Import error using an OOT
Type

   python3

then enter

  import ft8

and see if it works.

-- Cinaed


On 12/9/22 18:33, Elmore's wrote:
I have created an OOT which when I incorporate it in my flowgraph 
shows the following error:

Failed to evaluate import expression ‘import ft8’
The yaml file is:
id: ft8_run_response
label: ft8
category: '[ft8]'
templates:
  imports: import ft8
  make: ft8.run_response(${ft8_button})
callbacks:
  - set_ft8(${ft8_button})
#  Make one 'parameters' list entry for every parameter you want 
settable from the GUI.

# Keys include:
# * id (makes the value accessible as keyname, e.g. in the make 
entry)

# * label (label shown in the GUI)
# * dtype (e.g. int, float, complex, byte, short, xxx_vector, ...)
# * default
parameters:
- id: ft8_button
  label: ft8_button
  dtype: raw
  default: 0
# 'file_format' specifies the version of the GRC yml format used in 
the file

#  and should usually not be changed.
file_format: 1
I have developed and used an OOT before without an issue. I looked 
at the previous OOT and reviewed the GNU Radio docs on OOTs without 
seeing anything different.

I am using Python 3.92 with GNU radio 3.9.4.0 on a Raspberry Pi.
I hope someone can show me the error of my ways.
Jim

<http://www.avg.com/email-signature?utm_medium=email_source=link_campaign=sig-email_content=emailclient> 
	Virus-free.www.avg.com 
<http://www.avg.com/email-signature?utm_medium=email_source=link_campaign=sig-email_content=emailclient> 

Re: Import error using an OOT

[Cinaed Simson]

The main method is defined beginning on line 216 and called 4 times on 
lines 36-39.


And it appears the configparser is throwing the NoSectionError.

Try commenting out line 36 to see if line 37 throws the same exception.

When you said is has run before, did it run under python3.9?

-- Cinaed


On 12/11/22 19:11, Elmore Family wrote:
I have attached the 2 files in question. Look at the beginning of 
run_response.py. It uses ConfigParser to access the ft8_qso.conf 
configuration file.
This line seems to be the problem: my_call = str(parser.get('main', 
'my_call_sign')).
But ‘main’ is a section in the ft8_qso.conf file. Why can’t it find 
‘main’?

Jim
*From:* Cinaed Simson
*Sent:* Sunday, December 11, 2022 8:52 PM
*To:* Elmore Family
*Cc:* discuss-gnuradio@gnu.org
*Subject:* Re: Import error using an OOT
The problem appears to be in the python code

  response.py

- there is no 'main()' method.

-- Cinaed

On 12/11/22 09:48, Elmore Family wrote:

Here is the result:

pi@raspberrypi:~ $ python3
Python 3.9.2 (default, Mar 12 2021, 04:06:34)
[GCC 10.2.1 20210110] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import ft8
Traceback (most recent call last):
File "", line 1, in 
File "/usr/local/lib/python3.9/dist-packages/ft8/__init__.py", line 
23, in 

from .run_response import run_response
File "/usr/local/lib/python3.9/dist-packages/ft8/run_response.py", 
line 36, in 

my_call = str(parser.get('main', 'my_call_sign'))
File "/usr/lib/python3.9/configparser.py", line 781, in get
d = self._unify_values(section, vars)
File "/usr/lib/python3.9/configparser.py", line 1149, in _unify_values
raise NoSectionError(section) from None
configparser.NoSectionError: No section: 'main'

Jim

*From:* Cinaed Simson
*Sent:* Sunday, December 11, 2022 12:15 AM
*To:* discuss-gnuradio@gnu.org
*Subject:* Re: Import error using an OOT
Type

   python3

then enter

  import ft8

and see if it works.

-- Cinaed


On 12/9/22 18:33, Elmore's wrote:
I have created an OOT which when I incorporate it in my flowgraph 
shows the following error:

Failed to evaluate import expression ‘import ft8’
The yaml file is:
id: ft8_run_response
label: ft8
category: '[ft8]'
templates:
  imports: import ft8
  make: ft8.run_response(${ft8_button})
  callbacks:
  - set_ft8(${ft8_button})
#  Make one 'parameters' list entry for every parameter you want 
settable from the GUI.

# Keys include:
# * id (makes the value accessible as keyname, e.g. in the make 
entry)

# * label (label shown in the GUI)
# * dtype (e.g. int, float, complex, byte, short, xxx_vector, ...)
# * default
parameters:
- id: ft8_button
  label: ft8_button
  dtype: raw
  default: 0
#  'file_format' specifies the version of the GRC yml format used in 
the file

#  and should usually not be changed.
file_format: 1
I have developed and used an OOT before without an issue. I looked 
at the previous OOT and reviewed the GNU Radio docs on OOTs without 
seeing anything different.

I am using Python 3.92 with GNU radio 3.9.4.0 on a Raspberry Pi.
I hope someone can show me the error of my ways.
Jim

<http://www.avg.com/email-signature?utm_medium=email_source=link_campaign=sig-email_content=emailclient> 
	Virus-free.www.avg.com 
<http://www.avg.com/email-signature?utm_medium=email_source=link_campaign=sig-email_content=emailclient> 

Re: Import error using an OOT

[Cinaed Simson]

The problem appears to be in the python code

  response.py

- there is no 'main()' method.

-- Cinaed

On 12/11/22 09:48, Elmore Family wrote:

Here is the result:

pi@raspberrypi:~ $ python3
Python 3.9.2 (default, Mar 12 2021, 04:06:34)
[GCC 10.2.1 20210110] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import ft8
Traceback (most recent call last):
File "", line 1, in 
File "/usr/local/lib/python3.9/dist-packages/ft8/__init__.py", line 
23, in 

from .run_response import run_response
File "/usr/local/lib/python3.9/dist-packages/ft8/run_response.py", 
line 36, in 

my_call = str(parser.get('main', 'my_call_sign'))
File "/usr/lib/python3.9/configparser.py", line 781, in get
d = self._unify_values(section, vars)
File "/usr/lib/python3.9/configparser.py", line 1149, in _unify_values
raise NoSectionError(section) from None
configparser.NoSectionError: No section: 'main'

Jim


*From:* Cinaed Simson
*Sent:* Sunday, December 11, 2022 12:15 AM
*To:* discuss-gnuradio@gnu.org
*Subject:* Re: Import error using an OOT
Type

   python3

then enter

  import ft8

and see if it works.

-- Cinaed


On 12/9/22 18:33, Elmore's wrote:
I have created an OOT which when I incorporate it in my flowgraph 
shows the following error:

Failed to evaluate import expression ‘import ft8’
The yaml file is:
id: ft8_run_response
label: ft8
category: '[ft8]'
templates:
  imports: import ft8
  make: ft8.run_response(${ft8_button})
  callbacks:
  - set_ft8(${ft8_button})
#  Make one 'parameters' list entry for every parameter you want 
settable from the GUI.

# Keys include:
# * id (makes the value accessible as keyname, e.g. in the make 
entry)

# * label (label shown in the GUI)
# * dtype (e.g. int, float, complex, byte, short, xxx_vector, ...)
# * default
parameters:
- id: ft8_button
  label: ft8_button
  dtype: raw
  default: 0
#  'file_format' specifies the version of the GRC yml format used in 
the file

#  and should usually not be changed.
file_format: 1
I have developed and used an OOT before without an issue. I looked at 
the previous OOT and reviewed the GNU Radio docs on OOTs without 
seeing anything different.

I am using Python 3.92 with GNU radio 3.9.4.0 on a Raspberry Pi.
I hope someone can show me the error of my ways.
Jim

<http://www.avg.com/email-signature?utm_medium=email_source=link_campaign=sig-email_content=emailclient> 
	Virus-free.www.avg.com 
<http://www.avg.com/email-signature?utm_medium=email_source=link_campaign=sig-email_content=emailclient> 

Re: Import error using an OOT

[Cinaed Simson]

Type

   python3

then enter

  import ft8

and see if it works.

-- Cinaed


On 12/9/22 18:33, Elmore's wrote:
I have created an OOT which when I incorporate it in my flowgraph 
shows the following error:

Failed to evaluate import expression ‘import ft8’
The yaml file is:
id: ft8_run_response
label: ft8
category: '[ft8]'
templates:
  imports: import ft8
  make: ft8.run_response(${ft8_button})
  callbacks:
  - set_ft8(${ft8_button})
#  Make one 'parameters' list entry for every parameter you want 
settable from the GUI.

# Keys include:
# * id (makes the value accessible as keyname, e.g. in the make entry)
# * label (label shown in the GUI)
# * dtype (e.g. int, float, complex, byte, short, xxx_vector, ...)
# * default
parameters:
- id: ft8_button
  label: ft8_button
  dtype: raw
  default: 0
#  'file_format' specifies the version of the GRC yml format used in 
the file

#  and should usually not be changed.
file_format: 1
I have developed and used an OOT before without an issue. I looked at 
the previous OOT and reviewed the GNU Radio docs on OOTs without 
seeing anything different.

I am using Python 3.92 with GNU radio 3.9.4.0 on a Raspberry Pi.
I hope someone can show me the error of my ways.
Jim

 
	Virus-free.www.avg.com 
 



<#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>

Re: Import error using an OOT

[Cinaed Simson]

Type

   python3

in a terminal window, then enter

  import ft8

and see what happens.

-- Cinaed


On 12/9/22 18:33, Elmore's wrote:
I have created an OOT which when I incorporate it in my flowgraph 
shows the following error:

Failed to evaluate import expression ‘import ft8’
The yaml file is:
id: ft8_run_response
label: ft8
category: '[ft8]'
templates:
  imports: import ft8
  make: ft8.run_response(${ft8_button})
  callbacks:
  - set_ft8(${ft8_button})
#  Make one 'parameters' list entry for every parameter you want 
settable from the GUI.

# Keys include:
# * id (makes the value accessible as keyname, e.g. in the make entry)
# * label (label shown in the GUI)
# * dtype (e.g. int, float, complex, byte, short, xxx_vector, ...)
# * default
parameters:
- id: ft8_button
  label: ft8_button
  dtype: raw
  default: 0
#  'file_format' specifies the version of the GRC yml format used in 
the file

#  and should usually not be changed.
file_format: 1
I have developed and used an OOT before without an issue. I looked at 
the previous OOT and reviewed the GNU Radio docs on OOTs without 
seeing anything different.

I am using Python 3.92 with GNU radio 3.9.4.0 on a Raspberry Pi.
I hope someone can show me the error of my ways.
Jim

 
	Virus-free.www.avg.com 
 



<#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>

Re: Import error using an OOT

[Cinaed Simson]

Hi Elmore - type

  apt list | grep python3-pygccxml

and see if it's version 1.x.

If it's not installed, then

  apt install python3-pygccxml

will install it.

Version 1.x only works with python code - it may be all you need.

If you need version 2, then it's easy to upgrade the system from 
bullseye to bookworm.


-- Cinaed


On 12/9/22 18:33, Elmore's wrote:
I have created an OOT which when I incorporate it in my flowgraph 
shows the following error:

Failed to evaluate import expression ‘import ft8’
The yaml file is:
id: ft8_run_response
label: ft8
category: '[ft8]'
templates:
  imports: import ft8
  make: ft8.run_response(${ft8_button})
  callbacks:
  - set_ft8(${ft8_button})
#  Make one 'parameters' list entry for every parameter you want 
settable from the GUI.

# Keys include:
# * id (makes the value accessible as keyname, e.g. in the make entry)
# * label (label shown in the GUI)
# * dtype (e.g. int, float, complex, byte, short, xxx_vector, ...)
# * default
parameters:
- id: ft8_button
  label: ft8_button
  dtype: raw
  default: 0
#  'file_format' specifies the version of the GRC yml format used in 
the file

#  and should usually not be changed.
file_format: 1
I have developed and used an OOT before without an issue. I looked at 
the previous OOT and reviewed the GNU Radio docs on OOTs without 
seeing anything different.

I am using Python 3.92 with GNU radio 3.9.4.0 on a Raspberry Pi.
I hope someone can show me the error of my ways.
Jim

 
	Virus-free.www.avg.com 
 



<#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>

Re: BW(Sample Rate) Issue

[Cinaed Simson]

Hi Rohith - if you post a copy of your GRC file - not an image of the 
GRC file - then someone on the list should be able to help you.


Also, I noticed you're trying to use the RRC with excess bandwidth - 
typically excessive bandwidth requires raising  the sampling rate.


And at the risk of over generalization, everything is dependent on the 
sampling rate.


And please state what it is you're trying to accomplish.

Have you working through any of the tutorials at

https://wiki.gnuradio.org/index.php?title=Tutorials

?

-- Cinaed


On 11/30/22 05:54, Rohith Rajan wrote:


I am asking a doubt regarding receiver usinge t an  Adalm Pluto SDRsff
In the receiver section we are using *Polyphase Clock Sync*, *Linear 
Equalizer* and *Costas Loop.*
My doubt is that is the configuration parameters of these blocks are 
dependent on the BW of the signal(Sample Rate)


Keeping the parameters as Normal  (*In Polyphase Clock Sync block*- No 
of filters(nfilts) as 32, Loop Bw .0628, RRC filter as


/firdes.root_raised_cosine(nfilts, nfilts, 1.0/float(sps), 0.35, 
11*sps*nfilts), sps as 4/


;* In Linear Equalize*r No of Taps as 15 ;In CostasLoop Loop BW as 
.0628) when I set the BW(sample Rate around)1MHz I can receive the datas.


But when I set the BW(Sample Rate) as 125KHz I cannot receive the datas.

Anyone plese tell me what modification I have to make ?

Re: BW(Sample Rate) Issue

[Cinaed Simson]

Hi Rohith - Ihe minim sampling rate  for the Pluto is in the ball park 
of 500 KHz.


See

https://ez.analog.com/adieducation/university-program/f/q-a/557730/pluto-sdr-sampling-rate

-- Cinaed


On 11/30/22 05:54, Rohith Rajan wrote:


I am asking a doubt regarding receiver using an  Adalm Pluto SDR
In the receiver section we are using *Polyphase Clock Sync*, *Linear 
Equalizer* and *Costas Loop.*
My doubt is that is the configuration parameters of these blocks are 
dependent on the BW of the signal(Sample Rate)


Keeping the parameters as Normal  (*In Polyphase Clock Sync block*- No 
of filters(nfilts) as 32, Loop Bw .0628, RRC filter as


/firdes.root_raised_cosine(nfilts, nfilts, 1.0/float(sps), 0.35, 
11*sps*nfilts), sps as 4/


;* In Linear Equalize*r No of Taps as 15 ;In CostasLoop Loop BW as 
.0628) when I set the BW(sample Rate around)1MHz I can receive the datas.


But when I set the BW(Sample Rate) as 125KHz I cannot receive the datas.

Anyone plese tell me what modification I have to make ?

Re: QT GUI Label error in v 3.10.1.1

[Cinaed Simson]

I'd recommend adding

  export QT_QPA_PLATFORM=wayland

to your

  $HOME/.bash_profile

file or your

  $HOME/.bashrc

file - if you feel comfortable editing files on Linux.

I prefer the .bashrc since this were I place all my exports and group 
them all together.


However, the .bashrc isn't as tolerant to errors as the .bash_profile file.

In either case make a backup of the file before you edit the file.

You can check the results after you login again by typing

   echo $QT_QPA_PLATFORM

-- Cinaed


On 11/28/22 13:05, Jose Ruvalcaba wrote:

HI Cinaed and Jeff,

Sorry for the late reply. I checked if I had the qt-6 wayland and 
xwayland installed. Turns out I didn't have the qt6-wayland installed 
so I installed it. The issue still remained so I disabled wayland and 
it seemed to work. Just like what you guys saw, I stopped seeing the 
issue on my flowgraph.


However, I attempted another flowgraph that used QT GUI Label and the 
issue came back. I have added the new flowgraph I created along with 
its generated code.


I am working from a WIndows machine that has  a Virtual Machine with 
Ubuntu 22.04. One quick question though: Where would I set the export 
QT_QPA_PLATFORM


Thanks,
Jose Ruvalcaba

On Thu, Nov 24, 2022 at 5:25 PM Cinaed Simson 
 wrote:


Hi Jose - I can run your script for hours without any issues on
both GR 3.8 and 3.10.

Have you tried setting

  export QT_QPA_PLATFORM=wayland

as indicated in the first error message - to see if the script
runs longer then 10 minutes?

My guess is if you eliminate the first exception the other
exceptions will disappear.

Are you working from the console of a linux machine - or are you
working from the console of a Windows machine - and then
connecting to the a Linux machine by some method?

-- Cinaed


On Tue, Nov 22, 2022 at 10:23 PM Jose Ruvalcaba
 wrote:


Hello,

I've been noticing an issue popping out everytime I stop
running my flowgraph and I was wondering if someone had some
insight on it. I have a flowgraph where a signal source is
connected to a probe signal block. This block is constantly
updating values and are being displayed using the QT GUI
Label block. However, after running my flowgraph for about 10
minutes I get the following error:

*/Executing: /usr/bin/python3 -u
/home/spacerfvm/Documents/GNURadio_3.10_flowgraphs/func_probe_test.py/*

*/
/*

*/Warning: Ignoring XDG_SESSION_TYPE=wayland on Gnome. Use
QT_QPA_PLATFORM=wayland to run on Wayland anyway./*

*/Exception in thread Thread-1 (_amp_probe):/*

*/Traceback (most recent call last):/*

*/  File
"/home/spacerfvm/Documents/GNURadio_3.10_flowgraphs/func_probe_test.py",
line 150, in _amp_probe/*

*/self.doc.add_next_tick_callback(functools.partial(self.set_amp,val))/*

*/  File
"/usr/lib/python3/dist-packages/gnuradio/gr/hier_block2.py",
line 88, in __getattr__/*

*/return getattr(self._impl, name)/*

*/AttributeError: 'gnuradio.gr.gr_python.top_block_pb' object
has no attribute 'doc'/*

*/
/*

*/During handling of the above exception, another exception
occurred:/*

*/
/*

*/Traceback (most recent call last):/*

*/  File "/usr/lib/python3.10/threading.py", line 1016, in
_bootstrap_inner/*

*/self.run()/*

*/  File "/usr/lib/python3.10/threading.py", line 953, in run/*

*/self._target(*self._args, **self._kwargs)/*

*/  File
"/home/spacerfvm/Documents/GNURadio_3.10_flowgraphs/func_probe_test.py",
line 152, in _amp_probe/*

*/self.set_amp(val)/*

*/  File
"/home/spacerfvm/Documents/GNURadio_3.10_flowgraphs/func_probe_test.py",
line 182, in set_amp/*

*/self.set_variable_qtgui_label_0(self.amp)/*

*/  File
"/home/spacerfvm/Documents/GNURadio_3.10_flowgraphs/func_probe_test.py",
line 189, in set_variable_qtgui_label_0/*

*/Qt.QMetaObject.invokeMethod(self._variable_qtgui_label_0_label,
"setText", Qt.Q_ARG("QString",

str(self._variable_qtgui_label_0_formatter(self.variable_qtgui_label_0/*

*/RuntimeError: wrapped C/C++ object of type QLabel has been
deleted/*

*//*


It seems that my issue is related to the QT GUI Label block
because when I remove it and add say QT GUI Number sink, this
issue doesn't appear.


Has anyone experienced this issue? If so, would anyone be
able to steer me in the direction to fix it? I am currently
running on Ubuntu 22.04 and am running GNU RADIO 3.10.1.1
which I installed using sudo apt-get install. I've also
attached the flowgraph I am talking about.


Thanks,

Jose Ruvalcaba

Re: QT GUI Label error in v 3.10.1.1

[Cinaed Simson]

Hi Jose - I can run your script for hours without any issues on both GR 
3.8 and 3.10.


Have you tried setting

  export QT_QPA_PLATFORM=wayland

as indicated in the first error message - to see if the script runs 
longer then 10 minutes?


My guess is if you eliminate the first exception the other exceptions 
will disappear.


Are you working from the console of a linux machine - or are you working 
from the console of a Windows machine - and then connecting to the a 
Linux machine by some method?


-- Cinaed


On Tue, Nov 22, 2022 at 10:23 PM Jose Ruvalcaba  wrote:


Hello,

I've been noticing an issue popping out everytime I stop running
my flowgraph and I was wondering if someone had some insight on
it. I have a flowgraph where a signal source is connected to a
probe signal block. This block is constantly updating values and
are being displayed using the QT GUI Label block. However, after
running my flowgraph for about 10 minutes I get the following error:

*/Executing: /usr/bin/python3 -u
/home/spacerfvm/Documents/GNURadio_3.10_flowgraphs/func_probe_test.py/*

*/
/*

*/Warning: Ignoring XDG_SESSION_TYPE=wayland on Gnome. Use
QT_QPA_PLATFORM=wayland to run on Wayland anyway./*

*/Exception in thread Thread-1 (_amp_probe):/*

*/Traceback (most recent call last):/*

*/  File
"/home/spacerfvm/Documents/GNURadio_3.10_flowgraphs/func_probe_test.py",
line 150, in _amp_probe/*

*/self.doc.add_next_tick_callback(functools.partial(self.set_amp,val))/*

*/  File
"/usr/lib/python3/dist-packages/gnuradio/gr/hier_block2.py", line
88, in __getattr__/*

*/return getattr(self._impl, name)/*

*/AttributeError: 'gnuradio.gr.gr_python.top_block_pb' object has
no attribute 'doc'/*

*/
/*

*/During handling of the above exception, another exception
occurred:/*

*/
/*

*/Traceback (most recent call last):/*

*/  File "/usr/lib/python3.10/threading.py", line 1016, in
_bootstrap_inner/*

*/self.run()/*

*/  File "/usr/lib/python3.10/threading.py", line 953, in run/*

*/self._target(*self._args, **self._kwargs)/*

*/  File
"/home/spacerfvm/Documents/GNURadio_3.10_flowgraphs/func_probe_test.py",
line 152, in _amp_probe/*

*/self.set_amp(val)/*

*/  File
"/home/spacerfvm/Documents/GNURadio_3.10_flowgraphs/func_probe_test.py",
line 182, in set_amp/*

*/self.set_variable_qtgui_label_0(self.amp)/*

*/  File
"/home/spacerfvm/Documents/GNURadio_3.10_flowgraphs/func_probe_test.py",
line 189, in set_variable_qtgui_label_0/*

*/Qt.QMetaObject.invokeMethod(self._variable_qtgui_label_0_label,
"setText", Qt.Q_ARG("QString",
str(self._variable_qtgui_label_0_formatter(self.variable_qtgui_label_0/*

*/RuntimeError: wrapped C/C++ object of type QLabel has been deleted/*

*//*


It seems that my issue is related to the QT GUI Label block
because when I remove it and add say QT GUI Number sink, this
issue doesn't appear.


Has anyone experienced this issue? If so, would anyone be able to
steer me in the direction to fix it? I am currently running on
Ubuntu 22.04 and am running GNU RADIO 3.10.1.1 which I installed
using sudo apt-get install. I've also attached the flowgraph I am
talking about.


Thanks,

Jose Ruvalcaba

Re: QT GUI Label error in v 3.10.1.1

[Cinaed Simson]

Hi Jose - since it's complaining about wayland, check to see if the 
following software is installed


   qt6-wayland
   xwayland

On debian systems, type

  apt list --installed | grep wayland

to see what's installed.

wayland is efficient way to connect to your desktop.

-- Cinaed


On 11/22/22 19:22, Jose Ruvalcaba wrote:

Hello,

I've been noticing an issue popping out everytime I stop running my 
flowgraph and I was wondering if someone had some insight on it. I 
have a flowgraph where a signal source is connected to a probe signal 
block. This block is constantly updating values and are being 
displayed using the QT GUI Label block. However, after running my 
flowgraph for about 10 minutes I get the following error:


*/Executing: /usr/bin/python3 -u 
/home/spacerfvm/Documents/GNURadio_3.10_flowgraphs/func_probe_test.py/*


*/
/*

*/Warning: Ignoring XDG_SESSION_TYPE=wayland on Gnome. Use 
QT_QPA_PLATFORM=wayland to run on Wayland anyway./*


*/Exception in thread Thread-1 (_amp_probe):/*

*/Traceback (most recent call last):/*

*/  File 
"/home/spacerfvm/Documents/GNURadio_3.10_flowgraphs/func_probe_test.py", 
line 150, in _amp_probe/*


*/self.doc.add_next_tick_callback(functools.partial(self.set_amp,val))/*

*/  File "/usr/lib/python3/dist-packages/gnuradio/gr/hier_block2.py", 
line 88, in __getattr__/*


*/return getattr(self._impl, name)/*

*/AttributeError: 'gnuradio.gr.gr_python.top_block_pb' object has no 
attribute 'doc'/*


*/
/*

*/During handling of the above exception, another exception occurred:/*

*/
/*

*/Traceback (most recent call last):/*

*/  File "/usr/lib/python3.10/threading.py", line 1016, in 
_bootstrap_inner/*


*/self.run()/*

*/  File "/usr/lib/python3.10/threading.py", line 953, in run/*

*/self._target(*self._args, **self._kwargs)/*

*/  File 
"/home/spacerfvm/Documents/GNURadio_3.10_flowgraphs/func_probe_test.py", 
line 152, in _amp_probe/*


*/self.set_amp(val)/*

*/  File 
"/home/spacerfvm/Documents/GNURadio_3.10_flowgraphs/func_probe_test.py", 
line 182, in set_amp/*


*/self.set_variable_qtgui_label_0(self.amp)/*

*/  File 
"/home/spacerfvm/Documents/GNURadio_3.10_flowgraphs/func_probe_test.py", 
line 189, in set_variable_qtgui_label_0/*


*/Qt.QMetaObject.invokeMethod(self._variable_qtgui_label_0_label, 
"setText", Qt.Q_ARG("QString", 
str(self._variable_qtgui_label_0_formatter(self.variable_qtgui_label_0/*


*/RuntimeError: wrapped C/C++ object of type QLabel has been deleted/*

*//*


It seems that my issue is related to the QT GUI Label block because 
when I remove it and add say QT GUI Number sink, this issue doesn't 
appear.



Has anyone experienced this issue? If so, would anyone be able to 
steer me in the direction to fix it? I am currently running on Ubuntu 
22.04 and am running GNU RADIO 3.10.1.1 which I installed using sudo 
apt-get install. I've also attached the flowgraph I am talking about.



Thanks,

Jose Ruvalcaba

Re: Σχετ: Re: Pluto sink power issues

[Cinaed Simson]

Hi George - it may be a bug which may have been fixed in May of this year.

See

https://github.com/gnuradio/gnuradio/pull/5860
  gr-iio: fix grc pluto sink attenuation callback #5860

merged in 3.10  on May 19, 2022.

They may be able to help you.

-- Cinaed



On 11/20/22 21:24, George Katsimaglis wrote:

Hello again,

I have not seen any reaction yet.
Is this a bug or a misconfiguration of me?

Best regards
George SV1BDS


Στάλθηκε από το Ταχυδρομείο Yahoo σε Android 



Στις Τετ, 16 Νοε, 2022 στις 15:59, ο χρήστηςGeorge Katsimaglis
 έγραψε:
Hello,

Via desktop environment, not by hand.

Best regards

Στάλθηκε από το Ταχυδρομείο Yahoo σε Android



Στις Τετ, 16 Νοε, 2022 στις 14:59, ο χρήστηςMarcus Müller
 έγραψε:
It looks like your call to set_attenuation() is missing the
channel argument. Now, this
could be a bug on the GNU Radio end or your end: How did that
PlutoIMD.py get created?

Best,
Marcus

On 16.11.22 12:08, George Katsimaglis wrote:
>
> Hello,
>
> I have two issues about Pluto sink attenuation (Tx power)
for 3.10.1.1.
> In previous versions with attenuation 0 it produces about 0
dBm output for a single
> frequency output.
> Now it gives about -22 dBm.
> Also when I try to change attenuation from 0 to 1 using a QT
range :
>
> File
"/usr/lib/python3/dist-packages/gnuradio/qtgui/range.py", line
240, in changed
> self.notifyChanged(self.rangeType(value))
>    File
"/usr/lib/python3/dist-packages/gnuradio/qtgui/range.py", line
316, in counterChanged
> self.notifyChanged(self.rangeType(value))
>    File "/home/sv1bds/Documents/GNURadio/PlutoIMD.py", line
125, in set_txatten
> self.iio_pluto_sink_0.set_attenuation(self.txatten)
> TypeError: set_attenuation(): incompatible function
arguments. The following argument
> types are supported:
>      1. (self: gnuradio.iio.iio_python.fmcomms2_sink_fc32,
chan: int, attenuation: float)
> -> None
>
> Invoked with: , 1.0
>
> is displayed and attenuation does not change
>
> George SV1BDS
>

Re: Running flowfraph dies with segfault with GR 3.10.4 (gr-fosphor)

[Cinaed Simson]

Hi Vasil - when I checked out gr-fosphor from

  https://github.com/osmocom/gr-fosphor.git

it appeared the only versions supported using were

  3.7, 3.8

It's possible it's supported under under master - I didn't try.

Or maybe you have different author.

-- Cinaed


On 10/28/22 06:24, Ville Eerola wrote:

Hi all,

I used to have a working flowgraph developed with GR 3.10.2, but after 
update to GR 3.10.4 it just ends with a segmentation fault.


Now some details:
- I'm running Ubuntu 22.04, which is kept up to date.
- GR is installed from PPA 
https://ppa.launchpadcontent.net/gnuradio/gnuradio-releases/ubuntu/ 
jammy main
- GR was automatically updated with Software Updater (from 3.10.2 -> 
3.10.4)
- The flowgraph is using a gr-fosphor (Osmosdr) spectrum display 
(fosphor_qt_sink) (Two of them)
- The data comes from a Soapy BladeRF Source, which seems to 
initialize correctly
- If I disable the Fosphor displays (using "Disable" in GRC), the 
flowgraph runs just fine
- With the Fosphor displays enabled, the Flowgraph prints out the 
normal BladeRF initialization messages, and then "Done (return code 
-11)". When running the Python code from command line, instead of 
"Done", it prints out "Segmentation fault (core dumped)"


- In order to rectify this I have updated all the OOT modules from 
Osmocom, which I had previously installed with:

$ cd /
$ rm -rf build;
$ git fetch
$ git pull
$ mkdir build; cd build
$ cmake -DCMAKE_INSTALL_PREFIX=/usr -DBUILD_SHARED_LIBS=true ../
$ make
$ sudo make install; sudo ldconfig

But, this did not help

I was able to make a reduced testcase with just a Signal Source 
connected to the Fosphor Sink (Qt), and this segfaults in similar 
fashion to my full model.



Regards, Ville
--
Ville Eerola
ville.eer...@iki.fi
050-4804435

Re: Help Needed for "firdes.root_raised_cosine"

[Cinaed Simson]

See

https://wiki.gnuradio.org/index.php?title=SuggestedReading

-- CInaed

On 11/1/22 00:35, Shuvodip Majumdar wrote:

Hello Cinaed,

My doubt is not about the data types. It's about what the fields 
signify, e.g. symbol rate, sampling rate, excess bandwidth etc.


Regards,
Shuvodip

On Tue, Nov 1, 2022 at 12:49 PM Cinaed Simson 
 wrote:


Hi Shuvodip - if  the blocks have the same color, then they have the
same data type - but not necessarily the same value.

What version of gnuradio are you using?

-- Cinaed


On 10/31/22 21:41, Shuvodip Majumdar wrote:
> Dear all,
>
> I am currently going through the tutorials of GNU Radio. Here I
have
> doubts on "firdes.root_raised_cosine".
>
> For example, in the "QPSK Mod and Demod" chapter,
> "firdes.root_raised_cosine" has been used where there are five
types
> of data inside the bracket after "firdes.root_raised_cosine".
What do
> these data fields mean?
>
> Thanks in advance.
>
> With regards,
> Shuvodip

Re: Help Needed for "firdes.root_raised_cosine"

[Cinaed Simson]

Hi Shuvodip - if  the blocks have the same color, then they have the 
same data type - but not necessarily the same value.


What version of gnuradio are you using?

-- Cinaed


On 10/31/22 21:41, Shuvodip Majumdar wrote:

Dear all,

I am currently going through the tutorials of GNU Radio. Here I have 
doubts on "firdes.root_raised_cosine".


For example, in the "QPSK Mod and Demod" chapter, 
"firdes.root_raised_cosine" has been used where there are five types 
of data inside the bracket after "firdes.root_raised_cosine". What do 
these data fields mean?


Thanks in advance.

With regards,
Shuvodip

Re: Problems with gr-modtool on Ubuntu 20.04 (gnuradio 3.10.4)

[Cinaed Simson]

The warnings are for the developers.

It's clear cmake is working.

In the output of the trace there are 2-3 non-existent paths which appear 
to be related to the absolute path.


  "$HOME/gr-customModule/include/gnuradio/customModule"

If the absolute path gets clipped to "/include/gnuradio/customModule" , 
then


  "/include"

would become an non-existent directory since there is no "/include" 
directory on Linux.


And hence all directories below it would become nonexistent and cmake 
crashes and burns.


It's more likely it could be operator error of  gr-modtool then a 
problem with cmake.


-- Cinaed


On 10/18/22 14:47, Michael Matthews wrote:


Hey Ryan,

I went ahead and ran that cmake trace and it did produce something 
interesting.  I seems that two cmake policies are not set and both 
have the behavior to not throw warnings by default. The offending 
policies are:


- CMP0060

- CMP0082

CMP0060 is defined by the cmake documentation as "Link libraries by 
full path even in implicit directories".


CMake does allow projects to override this behavior by using an 
IMPORTED library target with its IMPORTED_LOCATION property set to the 
desired full path to a library file. In fact, many Find Modules are 
learning to provide Imported Targets instead of just the traditional 
Foo_LIBRARIES variable listing library files. However, this makes the 
link line generated for a library found by a Find Module depend on 
whether it is linked through an imported target or not, which is 
inconsistent. Furthermore, this behavior has been a source of 
confusion because the generated link line for a library file depends 
on its location. It is also problematic for projects trying to link 
statically because flags like -Wl,-Bstatic -lfoo -Wl,-Bdynamic may be 
used to help the linker select libfoo.a instead of libfoo.so but then 
leak dynamic linking to following libraries. (See the 
LINK_SEARCH_END_STATIC target property for a solution typically used 
for that problem.)


When the special case for libraries in implicit link directories was 
first introduced the list of implicit link directories was simply 
hard-coded (e.g. /lib, /usr/lib, and a few others). Since that time, 
CMake has learned to detect the implicit link directories used by the 
compiler front-end. If necessary, the find_library() command could be 
taught to use this information to help find libraries of the proper 
architecture.


For these reasons, CMake 3.3 and above prefer to drop the special case 
and link libraries by full path even when they are in implicit link 
directories. Policy CMP0060 provides compatibility for existing projects.


The OLD behavior for this policy is to ask the linker to search for 
libraries whose full paths are known to be in implicit link 
directories. The NEW behavior for this policy is to link libraries by 
full path even if they are in implicit link directories.


CMP0082 is defined by the cmake documentation as “Install rules from 
add_subdirectory() calls are interleaved with those in caller”.


CMake 3.13 and lower ran the install rules from add_subdirectory() 
after all other install rules, even if add_subdirectory() was called 
before the other install rules. CMake 3.14 and above prefer to 
interleave these add_subdirectory() install rules with the others so 
that they are run in the order they are declared. This policy provides 
compatibility for projects that have not been updated to expect the 
new behavior.


The OLD behavior for this policy is to run the install rules from 
add_subdirectory() after the other install rules. The NEW behavior for 
this policy is to run all install rules in the order they are declared.


My best guess is that CMP0060 is the primary offending issue on my 
system. I am as familiar with cmake policies as I am with other build 
systems. Would either or both need to be explicitly declared in the 
cmake files? I am running cmake 3.16.3 which is above the minimum 
(3.8) in the root CMakeLists.txt. CMP0082 is the only policy warning 
here that was defined after the minimum version.


Thank you for your help,

Michael

PS.

The trace output I received is below:

~/gr-customModule/build$ cmake .. 
--trace-source=/usr/lib/x86_64-linux-gnu/cmake/gnuradio/gnuradio-runtimeTargets.cmake


-- The CXX compiler identification is GNU 9.4.0

-- The C compiler identification is GNU 9.4.0

-- Check for working CXX compiler: /usr/bin/c++

-- Check for working CXX compiler: /usr/bin/c++ -- works

-- Detecting CXX compiler ABI info

-- Detecting CXX compiler ABI info - done

-- Detecting CXX compile features

-- Detecting CXX compile features - done

-- Check for working C compiler: /usr/bin/cc

-- Check for working C compiler: /usr/bin/cc -- works

-- Detecting C compiler ABI info

-- Detecting C compiler ABI info - done

-- Detecting C compile features

-- Detecting C compile features - done

-- Looking for pthread.h

-- Looking for pthread.h - found

-- Performing Test CMAKE_HAVE_LIBC_PTHREAD

-- 

Re: Problems with gr-modtool on Ubuntu 20.04 (gnuradio 3.10.4)

[Cinaed Simson]

Try this

  cd $HOME/gr-customModule
  rm -fr build
  mkdir build
  cd build
  cmake --debug-output .. >& build.log

The first couple of lines should have entries which look something like:

  /usr/share/cmake-3.18/Modules

Also, if you

cd $HOME/gr-customModule/build
  grep ROOT CMakeCache.txt

this will tell you where your cmake ROOT is located.

There are also 2 other log files in

$HOME/gr-customModule/build/CMakeFiles
 CMakeError.log
 CMakeOutput.log

-- Cinaed


On 10/17/22 20:56, Michael Matthews wrote:


Hi Cinaed,

Yes, sorry that was a typo. The flag I have been using is:

-DCMAKE_FIND_ROOT_PATH=/usr  (not =usr/)

Running

cmake ..

from

$HOME/gr-customModule/build

without that flag still results in the error.

I am unsure what you mean by remove CMAKE_FIND_ROOT_PATH, are you 
saying you believe I need to alter my cmake installation for this to 
work without the flag?


Doing some more digging through the wiki, I did find that I could 
check my gnuradio configuration information using 
gnuradio-config-info. If I run


gnuradio-config-info –prefix

I get:

/usr/

If this is related to the cmake root path, it seems to be set 
correctly by default when I installed gnuradio through the ppa.


I also tried upgrading my version of cmake to see if that would help. 
I removed the old version using apt (3.16.3) and installed the one 
managed through snap (3.24.2). This however did not solve the issue.


I am going to try uninstalling gnuradio with apt again, but will build 
gnuradio from source instead, and see if there have been any changes 
that may have fixed this. If not, and if there are no objections, I am 
inclined to submit an issue ticket since there seems to be problems 
with the cmake imported targets


  * gnuradio::gnuradio-runtime
  * Boost::date_time

When building an OOT using gr_modtool on fresh installs of v3.10.4.0 
and Ubuntu 20.04.


Thank you,

Michael Matthews
Graduate Software Engineer
Mobile: +1 847 714 4809


Micro-X <https://micro-x.com>

855 South 192nd St, Suite 600
SeaTac, WA, 98148, United States
*www.micro-x.com <https://micro-x.com>*

*From:*Cinaed Simson 
*Sent:* Monday, October 17, 2022 4:41 PM
*To:* Michael Matthews ; GNURadio Discussion 
List 

*Subject:* Re: Problems with gr-modtool on Ubuntu 20.04 (gnuradio 3.10.4)

The cmake flag

-DCMAKE_FIND_ROOT_PATH=usr/

has an incorrect root element - it's root element.

Make sure the CMAKE_FIND_ROOT_PATH defined by you has been removed.

Then start a new build:

  cd $HOME/gr-customModule
   rm -fr build
   mkdir bulid
   cd build
   cmake ..

-- Cinaed

On 10/17/22 11:43, Michael Matthews wrote:

Hi Cinaed,

I took your suggestion of making the customModule with gr-modtool
at the $HOME directory, in case this may be required. The tutorial
implied this was not necessary, but I gave it a shot anyway.
Invoking cmake from

$HOME/gr-customModule/build

as

cmake ..

resulted in no change and the error is still present if I do not
use the flag:

-DCMAKE_FIND_ROOT_PATH=usr/

When you mention there are 9 CMakeLists.txt files in your
directory, I believe those are the same as I listed. Could you
clarify if you have any outside those specific paths I mentioned?

I also wanted to follow up on your suggestion that I should not be
seeing the line
   -- Using install prefix: /usr/local

in my cmake output. It seems that that is printed from
$HOME/gr-customModule/lib/CMakeLists.txt line 47 (in the print
summary section). It prints CMAKE_INSTALL_PREFIX, which is
/usr/local by default on UNIX systems according to cmake
documentation. Could you also clarify what I should be seeing instead?

You also mention that if invoking cmake doesn’t work, it most
likely operator error. Again, I am new to gnuradio and I am unsure
what that error would be. I followed the tutorials verbatim. I am
running gnuradio 3.10.4, cmake 3.16.3, and Ubuntu 20.04.

I have tested this now on two clean VM installs of Ubuntu 20.04
and gnuradio 3.10.4 (through the apt PPA) and am still seeing this
error.

I appreciate the help! Cheers,

Michael Matthews
Graduate Software Engineer
Mobile: +1 847 714 4809



Micro-X

<https://aus01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmicro-x.com%2F=05%7C01%7Cmmatthews%40micro-x.com%7C287cb7d25ae24c04f20a08dab098ef66%7Cad206e7b8a5d4d9aabf6ab3a9fd2c934%7C0%7C0%7C638016468167854213%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C=vgFUEsxxOnxgHAJR4AtreU1EuzZAUn34IaggxushrDA%3D=0>

855 South 192nd St, Suite 600
SeaTac, WA, 98148, United States
*www.micro-x.com

<https://aus01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmicro-x.com%2F=05%7C01%7Cmmatthews%40micro-x.com%7C287cb7d25ae24c04f20a08dab098ef66%7Cad206e7b8a5d4d9aabf6ab3a9fd2c934%7C0%7C0%7C

Re: Discuss-gnuradio Digest, Vol 240, Issue 15

[Cinaed Simson]

Thanks - stupid me.

But you did get me thinking.

See

https://wiki.gnuradio.org/index.php/Packet_Communications#Using_BPSK_with_Hardware_Simulation_(version_3.9) 



- if you haven't already taken a  look.

I'm using it to test a new install of 3.10.4 remotely - but I had to 
replace a couple pdu/stream blocks from 3.10.


Works great!

And it uses zmq for the hardware source and sink - so I don't need to 
have any hardware connected to the remote machine.


-- Cinaed


On 10/14/22 22:28, Rohith Rajan wrote:

Re: Help For Packet Reception in GNU Radio

Hi Cinaed
hdr simply means header format. I am adding preamble and header to the
payload (data packet ) using
*digital.header_format_default(digital.packet_utils.default_access_code, 
0) *


Thank You
Rohith R

On Fri, Oct 14, 2022 at 9:34 PM  wrote:

Send Discuss-gnuradio mailing list submissions to
discuss-gnuradio@gnu.org

To subscribe or unsubscribe via the World Wide Web, visit
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
or, via email, send a message with subject or body 'help' to
discuss-gnuradio-requ...@gnu.org

You can reach the person managing the list at
discuss-gnuradio-ow...@gnu.org

When replying, please edit your Subject line so it is more specific
than "Re: Contents of Discuss-gnuradio digest..."


Today's Topics:

   1. Re: Help For Packet Reception in GNU Radio (Cinaed Simson)


--

Message: 1
Date: Thu, 13 Oct 2022 21:24:43 -0700
From: Cinaed Simson 
To: discuss-gnuradio@gnu.org
Subject: Re: Help For Packet Reception in GNU Radio
Message-ID: 
Content-Type: text/plain; charset=UTF-8; format=flowed

Hi Rohith - in the Protocol Formatter,  the hdr_format, I'm fairly
certain the hdr denotes "High Dynamic Range" used in imaging - TV
images
for instance.

In which case, it may easily generate 4 times the data then your
sentence contains in bits.

-- Cinaed

On 10/13/22 02:17, Rohith Rajan wrote:
> Hello,
> I am  doing Packet Transmission and Reception using Adalm Pluto
SDR in
> GNu radio companion. I am transmitting text file(.txt file with one
> sentence ) using one adalm pluto and receiving it   using 2nd adalm
> pluto. But while receiving there is much more noise and I can't
> properly receive the packet that I transmitted.
>
> Here I am attaching the .grc file and the images of the
> constellation diagrams.
>
> Please help me to receive the packet successfully
>
> Thank You
> Rohith R




--

Subject: Digest Footer

___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio


--

End of Discuss-gnuradio Digest, Vol 240, Issue 15
*

Re: Help For Packet Reception in GNU Radio

[Cinaed Simson]

Hi Rohith - in the Protocol Formatter,  the hdr_format, I'm fairly 
certain the hdr denotes "High Dynamic Range" used in imaging - TV images 
for instance.


In which case, it may easily generate 4 times the data then your 
sentence contains in bits.


-- Cinaed

On 10/13/22 02:17, Rohith Rajan wrote:

Hello,
I am  doing Packet Transmission and Reception using Adalm Pluto SDR in 
GNu radio companion. I am transmitting text file(.txt file with one 
sentence ) using one adalm pluto and receiving it   using 2nd adalm 
pluto. But while receiving there is much more noise and I can't 
properly receive the packet that I transmitted.


Here I am attaching the .grc file and the images of the 
constellation diagrams.


Please help me to receive the packet successfully

Thank You
Rohith R

Re: Problems with gr-modtool on Ubuntu 20.04 (gnuradio 3.10.4)

[Cinaed Simson]

Oops - you should only be invoking cmake once - not twice - as I implied 
in my reply.


It's cmake then make.

-- Cinaed


On 10/8/22 16:28, Cinaed Simson wrote:

Hi Michael - you really need to show where and how you're invoking cmake.

The first time you invoke cmake in the ./build directory it should be as

  cmake ..

so it can create the

   lib/CMakeLists.txt

which incidentally, it can't find.

Also, you should NOT be seeing this entry

   -- Using install prefix: /usr/local

the first time you invoke cmake.

Otherwise, my guess is you're just invoking cmake incorrectly.

If you have an alias for cmake try using

  \cmake ..

the first time you run cmake which will override the alias.

-- Cinaed


On 10/2/22 22:21, Michael Matthews wrote:


Hello,

I am new to gnuradio and have been going through the tutorials. I 
have been specifically interested in Creating C++  OOT with 
gr-modtool 
<https://wiki.gnuradio.org/index.php?title=Creating_c%2B%2B_OOT_with_gr-modtool> 
but I seem to be getting errors when trying to use cmake to create 
the make files.


My cmake errors are:

-- The CXX compiler identification is GNU 9.4.0

-- The C compiler identification is GNU 9.4.0

-- Check for working CXX compiler: /bin/c++

-- Check for working CXX compiler: /bin/c++ -- works

-- Detecting CXX compiler ABI info

-- Detecting CXX compiler ABI info - done

-- Detecting CXX compile features

-- Detecting CXX compile features - done

-- Check for working C compiler: /bin/cc

-- Check for working C compiler: /bin/cc -- works

-- Detecting C compiler ABI info

-- Detecting C compiler ABI info - done

-- Detecting C compile features

-- Detecting C compile features - done

-- Looking for pthread.h

-- Looking for pthread.h - found

-- Performing Test CMAKE_HAVE_LIBC_PTHREAD

-- Performing Test CMAKE_HAVE_LIBC_PTHREAD - Failed

-- Looking for pthread_create in pthreads

-- Looking for pthread_create in pthreads - not found

-- Looking for pthread_create in pthread

-- Looking for pthread_create in pthread - found

-- Found Threads: TRUE

-- Found PkgConfig: /bin/pkg-config (found version "0.29.1")

-- Checking for module 'gmp'

--   Found gmp, version 6.2.0

-- Found GMP: /usr/lib/x86_64-linux-gnu/libgmpxx.so

-- Using GMP.

-- Found MPLIB: /usr/lib/x86_64-linux-gnu/libgmpxx.so

-- Found Boost: 
/lib/x86_64-linux-gnu/cmake/Boost-1.71.0/BoostConfig.cmake (found 
suitable version "1.71.0", minimum required is "1.71.0") found 
components: date_time program_options system regex thread 
unit_test_framework


-- Found Volk: Volk::volk

-- User set python executable /usr/bin/python3

-- Found PythonInterp: /usr/bin/python3 (found version "3.8.10")

-- Found PythonLibs: /usr/lib/x86_64-linux-gnu/libpython3.8.so (found 
suitable exact version "3.8.10")


-- Check if the system is big endian

-- Searching 16 bit integer

-- Looking for sys/types.h

-- Looking for sys/types.h - found

-- Looking for stdint.h

-- Looking for stdint.h - found

-- Looking for stddef.h

-- Looking for stddef.h - found

-- Check size of unsigned short

-- Check size of unsigned short - done

-- Using unsigned short

-- Check if the system is big endian - little endian

-- Performing Test HAVE_VISIBILITY_HIDDEN

-- Performing Test HAVE_VISIBILITY_HIDDEN - Success

-- Performing Test HAVE_WARN_SIGN_COMPARE

-- Performing Test HAVE_WARN_SIGN_COMPARE - Success

-- Performing Test HAVE_WARN_ALL

-- Performing Test HAVE_WARN_ALL - Success

-- Performing Test HAVE_WARN_NO_UNINITIALIZED

-- Performing Test HAVE_WARN_NO_UNINITIALIZED - Success

-- Found Git: /bin/git

-- Found Doxygen: /usr/local/bin/doxygen (found version "1.9.5 
(2f6875a5ca481a69a6f32650c77a667f87d25e88)") found components: 
doxygen missing components: dot


-- Using install prefix: /usr/local

-- Building for version: 1.0.0.0 / 1.0.0

-- No C++ unit tests... skipping

-- PYTHON and GRC components are enabled

-- Python checking for pygccxml - found

-- Found PythonLibs: /usr/lib/x86_64-linux-gnu/libpython3.8.so

-- Performing Test HAS_FLTO

-- Performing Test HAS_FLTO - Success

-- LTO enabled

-- Configuring done

CMake Error in lib/CMakeLists.txt:

  Imported target "gnuradio::gnuradio-runtime" includes non-existent path

    "/include"

  in its INTERFACE_INCLUDE_DIRECTORIES. Possible reasons include:

  * The path was deleted, renamed, or moved to another location.

  * An install or uninstall procedure did not complete successfully.

  * The installation package was faulty and references files it does not

  provide.

CMake Error in lib/CMakeLists.txt:

  Imported target "gnuradio::gnuradio-runtime" includes non-existent path

    "/include"

  in its INTERFACE_INCLUDE_DIRECTORIES. Possible reasons include:

  * The path was deleted, renamed, or moved to another location.

  * An install or uninstall procedure did not complete successfully.

  * The installation package was fault

Re: Problems with gr-modtool on Ubuntu 20.04 (gnuradio 3.10.4)

[Cinaed Simson]

Hi Michael - you really need to show where and how you're invoking cmake.

The first time you invoke cmake in the ./build directory it should be as

  cmake ..

so it can create the

   lib/CMakeLists.txt

which incidentally, it can't find.

Also, you should NOT be seeing this entry

   -- Using install prefix: /usr/local

the first time you invoke cmake.

Otherwise, my guess is you're just invoking cmake incorrectly.

If you have an alias for cmake try using

  \cmake ..

the first time you run cmake which will override the alias.

-- Cinaed


On 10/2/22 22:21, Michael Matthews wrote:


Hello,

I am new to gnuradio and have been going through the tutorials. I have 
been specifically interested in Creating C++  OOT with gr-modtool 
 
but I seem to be getting errors when trying to use cmake to create the 
make files.


My cmake errors are:

-- The CXX compiler identification is GNU 9.4.0

-- The C compiler identification is GNU 9.4.0

-- Check for working CXX compiler: /bin/c++

-- Check for working CXX compiler: /bin/c++ -- works

-- Detecting CXX compiler ABI info

-- Detecting CXX compiler ABI info - done

-- Detecting CXX compile features

-- Detecting CXX compile features - done

-- Check for working C compiler: /bin/cc

-- Check for working C compiler: /bin/cc -- works

-- Detecting C compiler ABI info

-- Detecting C compiler ABI info - done

-- Detecting C compile features

-- Detecting C compile features - done

-- Looking for pthread.h

-- Looking for pthread.h - found

-- Performing Test CMAKE_HAVE_LIBC_PTHREAD

-- Performing Test CMAKE_HAVE_LIBC_PTHREAD - Failed

-- Looking for pthread_create in pthreads

-- Looking for pthread_create in pthreads - not found

-- Looking for pthread_create in pthread

-- Looking for pthread_create in pthread - found

-- Found Threads: TRUE

-- Found PkgConfig: /bin/pkg-config (found version "0.29.1")

-- Checking for module 'gmp'

--   Found gmp, version 6.2.0

-- Found GMP: /usr/lib/x86_64-linux-gnu/libgmpxx.so

-- Using GMP.

-- Found MPLIB: /usr/lib/x86_64-linux-gnu/libgmpxx.so

-- Found Boost: 
/lib/x86_64-linux-gnu/cmake/Boost-1.71.0/BoostConfig.cmake (found 
suitable version "1.71.0", minimum required is "1.71.0") found 
components: date_time program_options system regex thread 
unit_test_framework


-- Found Volk: Volk::volk

-- User set python executable /usr/bin/python3

-- Found PythonInterp: /usr/bin/python3 (found version "3.8.10")

-- Found PythonLibs: /usr/lib/x86_64-linux-gnu/libpython3.8.so (found 
suitable exact version "3.8.10")


-- Check if the system is big endian

-- Searching 16 bit integer

-- Looking for sys/types.h

-- Looking for sys/types.h - found

-- Looking for stdint.h

-- Looking for stdint.h - found

-- Looking for stddef.h

-- Looking for stddef.h - found

-- Check size of unsigned short

-- Check size of unsigned short - done

-- Using unsigned short

-- Check if the system is big endian - little endian

-- Performing Test HAVE_VISIBILITY_HIDDEN

-- Performing Test HAVE_VISIBILITY_HIDDEN - Success

-- Performing Test HAVE_WARN_SIGN_COMPARE

-- Performing Test HAVE_WARN_SIGN_COMPARE - Success

-- Performing Test HAVE_WARN_ALL

-- Performing Test HAVE_WARN_ALL - Success

-- Performing Test HAVE_WARN_NO_UNINITIALIZED

-- Performing Test HAVE_WARN_NO_UNINITIALIZED - Success

-- Found Git: /bin/git

-- Found Doxygen: /usr/local/bin/doxygen (found version "1.9.5 
(2f6875a5ca481a69a6f32650c77a667f87d25e88)") found components: doxygen 
missing components: dot


-- Using install prefix: /usr/local

-- Building for version: 1.0.0.0 / 1.0.0

-- No C++ unit tests... skipping

-- PYTHON and GRC components are enabled

-- Python checking for pygccxml - found

-- Found PythonLibs: /usr/lib/x86_64-linux-gnu/libpython3.8.so

-- Performing Test HAS_FLTO

-- Performing Test HAS_FLTO - Success

-- LTO enabled

-- Configuring done

CMake Error in lib/CMakeLists.txt:

  Imported target "gnuradio::gnuradio-runtime" includes non-existent path

    "/include"

  in its INTERFACE_INCLUDE_DIRECTORIES. Possible reasons include:

  * The path was deleted, renamed, or moved to another location.

  * An install or uninstall procedure did not complete successfully.

  * The installation package was faulty and references files it does not

  provide.

CMake Error in lib/CMakeLists.txt:

  Imported target "gnuradio::gnuradio-runtime" includes non-existent path

    "/include"

  in its INTERFACE_INCLUDE_DIRECTORIES. Possible reasons include:

  * The path was deleted, renamed, or moved to another location.

  * An install or uninstall procedure did not complete successfully.

  * The installation package was faulty and references files it does not

  provide.

CMake Error in python/customModule/bindings/CMakeLists.txt:

  Imported target "Boost::date_time" includes non-existent path

    "/include"

  in its INTERFACE_INCLUDE_DIRECTORIES. Possible reasons include:

  * The path 

Re: Promblems with gr-air-modes in gnuradio 3.10

[Cinaed Simson]

Hi Michelle - the  source code version of gr-air-modes from github

  https://github.com/bistromath/gr-air-modes.git

indicates it should build under 3.9 but it doesn't build 3.10 - it can't 
find


  GrSwig

which is no longer supported.

Sometimes OOT modules which work on 3.9 work on 3.10 - sometimes they 
don't.


It's possible your version gr-air-modes has a different author from git 
hub version above.


And I don't have a version of 3.9 either so I can't test it on 3.9 .

-- Cinaed



On 10/1/22 05:18, Michelle wrote:

Hello,

I have gnuradio 3.10 and I wanted to install gr-air-modes. In the chat 
one of the moderators told me the version of gr-air-modes that is 
compatible with gr3.9 would work with gr3.10.
So I installed this version in my computer, the installation was 
successfull however when I execute rx_modes I do not receive any 
signal. The output of the command is :


Inspiron-3793:~$ modes_rx
gr-air-modes warning: numpy+scipy not installed, FlightGear interface 
not supported
[INFO] [UHD] linux; GNU C++ version 9.2.1 20200304; Boost_107100; 
UHD_3.15.0.0-2build5
[INFO] [B200] Loading firmware image: 
/usr/share/uhd/images/usrp_b200_fw.hex...

[INFO] [B200] Detected Device: B200
[INFO] [B200] Loading FPGA image: 
/usr/share/uhd/images/usrp_b200_fpga.bin...

[INFO] [B200] Operating over USB 2.
[INFO] [B200] Detecting internal GPSDO
[INFO] [GPS] No GPSDO found
[INFO] [B200] Initialize CODEC control...
[INFO] [B200] Initialize Radio control...
[INFO] [B200] Performing register loopback test...
[INFO] [B200] Register loopback test passed
[INFO] [B200] Setting master clock rate selection to 'automatic'.
[INFO] [B200] Asking for clock rate 16.00 MHz...
[INFO] [B200] Actually got clock rate 16.00 MHz.
[INFO] [B200] Asking for clock rate 32.00 MHz...
[INFO] [B200] Actually got clock rate 32.00 MHz.
Setting gain to 38
Gain is 38
Rate is 400

please can i get some support to solve this problem?

Re: Regarding GNU radio 3.9 installation

[Cinaed Simson]

Hi Sumit - which operating system do you need help with installing 
gnuradio 3.9?


-- Cinaed


On 8/23/22 12:02, Sumit Agrawal (P19EE207) wrote:

Hi,

Kindly share the documentation to install the gnu radio 3.9 with uhd 
4.0 or 4.2.


--
/*Thanks & Regards,
Sumit Kumar Agrawal
Ph.D. (Electrical Engineering)
Indian Institute of Technology
Jodhpur, Rajasthan-342037*/
/*Mob. No.- 8410957412*/

Re: Ubuntu 20.04 cannot find the Hackrf board?

[Cinaed Simson]

Incidentally, don't use sudo to run the hackrf on Linux.

You should be able to run the hackrf on Linux under your login userid - 
you just need sudo to install the software on the system.


I suggest you subscribe to the hackrf list

   https://pairlist9.pair.net/mailman/listinfo/hackrf-dev

they should be able to help you.

-- Cinaed


On 8/15/22 03:04, Marcus Müller wrote:

Hi George,

On 8/3/22 19:23, George Edwards wrote:

Hi Marcus,  thanks for the response, very much appreciated!
I have a Windows PC and I believe that in order to build OOT blocks, 
one needs a Linux environment.

No, that is not correct.
I installed VirtualBox so that I can install Ubuntu 20.04 to get a 
Linux environment to install Gnuradio 3.9 in. George


Why would you then build from source? Just install the packages.

Best regards,

Marcus



On Wed, Aug 3, 2022, 8:26 AM Marcus Müller  
wrote:


    Hi George,

    you'll have to do a bit more investigation on your end, I'm
    afraid. We don't know how you
    set up your VM, or how you're passing through the USB driver.
    Generally, USB passthrough
    comes at a high overhead, and sometimes that's prohibitively slow,
    as well. Also, why do
    VirtualBox (and that's not a Microsoft product, so I'm really
    confused by what you're
    referring to), if you can have WSL2?

    Best regards,
    Marcus

    On 03.08.22 14:15, George Edwards wrote:
    > Hello GNURadio Community,
    >
    > I built a grc flowgraph in Gnuradio 3.9.5 on Ubuntu 20.04 inside
    Microsoft VirtualBox. I
    > have a HackRF One radio hardware. I installed the hackrf drivers
    in Ubuntu with command:
    > sudo apt-get install -y hackrf
    > and confirmed the installation. I connected the HackRF One board
    to my computer and in the
    > Terminal prompt entered the command hackrf_info and received
    the response that it does not
    > see the Hackrf board.
    >
    > And true to form when I ran the flowgraph, I get the following
    error message:
    > RuntimeError: no hackrf device matches
    >
    > Why is Ubuntu 20.04 running inside MS VirtualBox not seeing the
    HackRf board with the
    > HackRf drivers installed. And, how do I resolve this issue?
    >
    > Will appreciate any help to resolve this issue.
    >
    > George
    >

Re: Problem seeing Hackrf One Hardware properly going through VirtualBox

[Cinaed Simson]

Okay, this output looks better -  it appears you now have the libraries 
installed.


I don't understand the output

   Board ID Number: 2

If you have more then 1 board installed, unplug all the boards except 
for 1 board.


To run multiple boards you need to use serial numbers - but you need to 
get hackrf_info working correctly.


Type

   groups | grep plugdev

If it doesn't print anything, you need to add yourself to the group 
plugdev.


To do that use

   sudo usermod -a -G plugdev 

where  is your login name.

Then logout and then login again and type

  groups

and you should see an entry for plugdev.

And then run

  hackrf_info

-- Cinaed

**
On 8/12/22 09:20, George Edwards wrote:

Hello GNURadio Community,

I designed an FM receiver in Gnuradio-Companion to receive an FM 
broadcast signal from the Hackrf One. I am running Gnuradio-Companion 
3.9 on Ubuntu 20.04 inside VirtualBox 6.1. I installed the Hackrf 
software on Ubuntu and set VirtualBox USB port to see the Scott Gadget 
Hackrf One. Problem is: when I execute the command "hackrf_info" in 
the Ubuntu Terminal, it reads the Board ID, Firmware Version, and Part 
Number, but says the hackrf_info version and libhackrf version are 
"unknown". This is a snapshot of the terminal response from executing 
the hackrf_info query:


image.png

I cannot find any info online to solve this problem (allow the 
Terminal query “hackrf_info” to return all the board information). As 
a result when I run the GRC flow graph, it fails because it cannot 
open hackrf. I would appreciate any suggestions.


Thank you!

George

Re: Ubuntu 20.04 cannot find the Hackrf board?

[Cinaed Simson]

It sounds like you didn't

  apt install libhackrf-dev

If you did install the libraries, then you may have to update the firmware.

Post the entire results from

   apt list --installed | grep hackrf

so we can see the versions. There should be 2 entries.

Note the date of the firmware - 2014 - was  first year the hackrf was 
released via Kickstart.


-- Cinaed



On 8/3/22 05:15, George Edwards wrote:

Hello GNURadio Community,

I built a grc flowgraph in Gnuradio 3.9.5 on Ubuntu 20.04 inside 
Microsoft VirtualBox. I have a HackRF One radio hardware. I installed 
the hackrf drivers in Ubuntu with command: sudo apt-get install -y hackrf
and confirmed the installation. I connected the HackRF One board to my 
computer and in the Terminal prompt entered the command 
hackrf_info and received the response that it does not see the Hackrf 
board.


And true to form when I ran the flowgraph, I get the following error 
message:

RuntimeError: no hackrf device matches

Why is Ubuntu 20.04 running inside MS VirtualBox not seeing the HackRf 
board with the HackRf drivers installed. And, how do I resolve this issue?


Will appreciate any help to resolve this issue.

George

Re: Ubuntu 20.04 cannot find the Hackrf board?

[Cinaed Simson]

And you'll need to

  apt install gr-osmosdr

to use the hackrf with gnuradio.

-- Cinaed


On 8/3/22 23:21, Cinaed Simson wrote:

Hi George - the hackrf runs under ubuntu.

The latest version is

  release 2021.03.1
https://github.com/greatscottgadgets/hackrf/release
https://github.com/greatscottgadgets/hackrf/releases/download/v2021.03.1/hackrf-2021.03.1.tar.xz

The current firmware version on your hackrf is 2014.

You could try

   apt update
   apt install hackrf libhackrf-dev

which may give you the 2018 version for the hackrf utils and 
libhackrf-dev.


But I don't know how the firmware gets updated using apt - I've never 
used apt to install the hackrf software.


The 2014 firmware may play enough well with the 2018 software - I 
don't know. It may play well enough to indicate the hackrf works on 
ubuntu but Ideally you'd like the version of firmware to match the 
software.


-- Cinaed


On 8/3/22 18:28, George Edwards wrote:

Hello Gentlemen,

I installed VirtualBox extension pack and made the USB connection in 
VirtualBox to the HackerRF board. However, in the Ubuntu Terminal 
when I execute the command hackrf_info the info that comes up is:

hackrf_info version: unknown
libhackrf version: unknown (0.5)
Found HackRF
Index: 0
Board ID Number: 2 (HackRF One)
Firmware Version: 2014.08.1 (API:1.00)
Part ID Number: 0xa000cb3c 0x006e4756

The above shows Ubuntu is having trouble reading the top two version 
information and as a result when I try to run the Gnuradio flowgraph, 
it gives a message that it fails to open HackRF.


George



On Wed, Aug 3, 2022 at 10:32 AM James Anderson  wrote:

You might want to try running hackrf_info with superuser
privileges using sudo, i.e. "sudo hackrf_info". Many/most
peripherals require this in Linux by default.

Additionally, use of a VM may limit the sample rate you can
achieve since there is some overhead passing through the USB
connection. Consider installing Linux directly on your machine.


On Aug 3, 2022, at 6:12 AM, George Edwards
 wrote:


Hello GNURadio Community,

I built a grc flowgraph in Gnuradio 3.9.5 on Ubuntu 20.04 inside
Microsoft VirtualBox. I have a HackRF One radio hardware. I
installed the hackrf drivers in Ubuntu with command: sudo
apt-get install -y hackrf
and confirmed the installation. I connected the HackRF One board
to my computer and in the Terminal prompt entered the command
hackrf_info and received the response that it does not see the
Hackrf board.

And true to form when I ran the flowgraph, I get the following
error message:
RuntimeError: no hackrf device matches

Why is Ubuntu 20.04 running inside MS VirtualBox not seeing the
HackRf board with the HackRf drivers installed. And, how do I
resolve this issue?

Will appreciate any help to resolve this issue.

George

Re: Ubuntu 20.04 cannot find the Hackrf board?

[Cinaed Simson]

Hi George - the hackrf runs under ubuntu.

The latest version is

  release 2021.03.1
https://github.com/greatscottgadgets/hackrf/release
https://github.com/greatscottgadgets/hackrf/releases/download/v2021.03.1/hackrf-2021.03.1.tar.xz

The current firmware version on your hackrf is 2014.

You could try

   apt update
   apt install hackrf libhackrf-dev

which may give you the 2018 version for the hackrf utils and libhackrf-dev.

But I don't know how the firmware gets updated using apt - I've never 
used apt to install the hackrf software.


The 2014 firmware may play enough well with the 2018 software - I don't 
know. It may play well enough to indicate the hackrf works on ubuntu but 
Ideally you'd like the version of firmware to match the software.


-- Cinaed


On 8/3/22 18:28, George Edwards wrote:

Hello Gentlemen,

I installed VirtualBox extension pack and made the USB connection in 
VirtualBox to the HackerRF board. However, in the Ubuntu Terminal when 
I execute the command hackrf_info the info that comes up is:

hackrf_info version: unknown
libhackrf version: unknown (0.5)
Found HackRF
Index: 0
Board ID Number: 2 (HackRF One)
Firmware Version: 2014.08.1 (API:1.00)
Part ID Number: 0xa000cb3c 0x006e4756

The above shows Ubuntu is having trouble reading the top two version 
information and as a result when I try to run the Gnuradio flowgraph, 
it gives a message that it fails to open HackRF.


George



On Wed, Aug 3, 2022 at 10:32 AM James Anderson  wrote:

You might want to try running hackrf_info with superuser
privileges using sudo, i.e. "sudo hackrf_info". Many/most
peripherals require this in Linux by default.

Additionally, use of a VM may limit the sample rate you can
achieve since there is some overhead passing through the USB
connection. Consider installing Linux directly on your machine.


On Aug 3, 2022, at 6:12 AM, George Edwards
 wrote:


Hello GNURadio Community,

I built a grc flowgraph in Gnuradio 3.9.5 on Ubuntu 20.04 inside
Microsoft VirtualBox. I have a HackRF One radio hardware. I
installed the hackrf drivers in Ubuntu with command: sudo apt-get
install -y hackrf
and confirmed the installation. I connected the HackRF One board
to my computer and in the Terminal prompt entered the command
hackrf_info and received the response that it does not see the
Hackrf board.

And true to form when I ran the flowgraph, I get the following
error message:
RuntimeError: no hackrf device matches

Why is Ubuntu 20.04 running inside MS VirtualBox not seeing the
HackRf board with the HackRf drivers installed. And, how do I
resolve this issue?

Will appreciate any help to resolve this issue.

George

Re: GRU module removed, what can I do please ?

[Cinaed Simson]

Hi Jean-Philippe - did you change your PYTHONPATH from 3.8 to 3.10?

Also, please check the subversion of gnuradio-dev, e.g.,

  apt list gnuradio-dev

and the 3.10 should expand to something which looks like this

   3.10.2.0-1+b2

-- Cinaed

On 7/21/22 18:25, Jean-Philippe Buchet wrote:

Hello,
first of all I am surly not a gnuradio guru, not a python guru.
I use some scripts written by other peoples
Until last week, all was ok.
After an update ( Kali on raspberry)..
I have removed gnuradio, python3.8 ...
and afte, a new install via  apt  ( gnuradio, gnuradio-dev osmo-sdr .. 
python3.10 ..)


I still get the error : cannot import gru module from gnuradio.

To check, I start by hand in python3 the other imports from gnuradio. 
gr, digital, filters ...

All them work except "gru"

As I can see, after spent hours and hours, this gru module is removed 
from gnuradio.

(for the moment I don't understand gnuradio / modules and their goals)

What can I do please ?

OS: raspi-kali 5.15.44 Debian Kali-pi (2022-07-03)
GR Installation Method: apt install ( gnuradio, gnuradio-dev python3 ..)
GNU Radio Version  3.10 (maint-3.10)

Thank you

Re: Understanding Pulsed signal Demodulation and decimation in GNU Radio

[Cinaed Simson]

Hi Isaac - it sounds like there's a beat frequency - probably between 
the pulsed signal and the second freqency. I'm assuming you didn't see 
the problem in the pulsed signal signals.


-- Cinaed

The definition of the beat freuency is the absolute difference between 
two frequencie.


On 7/20/22 10:03, isaac mario tupac davila wrote:

Hello everyone

My name is Isaac. I'm dealing with a curious behaviour that I can't 
understand...


I'm generating my pulsed signal by multiplying a vector source and a 
signal source. Then I'm multiplying this pulsed signal with a 
continuous signal source at the same frequency, passing then for a low 
pass filter and seeing it in a time sink block.


The result should be a set of rectangles with the same amplitude and 
period. The curious thing here is that the amplitude varies in time 
(from 0 to max amplitude and vice versa). Any idea why the amplitude 
varies in time?


I attach the flowgraph just in case.

Any idea or help will be appreciated.
Thanks
Isaac t.

Re: gnuradio flow graph starts and stops

[Cinaed Simson]

Hi Zafar  - are you trying to run python code which was built on another 
machine?


Or are you running gnuradio remotely?

Which SDR are you using?

-- Cinaed


On 7/18/22 00:29, Zafar Iqbal wrote:eree

Hi,

Please help with the following issue. Thanks in advance

OS: Windows 11
Gnuradio version: 3.8.3.0
(Python 3.8.0)
Source: radioconda 2021.04.08

Observation: FLow graph starts, output windows appear and stops in a 
fraction of second.


Error:

gr::pagesize: no info; setting pagesize = 4096
Traceback (most recent call last):
  File "D:\\Google
Drive\\Zafar\\SDR_Course_WirelessPi\\Codes\time_shift_effect.py",
line 284, in 
    main()
  File "D:\\Google
Drive\\Zafar\\SDR_Course_WirelessPi\\Codes\time_shift_effect.py",
line 269, in main
    signal.signal(signal.SIGINT, sig_handler)
AttributeError: module 'signal' has no attribute 'SIGINT'


Regards
Zafar

Re: Controlling flowgraph

[Cinaed Simson]

Hi Vamshi - I vaguely remember the gr-osmosdr being optimized for 
transmission - the sinks and sources have different lifetimes.


For the price of a second hackrf, you can buy the hackrf add on known as 
the "operacake" which supports multiple antenna configurations -  which 
can configured for frequency or time.


There a link on their web page with details.

-- Cinaed


On 6/6/22 01:12, Vamshi Sainath Gavani wrote:
So what I'm doing is transmitting with a HackRF One and when I run the 
flowgraph the transmission starts and frames are sent as bursts and 
between the bursts, the transmitter stays on and I would like to turn 
it off at tx_eob and turn on tx at tx_sob

Below is the screenshot of the current flowgraph I'm implementing.

On Mon, Jun 6, 2022 at 1:14 PM Marcin Puchlik 
 wrote:


Hi Vamshi,
First, what do you mean by turning off/on the transmitter?
Marcin

pon., 6 cze 2022 o 09:14 Vamshi Sainath Gavani
 napisał(a):

Hello Folks,

Here I'm implementing the transmission of LoRa Frames and I
want to be able to stop the flowgraph(Stop Transmitting)
between frames say the packet is set to transmit every 3s so
at tx_eob turn off tx and tx_sob start tx.
Below is my Flow graph code snippet can you let me know how I
can turn off/on tx between the frames?

*def main(top_block_cls=lora_TX, options=None):
    tb = top_block_cls()

    def sig_handler(sig=None, frame=None):
        tb.stop()
        tb.wait()
        sys.exit(0)

    signal.signal(signal.SIGINT, sig_handler)
    signal.signal(signal.SIGTERM, sig_handler)

    tb.start()
    try:
        input('Press Enter to quit: ')
    except EOFError:
        pass
    tb.stop()
    tb.wait()

if __name__ == '__main__':
    main()*
Thanks and Regards,
Sainath Vamshi

Re: Vector Block Sample Rate

[Cinaed Simson]

First, for the active part of the flow graph - which doesn't have any 
hardware , will run as fast as your computer will allow it, i.e. it may 
cause your computer to slow down. To prevent this add a throttle.


Send, your noise source is an unknown source with 0 amplitude. If the 
noise source is unknown and 0 amplitude, why do you need a low pass filter?


Also, what version of gnuradio are you using?

-- Cinaed

On 6/4/22 14:09, DİREN ERDEM AYDIN via GNU Radio, the Free & Open-Source 
Toolkit for Software Radio wrote:

Hello All,

I'm working with Adalm Pluto SDR, trying to transmit and receive a 
custom burst signal given in the figure. To create the signal I'm 
using a vector block that creates a pulse and then due to a low pass 
filter I can extract the desired waveform. Flowgraph is also added.


As far as I know, input/output sample rates of connected blocks should 
be matched. However, I'm providing 10k fewer samples to LPF because of 
the high sample rate of pluto, 61.44 M. When I tried to increase the 
samples in the vector source to Mega ranges frequency response of the 
signal drops drastically. I have also tried to use interpolation in 
between vector block and LPF, but it doesn't work either.


My question is the LPF block normalizes the input sample rate to 61.44 
M? The whole system works OK but this thing stays unclear for me. 
Thank you.


Regards,
Diren

Re: GnuRadio 3.10 OOT python modules not found - destination path error '/usr/local/local/lib64'

[Cinaed Simson]

Hi Criss - I remember having the same issue.

I rolled with the punch by adding the python path - then I forgot about it.

I upgraded the OS but did a clean install of gnuradio 10.

I just updated volk and gnuradio and rebuilt volk  the problem is still 
there for me - at least after rebuilding volk


I was going to do a dist-upgrade to get rid of all the previous OS  
packages and update them but I haven't had chance.


-- Cinaed

On 5/31/22 11:39, Criss Swaim wrote:
Upgraded to GnuRadio 3.10 from 3.9 and gnuradio-companion aborts with 
a module not found trying to import my OOT python blocks.  The modules 
are being placed in /usr/local/local/lib64/python3.10/site-packages - 
note the local/local.  the destination should be 
/usr/local/lib64/python3.10/site-packages.


The fix is after running the cmake ../ command in the build directory, 
edit build/python/cmake_install.cmake and 
build/python/bindings/cmake_install.cmake and change


   file(INSTALL DESTINATION 
"$(CMAKE_INSTALL_PREFIX)/local/lib64/python3.10/site-packages.

to

  file(INSTALL DESTINATION 
"$(CMAKE_INSTALL_PREFIX)/lib64/python3.10/site-packages. (remove 
/local)


there are 2 changes in build/python/cmake_install.cmake and 8 changes 
in build/python/bindings/cmake_install.cmake


Make these changes before running the make/sudo make install.

I am unable to determine if this is a problem in the gr_modtool or in 
the GR_PYTHON_DIR constant or in some setting in my custom OOT project.


My environment is Fedora 36, Gnuradio 3.10 and Python 3.10.

Re: Support to Apply gr-dab-0.4-gnuradio39.patch

[Cinaed Simson]

Hi Mohammad - just to be clear, it's a patch for gr-dab-0.4 OOT module 
running under gnuradio-3.9.


And if you haven't done so already, you should download the source code 
for gr-dab-0.4 and build it to ensure you have all the necessary 
libraries needed for running gr-dab-0.4 under gnuradio-3.9.


Then apply the patch to source code for gr-dab-04 recompile and install.

See the following URL on how to apply a patch to source code

https://www.thegeekstuff.com/2014/12/patch-command-examples/

    2. Apply Patch File using Patch Command

-- Cinaed

On 5/30/22 00:51, Mohammad Riyazudeen wrote:

Dear Experts,

   I am not having much aware of GNU Radio 
installation and configuration,


Building and installing GNU Radio 3.9 from source code on UBUNTU 18.04.

Now i need to install gr-dab-0.4-gnuradio39.patch 
 
patch file for GNU Radio 3.9.


gr-dab-0.4-gnuradio39.patch 



https://pkgs.rpmfusion.org/cgit/free/gr-dab.git/commit/gr-dab-0.4-gnuradio39.patch

Please provide me a steps for applying the patch on GNU Radio 3.9

Thanks
Mohammad Riyazudeen

Re: Getting "referenced unknown base type gr::block"

[Cinaed Simson]

Hi Nikoloz - my guess is you may need to install version 11 of C++.

-- Cinaed

On 5/27/22 13:37, Nikoloz Glonti wrote:


I'm using manjaro linux, the newest one.
I use version of pybind11 2.9.2, so it's new one.

On 27.05.2022 18:57, Tom McDermott wrote:



> From: Nikoloz Glonti 
> To: "discuss-gnuradio@gnu.org" 
> Cc:
> Bcc:
> Date: Thu, 26 May 2022 17:11:50 +0200
> Subject: Getting "referenced unknown base type gr::block"
> Hi everyone,
>
> I have newest gnuradio 3.10, and I'm compiling example QPSK block -
> 
https://wiki.gnuradio.org/index.php?title=Guided_Tutorial_GNU_Radio_in_C%2B%2B 


> But when trying to run it i get following error.
>
>   File
> "/home/ng/Desktop/bloczki/gr-spektralsi/build/python/testFiltru.py",
> line 35, in 
> from gnuradio import pec
>   File
> "/usr/local/lib/python3.10/site-packages/gnuradio/pec/__init__.py", 
line

> 18, in 
>      from .pec_python import *
> ImportError: generic_type: type "qpsk_demod_cb" referenced unknown 
base

> type "gr::block"
>
> How can i fix it?
>
> Thank You in advance
> Niko

My experience is that this is commonly caused by pybind11-dev version 
incompatibility.
At least version 2.5.0 is needed. Ubuntu 20.04 provides version 
2.4.3 and I have not
been successful in updating to a later version on that specific OS 
release.   Ubuntu 22.04 provides
more recent versions of a bunch of tools, and for me that was what 
was needed.


-- Tom, N5EG

Re: File Source - File Sink data transfer

[Cinaed Simson]

Hi Jeff - let's take this offline.

We'll use the standard xxd "hello world" example.

  echo " 4865 6c6c 6f20 776f 726c 6421 " > hex.file

  xxd -r -p hex.file > binary.file

And you can look at the binary.file using

  xxd binary.file

-- Cinaed



On 5/16/22 09:56, user 1 wrote:

Hi Steven,

Thank you for your suggestion, but /dev/urandom  is an empty file  
  See Screenshot_3



jeff

--



Le 16/05/2022 à 16:41, Steven Barbo a écrit :

Howdy Jeff.
What happens if you use /dev/urandom as file source?

On Mon, May 16, 2022 at 9:09 AM user 1 <mailto:gnura...@onditech.com>> wrote:


    Hello Cinaed,

    Unfortunately scheme doesn't work, even with a bin file.



    jeff


    --

    Le 16/05/2022 à 12:06, Cinaed Simson a écrit :
 > Hi Jeff - the error indicates the file source has the wrong data
    type,
 > i.e. it may not be binary data.
 >
 > If the input file contains hex numbers, then you need to convert
    each
 > hex number to a binary number and concatenate them.
 >
 > -- CInaed
 >
 >
 > For instance, 40 hex is equivalent to 0100 binary.
 >
 > For instance,
 >
 > On 5/16/22 00:46, user 1 wrote:
 >> Hi,
 >>
 >> Somebody could tell me why this simple scheme doesn't work 
(see the

 >> screenshots)?
 >>
 >>   File Source   --->   Throttle --->   File Sink
 >>
 >>
 >> I work under Ubuntu 20.04.4  LTS and GnuRadio 3.9.6
 >>
 >>
 >> This scheme worked fine in the past with previous releases of
    GnuRadio.
 >>
 >>
 >> Thank you for your help.
 >>
 >>
 >>
 >> Jeff
 >



--
If something is requisite, how can it possibly be, prerequisite?

vanitas vanitatum omnia vanitas
later, steve
http://umn.edu/~barbo <http://umn.edu/~barbo>

Re: File Source - File Sink data transfer

[Cinaed Simson]

Hi Jeff - the error indicates the file source has the wrong data type, 
i.e. it may not be binary data.


If the input file contains hex numbers, then you need to convert each 
hex number to a binary number and concatenate them.


-- CInaed


For instance, 40 hex is equivalent to 0100 binary.

For instance,

On 5/16/22 00:46, user 1 wrote:

Hi,

Somebody could tell me why this simple scheme doesn't work (see the 
screenshots)?


  File Source   --->   Throttle    --->   File Sink


I work under Ubuntu 20.04.4  LTS and GnuRadio 3.9.6


This scheme worked fine in the past with previous releases of GnuRadio.


Thank you for your help.



Jeff

Re: [SOLVED] pybind11 problems, gr::block undefined in gnuradio 3.10

[Cinaed Simson]

Great!

It might have been a c++ compiler issue - might have needed version 11 
of c++ for pybind11 and 3.10.


-- Cinaed


On 5/15/22 14:40, Tom McDermott wrote:


>>> import hpsdr
Traceback (most recent call last):
  File "", line 1, in 
  File "/usr/lib/python3.8/site-packages/gnuradio/hpsdr/__init__.py", 
line 18, in 

    from .hpsdr_python import *
ImportError: generic_type: type "hermesNB" referenced unknown base 
type "gr::block"

>>>

The only way I found to solve this problem was to stop using Ubuntu 
20.04 Focal and move to Ubuntu 22.04 Jammy.
22.04 seems to have the latest versions of the key tools, it all 
built, and runs correctly.


I suspect this just affects pybind11,  if so folks probably would 
still be able to install the OOT
on the older version of Ubuntu, they just couldn't change anything 
that would require re-binding.


-- Tom, N5EG

Re: gr::block unknown base type (was: What version of pybind for 3.10.1.1 )

[Cinaed Simson]

I just checked the requirements for 3.10 and it only requires pybind11 
2.4.3.


And I presume you have volk-2.4.1 installed and

  import gnuradio

works.

I doubt if I can help you.

-- Cinaed

On 5/14/22 06:40, Tom McDermott wrote:


> In porting over my 3.9 OOT to 3.10,  I have the import error:
>
> >>> import hpsdr
> Traceback (most recent call last):
>   File "", line 1, in 
>   File 
"/usr/lib/python3.8/site-packages/gnuradio/hpsdr/__init__.py", line 
18, in 

>     from .hpsdr_python import *
> ImportError: generic_type: type "hermesNB" referenced unknown base 
type "gr::block"

> >>>
>
> When I went through this back in 3.9, it was due to a version 
problem in pybind11.

>
> I have installed pybind11-dev version 2.5.0 from the tarball.   
Ubuntu 20.04 package manager

> has reverted to 2.4.3 (after having been at 2.5.0 for awhile).
>
> Is this still a pybind11 versioning problem?  If so, what version of 
pybind11 should I be

> using to build my OOT for 3.10.1.1 ?
>

Update

Using Ubuntu 20.04 (focal).

The module has been tried using pybind11-dev  ver. 2.5.0 and  ver 
2.9.2 from tarball without success
(gr_modtool bind works OK, cmake, make, make install works OK.  Trying 
to run causes the python

exception gr::block not found).

The Ubuntu 20.04 package manager provides pybind11-dev v 2.4.3 only.

Then uninstalled v 2.9.2 (which is a proper superset of 2.5.0) since 
2.9.2 tarball creates an uninstall rule

( 2.5.0 does not create an uninstall rule).

Next pulled pybind11-dev  2.6.2 in from Ubuntu Impish by manipulating 
APT and installed
only that from the package manager, then cleaned up APT to prevent 
anything else from updating.


The 2.6.2 installed via APT gives exactly the same problem, gr::block 
exception.


Does anyone have advice on how to fix?

-- Tom, N5EG



Message ID: 

Re: OOT module problem

[Cinaed Simson]

Hi David - I can't't read the printing on the image - please post the grc
file.

-- Cinaed


On Fri, May 13, 2022 at 9:38 AM David Martini 
wrote:

> Dear Community,
>
> I'm starting to learn how to write an OOT module.
> I'm following the tutorial : all the compilation process go well but When
> I try to run my module i get the following error import test_001
> ModuleNotFoundError: No module named 'test_001'
>
> The module is present in the block list. see the attached picture.
>
> I'm not able to understand where the problem is
>
> Thank you for help
>
> David
>
>

-- 


 "We are drowning in information and starving for knowledge."

-- Rutherford
D. Roger

Re: What version of pybind11 is 3.10.1.1 built against?

[Cinaed Simson]

Hi Tom - I built 3.10.02 using pybind 2.9. on Debian 12 (or bookworm) -
which was the system default install for pybind. .

-- Cinaed

On Thu, May 12, 2022 at 12:44 PM Tom McDermott  wrote:

> In porting over my 3.9 OOT to 3.10,  I have the import error:
>
> >>> import hpsdr
> Traceback (most recent call last):
>   File "", line 1, in 
>   File "/usr/lib/python3.8/site-packages/gnuradio/hpsdr/__init__.py", line
> 18, in 
> from .hpsdr_python import *
> ImportError: generic_type: type "hermesNB" referenced unknown base type
> "gr::block"
> >>>
>
> When I went through this back in 3.9, it was due to a version problem in
> pybind11.
>
> I have installed pybind11-dev version 2.5.0 from the tarball.   Ubuntu
> 20.04 package manager
> has reverted to 2.4.3 (after having been at 2.5.0 for awhile).
>
> Is this still a pybind11 versioning problem?  If so, what version of
> pybind11 should I be
> using to build my OOT for 3.10.1.1 ?
>
>
> -- Tom, N5EG
>
>
>
>

-- 


 "We are drowning in information and starving for knowledge."

-- Rutherford
D. Roger

Re: r-trellis/docs/gr-trellis.xml does not validate

[Cinaed Simson]

It's possible cmake just can't find your gsl libraries.

When I installed gnuradio 10.2 on Debian12 (bookworm,)  I just used

   apt install libgsl-dev

-- Cinaed

On 5/1/22 04:51, stephen pearce wrote:

Linux mint 20.3
gnuradio 3.10

compiling from source
tried both  git master and maint-3.10  repositories.

Compile fail on make with this error ..

warning: failed to load external entity 
"/home/s/Downloads/a/gnuradio/gnuradio-maint-3.10/gr-trellis/docs/docbookx.dtd"

validity error : Could not load the external subset "docbookx.dtd"
Document 
/home/s/Downloads/a/gnuradio/gnuradio-maint-3.10/gr-trellis/docs/gr-trellis.xml 
does not validate


and later

make[2]: *** 
[gr-trellis/docs/CMakeFiles/gr_trellis_html.dir/build.make:61: 
gr-trellis/docs/gr-trellis.html] Error 13
make[1]: *** [CMakeFiles/Makefile2:8002: 
gr-trellis/docs/CMakeFiles/gr_trellis_html.dir/all] Error 2


I tried to look in the gr-trellis directory and id the problem but I 
am not familiar

with the doc style.

I have installed all the documentation dependencies (ascii2doc etc)

What am I doing incorrectly?

thanks

Re: Interpolating FIR Filter - sample delay

[Cinaed Simson]

Hi - first, it appears you're using version 3.7.x of gnuradio which is 
no longer supported. The constellation encoder for your version appears 
as a missing block on 3.8.


Second, there was no constellation posted for some reason.

Third, it appears you're using 2 stream sources and a streaming mux and 
then tagging on the packet_length - but it's difficult to figure out 
what's going on with the missing block.


Try using the tag probe and floats - and keep it simple.

See

https://wiki.gnuradio.org/index.php?title=File:Tags_interp.grc.png

And see

https://wiki.gnuradio.org/index.php/Simulation_example:_BPSK_Demodulation

for first step in BPSK demodulation.

-- Cinaed



On 4/22/22 02:32, Marcin Puchlik via GNU Radio, the Free & Open-Source 
Toolkit for Software Radio wrote:

Hello
I was playing with the Interpolating FIR Filter Block and noticed that 
the mentioned filter delays tags not properly. What I mean is that 
when the interpolation factor is different than 1, then the filter 
delays the tags by the /Sample Delay * Interpolation factor/ value. In 
my opinion this is not correct behavior. Group delay of the filter is 
constant and the interpolation factor shouldn't affect the process of 
delaying the tags. Below, I am attaching the plot and GRC flowgraph 
which demonstrate the problem and where you can see the observed 
behavior.

Number of the taps in RRC filter used in the simulation: 41
Group delay: 20
Actual group delay: 40
What do you think?
Rysunek bez nazwy.jpg

Re: Trouble With gr-osmosdr Install

[Cinaed Simson]

Try

  apt install gr-osmosdr

I'm assuming you installed gnuradio using apt and you're running an 
updated version of the original raspbian shipped with the device.


And since the install guide indicated it should be installed in 
/usr/local/lib and it's not working it may not be a problem - but in the 
end you should only have one install of gr-osmosdr.


You should be able to locate the one you install from source by typing

  find /usr/local/lib -name osmosdr -type d

-- Cinaed

On 4/13/22 20:28, Ambroise Curutchague wrote:

Hello,

I will preface this by saying I am a linux novice. I have been trying 
to set up GNURadio to use with a HackRF. To do this, I have installed 
gr-osmosdr following instructions from the install guide 
(https://osmocom.org/projects/gr-osmosdr/wiki/GrOsmoSDR). I have 
GNURadio Companion version 3.7.13.4. I am on a Raspberry Pi 4 running 
the most recent Raspbian.


My problem is that I cannot get the osmocom source and sink blocks to 
show up in GRC, and I cannot find the osmocom_source and osmocom_sink 
.XML files anywhere either.  I tried copying the hackrf_source and 
hackrf_sink .XML files directly to the folder in my GRC block path, 
but when starting GRC it would throw an error message that the .XML 
files were unrecognized. Not sure what else to do. Would greatly 
appreciate your help.


Best,
Ambroise - KN6NOR

Re: gr-soapy mishandles hackrf on flowgraph exit

[Cinaed Simson]

On 4/16/22 14:53, Gavin Jacobs wrote:
I had previously thought that there was an issue with the save/restore 
of the geometry of the QT window, but I determined that it was a 
problem when using the gr-soapy block with a hackrf, so I have started 
a new thread.


If I make a flowgraph using the "Soapy hackrf source" (i.e. gr-soapy 
block with a hackrf yml), it works fine when receiving the streaming 
data, but crashes the top block on exit. When I stop the flowgraph, I 
get the following message on the console area:

>>> Done (return code -11)
I now know that means a segmentation fault, and thanks to Vasil, I 
tried to debug it. The offending code is in a callback and references 
some memory that is no longer around, probably because all the blocks 
are shutting down and calling their respective destructors. So, I then 
disabled the gr-soapy source, and used the gr-osmosdr source 
(soapy=0,driver=hackrf). This worked as expected, including a normal 
message:

>>> Done
So, I compared the way the gr-osmosdr used soapyHackrf with the way 
gr-soapy does it, and I found that:
gr-osmosdr calls deactivateStream() on stop(), and closeStream() on 
~destructor()
gr-soapy never calls deactivateStream(), calls closeStream() on 
stop(), and does nothing in ~destructor()


My assessment is that gr-soapy should follow the pattern previously 
used in gr-osmosdr. The call to deactivateStream() stops the streaming 
and cancels the callback, so the problem would be fixed. A workaround 
is to use the gr-osmosdr/soapy/hackrf block, but it is marked as 
deprecated, so that won't do for long term.


Is there anyone with a hackrf that can verify the problem? and then, 
how to register a bug report?


Jake



Try posting an issue

https://github.com/pothosware/SoapyHackRF

-- Cinaed

Re: Why is OFDM_loopback slow with Random Source

[Cinaed Simson]

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: failed to fetch http://mirrordirector.org/rasbian ...

[Cinaed Simson]

Hi Elmore - those are system errors - not gnuradio errors.

How did you get from jessie to bullseye?

Did you consult anyone on the Debian mailing lists on how to proceed?

It's standard practice to backup anything you can't afford to loose when 
upgrading an operating system.


And it's possible you may have to re-image the system depending on how 
you did what you did.


Send me email instead of posting on this mailing list - and I'll see if 
I can help you.


-- CInaed


On 1/18/22 08:17, Elmore's wrote:

Marcus,
At your suggestion:
  
I upgraded to Debian 11 (Bullseye) following instructions I found on Tom’s Hardware site. It seemed to be successful except that GNU radio no longer executes.
  
Figuring that perhaps I need to install Debian 12 and upgrade to GNU radio 3.9 before it will run again I went to the following:

https://wiki.debian.org/DebianEdu/Documentation/Bookworm/Upgrades
  
The following happens during the installation process:
  
Execute ‘apt full-upgrade’:

     unmet dependencies:
     libc –dev –bin
     libc6 –dbg
     libc6 –dev
     libnih1
  
Execute ‘apt –f install’ at the suggestion of the instructions:

     dpkg: error processing archive /var/cache/apt/archives/init-system 
–helpers_1.60_all.deb (—unpack)
  
     Errors encountered while processing: /var/cache/apt/archives/init-system –helpers_1.60_all.deb
 
     Sub-process /usr/bin/dpkg returned an error code
  
Execute ‘apt –y full-upgrade’ at the suggestion of the instructions:

     unmet dependencies error same as above
  
Execute ‘apt-get –f install’ at the suggestion of the execution result:

     unmet dependencies error same as above
  
What’s next?
  
Jim


 
	Virus-free. www.avg.com 
 



<#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>

Re: failed to fetch http://mirrordirector.org/rasbian ...

[Cinaed Simson]

Hi Elmore - try

  apt install python3-distutils

-- Cinaed


On 1/15/22 17:07, Elmore's wrote:

Device: Raspberry Pi 3
OS: Rasbian Jessie
My goal is to install GNU Radio 3.9.
I am following the instructions in Installing GR on the gnuradio site.
In the installation for Volk I attempt to execute cmake 
–DCMAKE_BUILD_TYPE=Release –DPYTHON_EXECUTABLE=/usr/bin/python ../
I get a message that distutils is not found. I need to install 
python3_distutils.
When I attempt the installation, I get a series of messages “Failed to 
fetch mirrordirector.rasbian.org/rasbian/ ..” with different paths.
I have viewed many forums regarding this issue and they provide many 
different ”solutions” but nothing conclusive.

Please help.
Jim

 
	Virus-free. www.avg.com 
 



<#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>

Re: Reminder: SigMF Workshop this Thursday Noon Eastern

[Cinaed Simson]

Hi Derek - I have  a question regarding the installation of gr-sigmf.

Prior to installing gr-sigmf, I installed SigMF-0.0.2. I just did a pull 
and the version didn't change.


Things appears to be working - I just did a simple test using the 
source/sink grc file


I don't remember where I downloaded it from - I think it was a gnuradio 
repo.


Where should I be downloading SigMF from?

Or is it even necessary for gr-sigmf?

-- Cinaed


On 1/12/22 13:42, Derek Kozel wrote:

Hi folks,

The Signal Metadata Format (SigMF) has seen specification improvement, 
greater adoption, and will likely continue to see growth over the 
coming year including greater integration into GNU Radio. With the 
version 1.0 release finally here, there has never been a better time 
to learn more about what SigMF is, how it can help with RF 
data/metadata management, and where the specification is going. Join 
the SigMF development team for a workshop tomorrow on the future of 
the core SigMF specification, development tools, and integration with 
GNU Radio.


Thursday January 13th at Noon Eastern US

Join via Zoom 
Meeting ID: 861 8214 0744

Additional information about the specification can be found at 
sigmf.org . For discussions or questions please join 
the #sigmf:gnuradio.org  room 
on the Matrix chat server.


At the GNU Radio Conference in 2021 Ben Hilburn, Jacob Gilbert, and 
Kyle Logue presented the state of work in-progress for the 1.0.0 
specification release which was finalized on January 7th, 2022. Their 
talk can be viewed on YouTube.


GRCon21 - SigMF v1.0.0 Update 

Re: fosphor sink block error

[Cinaed Simson]

Hi Gwendoline - you may need to install python3.qt5 - try

  python3
  from PyQt5.QtWidgets import *

-- Cinaed


On 12/24/21 00:17, Gwendoline Hochet Derevianckine wrote:


Hello,

I remove all GNURadio and Fosphor packages/libraries on my laptop.

Then I reinstall GNURadio 3.9.
I am now trying to build gr-fosphor following the wiki.


I successfully do the cmake step after installing some dependancies.

But the make step raise this error :


I don't know what to do to solve it ...


For the record, I clone the repository in /usr/share since the wiki 
specify "Warning: Mixed prefix install is not supported. You need to 
install gr-fosphor in the same prefix as your GNU Radio install." By 
doing " dpkg-query -L gnuradio" I obtain a lot of lines starting by 
/usr/share/ so I assume that gnuradio were install there.



Hopping you can help me with this new issue 


Happy holiday season,

Gwendoline




*From:*Paul Atreides 
*Sent:* jeudi 23 décembre 2021 16:19
*To:* Gwendoline Hochet Derevianckine 
*Cc:* Sylvain Munaut <246...@gmail.com>; discuss-gnuradio@gnu.org
*Subject:* Re: fosphor sink block error

*Warning - External Email*



Gwendoline:

I think you may have conflicting versions of GNURadio and/or Fosphor. 
I have had this error before as well.


I use fosphor on a daily basis on both GNURadio 3.8 and 3.9 and I can 
confirm that it does work on several different nvidia GPU’s as Sylvain 
said. I have had some issues relating to the drivers for the GPU, but 
they were usually not related to GNURadio. I also have a machine 
without a GPU and am running Fosphor using the Intel CPU 
implementation of OpenCL found here:


https://osmocom.org/projects/sdr/wiki/Fosphor#Intel-CPU-OpenCL

You should start by uninstalling all previous versions of GNURadio and 
Fosphor before continuing. You’ll need to make sure that all libraries 
have been removed from your system before trying anything else.


Then, follow the build procedure for GNURadio 3.9 as 3.7 is EOL.

For Ubuntu 20 you’ll also need to make sure your computer is actually 
using the NVIDIA driver as it sometimes defaults to the nouveau driver 
even if NVIDIA is installed.






On Dec 23, 2021, at 08:37, Gwendoline Hochet Derevianckine via GNU
Radio, the Free & Open-Source Toolkit for Software Radio
mailto:discuss-gnuradio@gnu.org>> wrote:



Hi,

I install the package but before testing it I see a new problem.

Gnuradio is in version 3.9.4.0.

The fosphor sink block is in error so I can't run the flowgraph.

No matter what Window type I put, I have this error in block
parameters:

Param - Window Type(wintype):
    Value "firdes.WIN_BLACKMAN_hARRIS" cannot be evaluated:
    type object 'gnuradio.filter.filter_python.firdes' has no
attribute 'WIN_BLACKMAN_hARRIS'

Param - Window Type(wintype):
    Expression None is invalid for type 'int'.

Is it because of how I install gr-fosphor ?

Regards,

Gwendoline



*De :*Sylvain Munaut <246...@gmail.com>
*Envoyé :* jeudi 23 décembre 2021 12:13:53
*À :* Gwendoline Hochet Derevianckine
*Cc :* discuss-gnuradio@gnu.org
*Objet :* Re: fosphor sink block error

Warning - External Email


Hi,


If you're using Ubuntu, you can try the intel-opencl-icd package which
is the binary package for

https://github.com/intel/compute-runtime
which is the OpenCL driver for Intel GPUs.
However, I'm not sure anyone has ever run fosphor with it ... not sure
if it supports the features required, I only tried on AMD and NVidia
GPUs as I don't have any Intel GPU supporting that driver.

Cheers,

  Sylvain


To view our privacy policy, including the types of personal
information we collect, process and share, and the rights and
options you have in this respect, see
www.semtech.com/legal.


To view our privacy policy, including the types of personal 
information we collect, process and share, and the rights and options 
you have in this respect, see www.semtech.com/legal.

Re: Unknown CMake command "GR_PYTHON_CHECK_MODULE"

[Cinaed Simson]

Hi Some - the error message indicates cmake can't find thrift, i.e., 
see  FindTHRIFT.cmake in the error message.


I've never installed thrift.

-- Cinaed

On 12/7/21 23:40, Evariste Some wrote:

Given the following configuration: Ubuntu 20.04, Gnuradio 3.8, gr-gsm,etc.
We installed an application that  resulted to the following:
CMake Error at 
/usr/lib/x86_64-linux-gnu/cmake/gnuradio/FindTHRIFT.cmake:70 
(GR_PYTHON_CHECK_MODULE):

  Unknown CMake command "GR_PYTHON_CHECK_MODULE".
Call Stack (most recent call first):
/usr/share/cmake-3.16/Modules/CMakeFindDependencyMacro.cmake:47 
(find_package)
/usr/lib/x86_64-linux-gnu/cmake/gnuradio/gnuradio-runtimeConfig.cmake:24 
(find_dependency)

/usr/lib/x86_64-linux-gnu/cmake/gnuradio/GnuradioConfig.cmake:54 (include)
  CMakeLists.txt:111 (find_package)
-- Configuring incomplete, errors occurred!

We tirelessly went through the different configuration files, but 
still don't sense what we are missing.

Any form of help, suggestions will be highly appreciated.
Some E.

Re: Where are the blocjs ?

[Cinaed Simson]

Hi Gerard -using python3 on both machines type

from PyQt5.QtWidgets import *

and please post the result.

-- Cinaed


On 11/27/21 01:26, Gerard F6EEQ wrote:

Hi,

Another newbie question... I did not find answer in the wiki.

I try to use QT Dial, but did not find it.
This block is listed in the wiki, but is not present in my QT widget 
list menu, neither under Debian nor W10.


Thanks for hint.
Gerard

Re: Config files

[Cinaed Simson]

Hi Gerard - so the problems you're having are on W10 but not Debian?

If you're having trouble with Debian, please post the contents of

  /etc/debian_version

-- Cinaed

On 11/26/21 23:57, Gerard F6EEQ wrote:

Hi all,

I have two implementations of GNU.

One is under W10 on my main PC.
The second one is under LINUX (Debian) on a portable PC.

I do not have the same rendering on both machines.
For instance, when I look at he "oscilloscope" (QT Gui Time Sink) I 
have a capability to expand the trace on Debian, and not on W10.
There are probably some other differences, but this one is the main I 
have noticed.


I also noticed that on W10, when I execute the Time Sink there is a 
warning about something missing in the config file (which I did not 
find in W10!!).


Thanks for your help and sorry for newbie questions.
Gerard

.

Re: Gnuradio 3.8 on a Raspberry pi 4 B?

[Cinaed Simson]

Hi Glen - I'm late to the party. but I presume you have buster (debian 
10) installed - see /etc/os-release.


I don't own a raspberry pi 4 but I know someone who does and they 
recommend using following guide to upgrade to bullseye (debian 11)


https://www.tomshardware.com/how-to/upgrade-raspberry-pi-os-to-bullseye-from-buster 



bullseye (debian 10) comes with gnuradio 3.8.

If you need to use buster (debian 10) and gnuradio3.8, then you have to 
build it from source.


-- Cinaed


On 5/24/20 12:50, Glen I Langston wrote:

Hello

I’ve been a great proponent of gnuradio, but I’m finding in
increasing difficult to do anything new, as installation of 3.8 is
essentially impossible for most people.

I’ve written and built my own python modules and C++ blocks.

However, despite months of trying now, I can not get 3.8 to install
on a raspberry pi.

Has anyone achieved 3.8 on a raspberry pi?

If so can you please save the entire OS, gzip compressed and put it
online somewhere.  It will probably be about 3 GB compressed.

Thanks

Glen

Note that there are many many (too many) different guides on line

1) apt-get

2) pybombs

3) git clone then build

each one fails in a different way.

Re: No "osmocom source" and no RTL dongle

[Cinaed Simson]

If your end goal is to install gr-baz, then you need to build it from 
the source code.


It's old code and it assumes you have a UHD so you may need to install 
UHD  also to get it to build.


But to answer your question, you either need to build what you need from 
source or upgrade ubuntu.


And then it may not be able to get gr-baz to work regardless of which 
option you choose.


-- Cinaed


On 11/5/21 14:23, Ian Bennett wrote:

All,
I followed the install instructions from here: 
https://wiki.gnuradio.org/index.php/InstallingGR

After uninstalling 3.7 that came from the Ubuntu repos, I did:
$ sudo add-apt-repository ppa:gnuradio/gnuradio-releases
$ sudo apt update
$ sudo apt install gnuradio
This gave me version 3.8.2.0 (Python 3.6.9) and not 3.9 as indicated.
I now have no source for my RTL dongle, nor do I have a "osmocom 
source".
I note that during the install, one of the "Suggested Packages" is 
gr-osmosdr however at the bottom of the website install instructions 
it states "Attention: Do NOT try to install further packages like 
`gr-osmosdr` via Ubuntu's package management (i.e. using "apt"). 
Ubuntu will try to install a potentially incompatible version and your 
system will be in an undefined state."

How do I solve my RTL dongle and osmocom source problem?
Guidance appreciated.

Ian

On 6/11/21 7:51 am, Ian Bennett wrote:

Cinaed,
 Thanks for the reply.
 librtlsdr-dev was already installed. The other two were not and 
pulled in some other dependencies during the install process.

 This did not fix my problem though.
 I couldn't install gr-baz from the ubuntu repo so followed the 
build process for gr-baz on github. I could then get it to run, but 
with no output.
 After further reading, the website recommends a minimum version 
of 3.8. I note that 3.9 is available via a PPA so will install that 
and work through the tutorials (which I didn't find yesterday). Must 
have had a "man" look ;-)

 Thanks again for your assistance.

Ian

On 6/11/21 6:47 am, Cinaed Simson wrote:
I'd recommend installing -the following - if you haven't already 
done so


   librtlsdr-dev
   libosmosdr-dev
   libosmocore-dev (not sure)

And I'm just guessing - I don't have gnuradio 3.7 or ubuntu installed.

Also,unless you were able to in install the ubuntu package gr-baz 
from one of the ubuntu repositories - which is unlikely, then 
download and built  the code from


   https://github.com/balint256/gr-baz

I's an OOT module which doesn't come with gnuradio.

And I would test using the rtl dongle with gnuradio. Create a 
flowgraph with the "osmocom soure" and a "qt gui sink".


-- Cinaed

On 11/5/21 03:40, Ian Bennett wrote:

Good Evening,
I am taking my first tentative steps with GNU Radio.
I am using Ubuntu 18.04.6 LTS with a RTL2832U dongle from 
RTL-SDR.COM. This combination works fine with CubicSDR and rtl_433.
I installed gnuradio-companion from the repo (sudo apt install 
gnuradio) which gave me version 3.7.11-10.
I found a tutorial that built a FM receiver, so thought that 
would be a good place to start.
After a few issues building the receiver (solved with google), 
I finally got to the point where I could execute the flow graph.

Now I get the following in the terminal:

Executing: /usr/bin/python -u 
/data/Amateur_Radio/SDR/GNU-radio/top_block.py


Traceback (most recent call last):
  File "/data/Amateur_Radio/SDR/GNU-radio/top_block.py", line 35, 
in 

    import baz
  File "/usr/local/lib/python2.7/dist-packages/baz/__init__.py", 
line 40, in 

    from baz_swig import *
ImportError: No module named baz_swig

I can see there is "No module named baz_swig" but no amount of 
googling yielded a solution.

Hoping someone can help.
Regards,

Ian

.

Re: ImportError: No module named baz_swig

[Cinaed Simson]

I'd recommend installing -the following - if you haven't already done so

  librtlsdr-dev
  libosmosdr-dev
  libosmocore-dev (not sure)

And I'm just guessing - I don't have gnuradio 3.7 or ubuntu installed.

Also,unless you were able to in install the ubuntu package gr-baz from 
one of the ubuntu repositories - which is unlikely, then download and 
built  the code from


  https://github.com/balint256/gr-baz

I's an OOT module which doesn't come with gnuradio.

And I would test using the rtl dongle with gnuradio. Create a flowgraph 
with the "osmocom soure" and a "qt gui sink".


-- Cinaed

On 11/5/21 03:40, Ian Bennett wrote:

Good Evening,
I am taking my first tentative steps with GNU Radio.
I am using Ubuntu 18.04.6 LTS with a RTL2832U dongle from 
RTL-SDR.COM. This combination works fine with CubicSDR and rtl_433.
I installed gnuradio-companion from the repo (sudo apt install 
gnuradio) which gave me version 3.7.11-10.
I found a tutorial that built a FM receiver, so thought that would 
be a good place to start.
After a few issues building the receiver (solved with google), I 
finally got to the point where I could execute the flow graph.

Now I get the following in the terminal:

Executing: /usr/bin/python -u 
/data/Amateur_Radio/SDR/GNU-radio/top_block.py


Traceback (most recent call last):
  File "/data/Amateur_Radio/SDR/GNU-radio/top_block.py", line 35, in 


    import baz
  File "/usr/local/lib/python2.7/dist-packages/baz/__init__.py", line 
40, in 

    from baz_swig import *
ImportError: No module named baz_swig

I can see there is "No module named baz_swig" but no amount of 
googling yielded a solution.

Hoping someone can help.
Regards,

Ian

.

Re: Error installing spectrometer_w_cal.grc

[Cinaed Simson]

Hi Marcus - the buster OS is modern and I know it runs on the 
raspberry-pi4.


To install 3.8, on buster, one needs to use the backports from sid 
(which is not a release)


 apt install -t backports-buster gnuradio-dev

To use the backports, one needs to have the following entries in the 
/etc/apt/sources.list file


  deb http://ftp.debian.org/debian buster-backports main contrib non-free
  deb-src http://ftp.debian.org/debian buster-backports main contrib 
non-free


then run

  apt update

Sid is a rolling dsitribution which contains the latest packages.

-- Cinaed



Is buster the most recent debian version for Raspberry Pi? This would be much 
much much
easier if you had something more modern. Then, you could actually just `apt 
install
gnuradio gr-osmosdr` to get a GNU Radio 3.8.

wbfm_tx_rx.grc

[Cinaed Simson]

Hi Anish - here's a simple flow graph which transits and receives WBFM.  
The input is a wave file from https://github.com/drmpeg/gr-cessb and the 
output is the audio device.


-- Cinaed

options:
  parameters:
author: cinaed
category: '[GRC Hier Blocks]'
cmake_opt: ''
comment: ''
copyright: ''
description: ''
gen_cmake: 'On'
gen_linking: dynamic
generate_options: qt_gui
hier_block_src_path: '.:'
id: wbfm_tx_rx
max_nouts: '0'
output_language: python
placement: (0,0)
qt_qss_theme: ''
realtime_scheduling: ''
run: 'True'
run_command: '{python} -u {filename}'
run_options: prompt
sizing_mode: fixed
thread_safe_setters: ''
title: wbfm_tx_rx
window_size: (1000,1000)
  states:
bus_sink: false
bus_source: false
bus_structure: null
coordinate: [8, 8]
rotation: 0
state: enabled

blocks:
- name: audio_rate
  id: variable
  parameters:
comment: ''
value: '48000'
  states:
bus_sink: false
bus_source: false
bus_structure: null
coordinate: [224, 92.0]
rotation: 0
state: enabled
- name: quad_rate
  id: variable
  parameters:
comment: ''
value: audio_rate*10
  states:
bus_sink: false
bus_source: false
bus_structure: null
coordinate: [320, 20.0]
rotation: 0
state: enabled
- name: samp_rate
  id: variable
  parameters:
comment: ''
value: '48000'
  states:
bus_sink: false
bus_source: false
bus_structure: null
coordinate: [224, 20.0]
rotation: 0
state: enabled
- name: wbfm_bw
  id: variable
  parameters:
comment: ''
value: '20'
  states:
bus_sink: false
bus_source: false
bus_structure: null
coordinate: [320, 92.0]
rotation: 0
state: enabled
- name: analog_wfm_rcv_0
  id: analog_wfm_rcv
  parameters:
affinity: ''
alias: ''
audio_decimation: '10'
comment: ''
maxoutbuf: '0'
minoutbuf: '0'
quad_rate: quad_rate
  states:
bus_sink: false
bus_source: false
bus_structure: null
coordinate: [640, 228.0]
rotation: 0
state: enabled
- name: analog_wfm_tx_0
  id: analog_wfm_tx
  parameters:
affinity: ''
alias: ''
audio_rate: '48000'
comment: ''
fh: '-1.0'
max_dev: 75e3
maxoutbuf: '0'
minoutbuf: '0'
quad_rate: '48'
tau: 75e-6
  states:
bus_sink: false
bus_source: false
bus_structure: null
coordinate: [320, 204.0]
rotation: 0
state: true
- name: audio_sink_0
  id: audio_sink
  parameters:
affinity: ''
alias: ''
comment: ''
device_name: ''
num_inputs: '1'
ok_to_block: 'True'
samp_rate: samp_rate
  states:
bus_sink: false
bus_source: false
bus_structure: null
coordinate: [896, 236.0]
rotation: 0
state: true
- name: blocks_wavfile_source_0
  id: blocks_wavfile_source
  parameters:
affinity: ''
alias: ''
comment: ''
file: /opt/data/wave/ssbaudio.wav
maxoutbuf: '0'
minoutbuf: '0'
nchan: '1'
repeat: 'True'
  states:
bus_sink: false
bus_source: false
bus_structure: null
coordinate: [80, 228.0]
rotation: 0
state: true
- name: note_0
  id: note
  parameters:
alias: ''
comment: ''
note: https://github.com/drmpeg/gr-cessb/blob/master/apps/ssbaudio.wav
  states:
bus_sink: false
bus_source: false
bus_structure: null
coordinate: [80, 340.0]
rotation: 0
state: true
- name: qtgui_sink_x_0
  id: qtgui_sink_x
  parameters:
affinity: ''
alias: ''
bw: quad_rate
comment: ''
fc: '0'
fftsize: '1024'
gui_hint: ''
maxoutbuf: '0'
minoutbuf: '0'
name: '"WBFM Transmit"'
plotconst: 'False'
plotfreq: 'True'
plottime: 'False'
plotwaterfall: 'True'
rate: '10'
showports: 'False'
showrf: 'False'
type: complex
wintype: firdes.WIN_BLACKMAN_hARRIS
  states:
bus_sink: false
bus_source: false
bus_structure: null
coordinate: [640, 332.0]
rotation: 0
state: true
- name: qtgui_sink_x_1
  id: qtgui_sink_x
  parameters:
affinity: ''
alias: ''
bw: samp_rate
comment: ''
fc: '0'
fftsize: '1024'
gui_hint: ''
maxoutbuf: '0'
minoutbuf: '0'
name: '"WBFM recieve"'
plotconst: 'False'
plotfreq: 'True'
plottime: 'False'
plotwaterfall: 'True'
rate: '10'
showports: 'False'
showrf: 'False'
type: float
wintype: firdes.WIN_BLACKMAN_hARRIS
  states:
bus_sink: false
bus_source: false
bus_structure: null
coordinate: [872, 44.0]
rotation: 0
state: true

connections:
- [analog_wfm_rcv_0, '0', audio_sink_0, '0']
- [analog_wfm_rcv_0, '0', qtgui_sink_x_1, '0']
- [analog_wfm_tx_0, '0', analog_wfm_rcv_0, '0']
- [analog_wfm_tx_0, '0', qtgui_sink_x_0, '0']
- [blocks_wavfile_source_0, '0', analog_wfm_tx_0, '0']

metadata:
  file_format: 1

Re: LimeSDR | Sinewave test | Glitchy behavior

[Cinaed Simson]

Opps - ignore the following -I just realized  in my mind I was going the 
wrong direction - I got twisted:


  "If you were to add a signal source of 48 kHz, you would need to add 
a rational sampler in front of the WBFM block for a quadrature rate of 
480 kHz"


If you add a 48 kHz signal instead of the null source, then it would 
match the input sampling rate for WBFM transmit block.


-- Cinaed

Re: LimeSDR | Sinewave test | Glitchy behavior

[Cinaed Simson]

 Hi Anish - I would argue the flowgraph is a potentially a  model for a 
broken audio device :).


That is, the input signal to the WBFM block is not a 48 kHz signal - 
it's a null source, but you're telling the WBFM block to expect an input 
frequency of 48 kHz.


If you were to add a signal source of 48 kHz, you would need to add a 
rational sampler in front of the WBFM block for a quadrature rate of 480 
kHz.


And the typical bandwidth for a WBFM signal is roughly 200 kHz.

A mismatch in sampling rates in a flowgraph  is a common problem.

And there are other resamplers.

What I did previously was kludge so I could see the sine wave better 
without any hardware. If the other devices are actually using a null 
source, then they must be clipping the side bands.


-- Cinaed

On 5/15/21 5:34 AM, Anish Mangal wrote:

Hi. I performed some more tests and report the results on this thread.

https://discourse.myriadrf.org/t/glitchy-behavior-gr-limesdr-limesdr-usb-sinewave-test/7022/10?u=vu2tve 
<https://discourse.myriadrf.org/t/glitchy-behavior-gr-limesdr-limesdr-usb-sinewave-test/7022/10?u=vu2tve>


I'd love some advice with which I can produce a simple FM modulated 
sinewave with gnuradio and limesdr. If someone on this mailing list 
has a limesdr, and some bandwidth to test this out, I'll be more than 
happy to provide my flowgraphs.


Thanks!

On Mon, Mar 22, 2021 at 10:10 AM Anish Mangal <mailto:anis...@umich.edu>> wrote:


So far as I am able to tell with my limited knowledge of limesdr
and gnuradio, it seems like some kind of issue with the right
settings to me.

The gr-limesdr provides a sink block that allows one to use an
.ini file instead of the settings done via the block's settings. I
will have access to the radio in a few days' time and am thinking
i'll copy over the .ini file that was used in sdrangel and use the
exact same one in gnuradio and see what happens.

On Mon, Mar 22, 2021 at 8:22 AM Cinaed Simson
mailto:cinaed.sim...@gmail.com>> wrote:

Hi Anish - yes, I removed the LImeSDR block from the flow graph.

I inserted a throttle instead since I didn't have any front
end hardware available at the time.

I do have a WBFM receiver using gnuradio running on a HackRF
which works great.

But I'm using low pass filter taps in the complex rational
resampler which leads the WBFM receiver.

-- CInaed

On 3/20/21 7:52 PM, Anish Mangal wrote:

Hi Cinaed,

But this is without the actual LimeSDR sink block? Or with it?

Because, I can produce a clean sinewave with a HackRF, but
not the LimeSDR.

On Sun, Mar 21, 2021 at 1:07 AM Cinaed Simson
mailto:cinaed.sim...@gmail.com>> wrote:

Hi Anish - I think I may have found the problem.

When the complex rational resampler is on the out put of
the WBFM, it bothered me  later that I couldn't see the
top of the signal.

The scale on QT GUI SINK was clipping the signal but not
the computational noise.

In the QT GUI SINK, if I set the Y-min to be -99 and
Y-max to be 0,  the signal looks perfect.

And if the receiving RTL dongle has noise while
listening, it may be a DC offset problem.

-- Cinaed


On 3/18/21 6:58 AM, Anish Mangal wrote:

Here are two debug logs from LimeSuite GUI. In one, I
load the settings that gnuradio does to the limesdr and
see the debug log. The other is the settings file which
the sdrangel writes.

If I diff them, among other differences, this is what I
see in the end of the sdrangel-debug-log
DEBUG: Selected: VCOL
DEBUG: csw 169; interval [166, 172]
DEBUG: M=195, N=3, Fvco=1300.000 MHz

And this is what I see in the gnuradio-debug-log
DEBUG: Selected: VCOM
DEBUG: csw 174; interval [171, 177]

Now, I'm *very* new to this.. but could it mean that
different VCOs are used in both cases, and in the case
of gnuradio, it maybe has some issues to stabilize to
some freq?

On Thu, Mar 18, 2021 at 7:12 PM Christophe Seguinot
mailto:christophe.segui...@orange.fr>> wrote:

Hi all

There is something wrong in this simulation.

Attached is a flowgraph with a selectable Lime SDR
Source, and a RTL-SDR dongle as receiver. I tested
this with a Lime SDR Mini.

  * I was suspecting a Lime SDR issue, however this
is not so clear.
  * As Anish I also tested a const source.
  * The flowgraph is running fluently and I dont'
see any error m

Re: Sample Rate and audio underflow ....

[Cinaed Simson]

Hi Rob - you should just post the GRC file to the mailing list - just 
attach it to the message.


If the only thing you changed was sampling rate, then you will most 
likely have trouble.


 But you haven't provided enough information in order for anone to help 
you.


Note, the website in the URL appears to be insecure - at least my 
browser claims it's insecure - presumably because it usees http instead 
https.


-- Cinaed

On 5/13/21 1:30 PM, Rob Roschewsk wrote:

Hi all!

I'm working on a "Hello, World!" flow in GRC  just a simple NBFM 
receiver tuned to my local NOAA station.


Using an RTLSDR and the osmocom block ... into a low-pass that 
decimates by 5 into the NBFM block and then an audio sink. It doesn't 
get any more simple. Here is a image of the flow 
http://pabut.org/wiki/images/a/aa/My-fmrcv.grc.png 



So with the sampling rate set to 2M  works fine . if I REDUCE 
the sample rate, say 240k, I start to get audio sink underruns 
"aUaUaUaUaUaUaUaUaU" and I only get small blurbs of audio.


I'm sure to set the sample rate in the downstream blocks appropriately.

240k samples/sec should be plenty for a 5khz deviation FM signal ... 
right??


This is completely counterintuitive to what I was expecting.  I 
thought by reducing the sample rate I would lower CPU consumption ... 
and mitigate the exact problem I'm experiencing at the lower rate.


What am I not grocking here??

Thanks,
--> Rob

Re: HackRF and osmcom

[Cinaed Simson]

Hi Bruce - if you only have 1 HackRF One connected the computer, then 
you can just leave the "Device Arguments" blank.


Otherwise, take the last 8 characters of the serial number - not the 
entire serial number.


-- Cinaed


On 5/13/21 1:27 PM, KG4HLZ wrote:

Gnu Radio noob here.

I am trying to get osmocom working with HckRF One. I am getting the 
following:



Generating: '/home/bruce/Documents/gnuRadio/testHackRF.py'

Executing: /usr/bin/python3 -u 
/home/bruce/Documents/gnuRadio/testHackRF.py


QStandardPaths: XDG_RUNTIME_DIR not set, defaulting to '/tmp/runtime-root'
gr-osmosdr 0.2.0.0 (0.2.0) gnuradio 3.8.1.0
built-in source types: file osmosdr fcd rtl rtl_tcp uhd miri hackrf 
bladerf rfspace airspy airspyhf soapy redpitaya freesrp

Traceback (most recent call last):
  File "/home/bruce/Documents/gnuRadio/testHackRF.py", line 202, in 


    main()
  File "/home/bruce/Documents/gnuRadio/testHackRF.py", line 180, in main
    tb = top_block_cls()
  File "/home/bruce/Documents/gnuRadio/testHackRF.py", line 133, in 
__init__

    self.osmosdr_source_0 = osmosdr.source(
  File "/usr/lib/python3/dist-packages/osmosdr/osmosdr_swig.py", line 
1074, in make

    return _osmosdr_swig.source_make(*args, **kwargs)
RuntimeError: basic_string::compare: __pos (which is 
18446744073709551614) > this->size() (which is 32)


>>> Done (return code 1)


The HackRF seems to be running ok. I can pull information from it with 
no problem.


I am running Ubuntu 20.04.2 LTS (Focal Fossa).

I don't know is this mailing list forwards screen shots but heer is my 
osmcom setup:


Screenshot from 2021-05-13 14-50-01.png

Thanks!
Bruce

Re: GNU Radio gr-osmosdr on Ubuntu Installation Error; Kali Successfully Installs but Can’t Run

[Cinaed Simson]

Hi Chris - I'm saying, my updated git copy of gr-osmosdr usng

   git branch -a

doesn't have an enrty for 3.9 - so it suggests it has not  been ported 3.9

Acutally, I meant say "does not" have an entry for 3.9.

I've have never used gr-soapy so I don't anything about it.

-- Cinaed


On 5/7/21 2:33 AM, Chris Vine wrote:

On Fri, 7 May 2021 00:43:25 -0700
Cinaed Simson  wrote:

Hi David - looking at my local git hub copy of the source for
gr-osmosdr, it does appear to have been ported to 3.9 - just 3.7 and 3.8.

-- CInaed

On 5/5/21 4:48 AM, David Martini wrote:

In my case gr-osmosdr on ubuntu 20.04
Work just in gnuradio 3.8.1.
I'm not able to run it on ubuntu 3.9.. at least unit 10 days ago.

David Martini

Did you mean to say it has not been ported to 3.9, or that something
else (I am not sure what) has not been ported to 3.7 and 3.8?

If the former, that's not right: the master branch of the git repo at
git://git.osmocom.org/gr-osmosdr works fine with gnuradio-3.9.1.0.  You
must be on its gr3.8 branch by mistake if you are restricted to
gnuradio-3.8.

The problematic one is gr-soapy.  The has been ported to 3.8 and the
forthcoming 3.10 (where it is now in gnuradio's master branch) but not
to 3.9.  However there is a privately maintained repo at
git://gitlab.com/willcode4/gr-soapy.git which has a maint-3.9 branch
which moves the code to pybind11 and works OK with gnuradio-3.9 (for me
at least).

Chris

.

Re: GNU Radio gr-osmosdr on Ubuntu Installation Error; Kali Successfully Installs but Can’t Run

[Cinaed Simson]

Hi David - looking at my local git hub copy of the source for 
gr-osmosdr, it does appear to have been ported to 3.9 - just 3.7 and 3.8.


-- CInaed


On 5/5/21 4:48 AM, David Martini wrote:

In my case gr-osmosdr on ubuntu 20.04
Work just in gnuradio 3.8.1.
I'm not able to run it on ubuntu 3.9.. at least unit 10 days ago.

David Martini


Il Mer 5 Mag 2021, 12:49 Jeff Long > ha scritto:


On Ubuntu 20.04, apt install gr-osmosdr works.

It sounds like you've gone through quite a bit here.

What is the HackRF1 RF Receiver you mention?

On Wed, May 5, 2021 at 4:28 AM Jessica Chen
mailto:jessica.san.c...@gmail.com>>
wrote:

Dear all,

My main goal is to simply get the HackRF One FM receiver to
work on GRC. In short, I’ve tried:
- GNU Radio installation on Ubuntu 20.04 via PPAs, PyBOMBS,
and source. Unfortunately, no variation yields the osmocom
source I need. Additional attempts to install gr-osmosdr, via
default packet managers, git, and source, have failed, largely
due to version incompatibilities.
- The same processes worked on a Kali Linux virtual machine
(PPAs and PyBOMBS failed, both source installation worked).
However, this was a messy installation, and 3 tests failed
during make test (see below).
- GRC on Kali Linux fails to make the HackRF1 FM receiver (see
below). I’ve been able to get the FM receiver to work on GQRX
(Ubuntu) with the same hardware, so it shouldn’t be a hardware
problem.
- Other simple tutorial flow graphs fail to run on my Kali
Linux GRC.

Any help would be very much appreciated:
- How do I get gr-osmosdr on Ubuntu GRC? I know others have
ran into this problem on the mailing list archives, but I feel
like I’ve already ran through every suggestion. Please let me
know if you feel like I’ve missed any.
- Why is the FM receiver on my Kali GRC not working? Is it
just because I’m missing some fundamental knowledge on SDRs,
or is this problem rooted in installation?
- Should I separate my problems into multiple threads?

*Longer overview of what I've tried so far.* It’s still
truncated from my original documentation, so please feel free
to ask for an even longer version.
- [DEFAULT] On Ubuntu 20.04 LTS, apt-get installed hackrf and
gnuradio (gnuradio-config-info --version returns 3.8.1.0).
However, there's *no osmocom source*.
- [PYBOMBS] Since archives recommended PyBOMBS installation
for gr-osmosdr over source installation, I followed
instructions here (https://github.com/gnuradio/pybombs/
) to install PyBOMBS.
However, I ran into problems "while building package libvolk."
- [LIBVOLK] It seems a lot of people ran into a similar
problem, so I followed suggestions here
(https://github.com/gnuradio/gnuradio/issues/3814
) to set
"gitarg: --recursive" in libvolk.lwr. However, I found that my
version already had this recursive setting, so my libvolk
error was independent of the discussion on GitHub.
- [SOURCE] Followed instructions here
(https://wiki.gnuradio.org/index.php/InstallingGR#From_Source
)
to install GNU Radio from source. As recommended, I installed
volk first with no problems. I ran into an error with pybind
but I fixed it with the recommended conda installation
(python3-pybind11 did not work). I reached the end of
installation with minimal errors, but *still no OSMOCOM.*
- [PYBOMBS] Some people recommended using PyBOMBS to install
gr-osmosdr, so I tried it. This time, got past libvolk error,
but ran into *error**intsalling gr-iqbal*! I tried a long fix,
detailed here (https://hackmd.io/@j-chen/HJROJK8L_
), but it didn't work. At
some point, I realized my gnuradio-config-info --version
returns "v3.10.0.0git-265-g5547665e."
- [PPA] As such, I tried to "clean" Ubuntu using the top-voted
answer here

(https://askubuntu.com/questions/859448/is-there-a-command-to-factory-reset-ubuntu

)
(which I know doesn't actually clean it) and PPA re-installed
GNU Radio 3.8 AND 3.9 (tried both separately; neither
magically worked).
- [OSMO SOURCE] Followed instructions here
(https://osmocom.org/projects/gr-osmosdr/wiki
) to install
gr-osmosdr from source. However, I ran into an 

Re: Windows 7 x64 problem...

[Cinaed Simson]

Hi Alberto - this is the last release of python-2.x

  https://www.python.org/downloads/release/python-2718/

Since your problem doesn't appear to be  a gnuradio problem, you might 
want to contact a python discussion group


   https://stackoverflow.com/questions/tagged/python

- or a Windows 7 group.

-- Cinaed

On 4/22/21 1:01 PM, Alberto wrote:

No idea ?



Inviato da iPhone


Il giorno 19 apr 2021, alle ore 17:55, Alberto  ha 
scritto:

Hi !
I have created a simple example to View 100MHz signal from sdr receiver...but i 
have a problem.

My OS is Windows 7 x64, GNURadio 3.7.13.5.

When i start a receiver with gnuradio an window error open:

Pyton.exe has stop working

Can you help me ?

Alberto




Inviato da iPhone

Re: Why does preferences file get installed in /usr/local despite setting custom install prefix?

[Cinaed Simson]

Hi Wan - this path

  /home/..

is not your home path - or your home directory.

Type

  cd /home/..

and then

  ls

and see if you find the gnuradio directory. If you didn't have root 
privilege at the time then the install failed.


Assuming your userid is

  wan

then

  /home/wan

is you home directory..

What operating system and version are your running?

-- Cinaed


On 4/22/21 8:56 AM, wan wrote:

Hi Cinaed and Neel,

Thanks for your quick response.

My custom prefix is /home/. I was just shortening it with 
"/home/...", sorry for the confusion.


I followed a similar process as in the app note.
I ran $ cmake-gui ../ in the build directory.
Then I used the GUI to configure and generate the flags 
CMAKE_INSTALL_PREFIX, UHD_DIR, UHD_INCLUDE_DIRS, and UHD_LIBRARIES. I 
also set PYTHON_EXECUTABLE to usr/bin/python3.8


For good measure, tried to build again, this time I can ran
$ cmake -DCMAKE_INSTALL_PREFIX=/home/ -DUHD_DIR=/home/path>/lib/cmake/uhd -DUHD_INCLUDE_DIRS=/home//include 
-DUHD_LIBRARIES = /home//lib/libuhd.so 
-DPYTHON_EXECUTABLE=/usr/bin/python3.8 ../


The preferences file is still installed to /usr/local

Here's the full gnuradio-config-info output after second attempt

/home/
/home//etc
/usr/local/etc/gnuradio/conf.d
/home//.gnuradio
Thu, 22 Apr 2021 15:25:41
testing-support;python-support;post-install;doxygen;gnuradio-runtime;gr-ctrlport
3.9.0.0
cc (Ubuntu 9.3.0-17ubuntu1~20.04) 9.3.0
Copyright (C) 2019 Free Software Foundation, Inc.
This is free software see the source for copying conditions. There is NO
warranty not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
c++ (Ubuntu 9.3.0-17ubuntu1~20.04) 9.3.0
Copyright (C) 2019 Free Software Foundation, Inc.
This is free software see the source for copying conditions. There is NO
warranty not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
/usr/bin/cc:::-O3 -DNDEBUG  -fvisibility=hidden -Wsign-compare -Wall 
-Wno-uninitialized
/usr/bin/c++:::-O3 -DNDEBUG  -fvisibility=hidden -Wsign-compare -Wall 
-Wno-uninitialized



On Thu, 22 Apr 2021 at 08:31, Neel Pandeya <mailto:neel.pand...@ettus.com>> wrote:

>
> Hello Wan:
>
> Did you set a custom installation path when you ran CMake?
>
> How did you invoke CMake when you built GNU Radio?
>
> The Application Note listed below might help you.
>
> 
https://kb.ettus.com/Building_and_Installing_UHD_and_GNU_Radio_to_a_Custom_Prefix 
<https://kb.ettus.com/Building_and_Installing_UHD_and_GNU_Radio_to_a_Custom_Prefix>

>
> --Neel Pandeya
>
>
>
> On Thu, 22 Apr 2021 at 02:28, Cinaed Simson <mailto:cinaed.sim...@gmail.com>> wrote:

>>
>>
>> On 4/21/21 9:48 PM, wan wrote:
>> > Hi all,
>> >
>> > I set a custom install prefix while installing from source. However,
>> > the preference file still gets installed to /usr/local, as you 
can see

>> > from the gnuradio-config-info output below.
>> >
>> > gnuradio-config-info --print-all
>> > /home/.../envs/uhd-gr-default/
>> > /home/.../envs/uhd-gr-default/etc
>> > /usr/local/etc/gnuradio/conf.d
>> > /home/.../.gnuradio
>> >
>> > Why does preferences file get installed in /usr/local despite setting
>> > a custom install prefix? And is this expected?
>> >
>> > Regards,
>> >
>> > Wan L.
>>
>> Hi Wan - you should indicate the version of gnuradio you installed.
>>
>> Something appears to have gone wrong with your install - you're missing
>> most of the expected information. It looks like your home directory was
>>
>>    /home/..
>>
>> For comparison,  here's  the output for version 3.8 that I installed
>> from source.
>>
>> gnuradio-config-info --print-all
>> /opt/gnuradio
>> /opt/gnuradio/etc
>> /opt/gnuradio/etc/gnuradio/conf.d
>> /home/cinaed/.gnuradio
>>
>> 
testing-support;python-support;volk;doxygen;sphinx;gnuradio-runtime;gr-ctrlport;gnuradio-companion;gr-blocks;gr-fec;gr-fft;gr-filter;gr-analog;gr-digital;gr-dtv;gr-audio;*

>> alsa;* oss;* jack;*
>> 
portaudio;gr-channels;gr-qtgui;gr-trellis;gr-uhd;gr-utils;gr_modtool;gr-video-sdl;gr-vocoder;*

>> gsm;gr-wavelet;gr-zeromq
>> v3.8.2.0-73-g4a84443c
>> gcc (Debian 8.3.0-6) 8.3.0
>> Copyright (C) 2018 Free Software Foundation, Inc.
>> This is free software see the source for copying conditions.  There 
is NO
>> warranty not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR 
PURPOSE.

>> g++ (Debian 8.3.0-6) 8.3.0
>> Copyright (C) 2018 Free Software Foundation, Inc.
>> This is free software see the source for copying conditions.  There 
is NO
>> warranty not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR 
PURPOSE.

>> /usr/bin/gcc:::-O3 -DNDEBUG -march=native -O3 -fvisibility=hidden
>> -Wsign-compare -Wall -Wno-uninitialized
>> /usr/bin/g++:::-O3 -DNDEBUG -march=native -O3 -fvisibility=hidden
>> -Wsign-compare -Wall -Wno-uninitialized
>>
>>

Re: Why does preferences file get installed in /usr/local despite setting custom install prefix?

[Cinaed Simson]

On 4/21/21 9:48 PM, wan wrote:

Hi all,

I set a custom install prefix while installing from source. However, 
the preference file still gets installed to /usr/local, as you can see 
from the gnuradio-config-info output below.


gnuradio-config-info --print-all
/home/.../envs/uhd-gr-default/
/home/.../envs/uhd-gr-default/etc
/usr/local/etc/gnuradio/conf.d
/home/.../.gnuradio

Why does preferences file get installed in /usr/local despite setting 
a custom install prefix? And is this expected?


Regards,

Wan L.


Hi Wan - you should indicate the version of gnuradio you installed.

Something appears to have gone wrong with your install - you're missing 
most of the expected information. It looks like your home directory was


  /home/..

For comparison,  here's  the output for version 3.8 that I installed 
from source.


gnuradio-config-info --print-all
/opt/gnuradio
/opt/gnuradio/etc
/opt/gnuradio/etc/gnuradio/conf.d
/home/cinaed/.gnuradio

testing-support;python-support;volk;doxygen;sphinx;gnuradio-runtime;gr-ctrlport;gnuradio-companion;gr-blocks;gr-fec;gr-fft;gr-filter;gr-analog;gr-digital;gr-dtv;gr-audio;* 
alsa;* oss;* jack;* 
portaudio;gr-channels;gr-qtgui;gr-trellis;gr-uhd;gr-utils;gr_modtool;gr-video-sdl;gr-vocoder;* 
gsm;gr-wavelet;gr-zeromq

v3.8.2.0-73-g4a84443c
gcc (Debian 8.3.0-6) 8.3.0
Copyright (C) 2018 Free Software Foundation, Inc.
This is free software see the source for copying conditions.  There is NO
warranty not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
g++ (Debian 8.3.0-6) 8.3.0
Copyright (C) 2018 Free Software Foundation, Inc.
This is free software see the source for copying conditions.  There is NO
warranty not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
/usr/bin/gcc:::-O3 -DNDEBUG -march=native -O3 -fvisibility=hidden 
-Wsign-compare -Wall -Wno-uninitialized
/usr/bin/g++:::-O3 -DNDEBUG -march=native -O3 -fvisibility=hidden 
-Wsign-compare -Wall -Wno-uninitialized

Re: PT GUI SINK (name)

[Cinaed Simson]

Hi Marcus - not to beat a dead horse, but  in 3.8, the id sets both name 
of the python script and name the qtgui sink. In the qtgui sink, the 
name can be overridden.


-- Cinaed

On 4/12/21 12:54 PM, Marcus Müller wrote:

Hi Cinaed,

nope, that sets the id, i.e. the name of the Python object. That can't affect 
the Text
displayed.

Best regards,
Marcus

On 12.04.21 21:33, Cinaed Simson wrote:

Hi Alberto - in the GRC file, open the

   Options

block and set the

   Id

field to

   test

Doesn't need  quotes - and in general  no hyphens - use underscore instead.

-- Cinaed

On 4/12/21 4:30 AM, alberto.alle...@alice.it wrote:

  Hi to all!
Today i have another question..

I have created a small spectrum analyzer and it work fine.

But, in the QT GUI SINK, at "Name" field i have writted "Test".but when i 
execute in
the windows "Test" don't appear ... why ?

Screenshot attacched

Tnx
Alberto

Re: PT GUI SINK (name)

[Cinaed Simson]

Hi Alberto - in the GRC file, open the

  Options

block and set the

  Id

field to

  test

Doesn't need  quotes - and in general  no hyphens - use underscore instead.

-- Cinaed

On 4/12/21 4:30 AM, alberto.alle...@alice.it wrote:

 Hi to all!
Today i have another question..

I have created a small spectrum analyzer and it work fine.

But, in the QT GUI SINK, at "Name" field i have writted "Test".but 
when i execute in the windows "Test" don't appear ... why ?


Screenshot attacched

Tnx
Alberto

Re: R: Re: R: Re: Gnuradio / Ubuntu 20.10

[Cinaed Simson]

Also, you may want to install the rtl software

  apt install  rtl-sdr librtlsdr

It's possible they may have been installed with gr-osmosdr.

-- Cinaed


On 4/11/21 9:30 AM, alberto.alle...@alice.it wrote:

I have followed pdf guide and now work fine but
It work fine but after oper FFT window (QT GUI SINK) there is this alert:

Warning: failed to XInitThreads()
gr-osmosdr 0.2.0.0 (0.2.0) gnuradio 3.8.1.0

why ?

Alberto

Messaggio originale
Da: muel...@kit.edu
Data: 11-apr-2021 17.31
A: 
Ogg: Re: R: Re: Gnuradio / Ubuntu 20.10

Hi Ralf,

glad to hear you've got it to work!

When not using the PPA (which I was assuming you'd be doing),
you'd get the exact
gr-osmosdr that works with Ubuntu's version of GNU Radio (i.e.
3.8.1.0 as I thought you've
installed?).

Best regards,
Marcus

On 11.04.21 16:40, Ralf Gorholt wrote:
> Hello Marcus,
>
> I had done this before (installed from PPA) but I didn't get a
module
> that worked with GNU Radio 3.8.2. That's why I have compiled it
from
> source. When the module is compiled, you have to pay attention
to the
> correct prefix for cmake.
>
> Ralf
>
> Am 11.04.2021 um 14:37 schrieb Marcus Müller:
>> You have to do none of this,
>>
>> sudo apt install gr-osmosdr
>>
>> does everything. And then you're done and can use the OSMOSDR
Source or the RTL-Source
>> (which are essentially the same).
>>
>> Cheers,
>> Marcus
>>
>> On 11.04.21 13:26, Ralf Gorholt wrote:
>>> Hello Alberto,
>>>
>>> you may try this:
>>>
>>> git clone git://github.com/osmocom/gr-osmosdr -b gr3.8
>>>
>>> That's how I got the sources for GNU Radio 3.8 one or two
weeks ago.
>>>
>>> Regards,
>>>
>>> Ralf
>>>
>>> Am 11.04.2021 um 12:35 schrieb alberto.alle...@alice.it:
 I follow now this guide:


https://lists.gnu.org/archive/html/discuss-gnuradio/2020-09/pdfNp27msymbN.pdf




 But at point 7 i have a problem.

 alberto@alberto-Studio-XPS-1340:~/sdr_stuff$ git clone
https://git.osmocom.org/gr-osmosdr

 Clone in 'gr-osmosdr' in corso...
 error: Failed to connect to git.osmocom.org port 443:
Connessione scaduta (curl_result =
 7, http_code = 0, sha1 =
3d94e1a5d172fc93da9e9638536ee773f4b5a85a)
 error: Unable to find
99f14f4991f4154d743fd08b9c49e4eaf8a70001 under
 https://git.osmocom.org/gr-osmosdr

 Cannot obtain needed blob
99f14f4991f4154d743fd08b9c49e4eaf8a70001
 while processing commit
2d504bde50a0c560a9d31b7b38982bd44cc7fe9d.
 error: recupero non riuscito.
 alberto@alberto-Studio-XPS-1340:~/sdr_stuff$

  Messaggio originale
  Da: fab...@opencode.eu
  Data: 10-apr-2021 22.08
  A: 
  Ogg: Re: Gnuradio / Ubuntu 20.10

  Hi Alberto,
  Just open a terminal and run
  sudo apt install gnuradio
  And you should be fine. The dependencies for the rtl-sdr
are already included.
  It is probably not the latest version of
gnuradio, but IT should get you
  started.

  Fabian

  Am 10. April 2021 21:38:47 MESZ schrieb Alberto Alletto
:

  Hi!
  I’m new on ubuntu world.
  Today i have installed ubuntu 20.10 and i want
install Gnuradio to work with
 RTL-SDR receiver.

  what is the correct procedure to install gnuradio to
work with the rtl-sdr
 receiver?

  Tnx
  Alberto

  Inviato da iPhone



>
>

Re: R: Re: problem to install gr-osmosdr

[Cinaed Simson]

If you need to use gr-osmosdr and gr-iqbal, you need to install 
gnuradio-3.8 because those packages do not support gnuardio-3.9 yet.


Version 3.9 is the "bleeding edge".

I've never used pybombs to install software - I just use git - but you 
need to tell pybombs you want to install gnuradio 3.8.


If you ask on the gnuradio mailing list, they can tell you how  to force 
pybombs to install version 3.8.


Alternatively, if you're running Ubuntu 20, I believe you can install 
the Ubuntu version by typing


  apt install gnuradio

which will install version 3.8.

-- Cinaed


On 4/10/21 2:30 AM, alberto.alle...@alice.it wrote:

Tnx for your help.
Before your reply i have used this command:

alberto@alberto-Studio-XPS-1340:~$ pybombs prefix init ~/prefix-3.9 -R 
gnuradio-default

alberto@alberto-Studio-XPS-1340:~$ pybombs install gr-osmosdr
[INFO] Prefix Python version is: 3.8.5
[INFO] PyBOMBS Version 2.3.4
[INFO] Phase 1: Creating install tree and installing binary packages:
Install tree:
|
\- gr-osmosdr
   |
   +- gr-fcdproplus
   |
   +- bladeRF
   |
   +- airspyhf
   |
   +- hackrf
   |
   +- gr-iqbal
   |  |
   |  \- libosmo-dsp
   |
   +- airspy
   |
   +- soapysdr
   |
   +- rtl-sdr
   |
   \- osmo-sdr
[INFO] Phase 1 complete: All binary dependencies installed.
[INFO] Phase 2: Recursively installing source packages to prefix:
[INFO] Installing package: osmo-sdr
fatal: impossibile accedere a 'https://git.osmocom.org/osmo-sdr/': 
Failed to connect to git.osmocom.org port 443: Connessione scaduta

error: Impossibile recuperare osmo-sdr
[ERROR] Unexpected error while fetching 
git+https://git.osmocom.org/osmo-sdr.
[ERROR] Command '['git', 'remote', 'update', 'osmo-sdr']' returned 
non-zero exit status 1.

[ERROR] Problem occurred while building package osmo-sdr:
Unable to fetch recipe osmo-sdr
[ERROR] Error installing package osmo-sdr. Aborting.


So...another problem :
[INFO] Installing package: osmo-sdr
fatal: impossibile accedere a 'https://git.osmocom.org/osmo-sdr/': 
Failed to connect to git.osmocom.org port 443: Connessione scaduta

error: Impossibile recuperare osmo-sdr
[ERROR] Unexpected error while fetching 
git+https://git.osmocom.org/osmo-sdr.
[ERROR] Command '['git', 'remote', 'update', 'osmo-sdr']' returned 
non-zero exit status 1.

[ERROR] Problem occurred while building package osmo-sdr:
Unable to fetch recipe osmo-sdr
[ERROR] Error installing package osmo-sdr. Aborting.




Messaggio originale
Da: cinaed.sim...@gmail.com
Data: 9-apr-2021 20.28
A: 
Ogg: Re: problem to install gr-osmosdr

Hi Alberto - actually, everything will work at the moment without
gr-iqbal.

Type

   gnuradio-config-info -v

and post the output on this mailing list.

The reason gr-iqbal failed is because gr-iqbal thinks you install
gnuradio-3.9  instead of gnuradio-3.8.

-- Cinaed

Re: Upgrade to GNURadio v3.8 Python Issue?

[Cinaed Simson]

Hi Jeff - I can run the zeromq_pushpull.grcvfrom gnuradio3.8 examples 
without any warnings using version 3.8.2.0-73-g4a84443c, Python 3.7.3 
under Debian 10 (or buster.)


The gnuradio-3.8 install was a clean install.

-- Cinaed


I can run  zmpq

On 4/5/21 4:04 AM, Jeff S wrote:

I hope this is the correct list for this question.

I'm finally getting around to getting some PCs upgraded from 3.7 to 
3.8.  I did the installs to a local prefix and everything seems to be 
running.  What I'm seeing, however, is when I have a ZMQ Pull Source 
added to my graph (picture of the simple graph attached), I'm getting 
some startup warnings a whole bunch of:



$ gnuradio-companion
<<< Welcome to GNU Radio Companion v3.8.2.0-88-g38f5ab7b >>>

Block paths:
/home/sdr/sdr/x310/installs/share/gnuradio/grc/blocks

*Loading: "/home/sdr/jas/flow/untitled.grc"*
*/usr/lib/python3.6/importlib/_bootstrap.py:219: ImportWarning:
can't resolve package from __spec__ or __package__, falling back
on __name__ and __path__*
*  return f(*args, **kwds)*


I've searched the GNURadio Archives for "ImportWarning" to see what 
could be the issue and it doesn't seems to show up much.  I've checked 
my PYTHONPATH and LD_LOAD_PATH and I think they seem right (unless I'm 
not seeing the obvious):


$ echo $PYTHONPATH

/home/sdr/sdr/x310/installs/lib/python3/dist-packages:/home/sdr/sdr/x310/installs/lib/python3.6/site-packages:/usr/local/lib/python3/dist-packages:usr/local/lib/python2.7/site-packages:
$ echo $LD_LIBRARY_PATH
/home/sdr/sdr/x310/installs/lib:/user/local/lib:
$ gnuradio-config-info --prefix
/home/sdr/sdr/x310/installs
$ find /home/sdr/sdr/x310/installs -name gnuradio | grep "packages"
/home/sdr/sdr/x310/installs/lib/python3/dist-*packages*/gnuradio


Anyone see the obvious thing that I'm missing?

Thanks and regards,
Jeff

Re: LimeSDR | Sinewave test | Glitchy behavior

[Cinaed Simson]

Hi Anish - yes, I removed the LImeSDR block from the flow graph.

I inserted a throttle instead since I didn't have any front end hardware 
available at the time.


I do have a WBFM receiver using gnuradio running on a HackRF which works 
great.


But I'm using low pass filter taps in the complex rational resampler 
which leads the WBFM receiver.


-- CInaed

On 3/20/21 7:52 PM, Anish Mangal wrote:

Hi Cinaed,

But this is without the actual LimeSDR sink block? Or with it?

Because, I can produce a clean sinewave with a HackRF, but not the 
LimeSDR.


On Sun, Mar 21, 2021 at 1:07 AM Cinaed Simson <mailto:cinaed.sim...@gmail.com>> wrote:


Hi Anish - I think I may have found the problem.

When the complex rational resampler is on the out put of the WBFM,
it bothered me  later that I couldn't see the top of the signal.

The scale on QT GUI SINK was clipping the signal but not the
computational noise.

In the QT GUI SINK, if I set the Y-min to be -99 and Y-max to be
0,  the signal looks perfect.

And if the receiving RTL dongle has noise while listening, it may
be a DC offset problem.

-- Cinaed


On 3/18/21 6:58 AM, Anish Mangal wrote:

Here are two debug logs from LimeSuite GUI. In one, I load the
settings that gnuradio does to the limesdr and see the debug log.
The other is the settings file which the sdrangel writes.

If I diff them, among other differences, this is what I see in
the end of the sdrangel-debug-log
DEBUG: Selected: VCOL
DEBUG: csw 169; interval [166, 172]
DEBUG: M=195, N=3, Fvco=1300.000 MHz

And this is what I see in the gnuradio-debug-log
DEBUG: Selected: VCOM
DEBUG: csw 174; interval [171, 177]

Now, I'm *very* new to this.. but could it mean that different
VCOs are used in both cases, and in the case of gnuradio, it
maybe has some issues to stabilize to some freq?

On Thu, Mar 18, 2021 at 7:12 PM Christophe Seguinot
mailto:christophe.segui...@orange.fr>> wrote:

Hi all

There is something wrong in this simulation.

Attached is a flowgraph with a selectable Lime SDR Source,
and a RTL-SDR dongle as receiver. I tested this with a Lime
SDR Mini.

  * I was suspecting a Lime SDR issue, however this is not so
clear.
  * As Anish I also tested a const source.
  * The flowgraph is running fluently and I dont' see any
error message about transmission to Lime SDR

Conclusion of my simulations :

  * with a const source (=1) at Lime input : everything is
OK, the received signal is frequency shifted (normal) and
the SNR is correct if LimeSDR Gain is sufficient
  * Using ratioanal resampler followed by WBFM Transmit Same
reslt, everything is OK
  * First source+ WBFM + Rational resampler (this is a sample
file found on LimeSDR website
  o the spectrum is not correct (look like  a modulated
signal
  o the received signal magnitude is not constant
  o *BUT the send signal on the Time Sink look like
correct. ( I.E =1+j0 as for others sources, whitout
any glicht)
*

How can we further investigate this?


On 18/03/2021 13:13, Anish Mangal wrote:

And, if I try the attach gnuradio file, which is just a
constant source of value '1' going to the limesdr sink
block, I actually see a sine-ish wave without the glitchy
behavior.

On Thu, Mar 18, 2021 at 5:31 PM Anish Mangal
mailto:anis...@umich.edu>> wrote:

I tried your grc and got the same result.

See the waveform's envelope in this oscilloscope
capture. Note the timebase.

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

<https://drive.google.com/file/d/1b7PnpmvFfdQTDIwALuOzb22AzeffzR2w/view?usp=sharing>

This isn't happening in SDRAngel.

On Thu, Mar 18, 2021 at 3:49 AM Cinaed Simson
mailto:cinaed.sim...@gmail.com>> wrote:

I moved the rational resampler block from the output
side to the input side of the WBFM.

The output of WBFM block needs to match the input of
your LimeSDR.

I don't have the LimeSDR software installed so I
couldn't look inside the sink block.

-- Cinaed

P.S - yes, you can post GRC's on the mailing list  -
they're text based.


On 3/17/21 4:14 AM, Anish Mangal wrote:

I linked

<https://drive.google.com/file/d/1xQz1Kp_feAO1YrZRXXnMF25XEGgqVPSw/view?usp=sharing>
the grc file in the original email. Attaching it
here a

Re: LimeSDR | Sinewave test | Glitchy behavior

[Cinaed Simson]

Hi Anish - I think I may have found the problem.

When the complex rational resampler is on the out put of the WBFM, it 
bothered me  later that I couldn't see the top of the signal.


The scale on QT GUI SINK was clipping the signal but not the 
computational noise.


In the QT GUI SINK, if I set the Y-min to be -99 and Y-max to be 0, the 
signal looks perfect.


And if the receiving RTL dongle has noise while listening, it may be a 
DC offset problem.


-- Cinaed


On 3/18/21 6:58 AM, Anish Mangal wrote:
Here are two debug logs from LimeSuite GUI. In one, I load the 
settings that gnuradio does to the limesdr and see the debug log. The 
other is the settings file which the sdrangel writes.


If I diff them, among other differences, this is what I see in the end 
of the sdrangel-debug-log

DEBUG: Selected: VCOL
DEBUG: csw 169; interval [166, 172]
DEBUG: M=195, N=3, Fvco=1300.000 MHz

And this is what I see in the gnuradio-debug-log
DEBUG: Selected: VCOM
DEBUG: csw 174; interval [171, 177]

Now, I'm *very* new to this.. but could it mean that different VCOs 
are used in both cases, and in the case of gnuradio, it maybe has some 
issues to stabilize to some freq?


On Thu, Mar 18, 2021 at 7:12 PM Christophe Seguinot 
mailto:christophe.segui...@orange.fr>> 
wrote:


Hi all

There is something wrong in this simulation.

Attached is a flowgraph with a selectable Lime SDR Source, and a
RTL-SDR dongle as receiver. I tested this with a Lime SDR Mini.

  * I was suspecting a Lime SDR issue, however this is not so clear.
  * As Anish I also tested a const source.
  * The flowgraph is running fluently and I dont' see any error
message about transmission to Lime SDR

Conclusion of my simulations :

  * with a const source (=1) at Lime input : everything is OK, the
received signal is frequency shifted (normal) and the SNR is
correct if LimeSDR Gain is sufficient
  * Using ratioanal resampler followed by WBFM Transmit Same
reslt, everything is OK
  * First source+ WBFM + Rational resampler (this is a sample file
found on LimeSDR website
  o the spectrum is not correct (look like  a modulated signal
  o the received signal magnitude is not constant
  o *BUT the send signal on the Time Sink look like correct. (
I.E =1+j0 as for others sources, whitout any glicht)
*

How can we further investigate this?


On 18/03/2021 13:13, Anish Mangal wrote:

And, if I try the attach gnuradio file, which is just a constant
source of value '1' going to the limesdr sink block, I actually
see a sine-ish wave without the glitchy behavior.

On Thu, Mar 18, 2021 at 5:31 PM Anish Mangal mailto:anis...@umich.edu>> wrote:

I tried your grc and got the same result.

See the waveform's envelope in this oscilloscope capture.
Note the timebase.

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

<https://drive.google.com/file/d/1b7PnpmvFfdQTDIwALuOzb22AzeffzR2w/view?usp=sharing>

This isn't happening in SDRAngel.

On Thu, Mar 18, 2021 at 3:49 AM Cinaed Simson
mailto:cinaed.sim...@gmail.com>> wrote:

I moved the rational resampler block from the output side
to the input side of the WBFM.

The output of WBFM block needs to match the input of your
LimeSDR.

I don't have the LimeSDR software installed so I couldn't
look inside the sink block.

-- Cinaed

P.S - yes, you can post GRC's on the mailing list  -
they're text based.


On 3/17/21 4:14 AM, Anish Mangal wrote:

I linked

<https://drive.google.com/file/d/1xQz1Kp_feAO1YrZRXXnMF25XEGgqVPSw/view?usp=sharing>
the grc file in the original email. Attaching it here as
well. (Don't know if the mailing list allows attachments)



On Wed, Mar 17, 2021 at 1:40 PM Cinaed Simson
mailto:cinaed.sim...@gmail.com>> wrote:


Hi Anish - since this is a gnuradio mailing list,
the starting point would be to post your GRC - which
is an yaml or text file.

-- Cinaed

On 3/16/21 11:19 PM, Anish Mangal wrote:

Hi! Any pointers to where I can start debugging this?

Maybe run gnuradio-companion in debug mode?
Do more simpler tests?
Any other suggestions?

I have a HackRF One and will try the exact same
comparison there too ... SDRAngel & grc

On Mon, Mar 15, 2021 at 7:32 PM Anish Mangal
mailto:anis...@umich.edu>> wrote:

Hi,

To properly explain the issue I'm facing, I
r

Re: LimeSDR | Sinewave test | Glitchy behavior

[Cinaed Simson]

I moved the rational resampler block from the output side to the input 
side of the WBFM.


The output of WBFM block needs to match the input of your LimeSDR.

I don't have the LimeSDR software installed so I couldn't look inside 
the sink block.


-- Cinaed

P.S - yes, you can post GRC's on the mailing list  - they're text based.


On 3/17/21 4:14 AM, Anish Mangal wrote:
I linked 
<https://drive.google.com/file/d/1xQz1Kp_feAO1YrZRXXnMF25XEGgqVPSw/view?usp=sharing> 
the grc file in the original email. Attaching it here as well. (Don't 
know if the mailing list allows attachments)




On Wed, Mar 17, 2021 at 1:40 PM Cinaed Simson <mailto:cinaed.sim...@gmail.com>> wrote:



Hi Anish - since this is a gnuradio mailing list, the starting
point would be to post your GRC - which is an yaml or text file.

-- Cinaed

On 3/16/21 11:19 PM, Anish Mangal wrote:

Hi! Any pointers to where I can start debugging this?

Maybe run gnuradio-companion in debug mode?
Do more simpler tests?
Any other suggestions?

I have a HackRF One and will try the exact same comparison there
too ... SDRAngel & grc

On Mon, Mar 15, 2021 at 7:32 PM Anish Mangal mailto:anis...@umich.edu>> wrote:

Hi,

To properly explain the issue I'm facing, I recorded a video
showing Oscilloscope waveforms.


https://drive.google.com/file/d/11anGShu-I3NhL9Jet6YAiyBprvwP4kDc/view?usp=sharing

<https://drive.google.com/file/d/11anGShu-I3NhL9Jet6YAiyBprvwP4kDc/view?usp=sharing>

The gnuradio flowgraph is here:

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

<https://drive.google.com/file/d/1xQz1Kp_feAO1YrZRXXnMF25XEGgqVPSw/view?usp=sharing>

The various versions of the software/hardware involved are
the following.

gnuradio-companion: 3.8.2.0 (Python 3.6.9)
gr-limesdr: branch gr-3.8 (last commit
47511dd58de1695b70e1028366411bada85eb60f)
sdrangel: 4.12.1
OS: Linux Mint 19.1
CPU: Intel© Core™ i7-4900MQ CPU @ 2.80GHz × 4
RAM: 16GB
H/w: Thinkpad T440p

tl;dr
I'm trying a simple test to create a sinewave output from a
WFM modulator block. If there is no audio input, its WFM
modulated signal should be a simple sinewave. If I test this
with SDRAngel, I see a clean-ish actual sinewave in time
domain on the oscilloscope. But if I try to do the same with
gnuradio, it seems to produce a glitchy signal.

Could I have any advice on what I might be doing wrong?

Thanks,
Anish // VU2TVE





options:
  parameters:
author: Lime Microsystems
category: '[GRC Hier Blocks]'
cmake_opt: ''
comment: ''
copyright: ''
description: ''
gen_cmake: 'On'
gen_linking: dynamic
generate_options: qt_gui
hier_block_src_path: '.:'
id: fm_transmitter
max_nouts: '0'
output_language: python
placement: (0,0)
qt_qss_theme: ''
realtime_scheduling: ''
run: 'True'
run_command: '{python} -u {filename}'
run_options: prompt
sizing_mode: fixed
thread_safe_setters: ''
title: FM transmitter
window_size: ''
  states:
bus_sink: false
bus_source: false
bus_structure: null
coordinate: [8, 8]
rotation: 0
state: enabled

blocks:
- name: audio_rate
  id: variable
  parameters:
comment: ''
value: int(48e3)
  states:
bus_sink: false
bus_source: false
bus_structure: null
coordinate: [208, 108.0]
rotation: 0
state: enabled
- name: baseband
  id: variable_qtgui_entry
  parameters:
comment: ''
gui_hint: 0,0,1,2
label: TX Baseband [MHz]
type: real
value: '97'
  states:
bus_sink: false
bus_source: false
bus_structure: null
coordinate: [180, 8]
rotation: 0
state: true
- name: gain
  id: variable_qtgui_range
  parameters:
comment: ''
gui_hint: 1,0,1,1
label: Gain [dB]
min_len: '70'
orient: Qt.Horizontal
rangeType: int
start: '0'
step: '1'
stop: '60'
value: '30'
widget: counter_slider
  states:
bus_sink: false
bus_source: false
bus_structure: null
coordinate: [336, 9]
rotation: 0
state: true
- name: pa_path
  id: variable_qtgui_chooser
  parameters:
comment: ''
gui_hint: 1,1,1,1
label: PA Path
label0: Auto
label1: Band1
label2: Band2
label3: W
label4: ''
labels: '[]'
num_opts: '3'
option0: '0'
option1: '1'
option2: '2'
option3: '3'
option4: '4'
options: '[0, 1, 2]'
orient: Qt.QVBoxLayout
type: int
value: '255'
widget: combo_box
  states:
bus_sink: false
bus_source: false
bus_structure: null
coordinate: [462, 8]
rotation: 0
state: disabled
- name: quad_rate
  id: variable
  parameters:
comment: ''
value: int(10*audi

Re: Generator error flow graph

[Cinaed Simson]

That file will generate any error unless you have the input file 
"dummy.dat".


Try

   grep dummy.dat ./fm_rx.grc

which will return

   file: dummy.dat

or just open the file with GRC and replace file source with your front 
end hardware.


But you can run

  gnuradio/share/gnuradio/examples/analog/fmtest.py

without using the GRC.

-- CInaed

P.S. - please keep the discussion on the mailing list. Thank you.

On 3/17/21 4:37 AM, COURANT Frederique - Contractor wrote:


Hi Cinaed,

Sorry but I can’t attach my flow grap.

But for example, I have this error with fm_rx.grc available in 
gnuradio/gr-analog/examples.


Thanks for your help.

Fred

*De :*Discuss-gnuradio 
*De 
la part de* Cinaed Simson

*Envoyé :* mercredi 17 mars 2021 09:18
*À :* discuss-gnuradio@gnu.org
*Objet :* Re: Generator error flow graph

HI Fred - how about at least 1 example GRC which demonstrates the 
problem?


The  GRC file is a text file which you can attach to email.

-- Cinaed

On 3/17/21 12:12 AM, COURANT Frederique - Contractor wrote:

Hello all,

I would like to known if someone has ever had this error when you
want to generate python code with gnuradio :

Generate Error: ‘catch_execptions’

>>>Failure

Traceback (most recent call last):

File
“/usr/local/lib/python3/dist-packages/gnuradio/grc/gui/Application.py”,
line 710, in _/handle/_action

generator.write()

File

“/usr/local/lib/python3/dist-packages/gnuradio/grc/core/generator/top_block.py”,
line 83, in write

for filename, data in self._build_python_code_from_template():

File

“/usr/local/lib/python3/dist-packages/gnuradio/grc/core/generator/top_block.py”
line 123, in _/build/_python_code_from_template

‘catch_excetions’:fg.get_option(‘catch_exceptions’)

File
“/usr/local/lib/python3/dist-packages/gnuradio/grc/core/FlowGraph.py”,
line 181, in get_option

Return self.options_block.params[key].get_evaluated()

KeyError: ‘catch_exceptions’

The problem is present with my personal flow graph and examples
available with gnuradio.

I’m using UHD 4.0 and gnuradio 3.8.

Thanks for your help.

Best regards.

Fred

Re: Generator error flow graph

[Cinaed Simson]

HI Fred - how about at least 1 example GRC which demonstrates the problem?

The  GRC file is a text file which you can attach to email.

-- Cinaed

On 3/17/21 12:12 AM, COURANT Frederique - Contractor wrote:


Hello all,

I would like to known if someone has ever had this error when you want 
to generate python code with gnuradio :


Generate Error: ‘catch_execptions’

>>>Failure

Traceback (most recent call last):

File 
“/usr/local/lib/python3/dist-packages/gnuradio/grc/gui/Application.py”, 
line 710, in _/handle/_action


generator.write()

File 
“/usr/local/lib/python3/dist-packages/gnuradio/grc/core/generator/top_block.py”, 
line 83, in write


for filename, data in self._build_python_code_from_template():

File 
“/usr/local/lib/python3/dist-packages/gnuradio/grc/core/generator/top_block.py” 
line 123, in _/build/_python_code_from_template


‘catch_excetions’:fg.get_option(‘catch_exceptions’)

File 
“/usr/local/lib/python3/dist-packages/gnuradio/grc/core/FlowGraph.py”, 
line 181, in get_option


Return self.options_block.params[key].get_evaluated()

KeyError: ‘catch_exceptions’

The problem is present with my personal flow graph and examples 
available with gnuradio.


I’m using UHD 4.0 and gnuradio 3.8.

Thanks for your help.

Best regards.

Fred

Re: LimeSDR | Sinewave test | Glitchy behavior

[Cinaed Simson]

Hi Anish - since this is a gnuradio mailing list, the starting point 
would be to post your GRC - which is an yaml or text file.


-- Cinaed

On 3/16/21 11:19 PM, Anish Mangal wrote:

Hi! Any pointers to where I can start debugging this?

Maybe run gnuradio-companion in debug mode?
Do more simpler tests?
Any other suggestions?

I have a HackRF One and will try the exact same comparison there too 
... SDRAngel & grc


On Mon, Mar 15, 2021 at 7:32 PM Anish Mangal > wrote:


Hi,

To properly explain the issue I'm facing, I recorded a video
showing Oscilloscope waveforms.


https://drive.google.com/file/d/11anGShu-I3NhL9Jet6YAiyBprvwP4kDc/view?usp=sharing



The gnuradio flowgraph is here:

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



The various versions of the software/hardware involved are the
following.

gnuradio-companion: 3.8.2.0 (Python 3.6.9)
gr-limesdr: branch gr-3.8 (last commit
47511dd58de1695b70e1028366411bada85eb60f)
sdrangel: 4.12.1
OS: Linux Mint 19.1
CPU: Intel© Core™ i7-4900MQ CPU @ 2.80GHz × 4
RAM: 16GB
H/w: Thinkpad T440p

tl;dr
I'm trying a simple test to create a sinewave output from a WFM
modulator block. If there is no audio input, its WFM modulated
signal should be a simple sinewave. If I test this with SDRAngel,
I see a clean-ish actual sinewave in time domain on the
oscilloscope. But if I try to do the same with gnuradio, it seems
to produce a glitchy signal.

Could I have any advice on what I might be doing wrong?

Thanks,
Anish // VU2TVE

Re: Socket PDU TCP connection closed automatically

[Cinaed Simson]

Hi Jay - the error message 'boost::system::system_error' is simply 
restating what all the other error messages are stating - you can't 
connect to any of the listed clients - or they can't connect to your 
server.


It could be a problem with the firewall on your machine.

You should consult the unetpy mailing list on how to fix it.

-- Cinaed


On 3/10/21 8:50 PM, Jay Patel wrote:

Hi all,

I was testing our modem's python API,trying to establish the TCP 
connection using Socket PDU in GR 3.8.


 It looks like it established the connection correctly but somehow 
automatically closes it. And throw this error.


terminate called after throwing an instance of 
'boost::system::system_error'


Does this mean my GR build is broken or it is pointing me to broken 
boost libraries ?  I had also attached my logs.


Any pointers would be appreciated.

*/Regards,/*
/Jay Patel/

Re: ZMQ Message Debug

[Cinaed Simson]

Hi Jay - enclosed is the second part of your flow chart - it was easy to 
cut it out and paste in a separate flowgraph.


I fed the flowgraph with a wave file instead of using the output from 
the first part.


The message debug works.

The only block with is blabbering is the Squelch. If you switch it 
between the "pass through"  and "enable" positions, you'll see the PDU 
debug messages in the time frequency plot.


The problem may be in the first part of the flow graph.

Otherwise, I have no idea what you're doing or why you're doing it.

-- Cinaed


On 3/7/21 12:06 PM, Jay Patel wrote:

Hi all,

I am sending messages from an external application via (ZMQ PUSH) and 
received those messages in the GNURadio via ZMQ Pull message source.


From the ZMQ PULL side, I had correctly debugged the message coming 
from external applications.


I want to basically transmit those messages. But in the receiver side 
after the Tagged stream to PDU ->  message debug block don't print 
anything. I put a QT Freq sink to check if the data is coming properly 
or not.


Did I miss something? How can I properly debug the messages. I had 
attached my flow graph.


Any suggestions are welcome.

*/With Regards,/*
/Jay Patel/



options:
  parameters:
author: ''
category: '[GRC Hier Blocks]'
cmake_opt: ''
comment: ''
copyright: ''
description: ''
gen_cmake: 'On'
gen_linking: dynamic
generate_options: qt_gui
hier_block_src_path: '.:'
id: msg_debug_test
max_nouts: '0'
output_language: python
placement: (0,0)
qt_qss_theme: ''
realtime_scheduling: ''
run: 'True'
run_command: '{python} -u {filename}'
run_options: prompt
sizing_mode: fixed
thread_safe_setters: ''
title: msg_debug_test
window_size: (1000,1000)
  states:
bus_sink: false
bus_source: false
bus_structure: null
coordinate: [8, 8]
rotation: 0
state: enabled

blocks:
- name: EBW
  id: variable
  parameters:
comment: ''
value: '.05'
  states:
bus_sink: false
bus_source: false
bus_structure: null
coordinate: [680, 12.0]
rotation: 0
state: enabled
- name: RRC_filter_taps
  id: variable_rrc_filter_taps
  parameters:
alpha: EBW
comment: ''
gain: nfilts
ntaps: int(5*SPS*nfilts/RX_Decimation)
samp_rate: nfilts
sym_rate: '1.0'
  states:
bus_sink: false
bus_source: false
bus_structure: null
coordinate: [8, 92.0]
rotation: 0
state: enabled
- name: RX_Decimation
  id: variable
  parameters:
comment: ''
value: '49'
  states:
bus_sink: false
bus_source: false
bus_structure: null
coordinate: [560, 12.0]
rotation: 0
state: enabled
- name: SPS
  id: variable
  parameters:
comment: ''
value: '147'
  states:
bus_sink: false
bus_source: false
bus_structure: null
coordinate: [480, 12.0]
rotation: 0
state: enabled
- name: carrier_freq
  id: variable
  parameters:
comment: ''
value: 1.73E3
  states:
bus_sink: false
bus_source: false
bus_structure: null
coordinate: [280, 12.0]
rotation: 0
state: enabled
- name: fsk_deviation_hz
  id: variable
  parameters:
comment: ''
value: '100'
  states:
bus_sink: false
bus_source: false
bus_structure: null
coordinate: [768, 12.0]
rotation: 0
state: enabled
- name: nfilts
  id: variable
  parameters:
comment: ''
value: '32'
  states:
bus_sink: false
bus_source: false
bus_structure: null
coordinate: [152, 100.0]
rotation: 0
state: enabled
- name: samp_rate
  id: variable
  parameters:
comment: ''
value: '44100'
  states:
bus_sink: false
bus_source: false
bus_structure: null
coordinate: [184, 12]
rotation: 0
state: enabled
- name: analog_feedforward_agc_cc_0
  id: analog_feedforward_agc_cc
  parameters:
affinity: ''
alias: ''
comment: ''
maxoutbuf: '0'
minoutbuf: '0'
num_samples: '1024'
reference: '1.0'
  states:
bus_sink: false
bus_source: false
bus_structure: null
coordinate: [1184, 260.0]
rotation: 0
state: enabled
- name: analog_pwr_squelch_xx_1
  id: analog_pwr_squelch_xx
  parameters:
affinity: ''
alias: ''
alpha: '.01'
comment: ''
gate: 'True'
maxoutbuf: '0'
minoutbuf: '0'
ramp: '0'
threshold: '-60'
type: complex
  states:
bus_sink: false
bus_source: false
bus_structure: null
coordinate: [1000, 244.0]
rotation: 0
state: enabled
- name: analog_quadrature_demod_cf_0
  id: analog_quadrature_demod_cf
  parameters:
affinity: ''
alias: ''
comment: ''
gain: samp_rate/(2*math.pi*fsk_deviation_hz/8.0)/RX_Decimation
maxoutbuf: '0'
minoutbuf: '0'
  states:
bus_sink: false
bus_source: false
bus_structure: null
coordinate: [1288, 412.0]
rotation: 180
state: enabled
- name: analog_sig_source_x_0_0
  id: analog_sig_source_x
  

gr-satellites

[Cinaed Simson]

Hi - all the tests were all failing for make test in gr-satellite - and 
test.sh.


There was no module 'construct' installed.

I downloaded it and installed in /usr/local and  then all the tests 
passed - including the test.sh script.


Also, there was no contact email address in the "satellite_teams.md" 
file - just a name.


-- Cinaed

Re: PlutoSDR : Audio Sink not properly demodulating or miss-configured

[Cinaed Simson]

Hi Jay - then show us a simplified GRC file which demonstrates the 
problem as you outlined using the green and red boxes.


There are pluto sources or sinks in the GRC file you sent.

-- Cinaed

On 2/13/21 10:23 AM, Jay Patel wrote:

Hi all,

I had a non-GRC application (zmqPUSH.py) sending messages to GNURadio 
for Transmission. I had successfully got that msg inside gnuradio 
using ZMQ PUll message source and I debug that with message debug 
print and it printed perfectly ok.  I am testing a loopback where that 
message is transmitted using an audio sink and received and decoded 
using an audio source. I can see in QT time & Frequency sink that it 
is receiving the messages.


GNURadioError.png

But for some reason it is not properly decode the message using 
message debug. It looks like my Audio source is playing aUaUaUaU (I 
know this may be related issue to my my audio sink/source 
configuration), I googled and tried bunch of things suggested here : 
https://github.com/rxseger/linuxproblems/issues/4 
 but that didn't 
work either. Normally I test my audio source and sink with a 
simple sin source and that works fine without anything in the "device 
name".


Is there anything I am missing here ? Do I have to configure 
something specifically ? My end goal is replacing the audio sink and 
source with PlutoSDR for real time transmitting.


I know I should update my gnuradio version to a newer version but 
unfortunately, I don't have those leverages as I have other co-systems 
such as ROS Kinetic and external simulator which only runs properly 
with 16.04.


I had attached my files for your reference. Any help would be greatly 
appreciated.


*/With Regards,/*
/Jay Patel/

Re: cmake doesn't like xrdp

[Cinaed Simson]

And not to beat a dead horse - but I forgot to mention if you're using a 
Windows laptop to connect, then you most likely will need to install a 
X11 server on the Windows laptop - regardless of whether or not you 
login remotely to a Linux or a Windows machine.


-- Cinaed


And needless to say, if the Windows machine is sending your laptop X11 
protocol, then you're dead in the water.


On 1/29/21 2:32 PM, Cinaed Simson wrote:
It's not that xrpd doesn't like cmake, it's that the unknown device 
running the unknown OS doesn't like you :).


In other words, it's most likely an X authorization problem.

On the unknown device running the unknown OS, try typing

   xhost +

after you connect and see that corrects the problems.

You can test X by typing

  xclock

- assuming it's installed on the unknown device running the unknown OS.

And It could also be a problem with DISPLAY environment variable - but 
that could be a separate can of worms.


The problem with cmake is probably because after cmake gathers the 
necessary initial information, it then tries to start


  cmake-qt-gui

-  which requires X.

Without X there can be no graphics.

Or it could be worse - there is no X - but since it appears it's 
trying to start cmake-qt-gui - it probably has X.


If you log into the VM at the console, then you're owner of X so 
there's no problem.


-- Cinaed



On 1/29/21 10:10 AM, Gavin Jacobs wrote:
For two weeks I have been trying to build a new module/block on 3.9 
without much success. You can see some of the pain here:
https://lists.gnu.org/archive/html/discuss-gnuradio/2021-01/msg00073.html 
<https://lists.gnu.org/archive/html/discuss-gnuradio/2021-01/msg00073.html>


I finally discovered the cause of the problem and a workaround.
If you are running a remote session via xrdp, then the cmake step of 
gr_modtool, or building 3.9 from source, or just about any cmake 
involving gnuradio-runtime, will NOT work. You get error messages 
about a non-existent "/include" directory.


I discovered this by accident. I was getting frustrated with trying 
different things, so I created a virtual machine (using VMware 
Player), and kept a copy of the virtual machine with just the OS 
installed, updated, and configured the way I like it. Then I could 
try different things and go back to the base if it didn't work out. 
Yesterday I found that I could build the 3.9 maint branch from source 
on the vm, without the cmake errors. I also used gr_modtool to make a 
trivial block, and that worked too. Encouraged by this result, I went 
back to the laptop via xrdp and tried it there, and got the same old 
errors. In desperation, I tried the procedure on the laptop directly 
(which is a nuisance because it is in the basement, in a cold room, 
and not readily accessible), and it worked! Still haven't figured out 
what the difference is. So now, I have a development environment in a 
vm. I'm hoping I can do the code/test/edit/rebuild cycle on the 
target machine using xrdp, but we'll see what happens.


Also, here are a few other things that I learned:
"gr_modtool add" will complain about clang-format, so install that 
along with the prerequisites
"gr_modtool makeyaml" is not worth the trouble, it's easier to edit 
the file that was created by "gr_modtool add"
the in-tree blocks on github are not great examples for beginners, 
the example on the wiki is better


Hope that helps someone.

Re: cmake doesn't like xrdp

[Cinaed Simson]

It's not that xrpd doesn't like cmake, it's that the unknown device 
running the unknown OS doesn't like you :).


In other words, it's most likely an X authorization problem.

On the unknown device running the unknown OS, try typing

   xhost +

after you connect and see that corrects the problems.

You can test X by typing

  xclock

- assuming it's installed on the unknown device running the unknown OS.

And It could also be a problem with DISPLAY environment variable - but 
that could be a separate can of worms.


The problem with cmake is probably because after cmake gathers the 
necessary initial information, it then tries to start


  cmake-qt-gui

-  which requires X.

Without X there can be no graphics.

Or it could be worse - there is no X - but since it appears it's trying 
to start cmake-qt-gui - it probably has X.


If you log into the VM at the console, then you're owner of X so there's 
no problem.


-- Cinaed



On 1/29/21 10:10 AM, Gavin Jacobs wrote:
For two weeks I have been trying to build a new module/block on 3.9 
without much success. You can see some of the pain here:
https://lists.gnu.org/archive/html/discuss-gnuradio/2021-01/msg00073.html 



I finally discovered the cause of the problem and a workaround.
If you are running a remote session via xrdp, then the cmake step of 
gr_modtool, or building 3.9 from source, or just about any cmake 
involving gnuradio-runtime, will NOT work. You get error messages 
about a non-existent "/include" directory.


I discovered this by accident. I was getting frustrated with trying 
different things, so I created a virtual machine (using VMware 
Player), and kept a copy of the virtual machine with just the OS 
installed, updated, and configured the way I like it. Then I could try 
different things and go back to the base if it didn't work out. 
Yesterday I found that I could build the 3.9 maint branch from source 
on the vm, without the cmake errors. I also used gr_modtool to make a 
trivial block, and that worked too. Encouraged by this result, I went 
back to the laptop via xrdp and tried it there, and got the same old 
errors. In desperation, I tried the procedure on the laptop directly 
(which is a nuisance because it is in the basement, in a cold room, 
and not readily accessible), and it worked! Still haven't figured out 
what the difference is. So now, I have a development environment in a 
vm. I'm hoping I can do the code/test/edit/rebuild cycle on the target 
machine using xrdp, but we'll see what happens.


Also, here are a few other things that I learned:
"gr_modtool add" will complain about clang-format, so install that 
along with the prerequisites
"gr_modtool makeyaml" is not worth the trouble, it's easier to edit 
the file that was created by "gr_modtool add"
the in-tree blocks on github are not great examples for beginners, the 
example on the wiki is better


Hope that helps someone.

Re: Problem with OOT Interpolator Python module

[Cinaed Simson]

Hi Edward - okay, I sent the wrong copy anyway - the one I sent wasn't 
finished.When I change the inputs to 5 complex numbers I get 9 complex 
values.


And that's good because it appeared you weren't doing anything.

See the loop

  for k in range(0,2)

which is loop over only 3 values - may be you're clipping your output?

I don't anything about the OOT module or C++.

Sorry - I can't help you.

-- Cinaed
S


On 1/23/21 5:37 PM, George Edwards wrote:

Hi Cinaed,

Thanks again for your suggestion.

I can tell it will not work because I am not writing plain stand alone 
Python. My code is written within Gnuradio constructs in an OOT 
module. The QA test shows the module is reading in the input complex 
samples (5 complex samples) and responding with the correct amount of 
output samples (10 complex samples). However, it was working properly 
all 10 output samples would be 1+j1. Instead only the first two and 
last two samples are correct and the middle value 6 values are j0 
(which are wrong). So the question is: "how do I fix my code to output 
10 samples of 1+j1". Based on how I have written the code, I am under 
the belief that I am writing 1+j1 to the output buffer 10 times, but 
my output is not 1+j1 10 times, so something is wrong. So I am looking 
for help on how to modify the code to fulfill the proper operation of 
Gnuradio OOT Interpolator module.


Thanks again for the help.

George



On Sat, Jan 23, 2021 at 7:00 PM George Edwards <mailto:gedwards@gmail.com>> wrote:


Thanks Cinaed!

I will test how it works.

George

On Sat, Jan 23, 2021 at 2:58 PM Cinaed Simson
mailto:cinaed.sim...@gmail.com>> wrote:

Hi George - I'm presuming the enclosed example.py script is
what you're trying calculate - and that the input data is
complex.

I invented my own data.

If true, it should be easy to adapt it to your problem by
combining the 2 loops for any value of n.

-- Cinaed


On 1/22/21 10:49 AM, George Edwards wrote:

Hello,
I am working with the OOT Interpolator template and I set the
interpolation factor to 2. In the QA file I input 5-complex
samples  and based on my simple code below in the work()
method, I expect the QA test to return 1+j1, 10-times (5x2).
The QA returns ((1+1j), (1+1j), 0j,  0j,  0j,  0j,  0j, 0j, 
(1+1j) ,  (1+1j)). I have tried a lot of different coding
permutations and this is the closest I come to a
solution, but it is wrong!!! Any help is greatly appreciated!

defwork(self, input_items, output_items):

in0 = input_items[0]

out = output_items[0]

for ii inrange(0,len(in0)):

for k inrange(0,2):

out[k] = 1.0+1.0*1j

returnlen(output_items[0])

Thanks,
George

Re: Problem with OOT Interpolator Python module

[Cinaed Simson]

Hi George - I'm presuming the enclosed example.py script is what you're 
trying calculate - and that the input data is complex.


I invented my own data.

If true, it should be easy to adapt it to your problem by combining the 
2 loops for any value of n.


-- Cinaed


On 1/22/21 10:49 AM, George Edwards wrote:

Hello,
I am working with the OOT Interpolator template and I set the 
interpolation factor to 2. In the QA file I input 5-complex samples  
and based on my simple code below in the work() method, I expect the 
QA test to return 1+j1, 10-times (5x2). The QA returns ((1+1j), 
(1+1j), 0j, 0j,  0j,  0j, 0j, 0j,  (1+1j) , (1+1j)). I have tried a 
lot of different coding permutations and this is the closest I come to 
a solution, but it is wrong!!!  Any help is greatly appreciated!


defwork(self, input_items, output_items):

in0 = input_items[0]

out = output_items[0]

for ii inrange(0,len(in0)):

for k inrange(0,2):

out[k] = 1.0+1.0*1j

returnlen(output_items[0])

Thanks,
George



#!/bin/env python3
import cmath
n=4
m=2*n-1
print ("(n,m)=",[n,m])
u=[complex(0, 0) for k in range(n) ]
u[0]=complex(-1,2)
u[1]=complex(3,-3)
u[2]=complex(-4,4)
u[3]=complex(5,-6)
v=[complex(0, 0) for k in range(m) ]
v[0]=u[0]
v[1]=(u[0]+u[1])/2
v[2]=u[1]
v[3]=(u[1]+u[2])/2
v[4]=u[2]
v[5]=(u[2]+u[3])/2
v[6]=u[3]
print ("u=",u)
print ("v=",v)