how to install Gqrx on Raspberry PI based Raspbian

[HankrofRed]

Hello everyone , I'm using Raspberry-PI based raspbian os, 
I tried to look for binary files setup of gqrx from the official website ,
but I just found the Ubuntu version and Mac version .
Does anyone be able to tell me how to install gqrx on raspbian step by step ??
or the other way to install??
Forgive my poor English :(

[Alexandru Csete]

Gqrx can not run on a Raspberry Pi.

Alex

> --
> You received this message because you are subscribed to the Google Groups
> "Gqrx SDR" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to gqrx+uns...@googlegroups.com.
> To post to this group, send email to gq...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/gqrx/49132631-1158-492e-a209-c90732e26a20%40googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.

[HankrofRed]

On Saturday, August 23, 2014 6:00:59 AM UTC+8, Alexandru Csete wrote:

Gqrx can not run on a Raspberry Pi.

Alex

Thanks for your replying!
uh...it's mean I have to change the platform as PC??

Could you tell me why gqrx cannot run on R-PI??
I wanna know :(

[Alexandru Csete]

Because gqrx requires more processing power than what the raspberry pi
can offer. Even on PCs gqrx runs best on multicore processors.

Alex

[HankrofRed]

On Saturday, August 23, 2014 6:36:09 AM UTC+8, Alexandru Csete wrote:

Because gqrx requires more processing power than what the raspberry pi
can offer. Even on PCs gqrx runs best on multicore processors.

Alex

Thanks for you  explanation!
For now,I can figure out it.

[Dean Timothy]

If you really have your heart set on using Gqrx, set the RPi up as a rtl_tcp SDR server and access it from a machine running Gqrx as a client.

[ghos...@gmail.com]

So I may be reviving an old thread but now that the Raspberry Pi 2 is out, I thought I'd revisit gqrx on the Pi.  I ran into the same processing conclusion with the B+ but with the new A7 quad core I thought it might be enough to get gqrx to work.  I did ultimately get the application to run without any errors, however it still pegged the 4 cores between 86-100% and I wasn't getting good sound quality.  I have an android tablet that I use for a nice mobile platform for SDR and there's an app on there "sdrtouch" that's running great with just the spectrum and a dual core Atom Acer tablet I got for $79.  I'd love to see gqrx run on the new platform.  So I guess the design question is are there components that could possibly be disabled to save on CPU cycles?  I'm doing a learn-as-you-go project with my son on a Pi with a 3.5" display and we're playing with the SDR capabilities.  Could the waterfall be completely disabled to save on processing power for example? 

For anyone who wants to keep trying here's what I did to get it working on the Pi2:
I first tried some recommendations on trying it from the jesse repo by adding "deb http://archive.raspbian.org/raspbian jessie main" to sources.list.  The gqrx, gr-osmosdr, and rtl-sdr all installed.  rtl-sdr worked great but gr-osmosdr's osmocom_fft crashed until I added this to the Pi's /boot/config.txt (found in another post).  Then that worked.
framebuffer_depth=32
framebuffer_ignore_alpha=1

At first I had an issue with gqrx and pulseaudio till I followed some other online posts and added the following line to /etc/pulse/default.pa (reboot after making the change)
load-module module-alsa-card device_id=0

Then gqrx would run for about 2-3 seconds but then start printing all zero's.  However all of the rtl apps worked fine.  rtl_test came back fine, and I could play with rtl_fm (pick your fav frequency/radio station to test):
 rtl_fm -f $FREQUENCY -M wbfm -s 32k - | play -r 32k -t raw -e s -b 16 -c 1 -V1 -

So... I went back to source on everything and got the latest versions of rtlsdr, osmocom, libosmo-dsp, and gqrx from source and built them all.  Now all of the apps ran without error, but still no good FFT or waterfall and the cpu's were pegged.  I would bet if there were some checkboxes to disable higher cpu utilization functions that a user may be okay sacrificing on a Pi (like the waterfall), this would work great. 

For anyone who wants to try, I tried to turn my steps into a bash script as I was making the changes.  May be worth tinkering with (or wait for a Pi3?):

# -----------------------------------------
# script to install components from source

#!/bin/bash

# Set up rtlsdr and gr-osmosdr from source
echo "[`date`] Installing prerequisites..."
apt-get -y install hackrf libhackrf-dev boost-all-dev liblog4cpp5-dev swig fftw3 fftw3-dev doxygen

echo "[`date`] Removing repo versions if installed..."
apt-get remove rtlsdr gr-osmosdr

SDRROOT="/opt/sdr-build"

echo "[`date`] Setting up rtl-sdr..."
if [ -e $SDRROOT/rtl-sdr/build ]; then
    echo "[`date`] found $SDRROOT/rtl-sdr/build.  Uninstalling previous version."
    cd $SDRROOT/rtl-sdr/build/
    make uninstall
    make clean
    cd $SDRROOT
    rm -rf rtl-sdr
fi

cd $SDRROOT

echo "[`date`] Getting rtl-sdr source..."

git clone git://git.osmocom.org/rtl-sdr.git rtl-sdr
mkdir -p $SDRROOT/rtl-sdr/build
cd rtl-sdr/build

cmake ../ -DINSTALL_UDEV_RULES=ON -DDETACH_KERNEL_DRIVER=ON
make
make install
ldconfig
make install-udev-rules

echo "[`date`] Getting osmosdr..."

if [ -e $SDRROOT/gr-osmosdr/build ]; then
    echo "[`date`] found $SDRROOT/gr-osmosdr/build.  Uninstalling previous version."
    cd $SDRROOT/gr-osmosdr/build/
    make uninstall
    make clean
    cd $SDRROOT
    rm -rf $SDRROOT/gr-osmosdr
fi

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

echo "[`date`] Building libosmo-dsp..."
cd $SDRROOT
git clone git://git.osmocom.org/libosmo-dsp.git libosmo-dsp
cd libosmo-dsp

autoreconf -i
./configure
make
make install
ln -s /usr/local/bin/osmocom_fft /usr/bin/osmocom_fft

echo "[`date`] Building gr-iqbal..."
cd $SDRROOT
if [ -e $SDRROOT/gr-iqbal/build ]; then
    echo "[`date`] found $SDRROOT/gr-iqbal/build.  Uninstalling previous version."
    cd $SDRROOT/gr-iqbal/build/
    make uninstall
    make clean
    cd $SDRROOT
    rm -rf gr-iqbal
fi

cd $SDRROOT
git clone git://git.osmocom.org/gr-iqbal.git gr-iqbal
mkdir gr-iqbal/build
cd gr-iqbal/build
cmake ../
make
make install
ldconfig

echo "[`date`] Building gqrx...."
if [ -e $SDRROOT/gqrx/build ]; then
    echo "[`date`] found $SDRROOT/gqrx/build.  Uninstalling previous version."
    cd $SDRROOT/gqrx/build/
    make uninstall
    make clean
    cd $SDRROOT
    rm -rf gqrx
fi

apt-get -y install libqt4-dev libqtcore4 libqtgui4 libqt4-network libqt4-svg
cd $SDRROOT
git clone https://github.com/csete/gqrx.git gqrx
mkdir -p gqrx/build
cd gqrx/build
qmake ..
make
make install
ln -s /usr/local/bin/gqrx /usr/bin/gqrx

echo "[`date`] For a Raspberry Pi 2 add the following lines to /boot/config.txt"
echo "framebuffer_depth=32"
echo "framebuffer_ignore_alpha=1"
echo ""
echo "[`date`] for Pulseaudio to work correctly in gqrx on a Raspberry Pi/2, edit /etc/pulse/default.pa and add the line:"
echo "load-module module-alsa-card device_id=0"
echo "then reboot."

echo ""
echo "[`date`] Done."

# -----------------------------------------

[Alexandru Csete]

Hi,

I have seen people run gqrx on the Odroid C1 (quad core) as well as
the new Ettus E310 which has a Zynq 7020 with dual core ARM Cortex A9.
So, it is certainly possible but I suspect that until there are
packages built for specific targets special precautions must be taken
for this to be successful.

First, GNU Radio should be built from source for that specific target.
Once built, the volk_profile tool should be run on target to determine
which FPU insructions give the best performance.

Second, I don't think using pulseaudio is a good idea unless the OS
running on the target uses it already. AFAIK raspbian does not, so
gqrx should be built with gr-audio support instead.

I hope this helps.

Alex

[ghos...@gmail.com]

I had a chance to work on it a bit last night and volk_profile ran to completion and produced a config file, but no noticeable improvement.  I tried building gqrx both with pybombs and from source tarball and both gave errors building volk with a test all error, so I stuck with the 3.7.5 build from the Jesse repo. The cores still run relatively pegged.

I do notice in the console with gqrx running that I get printing characters "UOa", not necessarily in that order.  Are they codes for internal errors or anything?

I just think that A7 processor in the Pi2 still may not have enough processing capabilities to run it.

[Alexandru Csete]

On Tue, Mar 3, 2015 at 6:10 PM, <ghos...@gmail.com> wrote:
> I had a chance to work on it a bit last night and volk_profile ran to
> completion and produced a config file, but no noticeable improvement. I
> tried building gqrx both with pybombs and from source tarball and both gave
> errors building volk with a test all error, so I stuck with the 3.7.5 build
> from the Jesse repo. The cores still run relatively pegged.
>
> I do notice in the console with gqrx running that I get printing characters
> "UOa", not necessarily in that order. Are they codes for internal errors or
> anything?

THey are error messages coming from GNU Radio blocks that interface
with hardware

U = underrun
O = Overrun
a = audio

It means the software is not producing or consuming samples fast
enough, which is to be expected if the CPU load is very high.

Do you see any volk message in the terminal during startup? Something
like "Using volk machine ...."

Alex

[ghos...@gmail.com]

Yes it says:
Using Volk machine: neon_hardfp_orc.

It picked audio sink arch: alsa.  Other than some "Could not resolve property : pattern10600" (which I think I found some references that that's normal), everything seems to start okay.  I did some googling and someone said that the A9 processors you could expect 20-50% speed improvements over the A7's simply based on architecture.  I'm still betting the CPU's just under-powered.

Just FYI, on the Pi, compiling from source gave an error in compiling volk (which is why I stuck with the jesse repo version):
CMakeFiles/Makefile2:129: recipe for target 'volk/lib/CMakeFiles/test_all.dir/all' failed
make[1]: *** [volk/lib/CMakefiles/test_all.dir/all] Error 2
Makefile:147: recipe for target 'all' failed
make: *** [all] Error 2