Re: New install of GNU Radio executes old version

[Chris Gorman]

Hi Jim,

I did some google surfing to see what the problem was, given a missing
libuhd4.2.0.  The package available for bullseye is libuhd3.15.  The
package available for bookworm is libuhd4.3.0.  I have read one source
that said gnuradio > 3.8 will require libuhd > 4, so we won't be able
to install libuhd from apt and build gnuradio 3.10+.  (The source was
the cheat sheet I sent you.)  If I am wrong, hopefully someone on the
mailing list will correct me.  That said, it limits our options.

You could update to bookworm on your Pi.  This would allow you to use
the v3.10.5.1 gnuradio as Volker suggested.  I believe this requires a
64bit Pi.  I have never updated debian on a Pi, so I don't know the
obstacles, but from my memory it was fairly easy to do on an x86.
Alternatively, you could attempt a build of libuhd 4+ on your machine.
This will consume some time as well as it is a fairly large software
package.  The process is fairly easy (cmake, make, make install), but
you may run into build errors given the older software on the Pi and
newer software for the uhd.  If you're planning on trying to update
the UHD software, the link on how to do so is
https://wiki.gnuradio.org/index.php?title=Draft-AN-445#Building_and_installing_UHD_from_source_code
.

I wish I had better news for you given all the work you've already
done trying to get this up and running.

Best regards,

Chris








On Thu, Oct 10, 2024 at 6:15 PM Elmore Family  wrote:
>
> Chris,
>
> Here's the latest in this never-ending saga:
>
> pi@raspberrypi:~ $ sudo apt-get install --no-install-recommends libuhd4.2.0
> libuhd-dev
> Reading package lists... Done
> Building dependency tree... Done
> Reading state information... Done
> E: Unable to locate package libuhd4.2.0
> E: Couldn't find any package by glob 'libuhd4.2.0'
> E: Couldn't find any package by regex 'libuhd4.2.0'
>
> Jim
>
> -Original Message-
> From: Chris Gorman
> Sent: Wednesday, October 9, 2024 9:05 PM
> To: Elmore Family
> Cc: Volker Schroer ; discuss-gnuradio@gnu.org
> Subject: Re: New install of GNU Radio executes old version
>
> Hi Jim,
>
> I've found a cheat sheet on installing on the Pi.  It's available at
> https://www.radiosrs.net/installing_uhd_gnuradio.html .  When I
> originally read it I thought it said you'd need to build libuhd from
> scratch, but it appears upon closer inspection that there are packages
> for libuhd.  Yay!
>
> In short the author suggests,
>
> sudo apt-get install --no-install-recommends libuhd4.2.0 libuhd-dev
>
> to install UHD on the Pi.  If you have patience to try yet another
> build, try installing those packages and see if it fixes the build
> error.  (As you can see from the error it's happening with a Qt Rfnoc
> file.)  You'll have to ...
>
> cd /home/pi/gnuradio
> rm -rf build
> mkdir build
> cd build
> cmake -DCMAKE_INSTALL_PREFIX=/usr -DCMAKE_BUILD_TYPE=Release
> -DPYTHON_EXECUTABLE=/usr/bin/python3  ../
> make -j4
> sudo make install
>
> again, but my hope is with the libuhd4.2.0 and libuhd-dev packages,
> your error will go away.
>
> Don't feel bad if you are tired of builds and want to install your
> backup instead, I understand this has been a frustrating experience.
> However, I do hope you get the source build to work.
>
> Best regards,
>
> Chris
>
> On Wed, Oct 9, 2024 at 7:56 PM Elmore Family  wrote:
> >
> > Chris,
> >
> > Here is the latest.
> >
> > It did seem to complete the install but with the same 2 errors as before:
> >
> > gr-qtgui/lib/CMakeFiles/gnuradio-qtgui.dir/QRfnocF15ColorMapper.cc.o]
> > Error
> > > 1
> > > make[1]: *** [CMakeFiles/Makefile2:7870:
> > > gr-qtgui/lib/CMakeFiles/gnuradio-qtgui.dir/all] Error 2
> > > make: *** [Makefile:160: all] Error 2
> >
> > Again the only gnuradio-companion file is the one in /gnuradio/grc/scripts
> > whose execution results in cannot import gnuradio.
> >
> > Something must have been missed somewhere. I can't believe this can be
> > this
> > difficult.
> >
> > I have my backup of the system from before this began.
> >
> > Jim
> >
> >
> > -Original Message-
> > From: Chris Gorman
> > Sent: Tuesday, October 8, 2024 8:43 PM
> > To: Elmore Family
> > Cc: Volker Schroer ; discuss-gnuradio@gnu.org
> > Subject: Re: New install of GNU Radio executes old version
> >
> > Hi Jim,
> >
> > I'm guessing on this, but I have had experiences where I explicitly
> > disable a feature and it fixes a build failure.  So, rather than
> > letting cmake disable gr-uhd and uhd

Re: New install of GNU Radio executes old version

[Chris Gorman]

Hi Jim,

I've found a cheat sheet on installing on the Pi.  It's available at
https://www.radiosrs.net/installing_uhd_gnuradio.html .  When I
originally read it I thought it said you'd need to build libuhd from
scratch, but it appears upon closer inspection that there are packages
for libuhd.  Yay!

In short the author suggests,

sudo apt-get install --no-install-recommends libuhd4.2.0 libuhd-dev

to install UHD on the Pi.  If you have patience to try yet another
build, try installing those packages and see if it fixes the build
error.  (As you can see from the error it's happening with a Qt Rfnoc
file.)  You'll have to ...

cd /home/pi/gnuradio
rm -rf build
mkdir build
cd build
cmake -DCMAKE_INSTALL_PREFIX=/usr -DCMAKE_BUILD_TYPE=Release
-DPYTHON_EXECUTABLE=/usr/bin/python3  ../
make -j4
sudo make install

again, but my hope is with the libuhd4.2.0 and libuhd-dev packages,
your error will go away.

Don't feel bad if you are tired of builds and want to install your
backup instead, I understand this has been a frustrating experience.
However, I do hope you get the source build to work.

Best regards,

Chris

On Wed, Oct 9, 2024 at 7:56 PM Elmore Family  wrote:
>
> Chris,
>
> Here is the latest.
>
> It did seem to complete the install but with the same 2 errors as before:
>
> gr-qtgui/lib/CMakeFiles/gnuradio-qtgui.dir/QRfnocF15ColorMapper.cc.o] Error
> > 1
> > make[1]: *** [CMakeFiles/Makefile2:7870:
> > gr-qtgui/lib/CMakeFiles/gnuradio-qtgui.dir/all] Error 2
> > make: *** [Makefile:160: all] Error 2
>
> Again the only gnuradio-companion file is the one in /gnuradio/grc/scripts
> whose execution results in cannot import gnuradio.
>
> Something must have been missed somewhere. I can't believe this can be this
> difficult.
>
> I have my backup of the system from before this began.
>
> Jim
>
>
> -Original Message-
> From: Chris Gorman
> Sent: Tuesday, October 8, 2024 8:43 PM
> To: Elmore Family
> Cc: Volker Schroer ; discuss-gnuradio@gnu.org
> Subject: Re: New install of GNU Radio executes old version
>
> Hi Jim,
>
> I'm guessing on this, but I have had experiences where I explicitly
> disable a feature and it fixes a build failure.  So, rather than
> letting cmake disable gr-uhd and uhd-rfnoc, try forcing cmake's hand
> and disable them in the cmake call.  So I'd try ...
>
> cd /home/pi/gnuradio
> rm -rf build
> mkdir build
> cd build
> cmake -DCMAKE_INSTALL_PREFIX=/usr -DCMAKE_BUILD_TYPE=Release
> -DPYTHON_EXECUTABLE=/usr/bin/python3 -DENABLE_GR_UHD=OFF
> -DENABLE_UHD_RFNOC=OFF ../
> make -j4
> sudo make install
>
> And wait for a while, especially on a Pi.  Hope this helps (and works).
>
> Chris
>
>
>
> Chris
>
> On Tue, Oct 8, 2024 at 7:36 PM Elmore Family  wrote:
> >
> > Chris,
> >
> > I have attached the build log. The following shows the install errors. I
> > think it all began with the top line.
> >
> > Jim
> >
> > /home/pi/gnuradio/gr-qtgui/lib/QRfnocF15ColorMapper.cc: In member function
> > ‘void gr::qtgui::QRfnocF15ColorMapper::drawScale(std::string, float,
> > float,
> > float, float)’:
> > /home/pi/gnuradio/gr-qtgui/lib/QRfnocF15ColorMapper.cc:164:15: error:
> > ‘GL_TEXTURE_ENV’ was not declared in this scope; did you mean
> > ‘GL_TEXTURE_3D’?
> >   164 | glTexEnvf(GL_TEXTURE_ENV, GL_TEXTURE_ENV_MODE, GL_REPLACE);
> >   |   ^~
> >   |   GL_TEXTURE_3D
> > /home/pi/gnuradio/gr-qtgui/lib/QRfnocF15ColorMapper.cc:164:31: error:
> > ‘GL_TEXTURE_ENV_MODE’ was not declared in this scope; did you mean
> > ‘GL_TEXTURE_MAX_LOD’?
> >   164 | glTexEnvf(GL_TEXTURE_ENV, GL_TEXTURE_ENV_MODE, GL_REPLACE);
> >   |   ^~~
> >   |   GL_TEXTURE_MAX_LOD
> > /home/pi/gnuradio/gr-qtgui/lib/QRfnocF15ColorMapper.cc:164:5: error:
> > ‘glTexEnvf’ was not declared in this scope
> >   164 | glTexEnvf(GL_TEXTURE_ENV, GL_TEXTURE_ENV_MODE, GL_REPLACE);
> >   | ^
> > /home/pi/gnuradio/gr-qtgui/lib/QRfnocF15ColorMapper.cc:167:5: error:
> > ‘glBegin’ was not declared in this scope
> >   167 | glBegin(GL_QUADS);
> >   | ^~~
> > /home/pi/gnuradio/gr-qtgui/lib/QRfnocF15ColorMapper.cc:168:5: error:
> > ‘glTexCoord2f’ was not declared in this scope
> >   168 | glTexCoord2f(0.0f, 0.0f);
> >   | ^~~~
> > /home/pi/gnuradio/gr-qtgui/lib/QRfnocF15ColorMapper.cc:169:5: error:
> > ‘glVertex2f’ was not declared in this scope
> >   169 | glVertex2f(x0, y0);
> >   | ^~

Re: New install of GNU Radio executes old version

[Chris Gorman]

Hi Jim,

I'm guessing on this, but I have had experiences where I explicitly
disable a feature and it fixes a build failure.  So, rather than
letting cmake disable gr-uhd and uhd-rfnoc, try forcing cmake's hand
and disable them in the cmake call.  So I'd try ...

cd /home/pi/gnuradio
rm -rf build
mkdir build
cd build
cmake -DCMAKE_INSTALL_PREFIX=/usr -DCMAKE_BUILD_TYPE=Release
-DPYTHON_EXECUTABLE=/usr/bin/python3 -DENABLE_GR_UHD=OFF
-DENABLE_UHD_RFNOC=OFF ../
make -j4
sudo make install

And wait for a while, especially on a Pi.  Hope this helps (and works).

Chris



Chris

On Tue, Oct 8, 2024 at 7:36 PM Elmore Family  wrote:
>
> Chris,
>
> I have attached the build log. The following shows the install errors. I
> think it all began with the top line.
>
> Jim
>
> /home/pi/gnuradio/gr-qtgui/lib/QRfnocF15ColorMapper.cc: In member function
> ‘void gr::qtgui::QRfnocF15ColorMapper::drawScale(std::string, float, float,
> float, float)’:
> /home/pi/gnuradio/gr-qtgui/lib/QRfnocF15ColorMapper.cc:164:15: error:
> ‘GL_TEXTURE_ENV’ was not declared in this scope; did you mean ‘GL_TEXTURE_3D’?
>   164 | glTexEnvf(GL_TEXTURE_ENV, GL_TEXTURE_ENV_MODE, GL_REPLACE);
>   |   ^~
>   |   GL_TEXTURE_3D
> /home/pi/gnuradio/gr-qtgui/lib/QRfnocF15ColorMapper.cc:164:31: error:
> ‘GL_TEXTURE_ENV_MODE’ was not declared in this scope; did you mean
> ‘GL_TEXTURE_MAX_LOD’?
>   164 | glTexEnvf(GL_TEXTURE_ENV, GL_TEXTURE_ENV_MODE, GL_REPLACE);
>   |   ^~~
>   |   GL_TEXTURE_MAX_LOD
> /home/pi/gnuradio/gr-qtgui/lib/QRfnocF15ColorMapper.cc:164:5: error:
> ‘glTexEnvf’ was not declared in this scope
>   164 | glTexEnvf(GL_TEXTURE_ENV, GL_TEXTURE_ENV_MODE, GL_REPLACE);
>   | ^
> /home/pi/gnuradio/gr-qtgui/lib/QRfnocF15ColorMapper.cc:167:5: error:
> ‘glBegin’ was not declared in this scope
>   167 | glBegin(GL_QUADS);
>   | ^~~
> /home/pi/gnuradio/gr-qtgui/lib/QRfnocF15ColorMapper.cc:168:5: error:
> ‘glTexCoord2f’ was not declared in this scope
>   168 | glTexCoord2f(0.0f, 0.0f);
>   | ^~~~
> /home/pi/gnuradio/gr-qtgui/lib/QRfnocF15ColorMapper.cc:169:5: error:
> ‘glVertex2f’ was not declared in this scope
>   169 | glVertex2f(x0, y0);
>   | ^~
> /home/pi/gnuradio/gr-qtgui/lib/QRfnocF15ColorMapper.cc:176:5: error: ‘glEnd’
> was not declared in this scope
>   176 | glEnd();
>   | ^
> make[2]: *** [gr-qtgui/lib/CMakeFiles/gnuradio-qtgui.dir/build.make:1025:
> gr-qtgui/lib/CMakeFiles/gnuradio-qtgui.dir/QRfnocF15ColorMapper.cc.o] Error
> 1
> make[1]: *** [CMakeFiles/Makefile2:7870:
> gr-qtgui/lib/CMakeFiles/gnuradio-qtgui.dir/all] Error 2
> make: *** [Makefile:160: all] Error 2
>
>
>
> -Original Message-
> From: Chris Gorman
> Sent: Tuesday, October 8, 2024 4:44 PM
> To: Elmore Family
> Cc: Volker Schroer ; discuss-gnuradio@gnu.org
> Subject: Re: New install of GNU Radio executes old version
>
> Hi Jim,
>
> The --DPYTHON_EXECUATBLE=/usr with the extra switch is a typo on my
> part, it should be -DPYTHON_EXECUTABLE=/usr .  Sorry.  You should get
> an error from cmake with the second switch.
>
> Can you send the error and log file and I'll have a look.
>
> Hoping your nightmare ends soon. :)
>
> Chris
>
> On Tue, Oct 8, 2024 at 4:28 PM Elmore Family  wrote:
> >
> > Chris, et al,
> >
> > The install failed with 2 errors at qtgui.
> >
> > This is a nightmare.
> >
> > Jim
> >
> > -Original Message-
> > From: Chris Gorman
> > Sent: Tuesday, October 8, 2024 8:08 AM
> > To: Volker Schroer
> > Cc: discuss-gnuradio@gnu.org
> > Subject: Re: New install of GNU Radio executes old version
> >
> > Hi Jim,
> >
> > Your call on what to do about this.  If it were me, I'd probably try
> > what Volker is suggesting and use the prebuilt binary.  That said, if
> > you want to try to get gnuradio built on your pi, I'll try to help.
> > Unfortunately, I'm kind of confused about your results.  You should
> > have more than just python-support and libad9361 if all the
> > dependencies were installed.
> >
> > If you want to continue.  Run the following and attach the build.log
> > file produced to your next email.  (It's the build command followed by
> > stdio and stderr redirection to a file.)
> >
> > cmake -DCMAKE_INSTALL_PREFIX=/usr  -DCMAKE_BUILD_TYPE=Release
> > --DPYTHON_EXECUTABLE=/usr/bin/python3 ../ > build.log 2>&1
> >
> > I'll take a look at the results and compare to w

Re: New install of GNU Radio executes old version

[Chris Gorman]

Hi Jim,

The --DPYTHON_EXECUATBLE=/usr with the extra switch is a typo on my
part, it should be -DPYTHON_EXECUTABLE=/usr .  Sorry.  You should get
an error from cmake with the second switch.

Can you send the error and log file and I'll have a look.

Hoping your nightmare ends soon. :)

Chris

On Tue, Oct 8, 2024 at 4:28 PM Elmore Family  wrote:
>
> Chris, et al,
>
> The install failed with 2 errors at qtgui.
>
> This is a nightmare.
>
> Jim
>
> -Original Message-
> From: Chris Gorman
> Sent: Tuesday, October 8, 2024 8:08 AM
> To: Volker Schroer
> Cc: discuss-gnuradio@gnu.org
> Subject: Re: New install of GNU Radio executes old version
>
> Hi Jim,
>
> Your call on what to do about this.  If it were me, I'd probably try
> what Volker is suggesting and use the prebuilt binary.  That said, if
> you want to try to get gnuradio built on your pi, I'll try to help.
> Unfortunately, I'm kind of confused about your results.  You should
> have more than just python-support and libad9361 if all the
> dependencies were installed.
>
> If you want to continue.  Run the following and attach the build.log
> file produced to your next email.  (It's the build command followed by
> stdio and stderr redirection to a file.)
>
> cmake -DCMAKE_INSTALL_PREFIX=/usr  -DCMAKE_BUILD_TYPE=Release
> --DPYTHON_EXECUTABLE=/usr/bin/python3 ../ > build.log 2>&1
>
> I'll take a look at the results and compare to what I'm getting on my
> x86 machine.
>
> All the best,
>
> Chris
>
> On Tue, Oct 8, 2024 at 5:20 AM Volker Schroer  wrote:
> >
> > https://wiki.gnuradio.org/index.php?title=InstallingGR
> > says:
> > For Raspberry Pi OS64-bit ≥2021-10-30 the actual version of gnuradio is
> > v3.10.5.1.
> >
> > Why can't you use this?
> > > Chris,
> > >
> > > I did what you suggested.
> > >
> > > I then ran cmake as before. The result was the same except that the
> > > following were added to the gnuradio enabled components:
> > >
> > > python-support
> > > libad9361
> > >
> > > I'm considering giving up on this. I'm consuming a lot of your time and
> > > this is a personal project only. I really appreciate the effort you have
> > > put into this.
> > >
> > > I wanted to upgrade in order to add a component to my project that
> > > requires 3.10.
> > >
> > > I wouldn't be upset if you want to pull the plug on this.
> > >
> > > Jim
> > >
> > > -Original Message- From: Chris Gorman
> > > Sent: Monday, October 7, 2024 9:22 AM
> > > To: Barry Jackson
> > > Cc: discuss-gnuradio@gnu.org
> > > Subject: Re: New install of GNU Radio executes old version
> > >
> > > Hello Jim,
> > >
> > > As Barry said you're missing lots of devel packages.  I assume based
> > > on your python version that you're using Raspbian Bullseye as your OS.
> > > If that's the case, there is a list of packages that you'll need to
> > > install to build gnuradio.  I would try the list of packages
> > > recommended on https://wiki.gnuradio.org/index.php?title=UbuntuInstall
> > > .
> > >
> > > Basically,
> > >
> > > sudo apt install git cmake g++ libboost-all-dev libgmp-dev python3-numpy
> > > \
> > > python3-mako python3-sphinx python3-lxml doxygen libfftw3-dev \
> > > libsdl1.2-dev libgsl-dev libqwt-qt5-dev libqt5opengl5-dev python3-pyqt5
> > > \
> > > liblog4cpp5-dev libzmq3-dev python3-yaml python3-click python3-click-
> > > plugins \
> > > python3-zmq python3-scipy python3-gi python3-gi-cairo gir1.2-gtk-3.0 \
> > > libcodec2-dev libgsm1-dev libusb-1.0-0 libusb-1.0-0-dev libudev-dev
> > > python3-setuptools
> > >
> > > sudo apt install pybind11-dev python3-matplotlib libsndfile1-dev \
> > > libsoapysdr-dev soapysdr-tools python3-pygccxml python3-pyqtgraph
> > >
> > > and
> > >
> > > sudo apt install libiio-dev libad9361-dev libspdlog-dev
> > > python3-packaging python3-jsonschema python3-qtpy
> > >
> > > Once you get those installed, you'll need to rebuild gnuradio.  You're
> > > looking for a list of gnuradio enabled components after running cmake
> > > similar to the one I sent you.
> > >
> > > Hope this helps.
> > >
> > > Chris
> > >
> > > On Mon, Oct 7, 2024 at 4:21 AM Barry Jackson  wrote:
> > >>
> > >

Re: New install of GNU Radio executes old version

[Chris Gorman]

Hi Jim,

Your call on what to do about this.  If it were me, I'd probably try
what Volker is suggesting and use the prebuilt binary.  That said, if
you want to try to get gnuradio built on your pi, I'll try to help.
Unfortunately, I'm kind of confused about your results.  You should
have more than just python-support and libad9361 if all the
dependencies were installed.

If you want to continue.  Run the following and attach the build.log
file produced to your next email.  (It's the build command followed by
stdio and stderr redirection to a file.)

cmake -DCMAKE_INSTALL_PREFIX=/usr  -DCMAKE_BUILD_TYPE=Release
--DPYTHON_EXECUTABLE=/usr/bin/python3 ../ > build.log 2>&1

I'll take a look at the results and compare to what I'm getting on my
x86 machine.

All the best,

Chris

On Tue, Oct 8, 2024 at 5:20 AM Volker Schroer  wrote:
>
> https://wiki.gnuradio.org/index.php?title=InstallingGR
> says:
> For Raspberry Pi OS64-bit ≥2021-10-30 the actual version of gnuradio is
> v3.10.5.1.
>
> Why can't you use this?
> > Chris,
> >
> > I did what you suggested.
> >
> > I then ran cmake as before. The result was the same except that the
> > following were added to the gnuradio enabled components:
> >
> > python-support
> > libad9361
> >
> > I'm considering giving up on this. I'm consuming a lot of your time and
> > this is a personal project only. I really appreciate the effort you have
> > put into this.
> >
> > I wanted to upgrade in order to add a component to my project that
> > requires 3.10.
> >
> > I wouldn't be upset if you want to pull the plug on this.
> >
> > Jim
> >
> > -Original Message- From: Chris Gorman
> > Sent: Monday, October 7, 2024 9:22 AM
> > To: Barry Jackson
> > Cc: discuss-gnuradio@gnu.org
> > Subject: Re: New install of GNU Radio executes old version
> >
> > Hello Jim,
> >
> > As Barry said you're missing lots of devel packages.  I assume based
> > on your python version that you're using Raspbian Bullseye as your OS.
> > If that's the case, there is a list of packages that you'll need to
> > install to build gnuradio.  I would try the list of packages
> > recommended on https://wiki.gnuradio.org/index.php?title=UbuntuInstall
> > .
> >
> > Basically,
> >
> > sudo apt install git cmake g++ libboost-all-dev libgmp-dev python3-numpy \
> > python3-mako python3-sphinx python3-lxml doxygen libfftw3-dev \
> > libsdl1.2-dev libgsl-dev libqwt-qt5-dev libqt5opengl5-dev python3-pyqt5 \
> > liblog4cpp5-dev libzmq3-dev python3-yaml python3-click python3-click-
> > plugins \
> > python3-zmq python3-scipy python3-gi python3-gi-cairo gir1.2-gtk-3.0 \
> > libcodec2-dev libgsm1-dev libusb-1.0-0 libusb-1.0-0-dev libudev-dev
> > python3-setuptools
> >
> > sudo apt install pybind11-dev python3-matplotlib libsndfile1-dev \
> > libsoapysdr-dev soapysdr-tools python3-pygccxml python3-pyqtgraph
> >
> > and
> >
> > sudo apt install libiio-dev libad9361-dev libspdlog-dev
> > python3-packaging python3-jsonschema python3-qtpy
> >
> > Once you get those installed, you'll need to rebuild gnuradio.  You're
> > looking for a list of gnuradio enabled components after running cmake
> > similar to the one I sent you.
> >
> > Hope this helps.
> >
> > Chris
> >
> > On Mon, Oct 7, 2024 at 4:21 AM Barry Jackson  wrote:
> >>
> >> On 07/10/2024 01:11, Elmore Family wrote:
> >> > Chris,
> >> >
> >> > Here is what I have after cmake:
> >> >
> >> > -- ##
> >> > -- # Gnuradio enabled components
> >> > -- ##
> >> > --   * testing-support
> >> > --   * post-install
> >> > --   * doxygen
> >> > --   * man-pages
> >>
> >> You are missing lots of -devel packages for all those disabled missing
> >> components.
> >>
> >> As a guide look at the BuildRequires in our (Mageia) gnuradio.spec they
> >> start at line 75:
> >>
> >> http://svnweb.mageia.org/packages/cauldron/gnuradio/current/SPECS/
> >> gnuradio.spec?revision=2102453&view=markup
> >>
> >>
> >>
> >>
> >>
> >>
> >
> >
>
>

Re: New install of GNU Radio executes old version

[Chris Gorman]

Hello Jim,

As Barry said you're missing lots of devel packages.  I assume based
on your python version that you're using Raspbian Bullseye as your OS.
If that's the case, there is a list of packages that you'll need to
install to build gnuradio.  I would try the list of packages
recommended on https://wiki.gnuradio.org/index.php?title=UbuntuInstall
.

Basically,

sudo apt install git cmake g++ libboost-all-dev libgmp-dev python3-numpy \
python3-mako python3-sphinx python3-lxml doxygen libfftw3-dev \
libsdl1.2-dev libgsl-dev libqwt-qt5-dev libqt5opengl5-dev python3-pyqt5 \
liblog4cpp5-dev libzmq3-dev python3-yaml python3-click python3-click-plugins \
python3-zmq python3-scipy python3-gi python3-gi-cairo gir1.2-gtk-3.0 \
libcodec2-dev libgsm1-dev libusb-1.0-0 libusb-1.0-0-dev libudev-dev
python3-setuptools

