[Discuss-gnuradio] 3.8.0.0-rc2 build from source on macOS
Hi, With RC2 becoming available, I decided to give a new try building it under macOS (10.14) - I’ve been fighting w/ technical previews a couple of months ago with some limited success. The build is now successful, but I still have a couple of questions for which I did not find the answers on the GNUradio web site - or I more likely failed to locate them, as I found quite outdated answers that do not seem to apply to 3.8 series. - What is the proper/best/recommended UI framework to use? * Default build uses GTK, but it seems there is no spectrum/oscilloscope/... virtual device available with this framework. Am I wrong? * WxWidget does not seem to be supported anymore. Am I correct? * (Py)QT seems to be hardcoded to use Python2, whereas 3.8 can be build with Python3 as CMakeList.txt seems to check for Python2: gr-qtgui/CMakeLists.txt:find_package(PythonLibs 2) -- Configuring gnuradio-companion support... -- Dependency ENABLE_GNURADIO_RUNTIME = ON -- Dependency ENABLE_PYTHON = ON -- Dependency PYTHON_MIN_VER_FOUND = TRUE -- Dependency PYYAML_FOUND = TRUE -- Dependency MAKO_FOUND = TRUE -- Dependency PYGI_FOUND = TRUE -- Dependency GTK_GI_FOUND = TRUE -- Dependency CAIRO_GI_FOUND = TRUE -- Dependency PANGOCAIRO_GI_FOUND = TRUE -- Dependency NUMPY_FOUND = TRUE -- Enabling gnuradio-companion support. -- Override with -DENABLE_GRC=ON/OFF ... -- Configuring gr-qtgui support... -- Dependency Boost_FOUND = TRUE -- Dependency QT_FOUND = 1 -- Dependency QWT_FOUND = TRUE -- Dependency ENABLE_VOLK = ON -- Dependency ENABLE_GNURADIO_RUNTIME = ON -- Dependency ENABLE_GR_FFT = ON -- Dependency ENABLE_GR_FILTER = ON -- Dependency PYTHONLIBS_FOUND = TRUE -- Dependency PYQT5_FOUND = TRUE -- Enabling gr-qtgui support. -- Override with -DENABLE_GR_QTGUI=ON/OFF So I’m kind of lost here, any help/advice/URL would be greatly appreciated. I’ve successfully built the gnuradio-companion with GTK + PyQT + QWT, but I’m not sure it can work as expected with this Python 2 thing. Can it? How to know which framework is actually used, as it seems both GTK and QT dependencies are successfully found? Or does it mean the UI is using (Py)GTK, but some UI items rely on QT? I’m kinda lost…. When QT support is not added, GRC accepts to drag and drop blocks, but on the first attempt to interconnect two blocks, the UI gets lost, zoom in, then crashes. When QT support is present, GRC fails even earlier when the first block is dropped, with the following backtrace: $ gnuradio-companion <<< Welcome to GNU Radio Companion 3.8.0.0-rc2 >>> Block paths: /usr/local/Cellar/gnuradio/3.8.0.0-rc2/share/gnuradio/grc/blocks Traceback (most recent call last): File "/usr/local/Cellar/gnuradio/3.8.0.0-rc2/lib/python3.7/dist-packages/gnuradio/grc/gui/DrawingArea.py", line 103, in _handle_drag_data_received self._flow_graph.add_new_block(selection_data.get_text(), coords) File "/usr/local/Cellar/gnuradio/3.8.0.0-rc2/lib/python3.7/dist-packages/gnuradio/grc/gui/canvas/flowgraph.py", line 176, in add_new_block block.coordinate = coor AttributeError: 'NoneType' object has no attribute 'coordinate' BR, Thanks. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] 3.8.0.0-rc2 build from source on macOS
Hi Emmanuel, my Apple experience limits itself to using an iPod in the summer 2010 or so, but I hope I can still be of help. First of all: Which path are you taking to build stuff? > - What is the proper/best/recommended UI framework to use? > >* Default build uses GTK, but it seems there is no > spectrum/oscilloscope/... virtual device available with this framework. > Am I wrong? Kind of. GRC uses GTK as the UI which you use to build flow graphs. The flow graphs themselves are not related to that UI. So, mentally separate the signal processing design tool "GRC" from the signal displaying tool "gr-qtgui". The first is python using GTK, the second a mix of C++ and Python using Qt. The first generates a program that sets up a GNU Radio flow graph and executes it, the second is used in that flowgraph (potentially). >* WxWidget does not seem to be supported anymore. Am I correct? Correct. gr-wxgui wasn't maintainable for us anymore, and after 4 years of announcing that we're finally removing it :) >* (Py)QT seems to be hardcoded to use Python2, whereas 3.8 can be > build with Python3 as CMakeList.txt seems to check for Python2: > > gr-qtgui/CMakeLists.txt:find_package(PythonLibs 2) > > -- Configuring gnuradio-companion support... > -- Dependency ENABLE_GNURADIO_RUNTIME = ON > -- Dependency ENABLE_PYTHON = ON > -- Dependency PYTHON_MIN_VER_FOUND = TRUE > -- Dependency PYYAML_FOUND = TRUE > -- Dependency MAKO_FOUND = TRUE > -- Dependency PYGI_FOUND = TRUE > -- Dependency GTK_GI_FOUND = TRUE > -- Dependency CAIRO_GI_FOUND = TRUE > -- Dependency PANGOCAIRO_GI_FOUND = TRUE > -- Dependency NUMPY_FOUND = TRUE > -- Enabling gnuradio-companion support. > -- Override with -DENABLE_GRC=ON/OFF > ... > -- Configuring gr-qtgui support... > -- Dependency Boost_FOUND = TRUE > -- Dependency QT_FOUND = 1 > -- Dependency QWT_FOUND = TRUE > -- Dependency ENABLE_VOLK = ON > -- Dependency ENABLE_GNURADIO_RUNTIME = ON > -- Dependency ENABLE_GR_FFT = ON > -- Dependency ENABLE_GR_FILTER = ON > -- Dependency PYTHONLIBS_FOUND = TRUE > -- Dependency PYQT5_FOUND = TRUE > -- Enabling gr-qtgui support. > -- Override with -DENABLE_GR_QTGUI=ON/OFF > Ah! That might be a package naming problem. For example, on Fedora 30, the package you want for python3 PyQt would be python3-PyQt5 and python3-qt5-devel. >So I’m kind of lost here, any help/advice/URL would be greatly > appreciated. >I’ve successfully built the gnuradio-companion with GTK + PyQT + > QWT, but I’m not sure it can work as expected with this Python 2 > thing. Can it? So, two different things: making GRC work (GTK), and making gr-qtgui (QT, PyQt, Qwt) work. > >How to know which framework is actually used, as it seems both GTK > and QT dependencies are successfully found? Both, for different things. >Or does it mean the UI is using (Py)GTK, but some UI items rely on > QT? I’m kinda lost…. Hope I got you out of that confusion! >When QT support is not added, GRC accepts to drag and drop blocks, > but on the first attempt to interconnect two blocks, the UI gets lost, > zoom in, then crashes. That's probably something else, as said, Qt isn't used in GRC. You don't need Qt to have GRC, and you don't need GRC to get gr-qtgui. >When QT support is present, GRC fails even earlier when the first > block is dropped, with the following backtrace: > > $ gnuradio-companion > <<< Welcome to GNU Radio Companion 3.8.0.0-rc2 >>> > > Block paths: > /usr/local/Cellar/gnuradio/3.8.0.0-rc2/share/gnuradio/grc/blocks > Traceback (most recent call last): >File > "/usr/local/Cellar/gnuradio/3.8.0.0-rc2/lib/python3.7/dist-packages/gnuradio/grc/gui/DrawingArea.py", > > line 103, in _handle_drag_data_received > self._flow_graph.add_new_block(selection_data.get_text(), > coords) >File > "/usr/local/Cellar/gnuradio/3.8.0.0-rc2/lib/python3.7/dist-packages/gnuradio/grc/gui/canvas/flowgraph.py", > > line 176, in add_new_block > block.coordinate = coor > AttributeError: 'NoneType' object has no attribute 'coordinate' > I'd call that a bug! Can you tell us which blog you dragged onto the canvas, or does this happen with all blocks? Also: this is a clean install, right? There's no e.g. flowgraph.py flying around anywhere else on your system where python might be erratically picking it up? Best regards, Marcus smime.p7s Description: S/MIME cryptographic signature ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] 3.8.0.0-rc2 build from source on macOS
Hi Marcus, my Apple experience limits itself to using an iPod in the summer 2010 or so, but I hope I can still be of help. :-) First of all: Which path are you taking to build stuff? I’m using Homebrew (https://brew.sh) to build *nix applications on macOS. It is nice to have a controlled build environment. To build GR 3.0.0.8-rc2, I’m using the default Apple compiler: $ cc --version Apple LLVM version 10.0.1 (clang-1001.0.46.4) Target: x86_64-apple-darwin18.7.0 Thread model: posix and the following major dependencies: cmake 3.15.2 ninja 1.9.0 swig 4.0.0 python 3.7.4 pyqt 5.10.1 qwt 6.1.4 qt 5.13.0 For PyGTK, I’m not sure which version is actually used. import gi gi.version_info (3, 32, 2) but PyGTK2 was also installed. Let me know if there is a good/better way to check this point. Less relevant I believe: adwaita-icon-theme 3.32.0 doxygen 1.8.15 pkg-config 0.29.2 sphinx 2.1.2 boost 1.70.0 fftw 3.3.8_1 gsl 2.5 numpy 1.16.4 portaudio 19.6.0 libyaml 0.2.2 mpir 3.0.0 uhd 3.14.1.0 zeromq 4.3.2 freeglut 3.0.0 log4cpp 1.1.3 + all sub-dependencies + all Python modules :P GR is therefore built with CMake/Ninja, from an out of source build. I can post the build log if it can help. I’m not sure I answer your question about the build path I take, please let me know. Ah! That might be a package naming problem. For example, on Fedora 30, the package you want for python3 PyQt would be python3-PyQt5 and python3-qt5-devel. I think on QT side this is correct (QT5), but I’m not sure how to check which actual GTK version is actually used. I do develop on the same host with PyGTK3. I removed GTK2 and pygtk (for Py2) packages as they were only used for the previous GR 3.7 series on my host - it did not help up to now. So, two different things: making GRC work (GTK), and making gr-qtgui (QT, PyQt, Qwt) work. Ok, got it. Hope I got you out of that confusion! Yes. Thanks a lot for these details, I really mean it. That's probably something else, as said, Qt isn't used in GRC. You don't need Qt to have GRC, and you don't need GRC to get gr-qtgui. Ok. I'd call that a bug! Can you tell us which blog you dragged onto the canvas, or does this happen with all blocks? It happens with any block, as simple as the logical AND block, or Constant waveform source I was tracing the call before I receive your reply, and for now, here is what I found: BlockTreeWindow.py: def _handle_drag_get_data(self, widget, drag_context, selection_data, info, time): key = self._get_selected_block_key() if key: # key is a valid text string, e.g. “blocks_and_xx” or “analog_const_source_x” selection_data.set_text(key, len(key)) DrawingArea.py: def _handle_drag_data_received(self, widget, drag_context, x, y, selection_data, info, time): coords = x / self.zoom_factor, y / self.zoom_factor # here, selection_data is empty (no data, no text, no type), I can’t tell why. self._flow_graph.add_new_block(selection_data.get_text(), coords) flowgraph.py: def add_new_block(self, key, coor=None): id = self._get_unique_id(key) ... # key is None, and exception is raised block = self.new_block(key) Also: this is a clean install, right? There's no e.g. flowgraph.py flying around anywhere else on your system where python might be erratically picking it up? No, I’ve removed all the previous GNUradio installation, and Homebrew always installs each app in its own versioned directory, here “/usr/local/Cellar/gnuradio/3.8.0.0-rc2/“ There is no custom PYTHONPATH, and I also unset GRC_BLOCKS_PATH from a previous setup. When I edit the Python file (to track down this issue), my trace messages are executed as expected. PYTHONPATH is therefore defined to: PYTHONPATH="/usr/local/Cellar/gnuradio/3.8.0.0-rc2/lib/python3.7/dist-packages:\ /usr/local/Cellar/gnuradio/3.8.0.0-rc2/lib/python3.7/site-packages:\ /usr/local/Cellar/gnuradio/3.8.0.0-rc2/libexec/vendor/lib/python3.7/site-packages" 1: lib/python3.7/dist-packages: gnuradio, pmt 2: lib/python3.7/site-packages: volk_modtool 3: libexec/vendor/lib/python3.7/site-packages# Python modules for gnuradio (yaml, lxml, six, mako, click, …) Thanks for your help, Emmanuel. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] smith chart on GNU radio
Hi Nate, Thank you, unfortunately I have the following error when I execute "python ./example_smith.py": Traceback (most recent call last): File "./example_smith.py", line 24, in import smithchart as smith ImportError: No module named smithchart Could you help me? Thank you for your time. Best Regards, Simona Il giorno mar 6 ago 2019 alle ore 18:22 Nate Temple ha scritto: > Hi Simona, > > CGRAN [0] has gr-smithchart[1] listed, however, it hasn't had any commits > for 5yrs, it might work still. > > > [0] - http://cgran.org/ > [1] - https://github.com/mitul93/gr-smithchart > > > Regards, > Nate Temple > > On Tue, Aug 6, 2019 at 10:14 AM Simona Sibio wrote: > >> Hi all, >> >> I am working with GNU radio 3.7.13.4 and I would like to plot my data on >> the smith chart. >> Do you know if there is some module or some method? >> Thank you for your time. >> >> Best regards, >> >> Simona >> ___ >> Discuss-gnuradio mailing list >> Discuss-gnuradio@gnu.org >> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio >> > ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] smith chart on GNU radio
You've not install gr-smithchart successfully into the directory your python looks into. On Thu, 2019-08-08 at 15:07 +0100, Simona Sibio wrote: > Hi Nate, > > Thank you, unfortunately I have the following error when I execute "python > ./example_smith.py": > Traceback (most recent call last): > File "./example_smith.py", line 24, in > import smithchart as smith > ImportError: No module named smithchart > > Could you help me? > Thank you for your time. > Best Regards, > > Simona > > Il giorno mar 6 ago 2019 alle ore 18:22 Nate Temple > ha scritto: > > Hi Simona, > > > > CGRAN [0] has gr-smithchart[1] listed, however, it hasn't had any commits > > for 5yrs, it might work still. > > > > > > [0] - http://cgran.org/ > > [1] - https://github.com/mitul93/gr-smithchart > > > > > > Regards, > > Nate Temple > > > > On Tue, Aug 6, 2019 at 10:14 AM Simona Sibio wrote: > > > Hi all, > > > > > > I am working with GNU radio 3.7.13.4 and I would like to plot my data on > > > the smith chart. > > > Do you know if there is some module or some method? > > > Thank you for your time. > > > > > > Best regards, > > > > > > Simona > > > ___ > > > Discuss-gnuradio mailing list > > > Discuss-gnuradio@gnu.org > > > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio > > ___ > Discuss-gnuradio mailing list > Discuss-gnuradio@gnu.org > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio smime.p7s Description: S/MIME cryptographic signature ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] 3.8.0.0-rc2 build from source on macOS
Hi Emmanuel - I'm the GR OSX "expert" (LOL), as I do a lot of testing and verification and development on OSX (various versions). I'm happy to help as best I can. It might be that your issue is a generic GR bug. Let's take this discussion off-list & see what we can work out. If there's something relevant we can report back to the list and/or create a GR issue for it. - MLD On Thu, Aug 8, 2019, at 10:02 AM, Emmanuel Blot wrote: > Hi Marcus, > > > my Apple experience limits itself to using an iPod in the summer 2010 > > or so, but I hope I can still be of help. > > :-) > > > First of all: Which path are > > you taking to build stuff? > > I’m using Homebrew (https://brew.sh) to build *nix applications on > macOS. > It is nice to have a controlled build environment. > > To build GR 3.0.0.8-rc2, I’m using the default Apple compiler: > > $ cc --version > Apple LLVM version 10.0.1 (clang-1001.0.46.4) > Target: x86_64-apple-darwin18.7.0 > Thread model: posix > > and the following major dependencies: > > cmake 3.15.2 > ninja 1.9.0 > swig 4.0.0 > python 3.7.4 > pyqt 5.10.1 > qwt 6.1.4 > qt 5.13.0 > > For PyGTK, I’m not sure which version is actually used. > > >>> import gi > >>> gi.version_info > (3, 32, 2) > > but PyGTK2 was also installed. > > Let me know if there is a good/better way to check this point. > > Less relevant I believe: > > adwaita-icon-theme 3.32.0 > doxygen 1.8.15 > pkg-config 0.29.2 > sphinx 2.1.2 > boost 1.70.0 > fftw 3.3.8_1 > gsl 2.5 > numpy 1.16.4 > portaudio 19.6.0 > libyaml 0.2.2 > mpir 3.0.0 > uhd 3.14.1.0 > zeromq 4.3.2 > freeglut 3.0.0 > log4cpp 1.1.3 > + all sub-dependencies + all Python modules :P > > GR is therefore built with CMake/Ninja, from an out of source build. > I can post the build log if it can help. > > I’m not sure I answer your question about the build path I take, > please let me know. > > > Ah! That might be a package naming problem. For example, on Fedora 30, > > the package you want for python3 PyQt would be python3-PyQt5 and > > python3-qt5-devel. > > I think on QT side this is correct (QT5), but I’m not sure how to > check which actual GTK version is actually used. > I do develop on the same host with PyGTK3. > > I removed GTK2 and pygtk (for Py2) packages as they were only used for > the previous GR 3.7 series on my host - it did not help up to now. > > > So, two different things: making GRC work (GTK), and making gr-qtgui > > (QT, PyQt, Qwt) work. > > Ok, got it. > > > Hope I got you out of that confusion! > > Yes. Thanks a lot for these details, I really mean it. > > > That's probably something else, as said, Qt isn't used in GRC. You > > don't need Qt to have GRC, and you don't need GRC to get gr-qtgui. > > Ok. > > > I'd call that a bug! > > Can you tell us which blog you dragged onto the canvas, or does this > > happen with all blocks? > > It happens with any block, as simple as the logical AND block, or > Constant waveform source > > I was tracing the call before I receive your reply, and for now, here is > what I found: > > BlockTreeWindow.py: > def _handle_drag_get_data(self, widget, drag_context, > selection_data, info, time): > key = self._get_selected_block_key() > if key: > # key is a valid text string, e.g. “blocks_and_xx” or > “analog_const_source_x” > selection_data.set_text(key, len(key)) > > > DrawingArea.py: > def _handle_drag_data_received(self, widget, drag_context, x, y, > selection_data, info, time): > coords = x / self.zoom_factor, y / self.zoom_factor > # here, selection_data is empty (no data, no text, no type), I > can’t tell why. > self._flow_graph.add_new_block(selection_data.get_text(), > coords) > > > flowgraph.py: > def add_new_block(self, key, coor=None): > id = self._get_unique_id(key) > ... > # key is None, and exception is raised > block = self.new_block(key) > > > > Also: this is a clean install, right? There's no e.g. flowgraph.py > > flying around anywhere else on your system where python might be > > erratically picking it up? > > No, I’ve removed all the previous GNUradio installation, and Homebrew > always installs each app in its own versioned directory, here > “/usr/local/Cellar/gnuradio/3.8.0.0-rc2/“ > There is no custom PYTHONPATH, and I also unset GRC_BLOCKS_PATH from a > previous setup. When I edit the Python file (to track down this issue), > my trace messages are executed as expected. > > PYTHONPATH is therefore defined to: > PYTHONPATH="/usr/local/Cellar/gnuradio/3.8.0.0-rc2/lib/python3.7/dist-packages:\ > > /usr/local/Cellar/gnuradio/3.8.0.0-rc2/lib/python3.7/site-packages:\ > > /usr/local/Cellar/gnuradio/3.8.0.0-rc2/libexec/vendor/lib/python3.7/site-packages" > > 1: lib/python3.7/dist-packages: gnuradio, pmt > 2: lib/python3.7/site-packages: volk_modtool > 3: libexec/vendor/lib/python3.7/site-pack
[Discuss-gnuradio] GPS information
Hi, I'm using gnu radio companion along with my USRP B200. I also have a GPSDO installed on the radio. Does the gps information get collected along with any frequency data I collect via gnu radio companion? Also, is it possible to display that information in the metadata header? Thanks! ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] GPS information
On 08/08/2019 02:10 PM, Sara Kim wrote: Hi, I'm using gnu radio companion along with my USRP B200. I also have a GPSDO installed on the radio. Does the gps information get collected along with any frequency data I collect via gnu radio companion? Also, is it possible to display that information in the metadata header? Thanks! No, the GPS information is not carried along with samples. The underlying UHD driver does have a sensor interface. If you look at the source code for the "query_gpsdo_sensors" UHD utility, you can see how they work, and gr-uhd does provide APIs for querying, etc. But none of this is inserted automatically as stream tags or anything. https://www.gnuradio.org/doc/doxygen/classgr_1_1uhd_1_1usrp__source.html ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Remotely controlling a GNURadio flowgraph via LAN
Hi, I have created a simple tcp based iq stream using ZMQ blocks to use a HackRF remotely over an ethernet network. I have a linux computer (Raspberry Pi) connected to the HackRF running GNURadio. The HackRF source is connected to a ZMQ sink that transmits the packets to a receiving linux PC running GNURadio - where a ZMQ source connected to a QT sink for visualising the IQ signal stream. This works fine for a fixed frequency, sample rate and fft size etc, however my problem is that i want to be able to change those parameters from the receiving PC. Despite much research, i have been unable to find a way to change the parameters of the remote flowgraph (client) from the receiving display end (server). Is there a way to natively perform this operation within GNURadio and can someone provide guidance on how to setup a flowgraph to achieve this? Or is there some additional OOT block or custom python block i would need to create to do this. Thanks Alex ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
