WX GUI FFT sink on Raspberry Pi

I installed GNU Radio version 3.7.2 on my Raspberry Pi from the Raspbian
Jessie repository. It is working great for modeling a simple SSB
receiver. I
want to compare the CPU performance of the QT GUI Frequency Sink and the
WX
GUI FFT sink. The QT GUI Frequency display works fine. The WX GUI FFT
window
shows the controls but the FFT display is blank. Does anyone know a fix
for
this? The same flowgraph works fine with GNU Radio version 3.7.0 on my
MacBook running Ubuntu 13.10.

Regards,

Jim L.


View this message in context:
http://gnuradio.4.n7.nabble.com/WX-GUI-FFT-sink-on-Raspberry-Pi-tp46197.html
Sent from the GnuRadio mailing list archive at Nabble.com.

On Fri, Feb 7, 2014 at 1:18 AM, Jim L. [email protected] wrote:

Jim L.
The RaspberryPi is a pretty light-weight processor. WxGUI does a lot
of processing in Python, and it could just be that the processor
stalls with the amount of work it’s trying to handle.

Tom

Seems more viable to run it on a more modern cpu, such as
http://www.rtl-sdr.com/demonstrating-gqrx-running-beaglebone-black-rtl-sdr/

Hi Murat,

It was easy to install GNU Radio on the Raspberry Pi. I started with the
2014-01-07-wheezy-raspbian distribution.

Add the following entry to the /etc/apt/sources.list file:
deb Index of /raspbian jessie main contrib
non-free rpi

sudo apt-get update

sudo apt-get install gnuradio

73,

Jim N7IHQ


View this message in context:
http://gnuradio.4.n7.nabble.com/WX-GUI-FFT-sink-on-Raspberry-Pi-tp46197p46213.html
Sent from the GnuRadio mailing list archive at Nabble.com.

On Fri, Feb 7, 2014 at 9:25 PM, Wayne R. [email protected]
wrote:

Seems more viable to run it on a more modern cpu, such as
Demonstrating GQRX Running on a BeagleBone Black with RTL-SDR

I would not completely discount performance of the Raspberry Pi -
notably floating point performance against the Cortex-A8. In many
cases, the performance gap is probably smaller than a change of
architecture generations would normally dictate. The Raspberry Pi has
a full VFP implementation versus the more or less crippled
non-pipelined VFPLite version on the A8. It’s true that the A8 does
have a NEON unit, which is extremely capable, but that chunk of
silicon won’t see full use without explicitly written instructions.

Regarding the original question, is the CPU choking? Perf results
would be telling, but numbers from top are better than nothing.

-TT

Murat TA1DB wrote


Cmake couldn’t find GnuradioConfig.cmake file, I found this file of the
same version from my other computer running without problem and copied the
missed file into correct directory on Rpi. This couldn’t be the solution
either.

I duplicated your steps to build the osmocom modules and got the same
error
messages.

First, I had to install the Boost development files.
sudo apt-get install libboost-all-dev

Cmake fails because the GNU Radio development files are missing.
sudo apt-get install gnuradio-dev

Now Cmake works, but make fails because log4cpp development files are
missing.
sudo apt-get install liblog4cpp5-dev

Now make builds successfully. Let me know if this works for you.
Perhaps I should start a separate thread about installing GNU Radio from
the
repository
on the Raspberry Pi.

73,

Jim N7IHQ


View this message in context:
http://gnuradio.4.n7.nabble.com/WX-GUI-FFT-sink-on-Raspberry-Pi-tp46197p46285.html
Sent from the GnuRadio mailing list archive at Nabble.com.