sudo apt install pybind11-dev python3-matplotlib libsndfile1-dev \
libsoapysdr-dev soapysdr-tools python3-pygccxml python3-pyqtgraph

and

sudo apt install libiio-dev libad9361-dev libspdlog-dev
python3-packaging python3-jsonschema python3-qtpy

Once you get those installed, you'll need to rebuild gnuradio.  You're
looking for a list of gnuradio enabled components after running cmake
similar to the one I sent you.

Hope this helps.

Chris

On Mon, Oct 7, 2024 at 4:21 AM Barry Jackson  wrote:
>
> On 07/10/2024 01:11, Elmore Family wrote:
> > Chris,
> >
> > Here is what I have after cmake:
> >
> > -- ##
> > -- # Gnuradio enabled components
> > -- ##
> > --   * testing-support
> > --   * post-install
> > --   * doxygen
> > --   * man-pages
>
> You are missing lots of -devel packages for all those disabled missing
> components.
>
> As a guide look at the BuildRequires in our (Mageia) gnuradio.spec they
> start at line 75:
>
> http://svnweb.mageia.org/packages/cauldron/gnuradio/current/SPECS/gnuradio.spec?revision=2102453&view=markup
>
>
>
>
>
>

Re: New install of GNU Radio executes old version

[Chris Gorman]

Hi Jim,

Firstly, let me tell you that I haven't ever tried installing on a Pi,
so I may be missing some nuances.  Apologies if that's the case.

After step 5 gnuradio-companion should be in /usr/bin based on the
steps you took.  If gnuradio-companion is not in /usr/bin I suspect
that something was missing from your build.  Given your cmake command,
you will not need to set LD_LIBRARY_PATH and PYTHONPATH.   That's only
necessary if you didn't set -DCMAKE_INSTALL_PREFIX=/usr .

You should get something like the following at the end of your cmake command.

-SNIP-
-- ##
-- # Gnuradio enabled components
-- ##
--   * testing-support
--   * python-support
--   * post-install
--   * doxygen
--   * man-pages
--   * gnuradio-runtime
--   * common-precompiled-headers
--   * gr-ctrlport
--   * * thrift
--   * gnuradio-companion
--   * JSON/YAML config blocks
--   * gr-blocks
--   * gr-fec
--   * gr-fft
--   * gr-filter
--   * gr-analog
--   * gr-digital
--   * gr-dtv
--   * gr-audio
--   * * alsa
--   * * oss
--   * * jack
--   * * portaudio
--   * gr-channels
--   * gr-pdu
--   * gr-iio
--   * * libad9361
--   * gr-qtgui
--   * gr-trellis
--   * gr-uhd
--   * gr-uhd UHD 4.0 RFNoC
--   * gr-utils
--   * gr_modtool
--   * gr_blocktool
--   * gr-video-sdl
--   * gr-vocoder
--   * * codec2
--   * * freedv
--   * * gsm
--   * gr-wavelet
--   * gr-zeromq
--   * gr-network
--   * gr-soapy
-- 
-- ##
-- # Gnuradio disabled components
-- ##
--
-- Using install prefix: /usr
-SNIP-

Ensure gnuradio-companion is on the list.  Also note if you have any
components in the disabled components list.

Once make install has completed you should have, roughly speaking, the
following directories / files.

/etc/gnuradio - all the system configuration files
/usr/bin/gnuradio-companion
/usr/lib/libgnuradio* - all the c++ libraries
/usr/lib/python3.9.2/site-packages/gnuradio - all the python components
/usr/share/gnuradio/grc/blocks - all the blocks files
/usr/include/gnuradio - c++ header files

Cannot import gnuradio means python can't find the gnuradio directory
and it's contents in the "python components".  This is critical as
gnuradio-companion is all python driven.  If you have all these
directories, perhaps a review of
https://wiki.gnuradio.org/index.php?title=LinuxInstall#Installing_Volk
to see if you missed a step.  (maybe running sudo ldconfig or
something like that.)

Anyway hoping you get this working.  Let me know if you're missing anything.

Take care,

Chris

On Sun, Oct 6, 2024 at 1:50 PM Elmore Family  wrote:
>
> Chris,
>
> I have tried what you suggested but I am still having issues. I suspect that
> I am misunderstanding something.
>
> 1. I removed 3.9.4
> 2. I performed an export of LD-LIBRARY_PATH as you specified
> 3. I performed an export of PYTHONPATH with xx = .9.2
> 4. I performed
> cmake -DCMAKE_INSTALL_PREFIX=/usr  -DCMAKE_BUILD_TYPE=Release 
> --DPYTHON_EXECUTABLE=/usr/bin/python3
> ../
> 5. sudo make install
>
> Everything seemed to execute with no errors.
>
> I still find gnuradio-companion only in the /gnuradio/grc/scripts directory.
>
> When I execute it from the command line, a box pops up stating "Cannot
> import gnuradio" and asking if PYTHONPATH and LD_LIBRARY_PATH are set
> correctly.
>
> What is wrong now?
>
> Jim
>
> -Original Message-
> From: Chris Gorman
> Sent: Saturday, October 5, 2024 11:27 AM
> To: Volker Schroer
> Cc: discuss-gnuradio@gnu.org
> Subject: Re: New install of GNU Radio executes old version
>
> Hi Jim and Volker,
>
> I just tried what Jim is doing on my x86 system and got the same
> result.  Trying to run from the source tree runs the installed
> gnuradio (in my case 3.10.11).  My recommendations to Jim is to
>
> 1) `apt remove gnuradio` to remove gnuradio 3.9.4
> 2) install the gnuradio from his source tree
>`cd gnuradio/build/`
>`sudo make install`
> 3) then run gnuradio-companion from the command line.
>
> (Commands to run are in between ``).
>
> Some caveats from my installation experience unless
> -DCMAKE_INSTALL_PREFIX=/usr was set during the cmake configure, you
> will have to set both a LD_LIBRARY_PATH and PYTHONPATH to point to the
> directories in the install prefix.
>
> eg. with no -DCMAKE_INSTALL_PREFIX set, /usr/local becomes the default
> install prefix
> so Jim will need to export LD_LIBRARY_PATH=/usr/local/lib and export
> PYTHONPATH=/usr/local/lib/python3.xx/site-pacakges, where xx is the
> version of python on the system.
>
> Hope this helps,
>
> Good luck.
>
> Chris
>
> On Sat,

Re: New install of GNU Radio executes old version

[Chris Gorman]

Hi Jim and Volker,

I just tried what Jim is doing on my x86 system and got the same
result.  Trying to run from the source tree runs the installed
gnuradio (in my case 3.10.11).  My recommendations to Jim is to

1) `apt remove gnuradio` to remove gnuradio 3.9.4
2) install the gnuradio from his source tree
   `cd gnuradio/build/`
   `sudo make install`
3) then run gnuradio-companion from the command line.

(Commands to run are in between ``).

Some caveats from my installation experience unless
-DCMAKE_INSTALL_PREFIX=/usr was set during the cmake configure, you
will have to set both a LD_LIBRARY_PATH and PYTHONPATH to point to the
directories in the install prefix.

eg. with no -DCMAKE_INSTALL_PREFIX set, /usr/local becomes the default
install prefix
so Jim will need to export LD_LIBRARY_PATH=/usr/local/lib and export
PYTHONPATH=/usr/local/lib/python3.xx/site-pacakges, where xx is the
version of python on the system.

Hope this helps,

Good luck.

Chris

On Sat, Oct 5, 2024 at 6:45 AM Volker Schroer  wrote:
>
> Hi Jim!
> How did you install gnuradio 3.10.11 ? If you had 3.10.11 installed, you
> did not had to run it from the source directory. So you did not install
> 3.10.11. I suspect you downloaded the source code from somewhere, but
> missed to build and install it.
>
> How did you get 3.9.4 ?
>
> I  recommend to read the gnuradio installation docs.
>
> https://wiki.gnuradio.org/index.php?title=InstallingGR
>
> -- Volker
>
>
>

Re: unable to execute new installation

[Chris Gorman]

Hello Jim,

Volker is referring to a github pull request (bug fix).  You can find
his bug report number 7513 at
https://github.com/gnuradio/gnuradio/pull/7513 .

Best regards,

Chris



On Sun, Sep 29, 2024 at 9:06 PM Elmore Family  wrote:
>
> What does 7513 refer to? How do I find it?
>
> -Original Message-
> From: Volker Schroer
> Sent: Saturday, September 28, 2024 11:22 AM
> To: GNURadio Discussion List
> Subject: Re: unable to execute new installation
>
> Please stay on the list.
>
>
> First:
>
>   File "/home/pi/gnuradio/grc/main.py", line 250, in get_state_directory
>  f"files to '{newpath}'.")
> UnboundLocalError: local variable 'newpath' referenced before assignment
>
> is definitely a bug in the python code.
>
> I proposed a fix. See #7513 on github.
>
> This pr may not fix the reason of your problems, but you should get a
> better error message.
>
> What is the result of
>
> gnuradio-config-info --prefix
>
> Why do you start gnuradio-companion from the source tree and not from
> the install directory?
>
>
> Am 28.09.24 um 15:06 schrieb Elmore’s:
> > I did perform the install command and I thought it worked. You also say
> > this is a bug. Thus I am confused.
> > Sent from my iPhone
>
>
>
> --
> This email has been checked for viruses by AVG antivirus software.
> www.avg.com
>
>

Re: Timing a flowgraph execution

[Chris Gorman]

Hello Again,

Apologies for the extra email, but I found my problem and thought it
best to share my findings.  Firstly, I had an error in my flowgraph
that was causing Overflows and Underruns as well as Sequence errors
that I hadn't detected.  Fixing this fixed the problem I was having
with timing the flowgraph.

I have deleted the null source to throttle to null sink in the
flowgraph and set the "Function Probe" block to use the ID of the
"Soapy RTLSDR Source" block.  It then reports the value of
nitems_written as fprobe_val, which I use in the "QT GUI Level Gauge".
I set the value of the Level Gauge to be 'int(((fprobe_val /
samp_rate) / duration) * 100)'. When the flowgraph is run a progress
bar moves across the screen and I can tell how much of the satellite
pass has occurred and adjust the antenna position accordingly.

So I consider this fixed.

All the best,

Chris

On Wed, Sep 18, 2024 at 8:40 AM Chris Gorman  wrote:
>
> Hello all,
>
> I would like to set a timer to create a percent complete graph with
> the "QT GUI Level Gauge" block.  I've created a flowgraph that does
> this and attached a screenshot and the flowgraph.  My goal is to have
> this kind of "percent complete timer" to tell me when to move my
> antenna during a satellite pass.  This means adding a piece of
> hardware and its connections to the attached flowgraph and I am
> worried about having two timers in the same flowgraph.
>
> If I use this flowgraph and add hardware and use a head block with
> "samp_rate * duration" items it doesn't complete at the same time as
> the "percent complete timer".  There are more items to complete for
> the hardware when the "percent complete timer" ends.
>
> I have tried to use the "Function Probe" block to probe the source of
> my hardware piece, but that doesn't work properly as the timing is off
> for both timers.
>
> Does anyone have a suggestion on how to calculate the percentage
> complete from the timer on the hardware piece instead of using a
> separate null sink as I have in the attached flowgraph?
>
> Thanks in advance,
>
> Chris

Timing a flowgraph execution

[Chris Gorman]

Hello all,

I would like to set a timer to create a percent complete graph with
the "QT GUI Level Gauge" block.  I've created a flowgraph that does
this and attached a screenshot and the flowgraph.  My goal is to have
this kind of "percent complete timer" to tell me when to move my
antenna during a satellite pass.  This means adding a piece of
hardware and its connections to the attached flowgraph and I am
worried about having two timers in the same flowgraph.

If I use this flowgraph and add hardware and use a head block with
"samp_rate * duration" items it doesn't complete at the same time as
the "percent complete timer".  There are more items to complete for
the hardware when the "percent complete timer" ends.

I have tried to use the "Function Probe" block to probe the source of
my hardware piece, but that doesn't work properly as the timing is off
for both timers.

Does anyone have a suggestion on how to calculate the percentage
complete from the timer on the hardware piece instead of using a
separate null sink as I have in the attached flowgraph?

Thanks in advance,

Chris


time_flowgraph.grc
Description: application/gnuradio-grc


time_flowgraph.pdf
Description: Adobe PDF document

Attempt to build gr-customModule on windows using msys2

[Chris Gorman]

Hello All,

I've attempted to build gr-customModule (Creating Python OOT with
gr-modtool - GNU Radio) on windows using msys2 and I get a build
error.  When I complete the build on a linux system, I get the
following __init__.py file.

#
# Copyright 2008,2009 Free Software Foundation, Inc.
#
# SPDX-License-Identifier: GPL-3.0-or-later
#

# The presence of this file turns this directory into a Python package

'''
This is the GNU Radio CUSTOMMODULE module. Place your Python package
description here (python/__init__.py).
'''
import os

# import pybind11 generated symbols into the customModule namespace
try:
# this might fail if the module is python-only
from .customModule_python import *
except ModuleNotFoundError:
pass

# import any pure python here
from .addSubSelect import addSubSelect
#

When I build on windows I get the same __init__.py file minus the
"from .addSubSelect import addSubSelect" line.  I've spent the morning
looking through the cmake files to see why I don't get this line, but
am none the wiser.  Does anyone know what I am missing on the windows
side to get this line added?

Thanks in advance,

Chris

Re: Writing Drivers for Custom Hardware

[Chris Kuethe]

I've not played with the ZMQ blocks, but a number of other drivers can
operate in network mode, eg. UHD, SoapySDR, and rtlsdr. Since the firehose
appears to use 2-bit samples I feel like you could fairly easily convert
that into something resembling rtl_tcp (
https://github.com/osmocom/rtl-sdr/blob/master/src/rtl_tcp.c#L95).

On Fri, Jul 12, 2024 at 3:55 PM Walter Szeliga 
wrote:

> Hi all,
> I have a GNSS Firehose (
> https://transitiva.com/product/gnss-firehose-receiver-tri-band-quad-constellation/)
> and have been trying to get it working, in a streaming capacity, with
> Gnuradio. The Firehose sends packets over ethernet using the experimental
> ethertype 0x88b5. I've tried a few things to get data from the Firehose
> into Gnuradio, some have worked, others have not. Things that work:
>
> * Use tcpdump and filter on 0x88b5 and save to a file. Open and repackage
> each packet in the pcap dump as interleaved bytes of I&Q and save to a
> file. Read into Gnuradio.
>
> * Write a custom program using libpcap to filter on 0x88b5 on a selected
> interface, repackage the packets and write directly to a file. Read into
> Gnuradio.
>
> * Write a custom program using libpcap to filter on 0x88b5 on a selected
> interface, repackage the packets and PUB them using ZMQ. SUB to this PUB
> using a simple Python script and dump the message contents to a file. Read
> into Gnuradio. Both tcp and ipc PUB/SUB work equally well.
>
> Some things that do not work:
>
> * SUB to the ZMQ PUB/SUB using the Gnuradio ZMQ SUB Source block.
>
> * Write a custom program using libpcap to filter on 0x88b5 on a selected
> interface, repackage the packets and send them using UDP.
>
> The UDP approach doesn't work because too many packets get dropped and I
> have been unable to set sysctl values appropriately (on an M1 Mac) to avoid
> dropping too many packets.
>
> I'm not sure why the ZMQ approach does not work with Gnuradio. I've tried
> many simple flowgraphs to convert from vector to stream, ibyte to complex,
> you name it, and then dumping the data back out to a file using a File Sink
> (just to use existing software to check for data sanity). Data gets into
> Gnuradio, but it clearly loses something because constellation diagrams of
> the output data become blobs centered on the origin rather than pairs of
> point clouds offset from the origin as one would expect from the BPSK
> nature of the GNSS signals captured by the Firehose.
>
> I've come to the realization that it's probably best to write some sort of
> driver to get data straight from the Firehose into Gnuradio, but I have no
> idea where to start with this. Any ideas about how to fix my ZMQ approach
> or start writing a custom driver would be appreciated. There's a lot in
> here, so let me know if you would like code or flowgraph examples.
>
> Cheers,
> Walter
>


-- 
GDB has a 'break' feature; why doesn't it have 'fix' too?

Re: Looking to deprecate GRC_PREFS_PATH use in mingw64

[Chris Gorman]

Hi Marcus,

Thanks for the pointer.  I think my problem occurs because of mixing.
I used Ryan's patch to get rid of the need to use GRC_BLOCKS_PATH at
the same time 7350 was put in.  I mixed these two changes without
analyzing the logic and that was my mistake.  Since I need to use one
environment variable, I might as well use two.  I just need to figure
out how to make pacman spit out the requirement to set the environment
variables and I'll be happy with it.

Thanks again,

Chris


On Fri, Jun 21, 2024 at 2:21 PM Marcus Müller  wrote:
>
> Hi Chris,
>
> not sure if this is really what you're asking, but: Is this related to the 
> changes made in
>
> https://github.com/gnuradio/gnuradio/pull/7350 (or 7404 on maint-3.10)?
>
> Best regards,
> Marcus
>
> On 21.06.24 19:52, Chris Gorman wrote:
> > Hello All,
> >
> > I'm trying to get a build of gnuradio running under mingw64.  It is
> > installed and works mostly.  I've patched it with Ryan Volz's patch
> > for removing the global_blocks_path in favour of using prefix to set
> > the blocks path.  This works and I no longer need to set the
> > environment variable GRC_BLOCKS_PATH in my .bashrc to launch
> > gnuradio-companion.py.
> >
> > I'm wondering if there is an analogous solution to the use of
> > GRC_PREFS_PATH?  I currently have to set GRC_PREFS_PATH to the
> > grc.conf file in my .bashrc to have gnuradio-companion.py to save the
> > file on exit.  I don't have a problem with this, but it would be nice
> > to have it save the prefs path to a place in my home directory when it
> > exits without the use of the environment variable.
> >
> > I also noticed in my travels that the .config/gnuradio/grc.conf has
> > become a directory, I assume to facilitate the progression to using
> > the qt-gui.  Is the correct location for the grc.conf file
> > .config/gnuradio/grc.conf/grc.conf?
> >
> > I'm currently running main's 5c1edfe06 git hash as qwt-qt5 is at 6.3.0
> > under mingw64 and the 3.10.10.0 release requires that qwt-qt5 be less
> > than 6.3.0.  Perhaps I should be using a different branch?
> >
> > Thanks for your time.
> >
> > Chris
> >

Looking to deprecate GRC_PREFS_PATH use in mingw64

[Chris Gorman]

Hello All,

I'm trying to get a build of gnuradio running under mingw64.  It is
installed and works mostly.  I've patched it with Ryan Volz's patch
for removing the global_blocks_path in favour of using prefix to set
the blocks path.  This works and I no longer need to set the
environment variable GRC_BLOCKS_PATH in my .bashrc to launch
gnuradio-companion.py.

I'm wondering if there is an analogous solution to the use of
GRC_PREFS_PATH?  I currently have to set GRC_PREFS_PATH to the
grc.conf file in my .bashrc to have gnuradio-companion.py to save the
file on exit.  I don't have a problem with this, but it would be nice
to have it save the prefs path to a place in my home directory when it
exits without the use of the environment variable.

I also noticed in my travels that the .config/gnuradio/grc.conf has
become a directory, I assume to facilitate the progression to using
the qt-gui.  Is the correct location for the grc.conf file
.config/gnuradio/grc.conf/grc.conf?

I'm currently running main's 5c1edfe06 git hash as qwt-qt5 is at 6.3.0
under mingw64 and the 3.10.10.0 release requires that qwt-qt5 be less
than 6.3.0.  Perhaps I should be using a different branch?

Thanks for your time.

Chris

Re: Getting gnuradio to use zadig to connect to rtl-sdr in Windows

[Chris Gorman]

Hello again All,

Got it working.  I believe there is a deficiency in the soapysdr
module that was prebuilt in mingw64 and I can now use the rtl-sdr with
my gnuradio-osmocom package.

Thanks,

Chris

On Thu, Jun 13, 2024 at 7:29 PM Chris Gorman  wrote:
>
> Hello All,
>
> I have recently been playing with making a mingw w64 build of
> gnuradio.  I had some difficulties at the beginning getting it to
> work, but it now does.  I can connect to my pluto sdr and make a
> flowgraph of a radio and execute it.
>
> Unfortunately, the rtl-sdr is a different story.  It does work through
> zadig with radioconda, but it does not with my mingw w64 build.  If
> anyone has hints as to why it doesn't work and how to fix it, please
> let me know.
>
> Thanks in advance,
>
> Chris

Getting gnuradio to use zadig to connect to rtl-sdr in Windows

[Chris Gorman]

Hello All,

I have recently been playing with making a mingw w64 build of
gnuradio.  I had some difficulties at the beginning getting it to
work, but it now does.  I can connect to my pluto sdr and make a
flowgraph of a radio and execute it.

Unfortunately, the rtl-sdr is a different story.  It does work through
zadig with radioconda, but it does not with my mingw w64 build.  If
anyone has hints as to why it doesn't work and how to fix it, please
let me know.

Thanks in advance,

Chris

Re: gnuradio for windows built by mingw64

[Chris Gorman]

) from C:\msys64\mingw64\bin\libpython3.11.dll
#42 0x7ffe8faec3f0 in ?? () from C:\msys64\mingw64\bin\libpython3.11.dll
#43 0x7ffe8fbc3b1a in ?? () from C:\msys64\mingw64\bin\libpython3.11.dll
#44 0x7ffe8fb97e40 in ?? () from C:\msys64\mingw64\bin\libpython3.11.dll
#45 0x7ffe8fb2679d in ?? () from C:\msys64\mingw64\bin\libpython3.11.dll
#46 0x7ffe8fba52c9 in ?? () from C:\msys64\mingw64\bin\libpython3.11.dll
#47 0x7ffe8fb9da31 in ?? () from C:\msys64\mingw64\bin\libpython3.11.dll
#48 0x7ffe8faeb6c1 in ?? () from C:\msys64\mingw64\bin\libpython3.11.dll
#49 0x7ffe8faeb40e in ?? () from C:\msys64\mingw64\bin\libpython3.11.dll
#50 0x7ffe8faec3f0 in ?? () from C:\msys64\mingw64\bin\libpython3.11.dll
--Type  for more, q to quit, c to continue without paging--
#51 0x7ffe8fbc3b80 in ?? () from C:\msys64\mingw64\bin\libpython3.11.dll
#52 0x7ffe8fba2fc5 in ?? () from C:\msys64\mingw64\bin\libpython3.11.dll
#53 0x7ffe8fb9da31 in ?? () from C:\msys64\mingw64\bin\libpython3.11.dll
#54 0x7ffe8fa4d72e in ?? () from C:\msys64\mingw64\bin\libpython3.11.dll
#55 0x7ffe8fa633c3 in ?? () from C:\msys64\mingw64\bin\libpython3.11.dll
#56 0x7ffe8fa62e88 in ?? () from C:\msys64\mingw64\bin\libpython3.11.dll
#57 0x7ffe8fbd4385 in ?? () from C:\msys64\mingw64\bin\libpython3.11.dll
#58 0x7ffe8fbd478a in ?? () from C:\msys64\mingw64\bin\libpython3.11.dll
#59 0x7ffe8fbd287f in ?? () from C:\msys64\mingw64\bin\libpython3.11.dll
#60 0x7ffe8fbd4898 in ?? () from C:\msys64\mingw64\bin\libpython3.11.dll
#61 0x7ffe8fbeb159 in ?? () from C:\msys64\mingw64\bin\libpython3.11.dll
#62 0x7ffe8fa6a69a in ?? () from C:\msys64\mingw64\bin\libpython3.11.dll
#63 0x7ff6f99412f7 in ?? ()
#64 0x7ff6f9941406 in ?? ()
#65 0x7fff06cc257d in KERNEL32!BaseThreadInitThunk () from
C:\WINDOWS\System32\kernel32.dll
#66 0x7fff0784aa48 in ntdll!RtlUserThreadStart () from
C:\WINDOWS\SYSTEM32\ntdll.dll
#67 0x in ?? ()
(gdb) thread 2
[Switching to thread 2 (Thread 6076.0x1b48)]
#0  0x7fff0788f9d4 in ntdll!ZwWaitForSingleObject () from
C:\WINDOWS\SYSTEM32\ntdll.dll
(gdb) bt
#0  0x7fff0788f9d4 in ntdll!ZwWaitForSingleObject () from
C:\WINDOWS\SYSTEM32\ntdll.dll
#1  0x7fff0781a00e in ntdll!LdrGetDllHandleEx () from
C:\WINDOWS\SYSTEM32\ntdll.dll
#2  0x7fff078183a3 in ntdll!RtlLeaveCriticalSection () from
C:\WINDOWS\SYSTEM32\ntdll.dll
#3  0x7fff07863f6f in ntdll!LdrInitializeThunk () from
C:\WINDOWS\SYSTEM32\ntdll.dll
#4  0x7fff07863ea3 in ntdll!LdrInitializeThunk () from
C:\WINDOWS\SYSTEM32\ntdll.dll
#5  0x7fff07863dce in ntdll!LdrInitializeThunk () from
C:\WINDOWS\SYSTEM32\ntdll.dll
#6  0x in ?? ()
(gdb) thread 3
[Switching to thread 3 (Thread 6076.0x17a4)]
#0  0x7fff07893641 in ntdll!DbgBreakPoint () from
C:\WINDOWS\SYSTEM32\ntdll.dll
(gdb) bt
#0  0x7fff07893641 in ntdll!DbgBreakPoint () from
C:\WINDOWS\SYSTEM32\ntdll.dll
#1  0x7fff078c6f6e in ntdll!DbgUiRemoteBreakin () from
C:\WINDOWS\SYSTEM32\ntdll.dll
#2  0x7fff06cc257d in KERNEL32!BaseThreadInitThunk () from
C:\WINDOWS\System32\kernel32.dll
#3  0x7fff0784aa48 in ntdll!RtlUserThreadStart () from
C:\WINDOWS\SYSTEM32\ntdll.dll
#4  0x in ?? ()

What looks odd to me is the number of libpython3.11.dll instances I
get.  As I understand there are a lot of changes to mingw's python.
So is this where the hangup is?  I've tried to build a debug python,
but it failed out of the gate.  (I suspect due to a new compiler.)
When I run with radioconda's python I get ...

# cat import_gr_thread_radioconda_run.txt
(base) C:\Users\chris>gdb --args c:\programdata\radioconda\python.exe
-c "from gnuradio import gr;"
GNU gdb (GDB) 14.2
Copyright (C) 2023 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Type "show copying" and "show warranty" for details.
This GDB was configured as "x86_64-w64-mingw32".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<https://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
<http://www.gnu.org/software/gdb/documentation/>.

For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from c:\programdata\radioconda\python.exe...
(No debugging symbols found in c:\programdata\radioconda\python.exe)
(gdb) run
Starting program: c:\programdata\radioconda\python.exe -c "from
gnuradio import gr;"
[New Thread 7924.0x25b0]
[New Thread 7924.0x3044]
[New Thread 7924.0x2914]
[New Thread 7924.0x1b04]
[New Thread 7924.0x37a4]
[New Thread 7924.0x14c4]
[New Thread 7924.0x1070]
[New Thread 7

Re: Right spot for additional library for gnuradio-runtime

[Chris Gorman]

Hi Again,

Please disregard the first email.  I have found the CMakeLists.txt to
edit and it appears to have worked.  Sorry for the spam.

Chris

On Wed, May 22, 2024 at 9:11 PM Chris Gorman  wrote:
>
> Hello All,
>
> I'm currently trying to get gnuradio to build under mingw64.  I have
> run into a problem and would like some advice on how to fix it.
>
> When trying to link gnuradio-runtime.dll, I get an error due to a
> missing library in the link command.  It turns out I need to add
> -lwsock32 to the link command.  At the moment, I've done this by hand
> and the library links.
>
> I would like to know where to add -lwsock32 in the CMakeFile.txt so
> this can be automated.  I am more used to using a configure script
> where I could use LDFLAGS+=" -lwsock32" ./configure ...
>
> Any insights would be welcomed.
>
> Thanks in advance,
>
> Chris

Right spot for additional library for gnuradio-runtime

[Chris Gorman]

Hello All,

I'm currently trying to get gnuradio to build under mingw64.  I have
run into a problem and would like some advice on how to fix it.

When trying to link gnuradio-runtime.dll, I get an error due to a
missing library in the link command.  It turns out I need to add
-lwsock32 to the link command.  At the moment, I've done this by hand
and the library links.

I would like to know where to add -lwsock32 in the CMakeFile.txt so
this can be automated.  I am more used to using a configure script
where I could use LDFLAGS+=" -lwsock32" ./configure ...

Any insights would be welcomed.

Thanks in advance,

Chris

Trouble installing GNU RADIO 3.10

[Chris]

All,

I tried installing gnu radio today and was able to successfully install it
on Ubuntu 22.04, but when I open my apps I can't find the launcher. It is
installed and I see the files in my /usr directory.

Anyone else overcome this problem?
Thanks

Re: RFNOC tutorial

[Chris]

Apologies, I have posted in USRP mailing list thank you!

On Sat, Feb 10, 2024, 11:27 AM Brian Padalino  wrote:

> On Sat, Feb 10, 2024 at 2:14 PM Chris  wrote:
>
>> All, I am trying to offload some of my processing power onto my X310's
>> FPGA. I have the environment set up but still find myself confused on how
>> to build the out of tree block. I was able to add a block and I'm not sure
>> what to do next?
>>
>>
>> My design process is as follows: Matlab, get HDL code for DSP algorithms,
>> and deploy it on the RFNOC?
>>
>> My goal is to start out with implementing an adaptive filter on the FPGA.
>> When I looked in the FIR filter .v example I wasn't able to match how this
>> code works with the rfnoc environment. When I add my new oot block I have
>> the verilog code similar to the gain block example but not sure what else
>> needs to be changed besides dropping in the verilog code into the
>> newly_added_oot_block.v
>>
>> Is there any more documentation I can follow to make sure I am following
>> the right path?
>> Any pointers would be appreciated!
>>
>
> This is better asked over at the USRP users mailing list since it's USRP
> and RFNoC specific:
>
>   https://lists.ettus.com/list/usrp-users.lists.ettus.com
>
> I've got some pointers once you're signed up and ask over there.
>
> Brian
>
>>

RFNOC tutorial

[Chris]

 All, I am trying to offload some of my processing power onto my X310's
FPGA. I have the environment set up but still find myself confused on how
to build the out of tree block. I was able to add a block and I'm not sure
what to do next?


My design process is as follows: Matlab, get HDL code for DSP algorithms,
and deploy it on the RFNOC?

My goal is to start out with implementing an adaptive filter on the FPGA.
When I looked in the FIR filter .v example I wasn't able to match how this
code works with the rfnoc environment. When I add my new oot block I have
the verilog code similar to the gain block example but not sure what else
needs to be changed besides dropping in the verilog code into the
newly_added_oot_block.v

Is there any more documentation I can follow to make sure I am following
the right path?
Any pointers would be appreciated!

Best regards

Re: compiling gr-limesdr error

[Chris Gorman]

Hi Marcus,

I replied to Robin, but not the list, sorry.  One of the things I did in
the past (over 2 years ago) was to port gr-limesdr to gnuradio 3.9, that
work is available at https://github.com/chrisjohgorman/gr-limesdr .  I did
it to try to understand how to port something with gr_modtool and had
planned to buy a limesdr.  I believe this will still work with 3.10, but
without any hardware to test out, I'm not 100% sure.

Best regards,

Chris





On Sun, Aug 13, 2023 at 3:50 PM Marcus D. Leech 
wrote:

> On 13/08/2023 14:55, robin ivetic wrote:
>
> Hello,
>
> I try to install gr-limesdr on arch linux true pacman, but after gnuradio
> upgrade on 3.10.7, can't do that any more, and compiling gr-limesdr gives
> me this, and files are there
>
> CMake Warning (dev) at /lib/cmake/gnuradio/GrPython.cmake:21
> (find_package):
>  Policy CMP0148 is not set: The FindPythonInterp and FindPythonLibs modules
>  are removed.  Run "cmake --help-policy CMP0148" for policy details.  Use
>  the cmake_policy command to set the policy and suppress this warning.
>
> Call Stack (most recent call first):
>  /lib/cmake/gnuradio/GnuradioConfig.cmake:37 (include)
>  CMakeLists.txt:77 (find_package)
> This warning is for project developers.  Use -Wno-dev to suppress it.
>
> CMake Warning (dev) at /lib/cmake/gnuradio/GrPython.cmake:27
> (find_package):
>  Policy CMP0148 is not set: The FindPythonInterp and FindPythonLibs modules
>  are removed.  Run "cmake --help-policy CMP0148" for policy details.  Use
>  the cmake_policy command to set the policy and suppress this warning.
>
> Call Stack (most recent call first):
>  /lib/cmake/gnuradio/GnuradioConfig.cmake:37 (include)
>  CMakeLists.txt:77 (find_package)
> This warning is for project developers.  Use -Wno-dev to suppress it.
>
> -- Extracting version information from git describe...
> -- Found pybind11: //include (found version "2.11.1")
> -- Configuring LimeSuite C++ Libraries...
> CMake Error at /lib/cmake/LimeSuite/LimeSuiteConfig.cmake:49 (message):
>  cannot find LimeSuite includes in //include
> Call Stack (most recent call first):
>  CMakeLists.txt:135 (find_package)
>
> I have LimeSDR-USB, and when I'm using osmosdr sink block or Soapy LimeSDR
> sink below 30MHz, I'm geting this error, explained great here
> <https://discourse.myriadrf.org/t/mcu-error-3-sxr-tune-failed-on-limesdr-usb/5303>,and
> question is more for Myriadrf
>
> <https://discourse.myriadrf.org/t/mcu-error-3-sxr-tune-failed-on-limesdr-usb/5303>
> MCU error 3 (SXR tune failed) on LimeSDR USB
> <https://discourse.myriadrf.org/t/mcu-error-3-sxr-tune-failed-on-limesdr-usb/5303>
> Hi! I wanted to check LimeGPS project, but was unable to do this. Right
> now I’m facing calibration issues when running it: Opening and initializing
> device... Reference clock 30.72 MHz Sample rate: 250.0 Hz (Host) /
> 250.0 Hz (RF) Calibrating... Tx Calibration: MCU error 3 (SXR tune
> failed) Warning: Failed to calibrate device: Tx Calibration: MCU error 3
> (SXR tune failed) Setup TX stream... Creating GPS task... Using static
> location mode. xyz = 1335616.6, -4648136.6, 4144388.5 llh =...
> discourse.myriadrf.org
> **
>
>
> MCU error 3 (SXR tune failed) on LimeSDR USB
>
> but in my case, I will get error when I use more than 11.2e6 bandwith,
> that would be reason why I tried with gr-limesdr, but don't know how to
> bypass error.
> Or maybe someone can comment error to bypass error bellow 30MHz, because
> issue is here for a long time, or did someone tried emulate limeSDR USB
> with USRP 200
>
> Robin
>
> gr-limesdr hasn't been maintained in nearly 4 years.  It isn't compatible
> with GR 3.10.X
>
>
>

Re: Fw: Help Feedback with GNURadio Companion

[Chris Gorman]

Hi Tom,

Marcus outlined some good resources, but if you're like me and need a
little bit more hand holding in order to use gnuradio-companion to
build flowgraphs using blocks like the costas loop, etc., there is an
excellent course at Harvey Mudd College by Jason Gallicchio[1].  The
course is online and free to watch off youtube.  In the course, you
build a QPSK modem and GPS receiver, using gnuradio and a PlutoSDR and
an RTL-SDR.

I'm not finished the course yet, but I have enjoyed the material so
far.  Prof. Jason also has the flowgraphs online[2].

Best regards,
Chris

[1] https://gallicchio.github.io/learnSDR/
[2] https://github.com/gallicchio/learnSDR/



On Tue, Aug 8, 2023 at 8:31 AM Marcus Müller  wrote:
>
> Hi Tom,
>
> GNU Radio, the way it's currently written, does not allow you to build a loop 
> with sample
> streams – that's why you can't build a proper PLL from components in GRC :)
>
> But: there's ready-made PLLs for some use cases, namely for automatically 
> locking onto a
> carrier (and mixing down with it) [1], for detecting the frequency of a 
> carrier [2] and
> for detecting a carrier and generating a "clean" version of it [3].
>
> Now, these blocks do the PLL "block-internally", so if these PLLs don't 
> fulfill your phase
> locking purposes, then you'd need to implement that yourself (for example, in 
> a Python
> block, or in C++).
>
> So, maybe we should talk about what you need your PLL for? It's quite 
> possible we already
> have something like that ready-made or easy to modify.
>
> Best,
> Marcus
>
> [1] https://wiki.gnuradio.org/index.php?title=PLL_Carrier_Tracking
> [2] https://wiki.gnuradio.org/index.php?title=PLL_Frequency_Detector
> [3] https://wiki.gnuradio.org/index.php?title=PLL_Carrier_Regeneration
>
> On 08.08.23 13:12, tom sutherland wrote:
> > Is there a tutorial, example or guide to creating feedback loop (PLL, 
> > Costas, etc...)
> > using Companion/python?
> > Thanks...Tom
>

