Featured Articles
Announcing Pi
Technical Specifications
Raspberry Pi FAQs
Win a Pi
Raspberry Pi Wishlist
Actions
Forum Thread Details
  • Replies 40 replies
  • Subscribers 664 subscribers
  • Views 7638 views
  • Users 0 members are here
Related

Evaluate GNU Radio application performance on Pi4(2G)

colporteur

The results after using a Raspberry Pi 3B+ to run a GNU Radio flow graph were unacceptable. The audio outputed from the Pi was distorted. I speculate the SBC doesn't have the performance specification to support GNU Radio.

 

I am trying to determine if the Raspberry Pi (version ?) is capable of supporting a GNU Radio flow graph. My current assessment is no. The hardware performance is not sufficient to handle the digital signal processing requirements.

 

It was suggested I make a forum post while some testing was done, so other interested could follow.

 

My objective was to write a tutorial for the GNU Radio application using a Raspberry Pi. After successfully building two GNU Radio flow graphs on my Ubuntu 18.04 i7 processor desktop, I ported the flow graphs to a Pi3B+ connected to an HDMI with audio monitor. One flow graph is an audio signal generator outputed to a speaker. The second is an FM receiver. Both flow graphs work in the sense they produce audio but with distortion and in the case of FM broadcast, unreadable.

 

The audio flow graph requires a GNU Radio software installation. The FM flow graph requires an SDR dongle to gather a broadcasted signal to feed the GNU Radio FM radio receiver flow graph. The test will be using the audio flow graph since no additional hardware is required.

 

image

  has agreed to use his Pi4(2G) to run the test. Before starting the exercise, I will ask Christopher to review review the procedures and provide feedback. I'm keeping the the verbiage terse, assuming a higher level of understanding. If more details are required or feel something is more appropriate or missing please let me know.

 

A zip file of two flow graphs is attached. The file with basic is minimal as it gets. The second file provides a test module. I experienced a problem with both.

 

 

Test Procedure:

Fresh install of Raspbian Buster Full, current release.

Apply O/S updates/upgrades & Install GNU Radio

 

///CODE START///

sudo apt-get update -y;sudo apt-get upgrade -y

sudo reboot

sudo apt-get install gnuradio

///CODE END///

 

Take screen shots of htop screen at the following milestones.

1. O/S idle, no application running on the GUI desktop other than what is defaulted.

2. GNU Radio started, no flow graph

3. GNU Radio flow graph loaded.

4. GNU Radio flow graph started.

5. Evaluate audio coming from speaker and advise.

 

Depending on results, i would like to expand the test Ginny pig agreed.

 

Sean

 

Message was edited by: sean conway I have uploaded the two audio flow graphs for GNU Radio. The current version of GNU Radio encourages development in QT widgets verses the WX widgets. Three is discussion in the community support for WX will disappear. The flow graphs provided are QT. Sean

