Problems getting GQRX running on RPI3 with Lubuntu

[vk3...@gmail.com]

My setup:

RPI3

Latest Lubuntu 16.04 (from https://ubuntu-pi-flavour-maker.org/download/)

Using a 16GB Class 10 SD card

Expanded the file system (not sure if this is necessary with this OS distribution but it does not do any harm) and performed the upgrade/(dist-)update steps to bring everything up to the latest version

I have tried both:

- using the PPS libraries as per http://gqrx.dk/download/install-ubuntu

- just installing gqrx-sdr (and with it gnuradio and rtl-sdr packages) from the default package repository

In all cases the rtl_test and similar apps all run OK as does omocom_fft, so I'm happy that the RTL2832 dongle is working OK.

I've run the volk_profile and it has selected the neon architecture as appropriate.

I've run 'top' in one window while running gqrx form the command line in another.

My problems (which may all be related... or not):

1) gqrx starts with the configuration screen the first time, but even if I then close it down straight away, it always says there is a problem with the config file and brings up the config display again.

2) the bottom of the window is below the bottom of the screen and I can't move the top of the window down to reduce the window size (if I could then I hoped to move the window up the screen to see it all). I therefore need to up-dock the audio display so I can see it
I got this with the Mate desktop as well which is one reason why I moved to Lubuntu - it also bought me a more light-weight desktop (I hope!).

3a) I configure the RTL dongle to have a very low sample rate (e.g. 240KHz) and start the decoding. Within a minute or so the FFT display freezes and I start getting "OOOO" in the console window. Also the CPU usage drops from abut 170% to about 50%. I need to ^c the process as it never recovers once this starts.

3b) I configure the RTL dongle the same way and start the decoding but I then get a 'bus error' crash

My ultimate goal is to get gqrx being frequency controlled by gpredict and have the audio fed to WxToImg.

The fact I'm using about 170% of the CPU only makes me think that this should be possible (i.e. I'm not max'ing out the CPU) but I can't get gqrx to run reliably.

Can anyone please suggest what I'm doing wrong?

Susan

[Larry Dighera]

Hello Susan,

I have similar gqrx lock-up problems with the current gqrx release version.
However, gqrx version 2.5.3-37-g795e8be runs on my RPi3 under Debian Jessie
(noobs) with Airspy Mini & Spyverter connected, and produces a smooth
waterfall. To provide gqrx all the CPU cycles possible, I over-clock the RPi
CPU with this entry in /boot/config.txt: arm_freq-1100 (higher CPU frequencies
seem to negatively affect system stability/reliability). To overcome RPi
overheating, it was necessary to install a fan
<https://www.amazon.com/gp/product/B00YBS1010>; in my opinion, a fan is a
requirement for the RPi3 with its stacked chips.

Launching gqrx produces this message: libegl: Warning: DIR2: Failed to
authenticate (Some info here: <https://pi3d.github.io/html/FAQ.html>.), but
gqrx runs with 90-98% CPU loading (as indicated by the X11 widgit) when I click
Start. PulseAudio is configured with Sinks: bcm2835 ALSA Analog Stereo, and
Sources: ALSA_output.0.analog-stereo-monitor. Unfortunately, the audio
stutters to the point of being completely unintelligible. Recording audio with
gqrx succeeds sometimes producing a .wav file that is playable with ALSA
(aplay), but recording usually locks up gqrx.

My current guess is that Pulseadio is probably the main obsticale to getting
gqrx operational on the RPi3. By compairson, CubicSDR does operate nominaly,
if slugglishly.

If you should be successful in coaxing gqrx to operational status on the RPi3,
please post your results on this list. Thank you, and good luck.

Best regards,
Larry
WB6BBB

[Robin Gape]

Susan,

1) does this string offer any inspiration?
https://groups.google.com/forum/#!topic/gqrx/WymwzGiv8mg

2) You didn't tell us what resolution the screen is that you're using when the window fell off the bottom. The default window height seems to be 755 pixels, which can be minimised to 642 pixels. On other desktops Alt-F7 brings up a hand icon mouse pointer. Moving the mouse—but not pressing any mouse key—allows one to move the whole window around, including moving the window beyond the top of the screen. Pressing a mouse key restores normal mouse operation. My recollection is that this procedure works with the Lubuntu desktop. (My one Lubuntu machine is currently out on loan.)

3) OOOO indicates a buffer overflow. In other words, data is coming in faster than it may be consumed, probably as a result of a buffer being filled.
3A) The design of GQRX is outlined in
http://gqrx.dk/doc/gqrx-design#more-136
which notes that GQRX is built upon GNU Radio. One suspects—but is willing to be proved wrong—that GNU Radio implements each processing block single-threaded. (The volk_profile utility runs single-threaded.)
3B) Thus, the salient metric is the occupancy of the CPU core which is most intensively running. If one of the cores is running at 100%, that would be the culprit.