Will the built-in Equalization blocks work with CPM modulation (like GMSK)?

[Chris Devries]

I haven't been able to find an answer in any examples to this:  Is it possible 
to use the Linear or DFE equalizer with GMSK modulation?  I haven't been able 
to find an example and I'm not sure if you can even define a constellation for 
CPM modulation using the "variable constellation" option?

Re: update for gr-radar to gnuradio 3.10

[Chris Gorman]

Hello Again,


I have finally finished porting and testing (that I can) of my port of
gr-radar from kit-cel sources.  Unfortunately, I didn't notice that
this had already been done by Ryan Volz.  Thanks to Ryan's sources, I
debugged my qa python scripts and all but one runs properly now.

I plan on leaving this tree and only using it as reference and doing
my development if any on Ryan's tree.  No point on duplicating
efforts.  I am not sure if it is possible, but I would like to try
building an echotimer for the pluto sdr and then adding this to the
gr-radar tree.  (This may be beyond my programming capabilities.)
Anyone with pointers on how to best do this, please email me.

Best regards,

Chris






On Sun, Jul 30, 2023 at 2:52 PM Chris Gorman  wrote:
>
> Hello Again,
>
> Folks might want to consider this port alpha quality.  I have already
> found a few bugs.  (I've done something wrong with pybind11.)  I will
> repost when I have a quasi working port.
>
> Sorry for the distraction.
>
> Chris
>
> On Sun, Jul 30, 2023 at 1:47 PM Chris Gorman  wrote:
> >
> > Hello All,
> >
> > I have just finished a port of https://github.com/kit-cel/gr-radar
> > from gnuradio 3.8 to gnuradio 3.10.  It is available on my github page
> > https://github.com/chrisjohgorman/gr-radar .  I have only done the
> > bare minimum to update it, that is getting it to build.  I followed
> > the 
> > https://wiki.gnuradio.org/index.php/GNU_Radio_3.9_OOT_Module_Porting_Guide
> > , but it is quite possible I've made mistakes.  I welcome patches/pull
> > requests to fix the warning messages, as well as fixes for
> > functionality for those who are interested.  I want to thank the
> > original authors for making this package and all those who have
> > contributed to it.
> >
> > In the event that I have duplicated someone else's efforts in porting
> > this to 3.10, (ie. it has already been done), please let me know.
> >
> > Best regards,
> >
> > Chris

Re: update for gr-radar to gnuradio 3.10

[Chris Gorman]

Hello Again,

Folks might want to consider this port alpha quality.  I have already
found a few bugs.  (I've done something wrong with pybind11.)  I will
repost when I have a quasi working port.

Sorry for the distraction.

Chris

On Sun, Jul 30, 2023 at 1:47 PM Chris Gorman  wrote:
>
> Hello All,
>
> I have just finished a port of https://github.com/kit-cel/gr-radar
> from gnuradio 3.8 to gnuradio 3.10.  It is available on my github page
> https://github.com/chrisjohgorman/gr-radar .  I have only done the
> bare minimum to update it, that is getting it to build.  I followed
> the https://wiki.gnuradio.org/index.php/GNU_Radio_3.9_OOT_Module_Porting_Guide
> , but it is quite possible I've made mistakes.  I welcome patches/pull
> requests to fix the warning messages, as well as fixes for
> functionality for those who are interested.  I want to thank the
> original authors for making this package and all those who have
> contributed to it.
>
> In the event that I have duplicated someone else's efforts in porting
> this to 3.10, (ie. it has already been done), please let me know.
>
> Best regards,
>
> Chris

update for gr-radar to gnuradio 3.10

[Chris Gorman]

Hello All,

I have just finished a port of https://github.com/kit-cel/gr-radar
from gnuradio 3.8 to gnuradio 3.10.  It is available on my github page
https://github.com/chrisjohgorman/gr-radar .  I have only done the
bare minimum to update it, that is getting it to build.  I followed
the https://wiki.gnuradio.org/index.php/GNU_Radio_3.9_OOT_Module_Porting_Guide
, but it is quite possible I've made mistakes.  I welcome patches/pull
requests to fix the warning messages, as well as fixes for
functionality for those who are interested.  I want to thank the
original authors for making this package and all those who have
contributed to it.

In the event that I have duplicated someone else's efforts in porting
this to 3.10, (ie. it has already been done), please let me know.

Best regards,

Chris

Having some basic trouble generating BER for GMSK

[Chris Devries]

It seems that the stream will slip and get out of sync with the slightest bit 
of noise added.  I've searched for a solution but how can one do a basic error 
rate simulation which seems that it would require the 2 streams to be some how 
synchronized.  I'm fairly new to gnuradio so not sure if there is a mechanism 
for synchronizing or if I should be doing something else to test my output 
stream to look for bit errors.

Or am I going about this the wrong way?  My goal is to build a GMSK receiver 
and test it will an ideal source and channel model, and then use it in a live 
scenario.

Chris


gmsk_demod_tb.grc
Description: gmsk_demod_tb.grc

Re: Also bothered

[Chris Vine]

Read it again and you will see the posting was a spoof, artificially
mashed up by a random expression generator from a radio/electronics
related expression list.  Either ignore him or blacklist him from the
mailing list.

---
On Mon, 6 Feb 2023 16:00:45 +0100
Marcus Müller  wrote:
> Dear Matt,
> 
> this is just a quick reminder that this is the GNU Radio mailing list – 
> we're pretty open about the topics we discuss here, but your last three 
> emails were a bit far off.
> 
> Since (I think) you're new in this community: In case you wonder what 
> GNU Radio is exactly, there's a really nice introduction,
> https://wiki.gnuradio.org/index.php?title=What_Is_GNU_Radio
> 
> Best regards,
> Marcus
> 
> On 2/6/23 09:28, Matt Young wrote:
> > In ham radio we have twenty manufacturer all writing and producing 
> > their own LCD screens and menus. A nightmare.s Thy all started with 
> > DSP function then suddenly loads of investments into screens.
> >
> > Just add a USB port to the machines and plug in a chromebook, which 
> > costs 155.  Three hundred dollars save at the shack, money spent on 
> > pre and post analog for dealing with this chaotic atmosphere.
> >
> > The DSP is simple, we need in and out DACs at 8 mHz, 16 bit. We need 
> > ar least 80 Mflops of fixed point 32 bit signal 'taps'. Add in a 
> > separate center frequency LO on output.  Opens the market big time.  
> > Floating point does no good, if you did you Z transforms, 
> > everything should be scaled.
> > Your source code really is set of pure linear discrete inductance, 
> > capacitance and transconductance.  There are no parasitics.  We can 
> > generate assembly from Spice, then each DSP makerwrits thor own linker 
> > from Spice to DSP..
> >
> > Code never changes across bands.  The local oscillator mixes in the 
> > high precision interface to the antenna.  We really want the isolation 
> > of the digital from the horrors of atmospheric RF static.

Re: gnuradio permission problems?

[Chris Vine]

On Wed, 18 Jan 2023 13:33:08 +
Chris Vine  wrote:
> On Wed, 18 Jan 2023 13:03:53 +
> "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.
> 
> If your "evaluation kit antenna" comprises a hardware device which has
> a linux driver supplied for it (or uses a generic USB interface for
> which the linux kernel already supplies a driver), so that it is
> represented by a device file in the /dev directory, this looks more
> like a permissions issue concerning the device file rather than with
> gnuradio itself.  If that is the case you may need to write a udev rule
> for your hardware (http://www.reactivated.net/writing_udev_rules.html).
> 
> Having said that, if you have a linux driver for your hardware you
> would have expected it to come with an appropriate udev rules file in
> the first place.

As an addendum, note that if your device driver does already come with a
udev rules file, it may be just a matter of you making yourself a
member of a relevant group.  Examining whether you have a rules file
for your device, which may variously be installed
in /lib/udev/rules.d, /usr/lib/udev/rules.d or /etc/udev/rules.d (I
don't use Ubuntu), should tell you more.

Re: gnuradio permission problems?

[Chris Vine]

On Wed, 18 Jan 2023 13:03:53 +
"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.

If your "evaluation kit antenna" comprises a hardware device which has
a linux driver supplied for it (or uses a generic USB interface for
which the linux kernel already supplies a driver), so that it is
represented by a device file in the /dev directory, this looks more
like a permissions issue concerning the device file rather than with
gnuradio itself.  If that is the case you may need to write a udev rule
for your hardware (http://www.reactivated.net/writing_udev_rules.html).

Having said that, if you have a linux driver for your hardware you
would have expected it to come with an appropriate udev rules file in
the first place.

Re: S Meter

[Chris Vine]

On Fri, 9 Sep 2022 11:36:53 +0100
"R.P. Merrell"  wrote:
> Hi all
> 
> I am looking for a way to implement a display of the signal strength being
> received and have tried various methods using the available blocks in my GNU
> 3.10 installation to achieve without success, is their anyone out there who
> has successfully done that who could point me in the right direction,
> please.
> 
> Many thanks
> 
> Richard G4GUJ.

I have used a Qt GUI Number Sink block for this purpose although it has
the rather disconcerting property of providing textual output as well
as a sliding scale, which can't be switched off.  You obviously need to
take the block's input before your AGC block (if any) and because it
comprises a linear display use logarithmic compression and/or some other
form of compression on that input in order to get meaningful results as
a signal strength monitor.

Re: [VOLK] Release 2.5.2

[Chris Vine]

On Fri, 9 Sep 2022 11:35:26 +0200
Johannes Demel  wrote:

> Hi Chris,
> 
> The issue arises in an odd combination.
> 
> 1. you installed VOLK (and cpu_features) to your custom prefix before
> 2. your custom prefix is currently NOT sourced
> 3. you try to re-compile with `CMAKE_INSTALL_PREFIX=`
> 
> What I've learned so far:
> 1. It requires special configuration in a submodule to disable installation.
> 2. CMake tries to be smart and the linker does smth different.
> 
> A more complete analysis and a subsequent fix may be nice.
> 
> Cheers
> Johannes
> 
> On 08.09.22 23:40, Chris Vine wrote:
> > On Sun, 4 Sep 2022 18:41:18 +0200
> > Johannes Demel  wrote:
> >> Hi everyone!
> >>
> >> We have a new VOLK release! We are happy to announce VOLK v2.5.2! We
> >> want to thank all contributors. This release wouldn't have been possible
> >> without them.
> > 
> > Something seems to be amiss when compiling against the internal version
> > of cpu_features:
> > 
> >...
> >[ 88%] Built target volk_obj
> >[ 89%] Linking C shared library libvolk.so
> >/usr/bin/ld: cannot find -lcpu_features: No such file or directory
> >collect2: error: ld returned 1 exit status
> >make[2]: *** [lib/CMakeFiles/volk.dir/build.make:168: 
> > lib/libvolk.so.2.5.2] Error 1
> >make[1]: *** [CMakeFiles/Makefile2:239: lib/CMakeFiles/volk.dir/all] 
> > Error 2
> >make: *** [Makefile:146: all] Error 2

Yes I have volk (and gnuradio) installed in a custom prefix.  I think
you have identified at least part of the problem: volk-2.5.2 compiles
correctly if I uninstall the old version of volk (volk-2.5.0) _before_
compiling the new one.

The good news is that this seems to be caused by a fairly recent change
in volk's build system: volk-2.5.0 compiles fine with a previous version
installed - I have just done some test compiles and the build problem
seems to have first arisen with volk-2.5.1.

Re: [VOLK] Release 2.5.2

[Chris Vine]

On Sun, 4 Sep 2022 18:41:18 +0200
Johannes Demel  wrote:
> Hi everyone!
> 
> We have a new VOLK release! We are happy to announce VOLK v2.5.2! We 
> want to thank all contributors. This release wouldn't have been possible 
> without them.

Something seems to be amiss when compiling against the internal version
of cpu_features:

  ...
  [ 88%] Built target volk_obj
  [ 89%] Linking C shared library libvolk.so
  /usr/bin/ld: cannot find -lcpu_features: No such file or directory
  collect2: error: ld returned 1 exit status
  make[2]: *** [lib/CMakeFiles/volk.dir/build.make:168: lib/libvolk.so.2.5.2] 
Error 1
  make[1]: *** [CMakeFiles/Makefile2:239: lib/CMakeFiles/volk.dir/all] Error 2
  make: *** [Makefile:146: all] Error 2

Re: Time Partitioned FFT

[Chris Kuethe]

Why?

How would this work on a 2-core ARM SBC vs some fancy 32-core workstation?
What about the incoming sample rate? Are you getting 2Msps from an RTLSDR,
or 200Msps from a very powerful instrument?
And how many points is your FFT?
What are you doing with the output of the FFT?
1000ms / 40ms interval = up to 25 parallel FFT threads... do you have the
memory bandwidth to support this?

In other words: what problem are you trying to solve?

On Fri, Aug 5, 2022 at 6:22 PM Elmore's  wrote:

> Is it possible to use GNU radio to perform time partitioning of FFTs?
>
> I would like to be able to start an FFT and run it for 160 ms. A second
> one would start 40 ms after the start of the first and run for 160 ms. A
> third would start 40 ms after the start of the second. This process would
> continue for any number of FFTs.
>
> I hope I have correctly asked the question. I’m not even sure how you
> would limit the running time of the FFT.
>
>
> 
>  Virus-free.
> www.avg.com
> 
> <#m_-4793840578475885421_DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>
>


-- 
GDB has a 'break' feature; why doesn't it have 'fix' too?

Re: Use /dev/swradioN (v4l2 api) as source

[Chris Vine]

On Mon, 13 Jun 2022 21:26:34 +0200
Stefan Oltmanns  wrote:
> Hello,
> 
> is there any way to use devices exposed as /dev/swradioN by the v4l2
> Linux kernel API with GNURadio directly?
> 
> At the moment there are only two in-tree kernel drivers, one for the
> RTL2832U and the other for the Mirics MSi2500. For the RTL2832U
> librtlsdr seems to be the better option,b as it offers more features to
> control the device, but libmirisdr seems to unmaintained and not stable
> (at least for me), support has been removed from OsmoSDR years ago.
> I do have such a Dongle and with the kernel driver it seems to work just
> fine.
> 
> I also found an out-of-tree driver for CX2388x-based TV cards, so a V4L2
> source block could be very useful. Is there any specific reason, why
> such a source block doesn't exist yet?
> Or is it just that nobody needed it and therefore no one bothered
> writing one?

Not to answer your question about kernel drivers, but the SDRPlay
RSP1/1A devices use the Mirics MSi2500 and MSi001 chipset so it may be
worth trying out the SDRPlay-2.13.1 binary blob with SoapySDRPlay2 on
your device (or possibly the SDRPlay-3.* binary blob with
SoapySDRPlay3).  They work well for me using the gr-soapy built-in
gnuradio block, but I use SDRPlay-branded kit for which the blobs were
designed.

The gr-osmosdr block will also work with it provided you use
gr-osmosdr's soapy backend, and not the native sdrplay backend which is
completely broken.

Re: Realise a bandwidth segmentizer

[Chris Vine]

On Wed, 16 Mar 2022 08:34:55 +
e heuchamps  wrote:
[snip]
> P. S.: could you give me possible pointers to good references to
> learn the concepts quicker ? I already stumbled across the wonderful
> PySDR blog, and was wondering if there were
> other similar/complementary online ressources ?

For really basic stuff, the videos here are pretty good:
https://greatscottgadgets.com/sdr/ .  Although centred on the HackRF
One, you can follow the principles with pretty much any SDR device
(note though that many consumer-level devices have a lower maximum
sampling rate than does the HackRF One).

Re: [VOLK] Release 2.5.1

[Chris Vine]

On Sat, 12 Feb 2022 11:40:26 +0100
Johannes Demel  wrote:
> Hi everyone!
> 
> You can find the news at https://www.libvolk.org/release-v251.html as well.
> 
> We have a new VOLK release! We are happy to announce VOLK v2.5.1! We 
> want to thank all contributors. This release wouldn't have been possible 
> without them.

Hi,

Is this ABI compatible with volk-2.5.0 (or put another way, if I
upgrade from volk-2.5.0 will I need to recompile gnuradio)?

Chris

Re: reading rfm69 packet transmission

[Chris Gorman]

Hello again,

Just a small update in case someone wants to try this out.  I have two
patches to apply to get this working for me.  The first,
RFM69-Library-AVR-syncword.patch, is to apply against
fermitron2048/packetdemod and the second, RFM69.patch, is to apply
against nayem-cosmic/RFM69-Library-AVR.  My thanks to both
nayem-cosmic and fermitron2048 for their work writing these pieces of
software.

Take care.

Chris

On Thu, Feb 3, 2022 at 12:40 PM Chris Gorman  wrote:
>
> Hello All,
>
> I have two rfm69 boards [1] connected to two avrs and they are sending
> messages to each other over the airway.  Once I got this working I
> thought it would be fun to inspect the messages being sent with my
> rtl_sdr.  I can confirm the message is being sent over serial on the
> receiver.
>
> I went searching on the internet for a way to decode the transmission
> and found some scripts to use gnuradio to do packetdemod on rfm69
> boards [2].  The problem with this setup is it requires me to modify
> the code to the rfm69 [3] to prevent whitening.  My software to run
> the avrs isn't the same as the author of the packetdemod's and I can't
> apply his patch.  I have looked at the code to see if I am using
> whitening, but as far as I can tell I am not.  Regardless when I run
> the packetdemod script, I get 'Invalid packets" instead of my message.
>
> In my inbox this morning I found an email with a reference to packet
> communications with gnuradio [4] and am wondering if I should be using
> this method to decode the transmission between the two rfm69's?  I
> will try it out anyway as it seems interesting, but is this the
> correct direction to analyze the transmission between two boards like
> the rfm69s?
>
> Thanks in advance,
>
> Chris
>
> [1] https://www.sparkfun.com/products/12775
> [2] https://github.com/fermitron2048/packetdemod
> [3] https://github.com/nayem-cosmic/RFM69-Library-AVR
> [4] https://wiki.gnuradio.org/index.php?title=Packet_Communications
diff --git a/packetdemod.py b/packetdemod.py
index 1825c64..bdaf828 100644
--- a/packetdemod.py
+++ b/packetdemod.py
@@ -126,7 +126,7 @@ def parsepacket(bits):
 invalid_packets += 1
 return
 syncword = (ord(bytes[0])<<8) + ord(bytes[1])
-if(syncword != 0x2d21):
+if(syncword != 0x2dd4):
 print("Invalid packet")
 invalid_packets += 1
 return
@@ -192,7 +192,7 @@ def decode(values = []):
 
 # Align to sync word for beginning of packet
 for i in range(1,50):
-syncword = [0,0,1,0,1,1,0,1,0,0,1,0,0,0,0,1]
+syncword = [0,0,1,0,1,1,0,1,1,1,0,1,0,1,0,0]
 tmpbits = bits[i:]
 if(cmp(syncword,tmpbits[:16].tolist()) == 0):
 bits = bits[i:]
diff --git a/radio.py b/radio.py
index df67922..25e366f 100644
--- a/radio.py
+++ b/radio.py
@@ -81,7 +81,7 @@ def parsepacket(bits):
 invalid_packets += 1
 return
 syncword = (ord(bytes[0])<<8) + ord(bytes[1])
-if(syncword != 0x2d21):
+if(syncword != 0x2dd4):
 print("Invalid packet")
 invalid_packets += 1
 return
@@ -147,7 +147,7 @@ def decode(values = []):
 
 # Align to sync word for beginning of packet
 for i in range(1,50):
-syncword = [0,0,1,0,1,1,0,1,0,0,1,0,0,0,0,1]
+syncword = [0,0,1,0,1,1,0,1,1,1,0,1,0,1,0,0]
 tmpbits = bits[i:]
 if(cmp(syncword,tmpbits[:16].tolist()) == 0):
 bits = bits[i:]
diff --git a/RFM69.c b/RFM69.c
index 1a52fc3..83ba45f 100644
--- a/RFM69.c
+++ b/RFM69.c
@@ -59,11 +59,11 @@ void rfm69_init(uint16_t freqBand, uint8_t nodeID, uint8_t networkID)
 const uint8_t CONFIG[][2] =
 {
 /* 0x01 */ { REG_OPMODE, RF_OPMODE_SEQUENCER_ON | RF_OPMODE_LISTEN_OFF | RF_OPMODE_STANDBY },
-/* 0x02 */ { REG_DATAMODUL, RF_DATAMODUL_DATAMODE_PACKET | RF_DATAMODUL_MODULATIONTYPE_FSK | RF_DATAMODUL_MODULATIONSHAPING_00 }, // no shaping
-/* 0x03 */ { REG_BITRATEMSB, RF_BITRATEMSB_5}, // default: 4.8 KBPS
-/* 0x04 */ { REG_BITRATELSB, RF_BITRATELSB_5},
-/* 0x05 */ { REG_FDEVMSB, RF_FDEVMSB_5}, // default: 5KHz, (FDEV + BitRate / 2 <= 500KHz)
-/* 0x06 */ { REG_FDEVLSB, RF_FDEVLSB_5},
+/* 0x02 */ { REG_DATAMODUL, RF_DATAMODUL_DATAMODE_PACKET | RF_DATAMODUL_MODULATIONTYPE_OOK | RF_DATAMODUL_MODULATIONSHAPING_00 }, // no shaping
+/* 0x03 */ { REG_BITRATEMSB, RF_BITRATEMSB_1200}, // default: 4.8 KBPS
+/* 0x04 */ { REG_BITRATELSB, RF_BITRATELSB_1200},
+/* 0x05 */ { REG_FDEVMSB, RF_FDEVMSB_5000}, // default: 5KHz, (FDEV + BitRate / 2 <= 500KHz)
+/* 0x06 */ { REG_FDEVLSB, RF_FDEVLSB_5000},
 
 //* 0x07 */ { REG_FRFMSB, RF_FRFMSB_433},
 //* 0x08 */ { REG_FRFMID, RF_FRFMID_433},

reading rfm69 packet transmission

[Chris Gorman]

Hello All,

I have two rfm69 boards [1] connected to two avrs and they are sending
messages to each other over the airway.  Once I got this working I
thought it would be fun to inspect the messages being sent with my
rtl_sdr.  I can confirm the message is being sent over serial on the
receiver.

I went searching on the internet for a way to decode the transmission
and found some scripts to use gnuradio to do packetdemod on rfm69
boards [2].  The problem with this setup is it requires me to modify
the code to the rfm69 [3] to prevent whitening.  My software to run
the avrs isn't the same as the author of the packetdemod's and I can't
apply his patch.  I have looked at the code to see if I am using
whitening, but as far as I can tell I am not.  Regardless when I run
the packetdemod script, I get 'Invalid packets" instead of my message.

In my inbox this morning I found an email with a reference to packet
communications with gnuradio [4] and am wondering if I should be using
this method to decode the transmission between the two rfm69's?  I
will try it out anyway as it seems interesting, but is this the
correct direction to analyze the transmission between two boards like
the rfm69s?

Thanks in advance,

Chris

[1] https://www.sparkfun.com/products/12775
[2] https://github.com/fermitron2048/packetdemod
[3] https://github.com/nayem-cosmic/RFM69-Library-AVR
[4] https://wiki.gnuradio.org/index.php?title=Packet_Communications

Re: Releases v3.8.4.0 and v3.9.3.0

[Chris Vine]

On Sat, 20 Nov 2021 13:54:58 -0500 (EST)
Franco VENTURI  wrote:
> Glen,
> using the 'gr-soapy' source and the latest SoapySDRPlay module 
> (https://github.com/pothosware/SoapySDRPlay3), you should be able to control 
> biasT by using this argument:
> 
>   biasT_ctrl=true
> 
> (see here for some more details here: 
> https://github.com/pothosware/SoapySDRPlay3/issues/21)

I don't have gnuradio-3.8 installed any more, but I do still have
the .grc gr-soapy YAML file for my RSP1A which I used then, and that
definitely has a properties configuration entry for the soapy block
which in my case is "sdrplay_biastee: 'False'", and (as the OP is also
interested in the MF/VHF notches), similar entries for
"sdrplay_dabnotch" and "sdrplay_rfnotch".

These are not present in the YAML file for the built-in soapy block
provided by gnuradio-3.9.1.0 and later.  To provide a RF notch with that
one I had to supply a device argument of "rfnotch_ctrl=true", along the
lines of the one you have suggested above for bias tee.

So how you do it seems to depend on which version of gnuradio and/or
soapy block you are using.

Re: Releases v3.8.4.0 and v3.9.3.0

[Chris Vine]

On Sat, 20 Nov 2021 13:12:02 -0500
Glen Langston  wrote:
> Hi Chris,> 
> Thanks for  your reply.
> 
> After countless hours of messing around, I partially have 
> SDRPlay supported on a Raspberry PI 4 with gnuradio 3.8.2
> 
> Within gnuradio and osmosdr source blocks, I have SDRPlay data streaming, but 
> I’ve not been
> able to turn the bias-tee on or make any sense of the gain settings.
> 
> With gr-soapy source
> 
> I’ve got trouble getting the stream of data to flow.
> 
> with  SoapySDRUtil —find  I do find the device with reasonable values
> 
> ##
> ## Soapy SDR -- the SDR abstraction library ##
> ##
> 
> Found device 0
>   driver = sdrplay
>   label = SDRplay Dev0 RSP1A 190316E696
>   serial = 190316E696
> 
> So, my question is:
> 
> Do you (or anyone) have examples of the values to put in
> either of the source blocks to control the bias-tee 
> gains and notch filters?

You cannot set notch filters on the RSP1A using gr-osmosdr, and as far
as I recall (I no longer have gnuradio-3.8 installed) you cannot set
bias tee either.  There is also a problem with manaul gain control in
the gr-osmosdr block with gnuradio-companion (the rf gain cannot be set
properly manually but you can control if gain manually); but curiously
manual gain controls work OK when using gr-osmosdr with gqrx, and
gnuradio-companion works OK with gr-osmosdr with gain mode set to
automatic.

That is one of the reasons why I recommended that you should use the
gr-soapy block.  With that you can set the notch filters, bias tee,
manual gain and many other things.  The gr-soapy block is much superior
to the gr-osmosdr one, and is built-in with gnuradio-3.9.  gr-osmosdr is
virtually unsupported now and should really only be used with devices
for which soapySDR is not an option, or if you have to use gqrx.  I
would also use gnuradio-3.9 rather than gnuradio-3.8, if you can.

If you want to control gain manually then SoapySDRUtil --probe will
tell you more about values.[1]

In summary, for grqx, use gr-osmosdr with the soapy backend with the
device string "soapy=0,driver=sdrplay".  Otherwise use gr-soapy, which
is much superior.

Chris

[1]  Note that the gr-soapy block with gnuradio-3.8 has separate
manual controls for rf gain and if gain.  The built-in soapy block for
gnuradio-3.9 has a single control for both.

Re: Problem with GNU Radio Wiki

[Chris Kuethe]

API Rate limits or missing API client identification  connecting to
wikipedia? https://en.wikipedia.org/api/rest_v1/#/Math

Maybe missing restbase component on the gnuradio wiki server?
https://www.mediawiki.org/wiki/RESTBase

Dunno, it's been donkeys since I last touched MW.

On Sun, Nov 7, 2021 at 2:08 PM Jeff Long  wrote:

> Thanks for the report. Yes, this is a known issue. I'm not sure anyone has
> figured out what needs to be done yet.
>
> On Sun, Nov 7, 2021 at 4:39 PM Ian Bennett  wrote:
>
>> Good Morning,
>> I'm working my way through the tutorials and have come across a
>> problem when viewing
>> https://wiki.gnuradio.org/index.php/IQ_Complex_Tutorial
>> The message "Failed to parse (MathML with SVG or PNG fallback
>> (recommended for modern browsers and
>> accessibility tools): Invalid response ("Math extension cannot connect to
>> Restbase.") from server
>> "https://en.wikipedia.org/api/rest_v1/":):" is littered throughout the
>> page in bold, red coloured text.
>> Since I do see images, I assume they are what the message is
>> referring to but I am not sure. There
>> could be information I'm not seeing.
>> This happens on my Ubuntu 18.0.4 LTS installation with firefox
>> 89.0 and Chrome 95.0.4638.69.
>> It also happens on a Ubuntu 20.0.4 LTS VM using firefox 94.0.
>> Googling indicates a problem on the mediawiki server.
>> Curious as to whether anyone else is seeing this problem.
>> Regards,
>>
>> Ian
>>
>>

-- 
GDB has a 'break' feature; why doesn't it have 'fix' too?

Re: Release v3.9.4.0

[Chris Vine]

On Sun, 31 Oct 2021 10:48:27 -0400
Jeff Long  wrote:
> GNU Radio v3.9.4.0 has been released
> https://github.com/gnuradio/gnuradio/releases/tag/v3.9.4.0
> 
> This release is appearing a little early because of a couple of regressions
> in v3.9.3.0. While we were at it, we pulled in a few more helpful commits
> from the master branch.
> 
> This is an API compatible update to GNU Radio 3.9. Code written for 3.9.X
> versions should compile and link without modification. The ABI is not
> guaranteed to be compatible, so a rebuild of OOT modules may be necessary.
> 
> The next v3.8 and v3.9 releases are expected in Dec/Jan.

The release documentation for gnuradio-3.9.4.0 says that it now
supports GRC with Fedora-35, but doesn't that use python-3.10?  At
any rate, although I don't use Fedora-35, I had to apply the patch
below to get any gnuradio-companion flowchart using a range widget
to work with python-3.10.0.

There seem to be type errors in range.py which are detected by
python-3.10 but not by earlier versions.  The patch fixes it for all
my uses but I can't guarantee that it covers every possible dynamic
code path.

Chris

--- gnuradio-3.9.4.0/gr-qtgui/python/qtgui/range.py.cmakein.orig
2021-10-31 14:28:27.0 +
+++ gnuradio-3.9.4.0/gr-qtgui/python/qtgui/range.py.cmakein 2021-11-01 
12:27:00.362487046 +
@@ -131,7 +131,7 @@
 self.rangeType = rangeType
 
 # Setup the dial
-self.setRange(0, ranges.nsteps-1)
+self.setRange(0, int(ranges.nsteps-1))
 self.setSingleStep(1)
 self.setNotchesVisible(True)
 self.range = ranges
@@ -158,7 +158,7 @@
 
 # Setup the slider
 #self.setFocusPolicy(QtCore.Qt.NoFocus)
-self.setRange(0, ranges.nsteps - 1)
+self.setRange(0, int(ranges.nsteps - 1))
 self.setTickPosition(2)
 self.setSingleStep(1)
 self.range = ranges
@@ -191,7 +191,7 @@
 new = self.minimum() + ((self.maximum()-self.minimum()) * 
event.x()) / self.width()
 else:
 new = self.minimum() + ((self.maximum()-self.minimum()) * 
event.y()) / self.height()
-self.setValue(new)
+self.setValue(int(new))
 event.accept()
 # Use repaint rather than calling the super mousePressEvent.
 # Calling super causes issue where slider jumps to wrong value.
@@ -202,7 +202,7 @@
 new = self.minimum() + ((self.maximum()-self.minimum()) * 
event.x()) / self.width()
 else:
 new = self.minimum() + ((self.maximum()-self.minimum()) * 
event.y()) / self.height()
-self.setValue(new)
+self.setValue(int(new))
 event.accept()
 QtWidgets.QSlider.repaint(self)
 

Re: SoapySDR Question

[Chris Vine]

On Thu, 30 Sep 2021 22:22:38 -0400
Glen Langston  wrote:
> Hi Jeff,
> 
> Thanks for your quick reply.
> 
> I was having trouble figuring out what to put in the Soapy Source block.   
> Do you have a flow graph example?

With gnuradio-3.8 and the gr-soapy block I had this for
gnuradio-companion, but it's not going to help a great deal as a number
of the settings depend on variables.  The sample rate was 2e6/sec, and
bandwidth 600e3 Hz

- name: soapy_source_0
  id: soapy_source
  parameters:
affinity: ''
agc0: 'False'
agc1: 'False'
alias: ''
amp_gain0: '0'
ant0: RX
ant1: ''
args: ''
balance0: '0'
balance1: '0'
bw0: 600e3
bw1: '0'
center_freq0: mhz * 1e6
center_freq1: '0'
clock_rate: '0'
clock_source: ''
comment: ''
correction0: '0'
correction1: '0'
dc_offset0: '0'
dc_offset1: '0'
dc_removal0: 'True'
dc_removal1: 'True'
dev: sdrplay
devname: sdrplay
gain_mode0: Specific
gain_mode1: Overall
ifgr_gain: if_gain
lna_gain0: '0'
lna_gain1: '0'
maxoutbuf: '0'
minoutbuf: '0'
mix_gain0: '0'
nchan: '1'
nco_freq0: '0'
nco_freq1: '0'
overall_gain0: if_gain
overall_gain1: '0'
pga_gain0: '0'
pga_gain1: '0'
rfgr_gain: rf_gain
rxvga1_gain: '5'
rxvga2_gain: '0'
samp_rate: samp_rate
sdrplay_agc_setpoint: '-30'
sdrplay_biastee: 'False'
sdrplay_dabnotch: 'False'
sdrplay_if_mode: Zero-IF
sdrplay_rfnotch: 'True'
settings0: ''
settings1: ''
stream_args: ''
tia_gain0: '0'
tia_gain1: '0'
tune_args0: ''
tune_args1: ''
tuner_gain0: '0'
type: fc32
vga_gain0: '0'
  states:
bus_sink: false
bus_source: false
bus_structure: null
coordinate: [8, 136.0]
rotation: 0
state: enabled

Re: Releases v3.8.4.0 and v3.9.3.0

[Chris Vine]

On Thu, 30 Sep 2021 20:46:50 -0400
Glen Langston  wrote:
> Thanks for all everyone's efforts.   
> 
> We hope to give them a try.
> 
> I’ve got a Soapy SDR question.   Does anyone have a SDRPlay RSP1A running
> with Gnuradio 3.8.  I’ve not been able to find a running example.
> 
> Please send a link, if you’ve got a good example.

I don't have a link to offer you as my gnuradio installation is home-
compiled from a number of scripts.  However, I did have my RSP1A
working fine with gnuradio-3.8.2.0 using the out-of-tree gr-soapy block.
I have now moved on to gnuradio-3.9.2.0, which has the advantage of
providing an in-tree soapy block as part of the gnuradio distribution.

If you are using gnuradio-3.8 and can't move to gnuradio-3.9, I found
that the out-of-tree gr-soapy block, wrapping SoapySDR and SoapySDRPlay,
worked far better than trying to use the gr-osmosdr block's unfree
backend for the RSP driver directly.  gr-osmosdr's soapy backend worked
OK with the RSP driver and is what you will need if you are using gqrx,
otherwise that adds an unnecessary level of indirection: instead of
using gr-osmosdr's soapy backend you might just as well use gr-soapy
directly, and the latter enables you to configure for example the
RSP1A's MF/AM and VHF/DAB filters, which I never managed to do with
gr-osmosdr.

SoapySDRPlay seemed to work fine with both the 2.13.1 and 3.05.1
versions of the RSP driver; since the RSP1A only has a single hardware
sampler there is no advantage in using the 3.05.1 driver so I stuck with
version 2.13.1, which avoids having to start a daemon.

My main issue was in working out which gr-osmosdr and gr-soapy
repository worked with which version of gnuradio.  With gnuradio-3.9's
in-tree soapy block that is now obviated.  If you need help with
versions/repositories for gnuradio-3.8 I should be able to help.

Hope that helps.

Re: [EXTERNAL] Re: Changing the frequency of signal source at runtime

[Chris Vine]

On Wed, 14 Jul 2021 13:47:26 -0400
Jeff Long  wrote:
> With a recent GNU Radio 3.9, SoapySDR is supported, and there is a soapy
> sdrplay driver. This requires the sdrplay v3 API and service to be
> installed.

SoapySDR and SoapySDRPlay also work fine with the v2 API for the RSP1A
and gnuradio-3.9.  I use it myself (version 2.13.1) and prefer it to
the v3 API as it doesn't require a daemon process to be launched.  For
the RSP1A, the v3 API doesn't seem to offer anything that the v2 API
doesn't, as the RSP1A only offers a single hardware sampling device.

launching gnuradio generated python file core dumps

[Chris Gorman]

Hello All,

I'm generating a python file that attempts to replicate Victor Cai's
MFCW radar.  I don't know for sure if I've implemented it correctly,
but it causes a core dump when run.  I'm using the feature/gr-iio
branch, v3.10.0.0git-341-g131f32c7.  I don't have to run the program,
just launch and close the window and I get the following...

[chris@descartes radar]$ ./mfcw.py
free(): invalid pointer
Aborted (core dumped)

When I run the program using gdb, I get...

(gdb) run mfcw.py
Starting program: /usr/bin/python mfcw.py
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/usr/lib/libthread_db.so.1".
[New Thread 0x7fffe6b80640 (LWP 50441)]
[New Thread 0x7fffe635d640 (LWP 50442)]
[New Thread 0x7fffe5910640 (LWP 50443)]
[Thread 0x7fffe5910640 (LWP 50443) exited]
[New Thread 0x7fffe5910640 (LWP 50444)]
[New Thread 0x7fffe510f640 (LWP 50445)]
---snip---
[New Thread 0x7fff75d9f640 (LWP 50473)]
[New Thread 0x7fff7559e640 (LWP 50476)]
[Thread 0x7fff927fc640 (LWP 50464) exited]
[Thread 0x7fff92ffd640 (LWP 50463) exited]
---snip---
[Thread 0x7fffd7e67640 (LWP 50447) exited]
[Thread 0x7fffb3fff640 (LWP 50454) exited]
[Thread 0x7fff7559e640 (LWP 50476) exited]
[Thread 0x7fff765a0640 (LWP 50472) exited]
[Thread 0x7fff75d9f640 (LWP 50473) exited]
[Thread 0x7fff80ff9640 (LWP 50471) exited]
[Thread 0x7fff817fa640 (LWP 50470) exited]
[Thread 0x7fffe6b80640 (LWP 50441) exited]
[Thread 0x7fff81ffb640 (LWP 50469) exited]
[Thread 0x7fff827fc640 (LWP 50468) exited]
[Thread 0x7fff82ffd640 (LWP 50467) exited]
[Thread 0x7fff837fe640 (LWP 50466) exited]
[Thread 0x7fff83fff640 (LWP 50465) exited]
free(): invalid pointer
Thread 1 "python" received signal SIGABRT, Aborted.
0x77a58d22 in raise () from /usr/lib/libc.so.6
(gdb) bt
#0  0x77a58d22 in raise () at /usr/lib/libc.so.6
#1  0x77a42862 in abort () at /usr/lib/libc.so.6
#2  0x77a9ad28 in __libc_message () at /usr/lib/libc.so.6
#3  0x77aa292a in  () at /usr/lib/libc.so.6
#4  0x77aa3cfc in _int_free () at /usr/lib/libc.so.6
#5  0x77aa79e8 in free () at /usr/lib/libc.so.6
#6  0x7fffeb1dfd6f in gr::qtgui::number_sink_impl::~number_sink_impl() ()
at /usr/local/lib/libgnuradio-qtgui.so.3.10.0git
#7  0x7fffeb1e0123 in virtual thunk to
gr::qtgui::number_sink_impl::~number_sink_impl() () at
/usr/local/lib/libgnuradio-qtgui.so.3.10.0git
#8  0x7fffeb356e0a in  ()
at 
/usr/local/lib/python3.9/site-packages/gnuradio/qtgui/qtgui_python.cpython-39-x86_64-linux-gnu.so
#9  0x7fffeb37bce6 in  ()
at 
/usr/local/lib/python3.9/site-packages/gnuradio/qtgui/qtgui_python.cpython-39-x86_64-linux-gnu.so
#10 0x7fffeb34f9c4 in  ()
at 
/usr/local/lib/python3.9/site-packages/gnuradio/qtgui/qtgui_python.cpython-39-x86_64-linux-gnu.so
#11 0x77d09cb6 in  () at /usr/lib/libpython3.9.so.1.0
#12 0x76d98f26 in  ()
at /usr/lib/python3.9/site-packages/PyQt5/sip.cpython-39-x86_64-linux-gnu.so
#13 0x76d9a194 in  ()
at /usr/lib/python3.9/site-packages/PyQt5/sip.cpython-39-x86_64-linux-gnu.so
#14 0x77d029ac in  () at /usr/lib/libpython3.9.so.1.0
#15 0x77dc17de in  () at /usr/lib/libpython3.9.so.1.0
#16 0x77df09ba in PyGC_Collect () at /usr/lib/libpython3.9.so.1.0
#17 0x77dee8a9 in Py_FinalizeEx () at /usr/lib/libpython3.9.so.1.0
#18 0x77de643c in Py_RunMain () at /usr/lib/libpython3.9.so.1.0
#19 0x77db7349 in Py_BytesMain () at /usr/lib/libpython3.9.so.1.0
#20 0x77a43b25 in __libc_start_main () at /usr/lib/libc.so.6
#21 0x504e in _start ()

Since my last post was a known bug, I searched the issue tracker at
github for gnuradio, but I couldn't find anything about this one.
Should I move this there?

Thanks in advance,

Chris


mfcw.grc
Description: application/gnuradio-grc

Problem changing LO with qt-gui range on Pluto SDR

[Chris Gorman]

Hello All,

I am having difficulty using a qt-gui range with my plutosdr to change
the LO frequency.  I am using the feature/gr-iio branch,
v3.10.0.0git-297-gb13303bd.  When I run my python file and try to
change the LO frequency with a qt-gui range, I get the following
error.

[chris@descartes gnuradio]$ ./pluto_radio.py
Traceback (most recent call last):
  File "/usr/local/lib/python3.9/site-packages/gnuradio/qtgui/range.py",
line 186, in changed
self.notifyChanged(self.rangeType(val))
  File "/usr/local/lib/python3.9/site-packages/gnuradio/qtgui/range.py",
line 285, in sliderChanged
self.notifyChanged(self.rangeType(value))
  File "/home/chris/src/gnuradio/./pluto_radio.py", line 233, in set_f
   self.iio_pluto_source_0.set_params(int(self.f*1e6), self.samp_rate,
2000, 32768, True, True, True, 'slow_attack', 64, 'Design', '',
self.samp_rate/4, self.samp_rate/3)
TypeError: set_params(): incompatible function arguments. The
following argument types are supported:
1. (self: gnuradio.iio.iio_python.pluto_source, longfrequency:
int, samplerate: int, bandwidth: int, quadrature: bool, rfdc: bool,
bbdc: bool, gain: str, gain_value: float, filter_source: str = '',
filter_filename: str = '', Fpass: float = 0.0, Fstop: float = 0.0) ->
None

Invoked with: , 10240, 1536000, 2000, 32768, True, True,
True, 'slow_attack', 64, 'Design', '', 384000.0, 512000.0
Aborted (core dumped)

The python file is generated from the attached pluto_radio.grc file.

Should I create a ticket for this?

Thanks in advance,

Chris


pluto_radio.grc
Description: application/gnuradio-grc

Re: GNU Radio gr-osmosdr on Ubuntu Installation Error; Kali Successfully Installs but Can’t Run

[Chris Vine]

On Fri, 7 May 2021 12:24:42 -0700
Cinaed Simson  wrote:
> 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.
> 
> 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

Hi,

To be clear, there is no branch named "3.9" in of the gr-osmosdr git
repository because the current master branch covers gnuradio-3.9.  Your
suggestion that gr-osmosdr has not been ported to gnuradio-3.9 is wrong.

Re: GNU Radio gr-osmosdr on Ubuntu Installation Error; Kali Successfully Installs but Can’t Run

[Chris Vine]

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

Is it time?

[KB3CS - Chris]

you know? the top result of a web search "gnuradio donation" provides:

*Donations* - GNN Radio
https://gnnradio.org

/Donations/
*Donations* GNNradio is a non-profit ministry, funded by the generous
*donations* made by individuals, businesses and ministries. With your
prayerful and financial partnership, this ministry is able to reach
hundreds of thousands of listeners every week. We are committed to
providing solid, biblical teaching that shares the Good News of Jesus
Christ to the world […]

what is wrong with this picture!?!
Nowvia Google Fi
M-^Wr@M->@EM-QM-^FNO CARRIER

Re: stop making unneeded improvements

[KB3CS - Chris]

On Fri, 08 Jan 2021 22:16:22 -0500, "Marcus D. Leech" <
patchvonbr...@gmail.com> wrote a great many things, and then this excerpt:

> I "get" the whole "oh, but it's so very close to what I need".  But GR
> really is just a specialized programming environment, and GRC
>has the unfortunate (in some sense) side effect of making it seem
> like something else, sometimes tantalizingly so.
>
> Part of the problem here is that GRC isn't particularly *tutorial* in
> nature, and there has historically, and continues to be, a problem with
>providing adequate documentation on a block-by-block basis.  This is
> fixable by the mere application of hundreds of hours of
>tech-writer time.  That time, in the 16 years that GR has existed,
> has yet to materialize.  Coders are notoriously poor documentation people,
>and very-few tech writers seem to be imbued with the same
> public-spiritedness as competent coders.  This is not a problem
>peculiar to GR...
>
> Nobody in the GR "management" would be at all unhappy for folks to
> contribute to making it better-documented and with a
>"slicker" UI framework in GRC.   There's no conscious effort to block
> that.  But the pool of contributors are generally focussed
>on other things.  Just the nature of an open-source project.
>
 [... followed by more things ...]

is it possible part of what is going on here is an unfortunate lack of
imagination on the part of our GNURadio leadership? Wait, hang on a second,
before you greybeards (like mine) get huffy and ready to strike me down for
my insolence and/or impudence ..

what i have seen, for quite a while and ongoing, are the annual efforts to
expand the GNURadio codebase. i have also witnessed honest assessments of
the state of documentation, tutorials, and GUI elements.

why does not in my mind figure just as prominently as GSoC: other campaigns
like GSoD or GSoGUI ? (does anyone actually need me to fill in the
definitions for those abbreviations?)

i am now an elder veteran of much documentation and technical writing and
.. and .. and .. as one might expect after a lengthy and wide-ranging
career.

where is the sustained outreach to *today's* new promising up-and-coming
Instructors (for tutorials), Technical Writers (to expand descriptions and
elucidate and footnote), and Documentation Writers (answering at every turn
- what is this? what is that? why is this? where are the 'knobs'? where are
the 'connectors'?) ?

oh, it's a matter of money, i hear someone saying.. is it? is it really?
who passed the hat lately? a boot? a plate? a tip cup? something? where?

please do press on forward but do not fear to ask for what is needed. no
matter what it seems might be the result of honestly asking for help when
and where needed.

 M-^Wr@M->@EM-QM-^FNO CARRIER

trying to play two radio stations simultaneously

[Chris Gorman]

Hello All,

I'm trying out jean-michel.friedt's course on digital communications
and have a problem with getting two radio stations to play
simultaneously.  I have tried to follow jean-michel's example, but am
getting caught somewhere.  I get one radio station and hiss on the
other.

I've tried a few combinations, but haven't got a logical successful
solution.  I am choosing two local radio stations and can tune them
independently.  The first radio station is the osmocom source ch0
frequency.  This station I can tune without trouble.  The second
station is determined by s frequency translating filter and I make the
center frequency a negative difference between the ch0 frequency and
it's nearest neighbour.  In this case I'm choosing ch0 frequency
90.7e6 and center frequency -800e3.  (For a radio station at 91.5
MHz.)  Somewhere here I am getting into trouble.  This station can be
heard but is mostly hiss.

I'm including my grc file and a screenshot of my flow graph with the
hope that someone can point me to my error.  Thanks in advance.

Chris


fdma2.pdf
Description: Adobe PDF document


fdma2.grc
Description: application/gnuradio-grc

Re: gr_satellites receives SIGSEGV when run

[Chris Gorman]

Hello All,

I have found my error.  I found I had two installs of volk on my
computer.  (One for gr-3.8 and one for gr-3.9.)  gr_satellites linked
against one and the library loader picked the other one at runtime.
Starting with a fresh install of gnuradio-3.8 and deleting the volk
installs fixes this.

Thanks for your time.

Chris

On Wed, Jan 6, 2021 at 10:45 AM Chris Gorman  wrote:
>
> Hello All,
>
> I'm trying to run gr_satellites under gnuradio-3.8.2.0 and am getting
> a segfault.  I was wondering if anyone else has experienced this or
> has any suggestions.
>
> I've run it through gdb and here's what I get...
>
> (gdb) run /opt/gnuradio/bin/gr_satellites 1KUNS-PF --sa 48e3 --wavfile
> satellite-recordings/1kuns_pf.wav
> Starting program: /usr/bin/python /opt/gnuradio/bin/gr_satellites
> 1KUNS-PF --sa 48e3 --wavfile satellite-recordings/1kuns_pf.wav
> [Thread debugging using libthread_db enabled]
> Using host libthread_db library "/lib/libthread_db.so.1".
> [New Thread 0x7fffe3a7b640 (LWP 25317)]
> [New Thread 0x7fffe327a640 (LWP 25318)]
> [New Thread 0x7fffd2a79640 (LWP 25319)]
> [New Thread 0x7fffca278640 (LWP 25320)]
> [New Thread 0x7fffc1a77640 (LWP 25321)]
> [New Thread 0x7fffc1276640 (LWP 25322)]
> [New Thread 0x7fffb0a75640 (LWP 25323)]
> [New Thread 0x7fffa8274640 (LWP 25324)]
> [New Thread 0x7fff9fa73640 (LWP 25325)]
> [New Thread 0x7fff97272640 (LWP 25326)]
> [New Thread 0x7fff8ea71640 (LWP 25327)]
> gr::log :DEBUG: correlate_access_code_tag_bb0 - Access code: 930b51de
> gr::log :DEBUG: correlate_access_code_tag_bb0 - Mask: 
> gr::log :DEBUG: correlate_access_code_tag_bb1 - Access code: 930b51de
> gr::log :DEBUG: correlate_access_code_tag_bb1 - Mask: 
> [New Thread 0x7fff7acfc640 (LWP 25329)]
> [New Thread 0x7fff73fff640 (LWP 25330)]
> [New Thread 0x7fff7a4fb640 (LWP 25331)]
> [New Thread 0x7fff79cfa640 (LWP 25332)]
> [New Thread 0x7fff794f9640 (LWP 25333)]
> [New Thread 0x7fff78cf8640 (LWP 25334)]
> [New Thread 0x7fff737fe640 (LWP 25335)]
> [New Thread 0x7fff72ffd640 (LWP 25336)]
> [New Thread 0x7fff727fc640 (LWP 25337)]
> [New Thread 0x7fff71ffb640 (LWP 25338)]
> [New Thread 0x7fff717fa640 (LWP 25339)]
> [New Thread 0x7fff70ff9640 (LWP 25340)]
> [New Thread 0x7fff43fff640 (LWP 25341)]
> [New Thread 0x7fff3b7fe640 (LWP 25342)]
> [New Thread 0x7fff437fe640 (LWP 25343)]
> [New Thread 0x7fff42ffd640 (LWP 25344)]
> [New Thread 0x7fff427fc640 (LWP 25345)]
> [New Thread 0x7fff41ffb640 (LWP 25346)]
> [New Thread 0x7fff417fa640 (LWP 25347)]
> [New Thread 0x7fff40ff9640 (LWP 25348)]
> [New Thread 0x7fff3bfff640 (LWP 25349)]
> [New Thread 0x7fff3affd640 (LWP 25350)]
> [New Thread 0x7fff3a7fc640 (LWP 25351)]
> [New Thread 0x7fff39ffb640 (LWP 25352)]
> [New Thread 0x7fff397fa640 (LWP 25353)]
> [New Thread 0x7fff38ff9640 (LWP 25354)]
> [New Thread 0x7fff03fff640 (LWP 25355)]
> [New Thread 0x7fff037fe640 (LWP 25356)]
> [New Thread 0x7fff02ffd640 (LWP 25357)]
> [New Thread 0x7fff027fc640 (LWP 25358)]
> [New Thread 0x7fff01ffb640 (LWP 25359)]
> [New Thread 0x7fff017fa640 (LWP 25360)]
> [New Thread 0x7fff00ff9640 (LWP 25361)]
> [New Thread 0x7ffee3fff640 (LWP 25362)]
> [New Thread 0x7ffee37fe640 (LWP 25363)]
> [New Thread 0x7ffee2ffd640 (LWP 25364)]
> --Type  for more, q to quit, c to continue without paging--
>
> Thread 35 "binary_slicer_1" received signal SIGSEGV, Segmentation fault.
> [Switching to Thread 0x7fff3a7fc640 (LWP 25351)]
> 0x7fffe8b1383a in volk_32f_binary_slicer_8i_a_avx2 ()
>from /opt/gnuradio/lib/libvolk.so.2.0
> (gdb) bt
> #0  0x7fffe8b1383a in volk_32f_binary_slicer_8i_a_avx2 ()
>from /opt/gnuradio/lib/libvolk.so.2.0
> #1  0x7fff7c1d128f in virtual thunk to
> gr::digital::binary_slicer_fb_impl::work(int, std::vector std::allocator >&, std::vector std::allocator >&) ()
>from /opt/gnuradio/lib/libgnuradio-digital.so.3.8.2
> #2  0x7fffe97826b7 in gr::sync_block::general_work(int,
> std::vector >&, std::vector std::allocator >&, std::vector std::allocator >&) ()
>from /opt/gnuradio/lib/libgnuradio-runtime.so.3.8.2
> #3  0x7fffe973b9c3 in gr::block_executor::run_one_iteration() ()
>from /opt/gnuradio/lib/libgnuradio-runtime.so.3.8.2
> #4  0x7fffe9790642 in
> gr::tpb_thread_body::tpb_thread_body(boost::shared_ptr,
> boost::shared_ptr, int) ()
>from /opt/gnuradio/lib/libgnuradio-runtime.so.3.8.2
> #5  0x7fffe9780d0d in
> boost::detail::function::void_function_obj_invoker0,
> void>::invoke(boost::detail::function::function_buffer&) ()
>from /opt/gnuradio/lib/libgnuradio-runtime.so.3.8.2
> #6  0x7fffea047637 in thread_proxy ()
>from /usr/lib/libboost_thread.so.1.74

gr_satellites receives SIGSEGV when run

[Chris Gorman]

Hello All,

I'm trying to run gr_satellites under gnuradio-3.8.2.0 and am getting
a segfault.  I was wondering if anyone else has experienced this or
has any suggestions.

I've run it through gdb and here's what I get...

(gdb) run /opt/gnuradio/bin/gr_satellites 1KUNS-PF --sa 48e3 --wavfile
satellite-recordings/1kuns_pf.wav
Starting program: /usr/bin/python /opt/gnuradio/bin/gr_satellites
1KUNS-PF --sa 48e3 --wavfile satellite-recordings/1kuns_pf.wav
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/libthread_db.so.1".
[New Thread 0x7fffe3a7b640 (LWP 25317)]
[New Thread 0x7fffe327a640 (LWP 25318)]
[New Thread 0x7fffd2a79640 (LWP 25319)]
[New Thread 0x7fffca278640 (LWP 25320)]
[New Thread 0x7fffc1a77640 (LWP 25321)]
[New Thread 0x7fffc1276640 (LWP 25322)]
[New Thread 0x7fffb0a75640 (LWP 25323)]
[New Thread 0x7fffa8274640 (LWP 25324)]
[New Thread 0x7fff9fa73640 (LWP 25325)]
[New Thread 0x7fff97272640 (LWP 25326)]
[New Thread 0x7fff8ea71640 (LWP 25327)]
gr::log :DEBUG: correlate_access_code_tag_bb0 - Access code: 930b51de
gr::log :DEBUG: correlate_access_code_tag_bb0 - Mask: 
gr::log :DEBUG: correlate_access_code_tag_bb1 - Access code: 930b51de
gr::log :DEBUG: correlate_access_code_tag_bb1 - Mask: 
[New Thread 0x7fff7acfc640 (LWP 25329)]
[New Thread 0x7fff73fff640 (LWP 25330)]
[New Thread 0x7fff7a4fb640 (LWP 25331)]
[New Thread 0x7fff79cfa640 (LWP 25332)]
[New Thread 0x7fff794f9640 (LWP 25333)]
[New Thread 0x7fff78cf8640 (LWP 25334)]
[New Thread 0x7fff737fe640 (LWP 25335)]
[New Thread 0x7fff72ffd640 (LWP 25336)]
[New Thread 0x7fff727fc640 (LWP 25337)]
[New Thread 0x7fff71ffb640 (LWP 25338)]
[New Thread 0x7fff717fa640 (LWP 25339)]
[New Thread 0x7fff70ff9640 (LWP 25340)]
[New Thread 0x7fff43fff640 (LWP 25341)]
[New Thread 0x7fff3b7fe640 (LWP 25342)]
[New Thread 0x7fff437fe640 (LWP 25343)]
[New Thread 0x7fff42ffd640 (LWP 25344)]
[New Thread 0x7fff427fc640 (LWP 25345)]
[New Thread 0x7fff41ffb640 (LWP 25346)]
[New Thread 0x7fff417fa640 (LWP 25347)]
[New Thread 0x7fff40ff9640 (LWP 25348)]
[New Thread 0x7fff3bfff640 (LWP 25349)]
[New Thread 0x7fff3affd640 (LWP 25350)]
[New Thread 0x7fff3a7fc640 (LWP 25351)]
[New Thread 0x7fff39ffb640 (LWP 25352)]
[New Thread 0x7fff397fa640 (LWP 25353)]
[New Thread 0x7fff38ff9640 (LWP 25354)]
[New Thread 0x7fff03fff640 (LWP 25355)]
[New Thread 0x7fff037fe640 (LWP 25356)]
[New Thread 0x7fff02ffd640 (LWP 25357)]
[New Thread 0x7fff027fc640 (LWP 25358)]
[New Thread 0x7fff01ffb640 (LWP 25359)]
[New Thread 0x7fff017fa640 (LWP 25360)]
[New Thread 0x7fff00ff9640 (LWP 25361)]
[New Thread 0x7ffee3fff640 (LWP 25362)]
[New Thread 0x7ffee37fe640 (LWP 25363)]
[New Thread 0x7ffee2ffd640 (LWP 25364)]
--Type  for more, q to quit, c to continue without paging--

Thread 35 "binary_slicer_1" received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x7fff3a7fc640 (LWP 25351)]
0x7fffe8b1383a in volk_32f_binary_slicer_8i_a_avx2 ()
   from /opt/gnuradio/lib/libvolk.so.2.0
(gdb) bt
#0  0x7fffe8b1383a in volk_32f_binary_slicer_8i_a_avx2 ()
   from /opt/gnuradio/lib/libvolk.so.2.0
#1  0x7fff7c1d128f in virtual thunk to
gr::digital::binary_slicer_fb_impl::work(int, std::vector >&, std::vector >&) ()
   from /opt/gnuradio/lib/libgnuradio-digital.so.3.8.2
#2  0x7fffe97826b7 in gr::sync_block::general_work(int,
std::vector >&, std::vector >&, std::vector >&) ()
   from /opt/gnuradio/lib/libgnuradio-runtime.so.3.8.2
#3  0x7fffe973b9c3 in gr::block_executor::run_one_iteration() ()
   from /opt/gnuradio/lib/libgnuradio-runtime.so.3.8.2
#4  0x7fffe9790642 in
gr::tpb_thread_body::tpb_thread_body(boost::shared_ptr,
boost::shared_ptr, int) ()
   from /opt/gnuradio/lib/libgnuradio-runtime.so.3.8.2
#5  0x7fffe9780d0d in
boost::detail::function::void_function_obj_invoker0,
void>::invoke(boost::detail::function::function_buffer&) ()
   from /opt/gnuradio/lib/libgnuradio-runtime.so.3.8.2
#6  0x7fffea047637 in thread_proxy ()
   from /usr/lib/libboost_thread.so.1.74.0
#7  0x77baceae in start_thread (arg=0x7fff3a7fc640)
at pthread_create.c:463
#8  0x7798731f in clone ()
--Type  for more, q to quit, c to continue without paging--
at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95

I have tried to update python and get the same results with 3.9.1 as I
did with 3.8.5.  I did consider updating volk, but it seems that 2.0
is paired with gnuradio-3.8.2.0.  Is there a way to update volk in the
stable branch?

Thanks in advance,

Chris

Re: Stop making unneeded improvements

[Chris Vine]

On Tue, 22 Dec 2020 20:21:42 -0500
Glen Langston  wrote:
[snip]
> I like the SDRPlay device, but it can not be used in gnuradio 3.8.  According 
> to the web.
> But the web indicates it might be usable in 3.9
> So I installed 3.9 only to find that swig has been replace by pybind.  This 
> breaks all my
> existing C++ modules.   The modules worked fine, but if using ubuntu 20.40 
> the students can not
> easily install gnuradio 3.7.  The pybind instructions are puzzling.  
> gr-modtool all the
> modules copy something or other.   This is for no good reason that I’m aware 
> of.
> Either make the equivalent of pythons “2to3” or do not make the gnuradio 
> fundamental changes.

I use SDRPlay with gnuradio-3.8 with linux and it works fine.  The
gr-soapy backend works better than the gr-osmosdr one however.

In my case I use sdrplay-2.13.1, soapy-sdr (git master branch as at
2020-07-13), soapy-sdrplay (git master branch as at 2020-06-29),
gnuradio-3.8.2.0 and gr-soapy (git master branch as at 2020-06-07).

In addition, to use SDRPlay with gqrx, I use gr-iqbal (git master
branch as at 2019-12-01) and gr-osmosdr (git master branch as at
2020-08-05).  However, you should use the gr-osmosdr block's soapy
backend with soapy's sdrplay driver (pass the arguments
"soapy=0,driver=sdrplay" to the gr-osmosdr block), and not the sdrplay
backend which no longer works properly.

Re: headache from banging head against wall

[KB3CS - Chris]

In-Reply-To=
caehqls7ysl3jpdd_fovohwjugw8nwq9jzu5kzvkqwaqb3yb...@mail.gmail.com

I'm hoping the lack of response so far means that perhaps you've taken an
interest in my reported difficulties and might also be encountering some of
them?

In the meantime, would some knowledgeable person be able to indicate the
flowgraph *should* work?

That is, for every "^@^@^A^QTest" (4 byte default header plus 4 byte
payload) input to the transmitter, the output from the receiver should be
"Test"?

  = 0x49 =

Re: Spectrum Sensing and timer block

[Chris Kuethe]

You can use a signal generator to generate a ramp that goes from start
frequency to end frequency, and a function probe to sample the value of
that ramp periodically to then retune the radios. Somewhere I have a grc
file that does that. Basically a VCO.

On Thu, Oct 15, 2020 at 10:56 AM Steven Sharp 
wrote:

> This answer may not help but I will offer it up. You can sleep (pause) the
> flow graph python script, change parameters such as frequency then run the
> flow graph again. Note, in my set up  I dumped the first few samples after
> the change to clear the old data.
>
> If someone else has a solution go with that.
>
> Good luck
>
> On Wed, Oct 14, 2020, 7:02 AM Songyi Cao <2053234...@qq.com> wrote:
>
>> Kindly help out，is there any timer in GNU Radio?
>> I have six B205mini， I want to use all of them to achieve spectrum
>> sensing periodically，for example，the first usrp is used for sensing 1G-2G
>> frequency band，the second usrp is used for sensing 2G-3G frequency
>> band….…my task is to sense 1G-6G at the same time. But because of the
>> limitation of hardware，for every single usrp，it only can sense 56M
>> bandwidth at most for every moment，so I have to use a timer to control the
>> usrp ，this moment it should sense 1G-1.056G ，and next moment，it will move
>> to 1.056G-1.112G，but I didn't find a relevant block in GNU Radio.
>>
>>
>>
>>
>>
>> --
>> Best Wishes !
>> Songyi. Cao
>>
>

-- 
GDB has a 'break' feature; why doesn't it have 'fix' too?

Re: headache from banging head against wall

[KB3CS - Chris]

In-Reply-To=dc0a76d8-72e5-06c4-2c93-ecb59daf2...@gnuradio.org

I hope it would be possible to leave the walls undamaged and brain normally
percolating, but it appears circumstances do not allow it.

The frequency spectrum of the transmitter appeared to be suitable enough
with energy decreasing beyond +/- f/4 some 50 or 60 dB. Similarly, the
spectrum at the receiver after the filter seemed ordinary with only the 60
dB or so below peak removed. The constellation at the input of the
constellation decoder appeared to be the expected fairly sharp two points
along the x-axis. And yet, the output was obviously garbled.

Some progress has been made (see file attachments) but success is still not
achieved.

Two hard lessons (etwas durch persönliche Erfahrung lernen oder entdecken,
insbesondere das, was schwierig, schmerzhaft oder unangenehm ist) of note:
1. using a Message Debug block seems to guarantee losing control of grc
where grc no longer responds to user input and a CPU spins at 100%. "Force
Quit" is the way to regain control. It is best to run "top_block.py"
directly in a Terminal Session when Message Debug is enabled.
2. please observe the pair of Frequency Sinks used in the first sections of
the transmitter. I report that if this pair is replaced by a single
Frequency Sink with 2 inputs, the transmitter immediately behaves as if
there were no signal modulation! The two bit BPSK constellation collapses
into a single bit at the origin of the constellation.

One can no doubt imagine the amount of productive time lost to the issues
just described.

I can report it is easy enough to create a  construction
for transmission but the blocks which should remove the  and
deliver the  do not seem to  behave as expected. I have now a
flowgraph which accurately delivers  made from scratch all
the way to the receiver output prior to any attempt to remove the .

Am I supposed to use a Delay Block to time-align the  detection
with the data entering the Header/Payload Demux? If so, this is not shown
in any part of the GNU Radio documentation or in the grc examples in the
GNU Radio repository.

 = 1001001 =

On Wed, 7 Oct 2020 22:41:38 +0200 "Marcus Müller" 
wrote:

> Hi Chris,
>
> please, keep the walls intact and your brain operable.
>
> Hm, I've not looked too deeply into this, but:
> 2 Samples per symbol means that your bandwidth should be at least
> samplerate/2, and you've in fact got excess bandwidth. What does the
> frequency sink on transmitter side say?
>
> On the receiving side, you filter to samplerate/3, which is less!
>
> Then, this has no framing, so its impossible for the receiver to know
> whether something it received is the first bit in a byte!
>
> Still a bit peculiar that you're still getting valid ASCII, no doubt.
>
> Best regards,
> Marcus
>


modem2b.pdf
Description: Adobe PDF document


modem2.grc
Description: application/gnuradio-grc

headache from banging head against wall

[KB3CS - Chris]

after much review of Tutorials and Examples and various experiments over
the course of many days, i give up trying to do this on my own.

i do not understand why the best i can do with the flowgraph (attached)
using the Constellation Modulator and a BPSK Constellation Object with a
repeating input of "Test" (4 bytes, ASCII) is an output of "W7EF" (4 bytes,
ASCII).

where has this gone wrong? did i miss something? have i managed to make a
simple thing difficult instead?

thanks in advance.


modem2.pdf
Description: Adobe PDF document


modem2.grc
Description: application/gnuradio-grc

gnuradio 3.9 with gr-iio incorporated

[Chris Gorman]

Hello All,

First off thanks to Edward Kigwana for his efforts making gr-iio for a
pybind11 environment.  I am testing out his code and have some
questions. I am using the commits shown by
https://github.com/gnuradio/gnuradio/compare/master...ekigwana:merge-griio-upstream
.

When I try to make a simple flowgraph I get a python error in running
the script.

chris [ ~ ]$ python broadcast_fm.py.gr-3.9
Traceback (most recent call last):
  File "/opt/gnuradio/lib/python3.8/site-packages/gnuradio/gr/hier_block2.py",
line 31, in wrapped
endp = [(p.to_basic_block(), 0) if hasattr(p, 'to_basic_block')
  File "/opt/gnuradio/lib/python3.8/site-packages/gnuradio/gr/hier_block2.py",
line 32, in 
else (p[0].to_basic_block(), p[1]) for p in points]
AttributeError: 'gnuradio.iio.iio_python.pluto_source' object has no
attribute 'to_basic_block'

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "broadcast_fm.py.gr-3.9", line 200, in 
main()
  File "broadcast_fm.py.gr-3.9", line 176, in main
tb = top_block_cls()
  File "broadcast_fm.py.gr-3.9", line 118, in __init__
self.connect((self.iio_pluto_source_0, 0),
(self.rational_resampler_xxx_0, 0))
  File "/opt/gnuradio/lib/python3.8/site-packages/gnuradio/gr/hier_block2.py",
line 34, in wrapped
raise ValueError("Unable to coerce endpoints: " + str(err))
ValueError: Unable to coerce endpoints:
'gnuradio.iio.iio_python.pluto_source' object has no attribute
'to_basic_block'

This flow graph works when generated by gnuradio 3.8.2.  I'm wondering
if anyone has seen this error and can point me to a fix?

Thanks in advance.

Chris


broadcast_fm.grc
Description: application/gnuradio-grc


broadcast_fm.py.gr-3.9
Description: Binary data

Re: looking for tree to use for gr-iio and gnuradio 3.9

[Chris Gorman]

On Tue, Sep 15, 2020 at 12:40 PM Chris Gorman  wrote:
>
> Hello All,
>
> I am trying to migrate gr-iio -b maint-3.8 to gnuradio 3.9 with
> pybind11.  I have, I think, got most of it working.
>
> My latest hurdle is at
> https://wiki.gnuradio.org/index.php/GNU_Radio_3.9_OOT_Module_Porting_Guide.
> Step 8. Though not necessary, boost::bind instances for message port
> handlers can be replaced with lambda functions for performance and
> simplicity as well as consistency with the in-tree modules.
>
> My main reason for looking to do this is I get an error during my
> build related to boost::bind.
>
> [ 25%] Building CXX object lib/CMakeFiles/gnuradio-iio.dir/attr_sink_impl.cc.o
> cd /home/chris/src/iio/gr-iio/build/lib && /usr/bin/c++
> -DBOOST_ALL_NO_LIB -DBOOST_FILESYSTEM_DYN_LINK
> -DBOOST_PROGRAM_OPTIONS_DYN_LINK -DBOOST_REGEX_DYN_LINK
> -DBOOST_SYSTEM_DYN_LINK -DBOOST_THREAD_DYN_LINK -DFFTW3F_THREADS
> -DGR_CTRLPORT -Dgnuradio_iio_EXPORTS
> -I/home/chris/src/iio/gr-iio/lib/../include
> -I/home/chris/src/iio/gr-iio/build/lib -isystem /usr/include/python3.8
> -isystem /usr/lib/python3.8/site-packages/numpy/core/include -isystem
> /opt/gnuradio/include -O3 -DNDEBUG -fPIC   -fvisibility=hidden
> -std=gnu++11 -o CMakeFiles/gnuradio-iio.dir/attr_sink_impl.cc.o -c
> /home/chris/src/iio/gr-iio/lib/attr_sink_impl.cc
> /home/chris/src/iio/gr-iio/lib/attr_sink_impl.cc: In constructor
> ‘gr::iio::attr_sink_impl::attr_sink_impl(const string&, const string&,
> const string&, int, bool, bool)’:
> /home/chris/src/iio/gr-iio/lib/attr_sink_impl.cc:92:92: error: ‘_1’
> was not declared in this scope
>92 | ::mp("attr"), boost::bind(&attr_sink_impl::write_attribute, this, 
> _1));
>   |   ^~
>
> /home/chris/src/iio/gr-iio/lib/attr_sink_impl.cc:92:92: note:
> suggested alternatives:
> In file included from /usr/include/boost/mpl/aux_/include_preprocessed.hpp:37,
>  from /usr/include/boost/mpl/placeholders.hpp:43,
>  from /usr/include/boost/iterator/iterator_categories.hpp:16,
>  from /usr/include/boost/iterator/iterator_facade.hpp:13,
>  from /usr/include/boost/filesystem/path.hpp:29,
>  from /usr/include/boost/filesystem.hpp:16,
>  from /opt/gnuradio/include/gnuradio/logger.h:36,
>  from /opt/gnuradio/include/gnuradio/basic_block.h:16,
>  from /opt/gnuradio/include/gnuradio/block.h:15,
>      from
> /home/chris/src/iio/gr-iio/lib/../include/iio/attr_sink.h:27,
>  from /home/chris/src/iio/gr-iio/lib/attr_sink_impl.h:26,
>  from /home/chris/src/iio/gr-iio/lib/attr_sink_impl.cc:27:
> /usr/include/boost/mpl/aux_/preprocessed/gcc/placeholders.hpp:29:16:
> note:   ‘mpl_::_1’
>29 | typedef arg<1> _1;
>   |^~
> In file included from /usr/include/boost/system/error_code.hpp:19,
>  from /usr/include/boost/filesystem/path_traits.hpp:22,
>  from /usr/include/boost/filesystem/path.hpp:26,
>  from /usr/include/boost/filesystem.hpp:16,
>  from /opt/gnuradio/include/gnuradio/logger.h:36,
>  from /opt/gnuradio/include/gnuradio/basic_block.h:16,
>  from /opt/gnuradio/include/gnuradio/block.h:15,
>  from
> /home/chris/src/iio/gr-iio/lib/../include/iio/attr_sink.h:27,
>  from /home/chris/src/iio/gr-iio/lib/attr_sink_impl.h:26,
>  from /home/chris/src/iio/gr-iio/lib/attr_sink_impl.cc:27:
> /usr/include/c++/10.2.0/functional:221:34: note:   ‘std::placeholders::_1’
>   221 | extern const _Placeholder<1> _1;
>   |  ^~
> In file included from /usr/include/boost/mpl/aux_/include_preprocessed.hpp:37,
>  from /usr/include/boost/mpl/placeholders.hpp:43,
>  from /usr/include/boost/iterator/iterator_categories.hpp:16,
>  from /usr/include/boost/iterator/iterator_facade.hpp:13,
>  from /usr/include/boost/filesystem/path.hpp:29,
>  from /usr/include/boost/filesystem.hpp:16,
>  from /opt/gnuradio/include/gnuradio/logger.h:36,
>  from /opt/gnuradio/include/gnuradio/basic_block.h:16,
>  from /opt/gnuradio/include/gnuradio/block.h:15,
>  from
> /home/chris/src/iio/gr-iio/lib/../include/iio/attr_sink.h:27,
>  from /home/chris/src/iio/gr-iio/lib/attr_sink_impl.h:26,
>  from /home/chris/src/iio/gr-iio/lib/attr_sink_impl.cc:27:
> /usr/include/boost/mpl/aux_/p

looking for tree to use for gr-iio and gnuradio 3.9

[Chris Gorman]

Hello All,

I am trying to migrate gr-iio -b maint-3.8 to gnuradio 3.9 with
pybind11.  I have, I think, got most of it working.

My latest hurdle is at
https://wiki.gnuradio.org/index.php/GNU_Radio_3.9_OOT_Module_Porting_Guide.
Step 8. Though not necessary, boost::bind instances for message port
handlers can be replaced with lambda functions for performance and
simplicity as well as consistency with the in-tree modules.

My main reason for looking to do this is I get an error during my
build related to boost::bind.

[ 25%] Building CXX object lib/CMakeFiles/gnuradio-iio.dir/attr_sink_impl.cc.o
cd /home/chris/src/iio/gr-iio/build/lib && /usr/bin/c++
-DBOOST_ALL_NO_LIB -DBOOST_FILESYSTEM_DYN_LINK
-DBOOST_PROGRAM_OPTIONS_DYN_LINK -DBOOST_REGEX_DYN_LINK
-DBOOST_SYSTEM_DYN_LINK -DBOOST_THREAD_DYN_LINK -DFFTW3F_THREADS
-DGR_CTRLPORT -Dgnuradio_iio_EXPORTS
-I/home/chris/src/iio/gr-iio/lib/../include
-I/home/chris/src/iio/gr-iio/build/lib -isystem /usr/include/python3.8
-isystem /usr/lib/python3.8/site-packages/numpy/core/include -isystem
/opt/gnuradio/include -O3 -DNDEBUG -fPIC   -fvisibility=hidden
-std=gnu++11 -o CMakeFiles/gnuradio-iio.dir/attr_sink_impl.cc.o -c
/home/chris/src/iio/gr-iio/lib/attr_sink_impl.cc
/home/chris/src/iio/gr-iio/lib/attr_sink_impl.cc: In constructor
‘gr::iio::attr_sink_impl::attr_sink_impl(const string&, const string&,
const string&, int, bool, bool)’:
/home/chris/src/iio/gr-iio/lib/attr_sink_impl.cc:92:92: error: ‘_1’
was not declared in this scope
   92 | ::mp("attr"), boost::bind(&attr_sink_impl::write_attribute, this, _1));
  |       ^~

/home/chris/src/iio/gr-iio/lib/attr_sink_impl.cc:92:92: note:
suggested alternatives:
In file included from /usr/include/boost/mpl/aux_/include_preprocessed.hpp:37,
 from /usr/include/boost/mpl/placeholders.hpp:43,
 from /usr/include/boost/iterator/iterator_categories.hpp:16,
 from /usr/include/boost/iterator/iterator_facade.hpp:13,
 from /usr/include/boost/filesystem/path.hpp:29,
 from /usr/include/boost/filesystem.hpp:16,
 from /opt/gnuradio/include/gnuradio/logger.h:36,
 from /opt/gnuradio/include/gnuradio/basic_block.h:16,
 from /opt/gnuradio/include/gnuradio/block.h:15,
 from
/home/chris/src/iio/gr-iio/lib/../include/iio/attr_sink.h:27,
 from /home/chris/src/iio/gr-iio/lib/attr_sink_impl.h:26,
 from /home/chris/src/iio/gr-iio/lib/attr_sink_impl.cc:27:
/usr/include/boost/mpl/aux_/preprocessed/gcc/placeholders.hpp:29:16:
note:   ‘mpl_::_1’
   29 | typedef arg<1> _1;
  |^~
In file included from /usr/include/boost/system/error_code.hpp:19,
 from /usr/include/boost/filesystem/path_traits.hpp:22,
 from /usr/include/boost/filesystem/path.hpp:26,
 from /usr/include/boost/filesystem.hpp:16,
 from /opt/gnuradio/include/gnuradio/logger.h:36,
 from /opt/gnuradio/include/gnuradio/basic_block.h:16,
 from /opt/gnuradio/include/gnuradio/block.h:15,
 from
/home/chris/src/iio/gr-iio/lib/../include/iio/attr_sink.h:27,
 from /home/chris/src/iio/gr-iio/lib/attr_sink_impl.h:26,
 from /home/chris/src/iio/gr-iio/lib/attr_sink_impl.cc:27:
/usr/include/c++/10.2.0/functional:221:34: note:   ‘std::placeholders::_1’
  221 | extern const _Placeholder<1> _1;
  |  ^~
In file included from /usr/include/boost/mpl/aux_/include_preprocessed.hpp:37,
 from /usr/include/boost/mpl/placeholders.hpp:43,
 from /usr/include/boost/iterator/iterator_categories.hpp:16,
 from /usr/include/boost/iterator/iterator_facade.hpp:13,
 from /usr/include/boost/filesystem/path.hpp:29,
 from /usr/include/boost/filesystem.hpp:16,
 from /opt/gnuradio/include/gnuradio/logger.h:36,
 from /opt/gnuradio/include/gnuradio/basic_block.h:16,
 from /opt/gnuradio/include/gnuradio/block.h:15,
 from
/home/chris/src/iio/gr-iio/lib/../include/iio/attr_sink.h:27,
 from /home/chris/src/iio/gr-iio/lib/attr_sink_impl.h:26,
 from /home/chris/src/iio/gr-iio/lib/attr_sink_impl.cc:27:
/usr/include/boost/mpl/aux_/preprocessed/gcc/placeholders.hpp:29:16:
note:   ‘mpl_::_1’
   29 | typedef arg<1> _1;
  |^~
In file included from /usr/include/boost/bind/bind.hpp:2356,
 from /usr/include/boost/thread/detail/thread.hpp:33,
 from /usr/include/boost/thread/thread_only.hpp:22,
 from /usr/include/boost/thread/thread.hpp:12,
 from /usr/include/boost/thread.hpp:13,

gr-osmosdr link error with target_link_libraries

[Chris Gorman]

Hello All,

Just a quick patch for gr-blocks/lib/CMakeLists.txt.  I find without
this patch the command passes sndfile::sndfile to the linker, which
causes a gr-osmosdr build to fail.  I am using a LFS-10.0 install and
have libsndfile installed.  I'm not sure this patch is necessary, but
it fixes the error on my system.

Please let me know if this should be fixed elsewhere, or if it causes
any breakages.

Chris
From 0385eadbe2e7ebcf3d0e6820c39e03f118763f10 Mon Sep 17 00:00:00 2001
From: Chris Gorman 
Date: Mon, 14 Sep 2020 18:19:24 -0400
Subject: [PATCH] target_link_libraries sndfile::sndfile causes link error in
 gr-osmosdr

use of sndfile::sndfile causes linker error when trying to build
gr-osmosdr.  Change to sndfile links properly.
---
 gr-blocks/lib/CMakeLists.txt | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/gr-blocks/lib/CMakeLists.txt b/gr-blocks/lib/CMakeLists.txt
index c867d0ab0..c4ccf60d7 100644
--- a/gr-blocks/lib/CMakeLists.txt
+++ b/gr-blocks/lib/CMakeLists.txt
@@ -175,7 +175,7 @@ add_library(gnuradio-blocks
 target_link_libraries(gnuradio-blocks
 gnuradio-runtime
 Volk::volk
-sndfile::sndfile
+sndfile
 )
 
 target_include_directories(gnuradio-blocks
-- 
2.28.0

Porting gr-osmosdr to gr-3.9 without swig.

[Chris Gorman]

Hello All,

I was wondering if anyone had successfully built gr-osmosdr against
gnuradio-3.9 now that we don't use swig?  I have looked at
https://wiki.gnuradio.org/index.php/GNU_Radio_3.9_OOT_Module_Porting_Guide
and haven't figured out how to port gr-osmosdr. I've gotten to '4. (in
3.8 OOT) Call gr_modtool bind for each block in your OOT' and don't
know where to go from there.  I have tried various combinations of
gr_modtool bind block arguments with no success.

Continuing without adding bind blocks.  I run my cmake build command and get...

chris [ ~/src/gnuradio/gr-osmosdr/build ]$ cmake ../
CMake Warning (dev) at
/usr/share/cmake-3.18/Modules/GNUInstallDirs.cmake:225 (message):
  Unable to determine default CMAKE_INSTALL_LIBDIR directory because no
  target architecture is known.  Please enable at least one language before
  including GNUInstallDirs.
Call Stack (most recent call first):
  CMakeLists.txt:24 (include)
This warning is for project developers.  Use -Wno-dev to suppress it.

-- Build type not specified: defaulting to release.
CMake Warning (dev) at
/usr/share/cmake-3.18/Modules/FindPackageHandleStandardArgs.cmake:273
(message):
  The package name passed to `find_package_handle_standard_args` (PkgConfig)
  does not match the name of the calling package (GMP).  This can lead to
  problems in calling code that expects `find_package` result variables
  (e.g., `_FOUND`) to follow a certain pattern.
Call Stack (most recent call first):
  /usr/share/cmake-3.18/Modules/FindPkgConfig.cmake:59
(find_package_handle_standard_args)
  /opt/gnuradio/lib/cmake/gnuradio/FindGMP.cmake:1 (include)
  /opt/gnuradio/lib/cmake/gnuradio/FindMPLIB.cmake:1 (find_package)
  /usr/share/cmake-3.18/Modules/CMakeFindDependencyMacro.cmake:47 (find_package)
  /opt/gnuradio/lib/cmake/gnuradio/GnuradioConfig.cmake:14 (find_dependency)
  CMakeLists.txt:45 (find_package)
This warning is for project developers.  Use -Wno-dev to suppress it.

CMake Warning (dev) at
/usr/share/cmake-3.18/Modules/FindPackageHandleStandardArgs.cmake:273
(message):
  The package name passed to `find_package_handle_standard_args` (PkgConfig)
  does not match the name of the calling package (MPIR).  This can lead to
  problems in calling code that expects `find_package` result variables
  (e.g., `_FOUND`) to follow a certain pattern.
Call Stack (most recent call first):
  /usr/share/cmake-3.18/Modules/FindPkgConfig.cmake:59
(find_package_handle_standard_args)
  /opt/gnuradio/lib/cmake/gnuradio/FindMPIR.cmake:1 (include)
  /opt/gnuradio/lib/cmake/gnuradio/FindMPLIB.cmake:2 (find_package)
  /usr/share/cmake-3.18/Modules/CMakeFindDependencyMacro.cmake:47 (find_package)
  /opt/gnuradio/lib/cmake/gnuradio/GnuradioConfig.cmake:14 (find_dependency)
  CMakeLists.txt:45 (find_package)
This warning is for project developers.  Use -Wno-dev to suppress it.

-- Checking for module 'mpir >= 3.0'
--   No package 'mpir' found
-- Could NOT find MPIR (missing: MPIRXX_LIBRARY MPIR_LIBRARY MPIR_INCLUDE_DIR)
-- Found Boost: /usr/lib/cmake/Boost-1.74.0/BoostConfig.cmake (found
suitable version "1.74.0", minimum required is "1.74.0") found
components: date_time program_options filesystem system regex thread
unit_test_framework
CMake Warning (dev) at
/usr/share/cmake-3.18/Modules/FindPackageHandleStandardArgs.cmake:273
(message):
  The package name passed to `find_package_handle_standard_args` (VOLK) does
  not match the name of the calling package (Volk).  This can lead to
  problems in calling code that expects `find_package` result variables
  (e.g., `_FOUND`) to follow a certain pattern.
Call Stack (most recent call first):
  /usr/lib/cmake/volk/VolkConfig.cmake:32 (find_package_handle_standard_args)
  /usr/share/cmake-3.18/Modules/CMakeFindDependencyMacro.cmake:47 (find_package)
  /opt/gnuradio/lib/cmake/gnuradio/GnuradioConfig.cmake:34 (find_dependency)
  CMakeLists.txt:45 (find_package)
This warning is for project developers.  Use -Wno-dev to suppress it.

-- User set python executable /usr/bin/python3
-- Found PythonLibs: /usr/lib/libpython3.8.so (found suitable exact
version "3.8.5")
-- Found ALSA 1.2.3.2
-- Extracting version information from git describe...
-- Found Boost: /usr/lib/cmake/Boost-1.74.0/BoostConfig.cmake (found
suitable version "1.74.0", minimum required is "1.65") found
components: chrono thread system
-- 
-- The build system will automatically enable all components.
-- Use -DENABLE_DEFAULT=OFF to disable components by default.
-- Searching for GNURadio-Blocks...
--  Found GNURadio-Blocks: 1
-- Searching for IQ Balance...
-- Could NOT find gnuradio-iqbalance (missing: gnuradio-iqbalance_DIR)
--  Found IQ Balance: 0
-- Searching for UHD Drivers...
CMake Warning (dev) at
/usr/share/cmake-3.18/Modules/FindPackageHandleStandardArgs.cmake:273
(message):
  The package name passed to `find_package_handle_standard_args` (PkgConfig)
  does not

Re: Organizational Announcement: Partnership with The SETI Institute

[Chris Kuethe]

Awesome news! I've only met a few SETI folks but I've always been impressed
by the work they're doing, and by the openness and collaborative spirit
they've show me.

On Tue, Sep 8, 2020 at 10:28 AM Ben Hilburn  wrote:

> Hi all -
>
> Next week is GRCon, and prior to the conference we would like to share
> some exciting news. We are partnering with The SETI Institute to
> collaborate and further our joint goals in open & accessible research,
> education, and technology development with software radio. We first started
> working with The SETI Institute and some of their UC Berkeley faculty a
> couple of years ago, and since then have coordinated a number of successful
> events and co-developments.
>
> Specifically, what this partnership means for GNU Radio is that The SETI
> Institute will assume back-office responsibilities for the project and
> provide operational support - such as accounting and infrastructure. GNU
> Radio maintains its own leadership and administration duties and will
> appoint a Principal Investigator to directly represent the project inside
> the SETI Institute.. Through our partnership, we expect to pursue new
> funding opportunities for both the SETI Institute and GNU Radio, and
> continue to expand the impact of GNU Radio's free software approach to
> research & education.
>
> In GNU Radio's 19-year history, we've been through several different
> iterations of organizational support for the project and community. As most
> projects do, GNU Radio started out supported through the private companies
> / consultancies of the core developers working on it. Eventually, we
> founded the GNU Radio Foundation, and several years later migrated to the
> Free Software Foundation. Our partnership with the SETI Institute reflects
> our continued growth and success, and will provide the support we need to
> continue on that trajectory for years to come.
>
> The Free Software Foundation has expressed its support and excitement for
> this partnership, and is working closely with GNU Radio and SETI Institute
> leadership to make the back-office transition smooth.
>
> You can read more about this partnership from The SETI Institute's
> perspective here (just posted):
> https://www.seti.org/press-release/seti-institute-and-gnu-radio-join-forces
>
> We will be discussing this announcement further at GRCon. As always, feel
> free to reach out if you have questions, and Happy Hacking!
>
> Cheers,
> The GNU Radio Officers
>
>
>

-- 
GDB has a 'break' feature; why doesn't it have 'fix' too?

Re: laptop recommendations

[Chris Kuethe]

I've been pretty happy with my Lenovo Yogas ... both the 900 and c930. They
have USB3 ports which makes it possible to run USB3 radios like a USRP B2xx
or a LimeSDR. They do have integrated GPUs which work ok with beignet, and
therefor gr-fosphor. Upgrading the storage was easy: basically undo 6 or 8
screws on the bottom and there's your SSD that you can swap... I've never
actually booted the original windows install my c930 came with. I just put
in a 1TB SSD and booted Xubuntu.

I'm seriously unimpressed with the lenovo's ability to resist soaking in
coffee or water for half an hour while being powered up ... :D

On Wed, Jul 22, 2020 at 2:08 PM Noah Riley Thurston <
noahthurs...@email.arizona.edu> wrote:

> Hello,
>
> I’m looking to buy a linux laptop specifically for gnuradio with pybombs.
> Does anyone have specific hardware recommendations that work well or to
> avoid? Similarly, is it safe to use the most recent version of Ubuntu
> (20.04 LTS)? I’ve been mostly considering Dells because of their extensive
> ubuntu support.
>
> Any feedback or advice is appreciated!
>
> Thank you,
> Noah
>


-- 
GDB has a 'break' feature; why doesn't it have 'fix' too?

Re: Mpir Installation

[Chris Vine]

On Tue, 28 Apr 2020 17:57:36 +0200
"Vincenzo Mone"  wrote:
> WARNING: 'makeinfo' is missing on your system.
> 
>  You should only need it if you modified a '.texi' file, or
> 
>  any other file indirectly affecting the aspect of the manual.
> 
>  You might want to install the Texinfo package:
> 
>  
> 
>  The spurious makeinfo call might also be the consequence of
> 
>  using a buggy 'make' (AIX, DU, IRIX), in which case you might
> 
>  want to install GNU make:
> 
>  
> 
> Makefile:403: recipe for target 'mpir.info' failed
> 
> make[2]: *** [mpir.info] Error 127
> 
> make[2]: uscita dalla directory "/home/enzo/mpir/doc"
> 
> Makefile:952: recipe for target 'all-recursive' failed
> 
> make[1]: *** [all-recursive] Error 1
> 
> make[1]: uscita dalla directory "/home/enzo/mpir"
> 
> Makefile:755: recipe for target 'all' failed
> 
> make: *** [all] Error 2
> 
> Did I done something wrong?
> 
> Thanks

You are doing lots wrong.

First you are missing texinfo's makeinfo, which seems to be used by mpir
to make its documentation.  That's fine, you don't need texinfo.

Secondly, you don't need texinfo because you are pointlessly trying to
compile and install mpir.  Why?  Your distribution will already come
with gmp or mpir so it is completely unnecessary.

Thirdly, you are posting massively long posts with no regard for
snipping irrelevant content.

Fourthly, trying to install these out-of-distribution packages, when
your distribution will already provide them, is going to break your
installation.  You will end up with conflicting and incompatible
versions of different libraries installed.

I suggest deleting your current linux installation, reinstall it from
scratch, and install that distribution's version of gnuradio.  You are
way out of your depth.

Re: Qt GUI Chooser initial selection

[Chris Vine]

OK, understood.  I'm only a peripheral user, so if the gnuradio
developers can't be bothered, then I can't be bothered.


On Mon, 13 Apr 2020 17:57:30 +0200
Volker Schroer  wrote:
> Ok, then you should fill a pr or report an issue.
> Otherwise this issue won't be fixed I'm afraid.
> 
> -- Volker
> Am 12.04.20 um 22:08 schrieb Chris Vine:
> > Yes, on testing it that does work.
> >
> > But surely, as I said, this needs to go into the 3.8 branch of gnuradio
> > so that it is in the next 3.8 release?
> >
> > Chris
> >
> > 
> > On Sun, 12 Apr 2020 17:16:24 +0200
> > Volker Schroer  wrote:
> >> I think, it should be possible to take the qtgui_chooser.block.yml file
> >> from the master branch. This sould work, as there is no code affected.
> >>
> >> Volker
> >>
> >> Am 12.04.20 um 14:56 schrieb Chris Vine:
> >>> Ah, OK.  This did not find its way into gnuradio-3.8.1.0.  Presumably it
> >>> will apply OK to that version however?  (If so I suggest it is applied
> >>> to the 3.8 branch also.)
> >>>
> >>> Chris
> >>>
> >>> 
> >>> On Sun, 12 Apr 2020 11:48:56 +0200
> >>> Volker Schroer  wrote:
> >>>> Hi !
> >>>> This was fixed with #2778
> >>>>
> >>>> See also:
> >>>>
> >>>> https://github.com/gnuradio/gnuradio/pull/2778/files/ef5ca9fe51dc45c0332e41db36f822f145f6116a
> >>>>
> >>>>
> >>>> -- Volker
> >>>> Am 11.04.20 um 14:45 schrieb Chris Vine:
> >>>>> Hi,
> >>>>>
> >>>>> On porting a gnuradio-companion flow graph from gnuradio-3.7 to
> >>>>> gnuradio-3.8, I noticed that there no longer seems to be a way of
> >>>>> setting the initial (default) selection for the Qt GUI Chooser widget.
> >>>>> The initial selection seems now always to be the first one in the list.
> >>>>>
> >>>>> The widget is therefore no longer suitable for presenting a selection
> >>>>> of numeric values to the user in numerical order where you don't want
> >>>>> the initial default to be the highest (or lowest) value.
> >>>>>
> >>>>> Is there some way around this or some other widget that is now intended
> >>>>> to be used for this purpose?
> >>>>>
> >>>>> Chris
> >>>>>
> >>>>

Re: Qt GUI Chooser initial selection

[Chris Vine]

Yes, on testing it that does work.

But surely, as I said, this needs to go into the 3.8 branch of gnuradio
so that it is in the next 3.8 release?

Chris


On Sun, 12 Apr 2020 17:16:24 +0200
Volker Schroer  wrote:
> I think, it should be possible to take the qtgui_chooser.block.yml file
> from the master branch. This sould work, as there is no code affected.
> 
> Volker
> 
> Am 12.04.20 um 14:56 schrieb Chris Vine:
> > Ah, OK.  This did not find its way into gnuradio-3.8.1.0.  Presumably it
> > will apply OK to that version however?  (If so I suggest it is applied
> > to the 3.8 branch also.)
> >
> > Chris
> >
> > 
> > On Sun, 12 Apr 2020 11:48:56 +0200
> > Volker Schroer  wrote:
> >> Hi !
> >> This was fixed with #2778
> >>
> >> See also:
> >>
> >> https://github.com/gnuradio/gnuradio/pull/2778/files/ef5ca9fe51dc45c0332e41db36f822f145f6116a
> >>
> >>
> >> -- Volker
> >> Am 11.04.20 um 14:45 schrieb Chris Vine:
> >>> Hi,
> >>>
> >>> On porting a gnuradio-companion flow graph from gnuradio-3.7 to
> >>> gnuradio-3.8, I noticed that there no longer seems to be a way of
> >>> setting the initial (default) selection for the Qt GUI Chooser widget.
> >>> The initial selection seems now always to be the first one in the list.
> >>>
> >>> The widget is therefore no longer suitable for presenting a selection
> >>> of numeric values to the user in numerical order where you don't want
> >>> the initial default to be the highest (or lowest) value.
> >>>
> >>> Is there some way around this or some other widget that is now intended
> >>> to be used for this purpose?
> >>>
> >>> Chris
> >>>
> >>

Re: Looking for insight into gr-iio for plutosdr

[Chris Gorman]

Hello again,

I believe I have found my solution.  At least it fixes the segfault.

Adding

add_definitions(-DBOOST_CHRONO_HEADER_ONLY)

to the CMakeLists.txt file in upgrade-3.8 branch of gr-iio allows me
to import iio from python without error.

I would like to thank https://gist.github.com/DonOregano for the fix.
It is in one of his trees.

Chris

On Sat, Apr 11, 2020 at 8:41 PM Chris Gorman  wrote:
>
> Hello All,
>
> I am trying to install gr-iio to build the needed libraries for a
> plutosdr.  I have a slightly unique situation in that I am running on
> a linux from scratch machine and as a result uses shared libraries
> when possible.  I have followed the instructions on
> https://wiki.analog.com/resources/tools-software/linux-software/gnuradio
> , except I am using the upgrade-3.8 branch of gr-iio.  In order to get
> cmake to run, I need to pass -DBUILD_SHARED_LIBS=ON to cmake.  This
> causes a small problem with the resulting binaries.  When I try to
> load them I get errors.  A simple import of iio in Python causes a
> segfault.
>
> Python 3.7.4 (default, Dec 21 2019, 10:53:28)
> [GCC 9.2.0] on linux
> Type "help", "copyright", "credits" or "license" for more information.
> >>> import iio
> Fatal Python error: Segmentation fault
>
> Current thread 0x7fbf14c7a740 (most recent call first):
>   File "", line 219 in _call_with_frames_removed
>   File "", line 1043 in create_module
>   File "", line 583 in module_from_spec
>   File "", line 670 in _load_unlocked
>   File "", line 967 in _find_and_load_unlocked
>   File "", line 983 in _find_and_load
>   File "", line 219 in _call_with_frames_removed
>   File "", line 1035 in _handle_fromlist
>   File "/opt/gnuradio/lib/python3.7/dist-packages/iio/iio_swig.py",
> line 13 in 
>   File "", line 219 in _call_with_frames_removed
>   File "", line 728 in exec_module
>   File "", line 677 in _load_unlocked
>   File "", line 967 in _find_and_load_unlocked
>   File "", line 983 in _find_and_load
>   File "/opt/gnuradio/lib/python3.7/dist-packages/iio/__init__.py",
> line 36 in 
>   File "", line 219 in _call_with_frames_removed
>   File "", line 728 in exec_module
>   File "", line 677 in _load_unlocked
>   File "", line 967 in _find_and_load_unlocked
>   File "", line 983 in _find_and_load
>   File "", line 1 in 
> Segmentation fault
>
> When I try to run iio_swig.py from within gdb I get an error
> indicating that linking has gone wrong somehow.
>
> (gdb) run /opt/gnuradio/lib/python3.7/dist-packages/iio/iio_swig.py
> Starting program: /usr/bin/python3
> /opt/gnuradio/lib/python3.7/dist-packages/iio/iio_swig.py
> [Thread debugging using libthread_db enabled]
> Using host libthread_db library "/lib/libthread_db.so.1".
> Traceback (most recent call last):
>   File "/opt/gnuradio/lib/python3.7/dist-packages/iio/iio_swig.py",
> line 15, in 
> import _iio_swig
> ImportError: /opt/gnuradio/lib/libgnuradio-iio.so...: undefined
> symbol: _ZN5boost6chrono12steady_clock3nowEv
> [Inferior 1 (process 10709) exited with code 01
>
> _ZN5boost6chrono12setady_clock3nowEv exists in
> /usr/lib/libboost_chrono.so , but that library is not used by gr-iio
> as far as I can see.  (I can't find
> _ZN5boost6chrono12setady_clock3nowEv in any of the requested
> libraries: date_time; program_options; filesystem; system; regex;
> thread; unit_test_framework.)
>
> I'm attaching my build.log in case the fix can be found by perusing
> it.  (It hasn't helped me yet.)  Any ideas on how to fix my problem
> would be appreciated.
>
> Thanks in advance.
>
> Chris

Re: Qt GUI Chooser initial selection

[Chris Vine]

Ah, OK.  This did not find its way into gnuradio-3.8.1.0.  Presumably it
will apply OK to that version however?  (If so I suggest it is applied
to the 3.8 branch also.)

Chris


On Sun, 12 Apr 2020 11:48:56 +0200
Volker Schroer  wrote:
> Hi !
> This was fixed with #2778
> 
> See also:
> 
> https://github.com/gnuradio/gnuradio/pull/2778/files/ef5ca9fe51dc45c0332e41db36f822f145f6116a
> 
> 
> -- Volker
> Am 11.04.20 um 14:45 schrieb Chris Vine:
> > Hi,
> >
> > On porting a gnuradio-companion flow graph from gnuradio-3.7 to
> > gnuradio-3.8, I noticed that there no longer seems to be a way of
> > setting the initial (default) selection for the Qt GUI Chooser widget.
> > The initial selection seems now always to be the first one in the list.
> >
> > The widget is therefore no longer suitable for presenting a selection
> > of numeric values to the user in numerical order where you don't want
> > the initial default to be the highest (or lowest) value.
> >
> > Is there some way around this or some other widget that is now intended
> > to be used for this purpose?
> >
> > Chris
> >
> 

Looking for insight into gr-iio for plutosdr

[Chris Gorman]

Hello All,

I am trying to install gr-iio to build the needed libraries for a
plutosdr.  I have a slightly unique situation in that I am running on
a linux from scratch machine and as a result uses shared libraries
when possible.  I have followed the instructions on
https://wiki.analog.com/resources/tools-software/linux-software/gnuradio
, except I am using the upgrade-3.8 branch of gr-iio.  In order to get
cmake to run, I need to pass -DBUILD_SHARED_LIBS=ON to cmake.  This
causes a small problem with the resulting binaries.  When I try to
load them I get errors.  A simple import of iio in Python causes a
segfault.

Python 3.7.4 (default, Dec 21 2019, 10:53:28)
[GCC 9.2.0] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import iio
Fatal Python error: Segmentation fault

Current thread 0x7fbf14c7a740 (most recent call first):
  File "", line 219 in _call_with_frames_removed
  File "", line 1043 in create_module
  File "", line 583 in module_from_spec
  File "", line 670 in _load_unlocked
  File "", line 967 in _find_and_load_unlocked
  File "", line 983 in _find_and_load
  File "", line 219 in _call_with_frames_removed
  File "", line 1035 in _handle_fromlist
  File "/opt/gnuradio/lib/python3.7/dist-packages/iio/iio_swig.py",
line 13 in 
  File "", line 219 in _call_with_frames_removed
  File "", line 728 in exec_module
  File "", line 677 in _load_unlocked
  File "", line 967 in _find_and_load_unlocked
  File "", line 983 in _find_and_load
  File "/opt/gnuradio/lib/python3.7/dist-packages/iio/__init__.py",
line 36 in 
  File "", line 219 in _call_with_frames_removed
  File "", line 728 in exec_module
  File "", line 677 in _load_unlocked
  File "", line 967 in _find_and_load_unlocked
  File "", line 983 in _find_and_load
  File "", line 1 in 
Segmentation fault

When I try to run iio_swig.py from within gdb I get an error
indicating that linking has gone wrong somehow.

(gdb) run /opt/gnuradio/lib/python3.7/dist-packages/iio/iio_swig.py
Starting program: /usr/bin/python3
/opt/gnuradio/lib/python3.7/dist-packages/iio/iio_swig.py
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/libthread_db.so.1".
Traceback (most recent call last):
  File "/opt/gnuradio/lib/python3.7/dist-packages/iio/iio_swig.py",
line 15, in 
import _iio_swig
ImportError: /opt/gnuradio/lib/libgnuradio-iio.so...: undefined
symbol: _ZN5boost6chrono12steady_clock3nowEv
[Inferior 1 (process 10709) exited with code 01

_ZN5boost6chrono12setady_clock3nowEv exists in
/usr/lib/libboost_chrono.so , but that library is not used by gr-iio
as far as I can see.  (I can't find
_ZN5boost6chrono12setady_clock3nowEv in any of the requested
libraries: date_time; program_options; filesystem; system; regex;
thread; unit_test_framework.)

I'm attaching my build.log in case the fix can be found by perusing
it.  (It hasn't helped me yet.)  Any ideas on how to fix my problem
would be appreciated.

Thanks in advance.

Chris


build.log.gz
Description: application/gzip

Qt GUI Chooser initial selection

[Chris Vine]

Hi,

On porting a gnuradio-companion flow graph from gnuradio-3.7 to
gnuradio-3.8, I noticed that there no longer seems to be a way of
setting the initial (default) selection for the Qt GUI Chooser widget.
The initial selection seems now always to be the first one in the list.

The widget is therefore no longer suitable for presenting a selection
of numeric values to the user in numerical order where you don't want
the initial default to be the highest (or lowest) value.

Is there some way around this or some other widget that is now intended
to be used for this purpose?

Chris

Re: Pi GNURadion challenge.

[Chris Vine]

On Mon, 9 Mar 2020 10:59:04 -0400
Glen Langston  wrote:
> Hi
> 
> Thanks for your summary of experience with installing Gnuradio 3.8.1 for 
> Raspberry Pi.
> 
> I’ve started the install on a fresh version on the latest Raspberry Pi OS,
> but ran into a few issues I’m still working on.
> 
> One question/request for this group:
> 
> The folks at SDRPlay have done a very nice job of porting a good working 
> version of
> gnuradio into a working image of the Raspberry OS and compressed it.
> (https://www.sdrplay.com/downloads/)
> 
> After downloading (about 2GB) and writing to the SD card, this version just 
> works fine.
> The simple-minded user can then just start enjoying Gnuradio.
> 
> However they don’t yet have Gnuradio 3.8.1 on the SD card.

As far as I can tell there is no gnuradio-3.8.1.  Where did you find it?
I can see a first release candidate as of some weeks ago, which of
course is something different.

Re: Version compatibility problem

[Chris Vine]

On Wed, 12 Feb 2020 15:04:49 -0800
Laura Arjona  wrote:
> sorry, typed it wrong
> ~$ which gnradio-config-info
> /usr/local/bin/gnuradio-config-info

In which case you have built and installed gnuradio in the /usr/local
prefix by hand, not as a package you can install and uninstall using
your distribution's package manager.

You should be able to go through /usr/local and delete anything
gnuradio related.  Then install your distribution's binary package
of gnuradio using its package manager.  Unless you are a person who
likes to do their own compiling, there shouldn't be much in /usr/local.

Chris

Re: Signal Tracking

[Chris Kuethe]

One way you could do this is with a signal generator - proabably a slowly
increasing ramp signal - which you sample with a probe block, and then the
value of the probe block is used to retune the hardware. Not at my GR
machine right now otherwise I'd attach a flowgraph to show how to do this.

I'm sure there are other approaches.

On Tue, Nov 26, 2019 at 8:40 AM sarandis. Doulgeris <
sarandis.doulge...@gmail.com> wrote:

> Hi. Is there a way to change the center frequency of osmocom source,
> having the video bandwidth steady, automatically at a given rate istead of
> a range variable?
>


-- 
GDB has a 'break' feature; why doesn't it have 'fix' too?

Re: Gnuradio for Raspberry PI 4 and SDRPLay works well, but need documentation

[Chris Vine]

On Thu, 14 Nov 2019 19:35:13 +
Chris Vine  wrote:
> The original poster can get some information from installing soapy and
> doing 'SoapySDRUtil --probe'.

I should probably have appended what the probe tells me about my RSP1A,
which may or may not apply to his:


-- Device identification

  driver=SDRplay
  hardware=RSP1A
  mir_sdr_api_version=2.13
  mir_sdr_hw_version=255
  serial=xxx


-- Peripheral summary

  Channels: 1 Rx, 0 Tx
  Timestamps: NO
  Other Settings:
 * RF Gain Select - RF Gain Select
   [key=rfgain_sel, default=4, type=string, options=(0, 1, 2, 3, 4, 5, 6, 
7, 8, 9)]
 * IF Mode - IF frequency in kHz
   [key=if_mode, default=Zero-IF, type=string, options=(Zero-IF, 450kHz, 
1620kHz, 2048kHz)]
 * IQ Correction - IQ Correction Control
   [key=iqcorr_ctrl, default=true, type=bool]
 * AGC Setpoint - AGC Setpoint (dBfs)
   [key=agc_setpoint, default=-30, type=int, range=[-60, 0]]
 * BiasT Enable - BiasT Control
   [key=biasT_ctrl, default=true, type=bool]
 * RfNotch Enable - RF Notch Filter Control
   [key=rfnotch_ctrl, default=true, type=bool]
 * DabNotch Enable - DAB Notch Filter Control
   [key=dabnotch_ctrl, default=true, type=bool]


-- RX Channel 0

  Full-duplex: NO
  Supports AGC: YES
  Stream formats: CS16, CF32
  Native format: CS16 [full-scale=32767]
  Antennas: RX
  Corrections: DC removal
  Full gain range: [0, 48] dB
IFGR gain range: [20, 59] dB
RFGR gain range: [0, 9] dB
  Full freq range: [0.01, 2000] MHz
RF freq range: [0.01, 2000] MHz
CORR freq range:  MHz
  Sample rates: 0.25, 0.5, 1, 2, 2.048, 6, 7, 8, 9, 10 MSps
  Filter bandwidths: 0.2, 0.3, 0.6, 1.536, 5, 6, 7, 8 MHz

Re: Gnuradio for Raspberry PI 4 and SDRPLay works well, but need documentation

[Chris Vine]

On Thu, 14 Nov 2019 14:11:22 +
Müller, Marcus (CEL)  wrote:
> Hi Glen,
> 
> first of all: This email nearly eluded my attention – you replied to a
> completely different topic, and that means email clients will sort your
> mail under the "Simulated Time?" thread. Simply don't reply to emails
> if you don't mean to actually reply.
> 
> Then: The SDRPlay block isn't part of GNU Radio itself – it comes from
> somewhere else, and I must admit I don't know from where. You'll
> probably have to download the SDRPlay driver package and look inside.
> 
> Problem with the SDRPlay driver is: It's closed source, and as such,
> they can't link software against GNU Radio (which is GPL), and then
> distribute it. If someone could reverse engineer that and write a GPL-
> compatible driver (and integrate it with soapy or with gr-osmosdr),
> that'd be very cool.

The original poster can get some information from installing soapy and
doing 'SoapySDRUtil --probe'.

But I wonder what gnuradio block the original poster is using with the
proprietary driver?  I couldn't make it out from the image he posted.  I
only know of three: (i) gr-osmosdr's built-in support for sdrplay, (ii)
gr-osmosdr's built-in support for soapy and so for the soapy-sdrplay
plugin, and (iii) gr-soapy's support for soapy and so also for the
soapy-sdrplay plugin.  If there is a fourth I would be interested to
know what it is.  The first doesn't work that well for me with the
current proprietary driver whereas the last two work fine (for me on
x86/64).

In any event, with reference to the original poster's comments about
selecting the wrong band pass filter, RSP1A only supports certain
bandpass filtering widths.  These can be examined with the soapy
probe above.  Generally you want the bandwidth to be somewhat less than
the sample rate (soapy's probe will also tell you what sample rates are
available).

Re: [Discuss-gnuradio] Ubuntu: Pybombs install UHD hangs at 6%?

[Chris Kuethe]

I'm not sure that adding more swap would help; generally the problem
is that disk is thousands of times slower than RAM.

I sampled a few of my rPi machines and they can peak at 20MB/s
sustained read (ie. the fastest possible operation). I'd say you'd be
lucky to get quarter of that on random writes. Someone else has
already done the work of benchmarking and it looks like at worst, ram
is going to be 10x faster than sdcard at its best. Swap is fine for
emergencies or pages you don't really need very often at all, but
really... stay the heck away from swap.

http://www.roylongbottom.org.uk/Raspberry%20Pi%20Benchmarks.htm#anchor9

On Wed, Oct 16, 2019 at 1:32 PM Eamon Heaney  wrote:
>
> Thanks all, it makes sense that I'd be running out of memory on an old Pi. 
> Looks like my swap space was only 128MB, so maybe I'll bump that up just in 
> case.
>
> And thanks for the link, Chris; I should be able to get my hands on a Pi 3 
> with 2GB ram, hopefully that'll cut compile time.
>
> On Wed, Oct 16, 2019 at 4:25 PM Chris Kuethe  wrote:
>>
>> It's not hanging at the install, it's hanging during the build.
>>
>> With that little bit of pedantry out of the way, I'm going to *guess*
>> that you're running out of RAM and starting to hit swap. `htop`,
>> `top`, or `free` would show you if you're swapping. If that's the
>> case, you could try turning down the the number of parallel jobs to 1,
>> eg. only 1 gcc process at a time. This might allow the compile to
>> succeed. You might also need to reduce optimization levels. It sounds
>> a lot like you're having much the same problem as this guy
>> (https://www.raspberrypi.org/forums/viewtopic.php?t=169608) ... 6hrs
>> down to 7minutes when he's not getting swapped to death.
>>
>> On Wed, Oct 16, 2019 at 12:51 PM Eamon Heaney  wrote:
>> >
>> > Hi,
>> >
>> > I'm trying to get Bastib's gr-foo working on a raspberry pi. The OS is 
>> > Ubuntu Mate, freshly installed. I installed gnuradio with Pybombs, and 
>> > that's working fine, but when I try to "pybombs install uhd," it hangs 6% 
>> > of the way through "Building..."
>> >
>> > I interrupted it after it didn't budge for half an hour.
>> >
>> > Screenshot of the problem attached. Any idea why this is happening?
>> >
>> > --
>> > Eamon Heaney
>> > Fleet Commander
>> > President, Model UN at Virginia Tech
>> > ___
>> > Discuss-gnuradio mailing list
>> > Discuss-gnuradio@gnu.org
>> > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>>
>>
>>
>> --
>> GDB has a 'break' feature; why doesn't it have 'fix' too?
>
>
>
> --
> Eamon Heaney
> Fleet Commander
> President, Model UN at Virginia Tech



-- 
GDB has a 'break' feature; why doesn't it have 'fix' too?

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

Re: [Discuss-gnuradio] Ubuntu: Pybombs install UHD hangs at 6%?

[Chris Kuethe]

It's not hanging at the install, it's hanging during the build.

With that little bit of pedantry out of the way, I'm going to *guess*
that you're running out of RAM and starting to hit swap. `htop`,
`top`, or `free` would show you if you're swapping. If that's the
case, you could try turning down the the number of parallel jobs to 1,
eg. only 1 gcc process at a time. This might allow the compile to
succeed. You might also need to reduce optimization levels. It sounds
a lot like you're having much the same problem as this guy
(https://www.raspberrypi.org/forums/viewtopic.php?t=169608) ... 6hrs
down to 7minutes when he's not getting swapped to death.

On Wed, Oct 16, 2019 at 12:51 PM Eamon Heaney  wrote:
>
> Hi,
>
> I'm trying to get Bastib's gr-foo working on a raspberry pi. The OS is Ubuntu 
> Mate, freshly installed. I installed gnuradio with Pybombs, and that's 
> working fine, but when I try to "pybombs install uhd," it hangs 6% of the way 
> through "Building..."
>
> I interrupted it after it didn't budge for half an hour.
>
> Screenshot of the problem attached. Any idea why this is happening?
>
> --
> Eamon Heaney
> Fleet Commander
> President, Model UN at Virginia Tech
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio



-- 
GDB has a 'break' feature; why doesn't it have 'fix' too?

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

Re: [Discuss-gnuradio] Pybombs broken?

[Chris Kuethe]

On the upside, this is fantastic opportunity to figure out a
framework/process for the 3.8-3.9 upgrade.

On Wed, Oct 16, 2019, 11:18 Martin Braun  wrote:

> Hey Richard,
>
> PyBOMBS is having a hard time dealing with 3.7 vs. 3.8. Use the PyBOMBS
> master branch for any hope of it working.
>
> -- M
>
> On Tue, Oct 15, 2019 at 5:00 PM Richard Bell 
> wrote:
>
>> Hello,
>>
>> I'm using pybombs to install gnuradio 3.7.13.5 onto ubuntu 18.04. Pybombs
>> seems to be unable to install dependencies anymore. Each time I run
>>
>> pybombs prefix init ~/Documents/gnuradio/gr37 -a gr37 -R gnuradio-default
>>
>> it goes for a while until it finds software that is missing and errors
>> out. I then manually install the software and rerun the above command. I've
>> had to do this for several dependencies now, including:
>>
>> mako, cppunit, pyqt4, cheetah, thrift, numpy and more.
>>
>> Did something change recently that broke pybombs? About a year ago I was
>> using it without much problem, it installed everything for me.
>>
>> v/r,
>>
>> Rich
>> ___
>> 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
>
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] RTL-SDR source not working in 3.7.14.5

[Chris Gorman]

Hmm,

Not too sure what is wrong.  First off are you sure you have version
3.7.14.5?  I have 3.7.13.5 and can't find your newer version in the
releases (https://www.gnuradio.org/releases/gnuradio/).  Assuming you
have just made a small typo, I have built gr-osmosdr successfully with
3.7.13.5.  Here are the build instructions from the README

git clone git://git.osmocom.org/gr-osmosdr
cd gr-osmosdr/
mkdir build
cd build/
cmake ../
make
sudo make install
sudo ldconfig

It has been a while since I built this, so I don't recall the
dependencies you need to install, but you will at least need the dev
files for your rtl-sdr source.  I recommend trying to install the
rtl-sdr libraries and headers as described in
https://osmocom.org/projects/rtl-sdr/wiki .  (Note this needs to be
done before you install gr-osmosdr.)

As to installing under windows, I don't know how to help with that.  Sorry.

Let me know what you get after trying to build rtl-sdr and gr-osmosdr.

Chris

On Sat, Oct 12, 2019 at 8:07 AM Beau Thompson  wrote:
>
> Hi If i try an run any code with RTL-SDR source it will not run
>
> how can i fix this or is there a way i can have to installs under windows
>
> thanks beau
>
>
> ___
> 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] cmake fails when installing maint_3.7 branch on VM-Ubuntu 18.04

[Chris Kuethe]

"/usr/bin/ld: cannot find -lpthreads"

and there probably isn't a libpthread*s* ... just libpthread

I'd start with "grep -r pthreads /home/anastas/workarea-gnuradio/" to
figure out what file is trying to search for pthreads and replace it
with pthread.

On Tue, Oct 1, 2019 at 12:04 PM Achilleas Anastasopoulos
 wrote:
>
> Hi all,
>
> I have the following issue trying a fresh installation on a VM-Ubuntu 18.04.
> After installing the dependencies etc from here:
> https://wiki.gnuradio.org/index.php/UbuntuInstall
>
> and after checking out the maint_3.7 branch the cmake fails with the 
> following CMakeError.log file.
>
> Something tell me I am missing something obvious, but don't know what...
> This is the first time I see something like this.
>
> Any help is appreciated.
>
> best
> Achilleas
>
>
>
>
> ---
>
> Determining if the pthread_create exist failed with the following output:
> Change Dir: /home/anastas/workarea-gnuradio/build_maint37/CMakeFiles/CMakeTmp
>
> Run Build Command:"/usr/bin/make" "cmTC_a2fc5/fast"
> /usr/bin/make -f CMakeFiles/cmTC_a2fc5.dir/build.make 
> CMakeFiles/cmTC_a2fc5.dir/build
> make[1]: Entering directory 
> '/home/anastas/workarea-gnuradio/build_maint37/CMakeFiles/CMakeTmp'
> Building C object CMakeFiles/cmTC_a2fc5.dir/CheckSymbolExists.c.o
> /usr/bin/cc   -std=gnu99 -fvisibility=hidden -Wsign-compare -Wall 
> -Wno-uninitialized-o CMakeFi
> les/cmTC_a2fc5.dir/CheckSymbolExists.c.o   -c 
> /home/anastas/workarea-gnuradio/build_maint37/CMakeF
> iles/CMakeTmp/CheckSymbolExists.c
> Linking C executable cmTC_a2fc5
> /usr/bin/cmake -E cmake_link_script CMakeFiles/cmTC_a2fc5.dir/link.txt 
> --verbose=1
> /usr/bin/cc  -std=gnu99 -fvisibility=hidden -Wsign-compare -Wall 
> -Wno-uninitialized -rdynamic
> CMakeFiles/cmTC_a2fc5.dir/CheckSymbolExists.c.o  -o cmTC_a2fc5
> CMakeFiles/cmTC_a2fc5.dir/CheckSymbolExists.c.o: In function `main':
> CheckSymbolExists.c:(.text+0x1b): undefined reference to `pthread_create'
> collect2: error: ld returned 1 exit status
> CMakeFiles/cmTC_a2fc5.dir/build.make:97: recipe for target 'cmTC_a2fc5' failed
> make[1]: *** [cmTC_a2fc5] Error 1
> make[1]: Leaving directory 
> '/home/anastas/workarea-gnuradio/build_maint37/CMakeFiles/CMakeTmp'
> Makefile:126: recipe for target 'cmTC_a2fc5/fast' failed
> make: *** [cmTC_a2fc5/fast] Error 2
>
> File 
> /home/anastas/workarea-gnuradio/build_maint37/CMakeFiles/CMakeTmp/CheckSymbolExists.c:
> /* */
> #include 
>
> int main(int argc, char** argv)
> {
>  (void)argv;
> #ifndef pthread_create
>  return ((int*)(&pthread_create))[argc];
> #else
>  (void)argc;
>  return 0;
> #endif
> }
>
> Determining if the function pthread_create exists in the pthreads failed with 
> the following output
> :
> Change Dir: /home/anastas/workarea-gnuradio/build_maint37/CMakeFiles/CMakeTmp
>
> Run Build Command:"/usr/bin/make" "cmTC_cfcc3/fast"
> /usr/bin/make -f CMakeFiles/cmTC_cfcc3.dir/build.make 
> CMakeFiles/cmTC_cfcc3.dir/build
> make[1]: Entering directory 
> '/home/anastas/workarea-gnuradio/build_maint37/CMakeFiles/CMakeTmp'
> Building C object CMakeFiles/cmTC_cfcc3.dir/CheckFunctionExists.c.o
> /usr/bin/cc   -std=gnu99 -fvisibility=hidden -Wsign-compare -Wall 
> -Wno-uninitialized -DCHECK_FUNCT
> ION_EXISTS=pthread_create   -o 
> CMakeFiles/cmTC_cfcc3.dir/CheckFunctionExists.c.o   -c /usr/share/c
> make-3.10/Modules/CheckFunctionExists.c
> Linking C executable cmTC_cfcc3
> /usr/bin/cmake -E cmake_link_script CMakeFiles/cmTC_cfcc3.dir/link.txt 
> --verbose=1
> /usr/bin/cc  -std=gnu99 -fvisibility=hidden -Wsign-compare -Wall 
> -Wno-uninitialized -DCHECK_FUNCTI
> ON_EXISTS=pthread_create-rdynamic 
> CMakeFiles/cmTC_cfcc3.dir/CheckFunctionExists.c.o  -o cmTC_c
> fcc3 -lpthreads
> /usr/bin/ld: cannot find -lpthreads
> collect2: error: ld returned 1 exit status
> CMakeFiles/cmTC_cfcc3.dir/build.make:97: recipe for target 'cmTC_cfcc3' failed
> make[1]: *** [cmTC_cfcc3] Error 1
> make[1]: Leaving directory 
> '/home/anastas/workarea-gnuradio/build_maint37/CMakeFiles/CMakeTmp'
> Makefile:126: recipe for target 'cmTC_cfcc3/fast' failed
> make: *** [cmTC_cfcc3/fast] Error 2
>
>
> -
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio



-- 
GDB has a 'break' feature; why doesn't it have 'fix' too?

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

[Discuss-gnuradio] Tutorial on complex signals and receiving SSB no audio

[Chris Gorman]

Hello All,

I'm trying S. Katz's tutorial
(http://www.csun.edu/~skatz/katzpage/sdr_project/sdr/grc_tutorial4.pdf)
on SSB and can't seem to get any audio out of the gnuradio-companion
flow graph I've generated.  I'm sure the error is mine, but can't
figure out where I made it.

I'm using gnuradio 3.7.13.5 under Linux and have attached my grc file.
If anyone has the time to try it out, you will need to download
ssb_lsb_256k_complex2.dat from
http://www.csun.edu/~skatz/katzpage/sdr_project/sdr/ssb_lsb_256k_complex2.dat.zip
and unzip it, then change the file source in my tutorial4.grc file to
point to the unzipped file.

Thanks in advance,

Chris


tutorial4.grc
Description: Binary data
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] ffast-math

[Chris Kuethe]

To be fair, I was running on a 1GHz Cortex-A8, that only had vfp3 (
https://en.wikipedia.org/wiki/CHIP_(computer)#CHIP). I fully expect that
you're going to need to spend some time going through all the different
compiler flags (-Ofast, -march, -mcpu, -mtune, -ffast-math,
-fthis-that-and-the-other) to figure out whether or not any knob makes the
program run faster on that particular board, makes it use more efficient
cpu instructions, or makes it produce (un)?acceptable solutions. Test
suites are awesome.

Re: dump1090, I ran my test with the mutability version and since then I've
switched to the flightaware fork since I run a few "piaware" sensors.

On Tue, Sep 3, 2019 at 9:59 AM Albin Stigö  wrote:

> In my experience VOLK runs about 10% faster on Raspberry Pi 4 with
> -ffast-math, depending on the flowgraph you might get more. Three
> kernels had some minor problems with precision, but I think they can
> be fixed so all will pass... The fun thing about these embedded
> platforms is that the possibilities for optimizations are almost
> endless!
>
> On a side note, which fork of dump1090 should I run? There seems to be so
> many!
>
>
> --Albin
>
> On Tue, Sep 3, 2019 at 6:18 PM Chris Kuethe 
> wrote:
> >
> > Yep, on some processors with some workloads it really makes a huge
> difference. As others have commented, there may be significant trade-offs
> with regard to numerical behaviro.
> >
> > Some of my observations:
> > dump1090 loses accuracy below the 7th digit when calculating precision,
> but consumes 10% less power on the device under test
> > rtl_433 runs about 35% faster
> > and acarsdec runs over 400% faster.
> >
> >
> > On Sun, Sep 1, 2019, 07:11 Albin Stigö  wrote:
> >>
> >> Anyone has experience with the real world impact of using gcc
> -ffast-math with SDR in general, and GNURadio/Volk in particular?
> >>
> >>
> >> --Albin SM6WJM
> >> ___
> >> Discuss-gnuradio mailing list
> >> Discuss-gnuradio@gnu.org
> >> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>


-- 
GDB has a 'break' feature; why doesn't it have 'fix' too?
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] ffast-math

[Chris Kuethe]

Yep, on some processors with some workloads it really makes a huge
difference. As others have commented, there may be significant trade-offs
with regard to numerical behaviro.

Some of my observations:
dump1090 loses accuracy below the 7th digit when calculating precision, but
consumes 10% less power on the device under test
rtl_433 runs about 35% faster
and acarsdec runs over 400% faster.


On Sun, Sep 1, 2019, 07:11 Albin Stigö  wrote:

> Anyone has experience with the real world impact of using gcc -ffast-math
> with SDR in general, and GNURadio/Volk in particular?
>
>
> --Albin SM6WJM
> ___
> 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] unable to get sound from alsa sink

[Chris Gorman]

Hi Michael,

Thanks for your input.  I will change the grc script as you suggested.
This may not solve my issue explicitly, but I want to learn gnuradio
so everything helps.  I have been running gnuradio 3.7 mostly because
I have seen everyone's scripts use WX widgets and I found it easier to
port them to QT via 3.7.  Perhaps I should upgrade, but I found a
small bug in 3.9 when I was using it. (I couldn't get and 'ID' for my
'QT GUI Tab Widget' so I could use ID@0, ID@1, ... with the my other
QT GUI widgets and place them into tabs.  I emailed the list, but
didn't file a bug report and my email wasn't very verbose.  Sorry.  I
ran a git rev-list to try to get an id as to be able to log the error.
'git rev-list --count HEAD' gave me 13291.  Not sure if this will help
you track it.)

Thanks again and take care,

Chris

On Mon, Aug 26, 2019 at 1:43 PM Michael Dickens
 wrote:
>
> Hi Chris - A few comments, more than anything else:
>
> * You're generating 2 sinusoids then pushing them directly into the audio 
> sink. You're not guaranteed that the audio sink can support 2 input channels, 
> even if it seem to be able to. If the audio sink is working, it will always 
> support at least 1 channel.
>
> ==> Use an "add" block to sum them into a single audio stream.
>
> * The sinusoids are at 0.5 amplitude ... which may or not be enough for your 
> specific audio system.
>
> ==> Add a "Multiply Const" block to get the levels audible. (or 2 of them if 
> you insist on using 2 audio streams). Use a Qt GUI Range slider set between 
> 0.0 and 1.0 to set the gain for any Multiple Const block in use.
>
> * At least in my testing, the buttons in the top don't work, but some of the 
> radio buttons do. Note that the "no tone 0 Hz" seems to be the same as "1209 
> Hz" ... note that Audio -does- come out for me using the GRC script.
>
> Since I'm currently using GR38 & your Python script is for GR37, it's 
> non-trivial to get the Python script going ... so, hope this helps! - MLD
>
> On Mon, Aug 26, 2019, at 1:22 PM, Chris Gorman wrote:
> > Hi Michael,
> >
> > Here's the original .grc file.  Thanks for your help.
> >
> > Chris

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

Re: [Discuss-gnuradio] unable to get sound from alsa sink

[Chris Gorman]

Hi Michael,

Here's the original .grc file.  Thanks for your help.

Chris

On Mon, Aug 26, 2019 at 1:19 PM Michael Dickens
 wrote:
>
> Can you send me the original GRC flowgraph too? I know you modified the 
> output Python, but it might be useful. Also: I'm trying to use GR38 (just 
> because) ... so seeing what Python it generates will be useful. Thx! - MLD
>
> On Mon, Aug 26, 2019, at 11:13 AM, Chris Gorman wrote:
> > Hi Michael,
> >
> > Thanks for looking at this for me.  I'm using gnuradio-3.7.13.5 on
> > ubuntu 18.04.
> >
> > Chris


dtmf.grc
Description: Binary data
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] unable to get sound from alsa sink

[Chris Gorman]

Hi Michael,

Thanks for looking at this for me.  I'm using gnuradio-3.7.13.5 on
ubuntu 18.04.

Chris

On Mon, Aug 26, 2019 at 11:05 AM Michael Dickens
 wrote:
>
> OK good to know, Chris. Can you send me the latest version of your test 
> script as an attachment? I'll give it a go & see what happens for me. Sorry 
> if you've answered this already: Which version of GR are you using? - MLD
>
> On Mon, Aug 26, 2019, at 10:48 AM, Chris Gorman wrote:
> > Oh yes, audio is working fine.  It is a linux system and audio is
> > working when I use the flowgraph.  Just not when I attempt to make a
> > python script of my own.  I basically used the gnuradio-companion
> > generated code and reduced it to try to connect events to a
> > QtPushButton.  I'm sure the error is due to my lack of experience with
> > Qt and python.
> >
> > Chris
from PyQt4 import Qt
from gnuradio import gr
from gnuradio import audio
from gnuradio import analog
from gnuradio import eng_notation
from gnuradio.eng_option import eng_option
from gnuradio.filter import firdes
from optparse import OptionParser
import sys
from gnuradio import qtgui

if __name__ == '__main__':
import ctypes
import sys
if sys.platform.startswith('linux'):
try:
x11 = ctypes.cdll.LoadLibrary('libX11.so')
x11.XInitThreads()
except:
print "Warning: failed to XInitThreads()"

class top_block(gr.top_block, Qt.QWidget):
def __init__(self):
gr.top_block.__init__(self)
Qt.QWidget.__init__(self)
self.setWindowTitle("Top Block")
qtgui.util.check_set_qss()
try:
self.setWindowIcon(Qt.QIcon.fromTheme('gnuradio-grc'))
except:
pass
self.top_scroll_layout = Qt.QVBoxLayout()
self.setLayout(self.top_scroll_layout)
self.top_scroll = Qt.QScrollArea()
self.top_scroll.setFrameStyle(Qt.QFrame.NoFrame)
self.top_scroll_layout.addWidget(self.top_scroll)
self.top_scroll.setWidgetResizable(True)
self.top_widget = Qt.QWidget()
self.top_scroll.setWidget(self.top_widget)
self.top_layout = Qt.QVBoxLayout(self.top_widget)
self.top_grid_layout = Qt.QGridLayout()
self.top_layout.addLayout(self.top_grid_layout)

self.settings = Qt.QSettings("GNU Radio", "top_block")
self.restoreGeometry(self.settings.value("geometry").toByteArray())

sample_rate = 32000
ampl = 0.5

_Zero_push_button = Qt.QPushButton('0')
_Zero_push_button.pressed.connect(lambda: dtmf(self, 941, 1336, sample_rate, ampl))
_Zero_push_button.released.connect(lambda: dtmf(self, 0, 0, sample_rate, ampl))
self.top_grid_layout.addWidget(_Zero_push_button, 3, 1, 1, 1)
for r in range(3, 4):
self.top_grid_layout.setRowStretch(r, 1)
for c in range(1, 2):
self.top_grid_layout.setColumnStretch(c, 1)

def dtmf(self, freq_one, freq_two, sample_rate, ampl):
src0 = analog.sig_source_f(sample_rate, analog.GR_SIN_WAVE, freq_one, ampl)
src1 = analog.sig_source_f(sample_rate, analog.GR_SIN_WAVE, freq_two, ampl)
dst = audio.sink(sample_rate, 'sysdefault:CARD=Intel', True)
self.connect(src0, (dst,0))
self.connect(src1, (dst,1))

def main(top_block_cls=top_block, options=None):

from distutils.version import StrictVersion
if StrictVersion(Qt.qVersion()) >= StrictVersion("4.5.0"):
style = gr.prefs().get_string('qtgui', 'style', 'raster')
Qt.QApplication.setGraphicsSystem(style)
qapp = Qt.QApplication(sys.argv)

tb = top_block_cls()
tb.start()
tb.show()

def quitting():
tb.stop()
tb.wait()
qapp.connect(qapp, Qt.SIGNAL("aboutToQuit()"), quitting)
qapp.exec_()

if __name__ == '__main__':
main()___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] unable to get sound from alsa sink

[Chris Gorman]

Hi Barry,

Thanks for your time and expertise.  I should have been more verbose
in my email.  I can get sound out of my code when I use the
gnuradio-companion program, but not when I run the snippet I gave you.
The purpose of the hacked code is to try to tie a 4x4 Qt.PushButton to
the various frequencies needed to make a Touch tone generator.  (I
currently have it working with radio buittons, through
gnuraidio-companion, but want to use Qt.PushButtons instead.)  I tried
your suggestion and can get the sound working, but not outside of grc.

I am using gnuradio-companion 3.7.13.5 on ubuntu 18.04.  aplay -L
gives me lots of options but the one that appears to be default is...

sysdefault:CARD=Intel
HDA Intel, STAC9221 A1 Analog
Default Audio Device

I'm wondering if this is a sound system permission issue?

Thanks for your help.

Chris


Chris

On Mon, Aug 26, 2019 at 9:36 AM Barry Duggan  wrote:
>
> Hi Chris,
>
> You didn't mention your OS or your platform, but this works for a Linux
> system:
>
> Using a terminal screen, enter 'aplay -L'
>
> Here is an excerpt from my Raspberry Pi:
>
> """
> default:CARD=ALSA
>  bcm2835 ALSA, bcm2835 ALSA
>  Default Audio Device
> hw:CARD=ALSA,DEV=1
>  bcm2835 ALSA, bcm2835 IEC958/HDMI
>  Direct hardware device without any conversions
> hw:CARD=Device,DEV=0
>  USB Audio Device, USB Audio
>  Direct hardware device without any conversions
> """
>
> The Pi has a headphone jack, an HDMI port, and I have a USB audio
> dongle. What you need to do is pick the appropriate entry for your
> system, and the enter the Device Name in the Audio Sink properties. For
> example, I use "hw:CARD=ALSA,DEV=1" to get sound on my monitor.
>
> On Windows or Mac, you might just enter "default:CARD=ALSA".
>
> Good luck,
> --
> Barry Duggan
>
> On Sun, 25 Aug 2019 17:27:31 -0400, Chris Gorman wrote:
>
> Hello All,
>
> I have been hacking at a python script with an attempt to pass two
> frequencies to be added to audio sink.  I can't seem to get any sound
> out of the sound card, though.  When I run the script I get "gr::log
> :INFO: audio source - Audio sink arch: alsa".  The script follows.  My
> python and QT skills are very poor, I simply started with
> gnuradio-companion code and tried to hack the result.  Can anyone see
> where I might fix this?
>
> Thanks in advance.
>
> Chris
>
> 

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

[Discuss-gnuradio] unable to get sound from alsa sink

[Chris Gorman]

Hello All,

I have been hacking at a python script with an attempt to pass two
frequencies to be added to audio sink.  I can't seem to get any sound
out of the sound card, though.  When I run the script I get "gr::log
:INFO: audio source - Audio sink arch: alsa".  The script follows.  My
python and QT skills are very poor, I simply started with
gnuradio-companion code and tried to hack the result.  Can anyone see
where I might fix this?

Thanks in advance.

Chris

from PyQt4 import Qt
from gnuradio import gr
from gnuradio import audio
from gnuradio import analog
from gnuradio import eng_notation
from gnuradio.eng_option import eng_option
from gnuradio.filter import firdes
from optparse import OptionParser
import sys
from gnuradio import qtgui

if __name__ == '__main__':
import ctypes
import sys
if sys.platform.startswith('linux'):
try:
x11 = ctypes.cdll.LoadLibrary('libX11.so')
x11.XInitThreads()
except:
print "Warning: failed to XInitThreads()"

class top_block(gr.top_block, Qt.QWidget):
def __init__(self):
gr.top_block.__init__(self)
Qt.QWidget.__init__(self)
self.setWindowTitle("Top Block")
qtgui.util.check_set_qss()
try:
self.setWindowIcon(Qt.QIcon.fromTheme('gnuradio-grc'))
except:
pass
self.top_scroll_layout = Qt.QVBoxLayout()
self.setLayout(self.top_scroll_layout)
self.top_scroll = Qt.QScrollArea()
self.top_scroll.setFrameStyle(Qt.QFrame.NoFrame)
self.top_scroll_layout.addWidget(self.top_scroll)
self.top_scroll.setWidgetResizable(True)
self.top_widget = Qt.QWidget()
self.top_scroll.setWidget(self.top_widget)
self.top_layout = Qt.QVBoxLayout(self.top_widget)
self.top_grid_layout = Qt.QGridLayout()
self.top_layout.addLayout(self.top_grid_layout)

self.settings = Qt.QSettings("GNU Radio", "top_block")
self.restoreGeometry(self.settings.value("geometry").toByteArray())

sample_rate = 32000
ampl = 0.5

_Zero_push_button = Qt.QPushButton('0')
_Zero_push_button.pressed.connect(lambda: dtmf(self, 941,
1336, sample_rate, ampl))
_Zero_push_button.released.connect(lambda: dtmf(self, 0, 0,
sample_rate, ampl))
self.top_grid_layout.addWidget(_Zero_push_button, 3, 1, 1, 1)
for r in range(3, 4):
self.top_grid_layout.setRowStretch(r, 1)
for c in range(1, 2):
self.top_grid_layout.setColumnStretch(c, 1)

def dtmf(self, freq_one, freq_two, sample_rate, ampl):
src0 = analog.sig_source_f(sample_rate, analog.GR_SIN_WAVE, freq_one, ampl)
src1 = analog.sig_source_f(sample_rate, analog.GR_SIN_WAVE, freq_two, ampl)
dst = audio.sink(sample_rate, "")
self.connect(src0, (dst,0))
self.connect(src1, (dst,1))

def main(top_block_cls=top_block, options=None):

from distutils.version import StrictVersion
if StrictVersion(Qt.qVersion()) >= StrictVersion("4.5.0"):
style = gr.prefs().get_string('qtgui', 'style', 'raster')
Qt.QApplication.setGraphicsSystem(style)
qapp = Qt.QApplication(sys.argv)

tb = top_block_cls()
tb.start()
tb.show()

def quitting():
tb.stop()
tb.wait()
qapp.connect(qapp, Qt.SIGNAL("aboutToQuit()"), quitting)
qapp.exec_()

if __name__ == '__main__':
main()

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

[Discuss-gnuradio] DTMF (Touch Tone) encoder

[Chris Gorman]

Hello All,

I have looked around and I can't seem to find a touch tone encoder for
gnuradio.  The beginner tutorial adding two sin waves to create a dial
tone made me want to play with dial tone, busy tone, and phone number
key presses, etc.  All the frequencies are available on wikipedia, but
I have not been able to put the logic together in gnuradio.  I am
looking at a simple 16 button keypad, that when a key is pressed it
adds the two sin waves together.  I have made a hack that I am
attaching to this email where I can select two radio buttons and make
a tone that way.

I was wondering if anyone had some pointers on how to change the
current design to a keypad based one with say QT GUI Push Button
instead of the QT GUI Chooser radio button one I have.  This project
has no practical application other than to entertain me and to teach
me gnuradio, so don't stop important work to respond to this.  (Unless
you want to ;)

Thanks to all the developers for their work in making such an
interesting piece of software.

Chris


dtmf.grc
Description: Binary data
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] QT GUI Tab Widget id is missing in gnuradio 3.9

[Chris Gorman]

Hello All,

I am looking to use the QT GUI Tab Widget and cannot find the id. I am
using gnuradio 3.9 with the following version number.

$ git rev-list --count HEAD
13291

In 3.7.11 the QT_GUI_Tab_Widget has an id.

Chris

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

Re: [Discuss-gnuradio] Unable to get python3 to import osmosdr module.

[Chris Gorman]

Hello All,

I have solved this problem, I think.  First off I have attempted to
use two repositories for building gr-osmosdr.
The first from Mickey Vänskä
https://github.com/mvaenskae/gr-osmosdr/tree/gr3.8 builds for me, but
python3 fails to load the osmosdr module due to a unresolved symbol
_ZTIN2gr11hier_block2E.  The second by Igor Freire,
https://github.com/igorauad/gr-osmosdr/tree/gr3.8 seems to work, ie.
doesn't have the unresolved symbol.  But I have yet to test it
properly.

In order to get this working properly I had to update swig to swig 4
and remove swig 3 from my machine. (The build kept using swig 3 rather
than swig 4.)

I will now test this and see what I get.

Thanks

Chris

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

[Discuss-gnuradio] Unable to get python3 to import osmosdr module.

[Chris Gorman]

Hello All,

I have been playing around with gnuradio-3.9 from git.  The new
gnuradio uses python3 and I have been unable to get gr-osmosdr to load
with python3.  I am using Mickey Vänskä's repository of gr-osmosdr for
gnuradio 3.8. ( https://github.com/mvaenskae/gr-osmosdr/tree/gr3.8 )

I can get the library to build and install but when I attempt to load
the osmosdr module I get ...

$ python3 -c 'import osmosdr'
No module named '_osmosdr_swig'

I have tried setting the PYTHONPATH to see if perhaps that would fix
the problem, but it does not.

The directory /usr/local/lib/python3.6/dist-packages/osmosdr contains

$ ls /usr/local/lib/python3.6/dist-packages/osmosdr
__init__.py   osmocom_siggen_base.py   osmosdr_swig.py   _osmosdr_swig.so
__init__.pyc  osmocom_siggen_base.pyc  osmosdr_swig.pyc
__init__.pyo  osmocom_siggen_base.pyo  osmosdr_swig.pyo

I have triied building swig 4 to see if that made a difference with
osmosdr_swig.py, but it is still being built with swig 3.0.12.

I believe this is a problem with python2 vs python3, but I have yet to
test that as it means a rebuild of gnuradio and I wanted to ask if
anyone knows what I'm missing first.

Thanks in advance.

Chris Gorman

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

Re: [Discuss-gnuradio] GNURadio v3.8.0.0 Blocs .xml

[Chris Vine]

On Wed, 14 Aug 2019 08:44:31 -0400
"Michael Dickens"  wrote:
> Hi Jean Pierre & Kyeong - gr-osmosdr does not have an official port to GR3.8 
> as of yet. There are 3rd-party ports that might work, such as those from the 
> issue noted: https://osmocom.org/issues/3855 . See also:
> 
> https://github.com/igorauad/gr-osmosdr/tree/gr3.8
> https://github.com/mvaenskae/gr-osmosdr/tree/gr3.8
> https://github.com/igorauad/gr-osmosdr/tree/gr3.8
> 
> Hope this is useful! - MLD

To get the igograud's repository to link cleanly with boost-1.70.0 and
gnuradio-3.8.0.0, I had to add this patch to gr-osmosdr's cmake build
system, as gr-osmosdr links to functions in boost::chrono.  I have not
yet verified that gr-osmosdr actually works with gnuradio-3.8, but it
does at least compile and link.

There may well be a better way to do it in cmake: I neither like cmake,
nor know it especially well.



diff --git a/lib/CMakeLists.txt b/lib/CMakeLists.txt
index 2171df2..9ba4592 100644
--- a/lib/CMakeLists.txt
+++ b/lib/CMakeLists.txt
@@ -52,6 +52,7 @@ endif()
 GR_OSMOSDR_APPEND_LIBS(
 ${Boost_LIBRARIES}
 gnuradio::gnuradio-blocks
+boost_chrono
 ${GNURADIO_ALL_LIBRARIES}
 )
 

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