Attachments:
gnuradio.zip
gnuradio_FM.zip
  • in reply to colporteur

    > What is your assessment of the HackRF?

     

    It's more capable than I am, and I wish I had two of them.

  • Running Pi 4, 4GB in a cooled case

    - downloaded latest raspbian

    - installed latest updates

    - installed latest firmware

    - installed latest bootloader

    - ran sudo apt-get install rtl-sdr gnuradio gr-osmosdr

     

    image

     

    - opened gnuradio

     

    image

     

    - opened file audio_QTv1.grc

    - clicked to 'generate'

    - clicked to 'run'

    - received error 'xterm executable is missing, you can change this setting in your gnuradio.conf in section [grc] xterm_executable

    fix- https://steemit.com/raspberrypi/@chirimenjako/gnuradio-tips-terminal-error

     

    - Ran again

     

    execute:

    Warning: failed to XInitThreads()

    qt5ct: using qt5ct plugin

     

    (process:2326): Gtk-WARNING **: 21:36:30.684: Locale not supported by C library.

    Using the fallback 'C' locale.

    gr::log :INFO: audio source - Audio sink arch: alsa

    gr::log :ERROR: audio_alsa_sink0 - [default]: set_channels failed: Invalid argument

    Traceback (most recent call last):

      File "/home/pi/gnu/gnur/top_block.py", line 172, in <module>

        main()

      File "/home/pi/gnu/gnur/top_block.py", line 161, in main

        tb.start()

      File "/usr/lib/python2.7/dist-packages/gnuradio/gr/top_block.py", line 109, in start

        top_block_start_unlocked(self._impl, max_noutput_items)

      File "/usr/lib/python2.7/dist-packages/gnuradio/gr/runtime_swig.py", line 5656, in top_block_start_unlocked

        return _runtime_swig.top_block_start_unlocked(r, max_noutput_items)

    RuntimeError: check topology failed on audio_alsa_sink(2) using ninputs=1, noutputs=0

  • in reply to cstanton

    G'Day,

    The last line in your error message I have seen on other installs.

    RuntimeError: check topology failed on audio_alsa_sink(2) using ninputs=1, noutputs=0

     

    I haven't narrowed down the problem or a permanent fix. I have seen the error message posted but haven't found any reliable knowledge directing to a solution.

     

    I did stumble across a kludge that got GRC working.

    install gqrx-sdr and/or cubicsdr

     

     

    Take a look at my post above. I have another person who ran into problems.

     

    Can you tell me if you get GRC to run a flow graph. I suspect the audio may suck.

     

    Sean

  • in reply to colporteur

    Another work around is to establish a bluetooth speaker. I just tested this and it eliminates the issue.

     

    A side effect, the audio sounds correctly. I suspect the bad audio was related to what ever audio configuration I had on the Pi. I haven't tested it yet but I am thinking the FM test circuit will work also.

     

    I am not familiar with Pi audio to identify the issue but that is where I think my investigation needs to go.

     

    Sean

  • Former Member
    Former Member

    I used Gnu Radio GUI to generate a Python program for audio_QTv1.grc from the gnuradio.zip file.  The generation went fine.  But, these issues are apparent:

    (1) The generated code used the print syntax of Python 2.  This was easily fixable.

    (2) There are no Python 3 libraries as a result of the installation (apt install gnuradio).  I could only find gnuradio packages in /usr/lib/python2.7/dist-packages/gnuradio.

    (3) For those of you who use Anaconda instead of pip/pip3 to maintain your packages, this is probably a show stopper.

     

    Note that Python 2 is deprecated as of 2020-01-01.  Many developers are in the process of migrating to Python 3, particularly in scientific communities.

     

    So, if you want Python 3 support, do not do this immediately:  sudo apt-get install gnuradio

    Instead, use the PPA methodology first as described on https://wiki.gnuradio.org/index.php/InstallingGR#Ubuntu_PPA_Installation and then:  sudo apt-get install gnuradio

  • Former Member
    Former Member in reply to Former Member

    With the newer version of GRC, it generated a Python 3 version of top_block.py that worked fine the first time.

  • in reply to Former Member

    Can i get some clarification. I feel like we are both flying around the same light bulb seeing something different.

     

    • How are you installing GRC (i.e. GNU Radio). apt-get or compiling?
    • What version of GRC is reported within the application?
    • I understand the python version relationship. I thought a 3.8 install of GRC was Python3 and Python 2 was gone. Is this correct?
    • I am seeing differences in GRC version depending if the load is for a Pi or say a Ubuntu Linux. You suggest a newer version of GRC will produce a top_block for the audio flow graph without errors. That has not been my experience as late as my last post. What do you believe is a new version of GRC?

     

    This post I stumbled across https://github.com/lutusp/PLSDR/issues/6  alludes to a similar error code. It is pretty general on the problem description but rings to an audio configuration problem with the application. I'm thinking GRC is expecting a particular audio configuration on the Pi that is not there generating the error. The work around of establishing a bluetooth configuration puts in place a audio configuration GRC can use. I wish I was more familiar with Pi audio architecture but I work with what I have.

     

    I do like your thought process and would like to continue the discussion. My goal is to establish a consistent process for a Pi GRC installation. The process would give you the ability to verify the install to say this should work.

     

    Sean

  • Former Member
    Former Member in reply to colporteur

    My premise is that I will no longer use Python 2 since it is deprecated; all of my projects are now converted to Python 3.  What I described previously was what I did for an x86/x64 APT-based Linux system like one of the *buntus or debian.  On my Xubuntu x64 build, it worked perfectly.  Clearly, this is not appropriate for a Raspberry Pi.  So, I'll see what I can do on my Raspberry Pi 3B (don't have a 4 yet) which boots and runs from a USB disk (relief from using a MicroSD which I highly recommend!).

     

    This is what I found for the Raspberry Pi: https://wiki.gnuradio.org/index.php/InstallingGRFromSource_on_Raspberry_Pi which leads you to https://wiki.gnuradio.org/index.php/InstallingGR#To_install_system_wide as part of installation.

    I did this because the existing Raspbian Buster does not yet have a Python 3 oriented package for gnuradio; this is a "build from (github source") exercise.  Certainly, gnuradio 3.8.0 (latest github version) will eventually find its ways into all of the repositories.

     

    On a Raspberry Pi 4, building from source is MUCH faster, I would imagine! image

     

    If you are not worried about excess heat and freezing up, when you get to the `make` step, use the -j parameter for specifying more than one CPU cores.  I used `make -j3 # 3 CPU cores` since my Pi is otherwise idle at the moment.  It feels cool to the touch but, then again, it is not a Pi 4.

     

    Version: The CHANGELOG.md file on github indicates that this is [3.8.0.0] - 2019-08-09.

    Python flavor: I selected Python 3 per instructions (recommended). I did not try Python 2.

    Differences in GRC between Pi and Ubuntu: Going to be looking out for this.  Thanks for the heads up.

     

    Begin make step at 13:25 USA CT.  I'll report when the make step ends. Time for tea and scones.

    image

  • in reply to colporteur

    If you live in a rural area you are lucky! FM radios are boring, satellites are much  more interesting!

  • in reply to colporteur

    FM radio is relatively easy to demodulate. You can probably demodulate mono FM in Python (no GRC) in less than 20 lines of code; and its a pretty good excercise to actually understand how FM works.