4) If the analysis above is correct, then overclocking the RPI3 and fitting an after-market heatsink to cope with the heat dissipation may be in order. It is also possible that the RPI3 is thermally overloaded after 2 minutes and thermally throttling back which would also trigger a buffer overflow. Again, the obvious solution is a heatsink, as used by Larry.
4A) For comparison, the ODROID C2
(http://www.hardkernel.com/main/products/prdt_info.php?g_code=G145457216438) has a beefy heatsink included. The RPI3
(http://uk.rs-online.com/web/p/processor-microcontroller-development-kits/8968660/) has no processor heatsink, presumably to reduce cost of manufacture.
4B) The ODROID C2 is capable of running GQRX, as noted:
http://gqrx.dk/blog/gqrx-on-the-odroid-c2#more-364 (the associated video is silent, BTW)

HTH, Good luck,

Robin, G8DQX

--
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/dc3c7ef7-b5a2-4d4b-8a11-9176056e9ffc%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[vk3...@gmail.com]

Sorry for the delay but I really only get to play with this on the weekends occasionally.

The screen is HDMI 1360x768 (according to the display as the RPi3 starts up).

I've noticed a couple of things that may or may not be relevant.

The RPi3 normally runs at about 60C and CPU at 600MHz with the occasional 'spike' to 1200MHz. This does not seem to change very much when gqrx is running except the 1200MHz is on for longer and (now that I have a heatsink on the processor) it gets to about 75C. 

Looking at the 'top' command, when gqrx is working correctly it uses just under 200% of the CPU. When gqrx 'freezes', the cpu usage goes down to about 50%.

All of this seems to indicate that the CPU is not overloaded.

I can select the alsa audio output or the 'default' (which I assume is pulseaudio) but that does not seem to make any difference.

I also seem to be getting "No audio FFT data" a lot but that also stops when gqrx freezes.

Actually, there seem to be different ways it freezes: sometimes the GUI is completely unresponsive, other times I can access the menu items but not turn off the DSP. I've also been able to click away from the GUI window and then come back and have it repaint correctly but other times the repaint doesn't happen.

Susan

[Larry Dighera]

Hello Susan,

My RPi3 CPU clock is set to 1100 in /boot/config.txt, and heat-sinks and fan
keep temperature, as reported by the X11 widget, to ~<=60'C; Maximum
permissible temperature is 70'C if I'm not mistaken. Here's the output from
sensors.sh and lscpu:

sensors.sh

S Y S T E M T E M P E R A T U R E OK

The BCM2835 SoC (CPU/GPU) temperature is: 123.8° F (51.0° C)
(70° C HIGH-TEMP LIMIT will be reached in 19.0° C higher)


S Y S T E M V O L T A G E S

The Core voltage is: 1.2000V
The sdram Core voltage is: 1.2000V
The sdram I/O voltage is: 1.2000V
The sdram PHY voltage is: 1.2250V


C L O C K F R E Q U E N C I E S

arm frequency(45)=600000000 Hz pwm frequency(25)=100000000 Hz
core frequency(1)=250000000 Hz emmc frequency(47)=250000000 Hz
h264 frequency(28)=250000000 Hz pixel frequency(29)=148500000 Hz
isp frequency(42)=250000000 Hz vec frequency(10)=0 Hz
v3d frequency(43)=250000000 Hz hdmi frequency(9)=163683000 Hz
uart frequency(22)=47999000 Hz dpi frequency(4)=0 Hz


Thu 28 Jul 19:41:43 PDT 2016
# lscpu
Architecture: armv7l
Byte Order: Little Endian
CPU(s): 4
On-line CPU(s) list: 0-3
Thread(s) per core: 1
Core(s) per socket: 4
Socket(s): 1
Model name: ARMv7 Processor rev 4 (v7l)
CPU max MHz: 1100.0000
CPU min MHz: 600.0000
-----------------------------------------------------------------------------

I had a mini breakthrough running gqrx on the RPi3. I edited the
/etc/pulse/daemon.conf file to enable pulseaudio daemon to run in realtime. The
following parameters were uncommented:

realtime-scheduling = yes
realtime-priority = 5

The sampling parameters were also changed to reduce CPU load:

resample-method = trivial # The fastest per manual page
default-sample-rate = 48000 # Re-sampling shouldn't occur
alternate-sample-rate = 44100 # pulseaudio daemon demands this parameter be
set

The pulseaudio daemon, already running, was then caused to re-read the modified
/etc/pulse/daemon.conf file with the following command:

pulseaudio --start

These changes resulted in about a 50% reduction of CPU load with RTL-SDR
dongle; here's top output after the changes in the /etc/pulse/daemon.conf file:

-----------------------------------------------------------------------------
top - 13:02:01 up 1:36, 2 users, load average: 3.28, 3.22, 3.00
Tasks: 156 total, 1 running, 155 sleeping, 0 stopped, 0 zombie
%Cpu(s): 53.2 us, 6.9 sy, 0.0 ni, 39.7 id, 0.0 wa, 0.0 hi, 0.2 si, 0.0
st
KiB Mem: 882788 total, 388876 used, 493912 free, 37420 buffers
KiB Swap: 102396 total, 0 used, 102396 free. 214912 cached Mem

PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
2139 root 20 0 521008 78136 52592 S 224.3 8.9 36:15.20 gqrx 1392
root 9 -11 168360 19724 18196 S 10.3 2.2 5:09.33 pulseaudio
1244 root 19 -1 127040 48580 22800 S 5.0 5.5 2:22.50 Xorg
1357 root 20 0 81868 23344 19352 S 0.7 2.6 0:19.21 lxpanel
1481 root 20 0 48448 20596 17092 S 0.7 2.3 0:15.83 lxterminal
70 root 1 -19 0 0 0 S 0.3 0.0 0:11.39 VCHIQ-0
-----------------------------------------------------------------------------

and the CPU Usage Monitor X11 widget indicated about 42% load.

With the AirSpy dongle, CPU load was ~<=90%:

-----------------------------------------------------------------------------
top - 13:23:57 up 1:58, 2 users, load average: 3.79, 3.16, 2.18
Tasks: 155 total, 2 running, 153 sleeping, 0 stopped, 0 zombie
%Cpu(s): 68.8 us, 20.1 sy, 0.0 ni, 8.9 id, 0.0 wa, 0.0 hi, 2.2 si, 0.0 st
KiB Mem: 882788 total, 448316 used, 434472 free, 38132 buffers
KiB Swap: 102396 total, 0 used, 102396 free. 229900 cached Mem

PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
2139 root 20 0 475364 119876 53556 R 315.2 13.6 49:56.12 gqrx 1392
root 9 -11 168360 33924 31604 S 36.0 3.8 6:43.36 pulseaudio 1244
root 19 -1 129952 51564 22872 S 6.6 5.8 2:42.84 Xorg 1481 root
20 0 49044 21024 17196 S 0.7 2.4 0:21.33 lxterminal 2902 root
20 0 5244 2608 2152 R 0.7 0.3 0:00.07 top 70 root 1 -19
0 0 0 S 0.3 0.0 0:13.91 VCHIQ-0
-----------------------------------------------------------------------------

not nearly as large a reduction in CPU load with the AirSpy, but the spectrum
span was awesome.

However there was NO AUDIO OUTPUT from gqrx with the RTL-SDR or AirSpy.

CubicSDR still consumed about 90% CPU with either RTL-SDR or AirSpy dongle:

-----------------------------------------------------------------------------
top - 13:34:16 up 2:09, 2 users, load average: 5.17, 4.52, 3.47
Tasks: 156 total, 1 running, 155 sleeping, 0 stopped, 0 zombie
%Cpu(s): 89.0 us, 2.8 sy, 0.0 ni, 8.2 id, 0.0 wa, 0.0 hi, 0.0 si, 0.0 st
KiB Mem: 882788 total, 466044 used, 416744 free, 38644 buffers
KiB Swap: 102396 total, 0 used, 102396 free. 232048 cached Mem

PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
2929 root 20 0 441092 131840 55512 S 356.4 14.9 18:32.25 CubicSDR
1244 root 19 -1 137376 55364 20880 S 4.0 6.3 3:14.41 Xorg 1392
root 9 -11 168360 40188 37868 S 2.3 4.6 8:02.34 pulseaudio 1481
root 20 0 49560 21592 17196 S 1.3 2.4 0:25.61 lxterminal 3023
root 20 0 5244 2600 2144 R 0.7 0.3 0:00.06 top 70 root
1 -19 0 0 0 S 0.3 0.0 0:15.36 VCHIQ-0
-----------------------------------------------------------------------------

CubicSDR audio was full, with only slightly discernable stutter which I
attribute to pulseaudio.

AirSpy dongle finally crashed CubicSDR:

Warning: ReBuffer 'SDRPostThreadVisualDataBuffers' count '120' exceeds
threshold of '100'

I'd be interested in learning if others find a benefit in making similar
changes to the /etc/pulse/daemon.conf file

Best regards,
Larry