gnuradio 3.10: "kill the flow graph" not working

[ra1nb0w]

Hi, I am doing a few tests with your great OOT on gnuradio 3.10 and I noticed that if:

• I close the flow graph window the plugin doesn't close/return correctly and only "kill the flow graph" button is enabled
• I try to close the flow graph with "kill the flow graph" doesn't close/kill the graph.

In attachment the grc that I use. I moved from 3.8 to 3.10 therefore I don't know if this problem is present on 3.9.

thank you hpsdr-test.grc.zip

[Tom-McDermott]

The code has not yet been ported to version 3.10. The latest version available for the OOT is 3.9

[ra1nb0w]

I know but the API is essentially the same and should work out of the box this is why I am asking. In fact, many researchers are jumping from 3.8 to 3.10 (ettus, debian, accademia, ecc) and this is the reason of my tests. Have you already encountered the issue with 3.9?

[Tom-McDermott]

I've used the 3.9 OOT extensively, but re-tested it this morning on Ubuntu 20.04. The 3.9 version of the OOT module works correctly and shuts down correctly in gnuradio 3.9.1.0. So it appears there are some differences between 3.9 and 3.10.

We will need to await porting to 3.10. 3.10.0 apparently had a few major issues, 3.10.1 is current. I usually wait a bit before porting as the initial release of each version has had breaking porting issues for me. The structure of the OOT modules changes quite a bit between 3.9 and 3.10.

-- Tom, N5EG

[ra1nb0w]

Yes, they changed include and python structures and it is reflected by gr_modtool info with API version: post-3.10. If you use the 3.9 you get post-3.8.

Ok. I wait. Do you want to leave this issue open?

[Tom-McDermott]

I have been working on the port. There have been some issues worked through far: pygccxml version - not compatible. Need to install a version later than what's standard in the package manager. (Thanks: Ryan Volz @ MIT for finding this). spdlog - missing dependency. pybind11 - I think there is a version problem here. The package manger reverted the version used in 3.9. I've manually installed the version that worked in 3.9 from the tarball, but that does not work in 3.10.1.1 (gr::block is undefined). In general I'm not sure how to tell which pybind11 version a binary was built against. Asked for help on the list.

This is being ported to 3.10 so that it can be instrumented since the stop() problem is not reproducible in 3.9. It is necessary to be able to modify / build debug version / reinstall in 3.10. The module allocates a substantial amount of buffer memory on the heap that is freed upon stop(). Gnuradio changed how this works between 3.6, 3.7, and later versions.

-- Tom

[ra1nb0w]

At macports we use pybind11 2.9.2 and seems to work fine.

[Tom-McDermott]

Ripped out and reinstalled gnuradio 3.10 and dependencies.

Installed pybind11-dev 2.9.2 from the tarball. This installed and build correctly.

Does not fix the problem - still have unknown base type gr::block

[ra1nb0w]

maybe you have another pybind11 already installed? I found this for gnuradio 3.9

[Tom-McDermott]

I've tried pybind11-dev versions 2.5.0 2.6.2 and 2.9.2.

I wasn't sure the make/install from tarball was working correctly, so I added the impish release to 20.04, updated apt, and apt install that one package. Then remove impish and apt update to prevent anything else from updating.

This shows 2.6.2 as the installed version of pybind11-dev with 2.4.3 as a candidate.

Still has the exact same problem.

-- Tom

[ra1nb0w]

probably multiple version installed. Why you don't use the ppa ?

[Tom-McDermott]

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.

Thus it seems this is pretty well stuck at this point.

-- Tom, N5EG

On Fri, May 13, 2022 at 10:43 PM ra1nb0w @.***> wrote:

probably multiple version installed. Why you don't use the ppa https://wiki.gnuradio.org/index.php/UbuntuInstall ?

— Reply to this email directly, view it on GitHub https://github.com/Tom-McDermott/gr-hpsdr/issues/19#issuecomment-1126647053, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABZR5HCTMY7PZNLW2O27EYLVJ44Q7ANCNFSM5OHCCQPA . You are receiving this because you commented.Message ID: @.***>

[ra1nb0w]

But have you uninstalled the ubuntu pybind11 and pybind11-dev packages?

[Tom-McDermott]

uninstalling pybind11-dev using the package manager also uninstalls gnuradio-dev. That's why everything blew up yesterday.

Re-installing gnuradio also re-installs pybind11-dev 2.4.3 if none is there.

So using APT to install the Impish package avoids this and updates onlypybind11-dev in place (as any otherwise normal update would do).

-- Tom, N5EG

On Sat, May 14, 2022 at 8:33 AM ra1nb0w @.***> wrote:

But have you uninstalled the ubuntu pybind11 and pybind11-dev packages?

— Reply to this email directly, view it on GitHub https://github.com/Tom-McDermott/gr-hpsdr/issues/19#issuecomment-1126737975, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABZR5HBMJR3QU5HUDZVEZ5DVJ7BWFANCNFSM5OHCCQPA . You are receiving this because you commented.Message ID: @.***>

[ra1nb0w]

You can have only one pybind11 library in the system otherwise you need to specify accordingly the cmake build system (and can mess up anyway). My suggestion is to remove the system gnuradio and use the pre-build ppa without build anything.

[Tom-McDermott]

The gnuradio is from the pre-built PPA. It was not built separately.

-- Tom

On Sat, May 14, 2022 at 11:01 AM ra1nb0w @.***> wrote:

You can have only one pybind11 library in the system otherwise you need to specify accordingly the cmake build system (and can mess up anyway). Remove the system gnuradio and use the pre-build ppa without build anything.

— Reply to this email directly, view it on GitHub https://github.com/Tom-McDermott/gr-hpsdr/issues/19#issuecomment-1126785949, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABZR5HCPXLGJVBGO46W7SHTVJ7TAJANCNFSM5OHCCQPA . You are receiving this because you commented.Message ID: @.***>

[ra1nb0w]

So, you should have already gnuradio 3.10. Why build from source?

[Tom-McDermott]

I did not build gnuradio from source. It was only installed via the ppa. The only thing I am trying to build is my OOT.

The package manager refers to all the libraries installed by the PPA that are needed to build an OOT as gnuradio-dev. It's a strange way to name things in my opinion, but that's how it was named.

At this point Ubuntu 20.04 seems counterproductive. I'm building a Ubuntu 22.04 VM and will try all this on that VM.

-- Tom, N5EG

[ra1nb0w]

It is a very strange behavior. Yes, try with the VM ;-)

[Tom-McDermott]

Ok. This now builds and runs on Ubuntu 22.04 / gnuradio 3.10 So Ubuntu 20.04 appears too old to do some things like bind. The stop button (gui) and Enter key (terminal) correctly stop the flowgraph.

I will do some basic QA testing before putting up a release candidate.

-- Tom, N5EG

[ra1nb0w]

Oh finally :) Ok. I will do a few test when you release the RC. thank you very much for your work

[Tom-McDermott]

I've pushed gr_3.10 and tagged it V3.10. The gui and terminal stop buttons still work, but there were no code changes in this area. Please test and let me know if the issue is still there. If stop still does not work then could be an OS dependence.

-- Tom, N5EG

[ra1nb0w]

Thank you. Updated to gnuradio 3.10.2.0 then built the branch gr_3.10 but I have a very strange error:

   self.hpsdr_hermesNB_0 = hpsdr.hermesNB(7200000, 7200000, 7200000, 7200000, 7200000, 7200000, 7200000, 7200000, 7200000, 0, 0, 1, 1, 0, 48000, "en0", "0xF8", 0, 0, 0x00, 0x00, 1, 1, "*")
AttributeError: module 'hpsdr' has no attribute 'hermesNB'

but python_bindings.cc is fine.

Any idea?

[Tom-McDermott]

The PYTHONPATH changed in gr_3.10 as the modules were moved into a subdirectory. The README.md page provides recommended PYTHONPATH and LD_LIBRARY_PATH settings for gnuradio 3.10 and Python 3.10 (coincidentally the same release number).

-- Tom, N5EG

On Wed, May 18, 2022 at 1:14 AM ra1nb0w @.***> wrote:

Thank you. Updated to gnuradio 3.10.2.0 then built the branch gr_3.10 but I have a very strange error:

self.hpsdr_hermesNB_0 = hpsdr.hermesNB(7200000, 7200000, 7200000, 7200000, 7200000, 7200000, 7200000, 7200000, 7200000, 0, 0, 1, 1, 0, 48000, "en0", "0xF8", 0, 0, 0x00, 0x00, 1, 1, "*") AttributeError: module 'hpsdr' has no attribute 'hermesNB'

but python_bindings.cc https://github.com/Tom-McDermott/gr-hpsdr/blob/gr_3.10/python/hpsdr/bindings/python_bindings.cc is fine.

Any idea?

— Reply to this email directly, view it on GitHub https://github.com/Tom-McDermott/gr-hpsdr/issues/19#issuecomment-1129708520, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABZR5HG2SFJEIAR7FO375Z3VKSRFBANCNFSM5OHCCQPA . You are receiving this because you commented.Message ID: @.***>

[ra1nb0w]

my fault. sorry for the noise. the "kill" close the flow graph application but it remains as is. the "kill" button remains active and the "start" is not enabled. Probably can be this

Exception in thread Thread-2:
Traceback (most recent call last):
  File "/opt/local/Library/Frameworks/Python.framework/Versions/3.9/lib/python3.9/threading.py", line 973, in _bootstrap_inner
    self.run()
  File "/opt/local/Library/Frameworks/Python.framework/Versions/3.9/lib/python3.9/site-packages/gnuradio/grc/gui/Executor.py", line 115, in run
    r = self.process.stdout.read(1)
  File "/opt/local/Library/Frameworks/Python.framework/Versions/3.9/lib/python3.9/codecs.py", line 322, in decode
    (result, consumed) = self._buffer_decode(data, self.errors, final)
UnicodeDecodeError: 'utf-8' codec can't decode byte 0xd0 in position 164: invalid continuation byte

Running the python flow graph doesn't show this error therefore it is something from gnuradio but it is something that happen "only" with your OOT.

And probably the self.process.stdout.read(1) fails and can't self.process.stdout.close() and therefore gnuradio-companion wait the execution thread to terminate.

[Tom-McDermott]

I am unable to duplicate this on Ubuntu 22.04 The 'kill' button in GRC functions correctly: the flow graph closes, the buffer statistics print correctly, the console does not show any python errors, and GRC goes to a flowgraph stopped state where the flowgraph can be restarted via the run button.

What operating system and version are you using?

-- Tom, N5EG

[ra1nb0w]

macOS 10.14 gnuradio 3.10.2.0 with macports

I need to take the time to investigate that issue since it is very strange that arise only with your OOT.

Thank you for your work and support.