Gqrx vs SDRsharp

[Peter Barrett]

I have a Dell Studio 1.7GHz dual core machine which dual-boots Windows Vista and Debian Jessie/sid

I installed gqrx 2.2.0.74 precompiled binary from the repo
gr-osmosdr 0.1.1
gnuradio 3.7.2.1

top shows that gqrx consumes 98% CPU to start and then it may settle down to 75% while listening to WB FM broadcast.
Sometimes the application never settles and the audio is unintelligible and choppy.
The audio quality is never really good.
The side windows for audio, FFT RX and input do not size properly and the window is frequently untidy.

On the other hand SDR sharp over Windows Vista requires just 30% CPU to start and then settles to 20%. The audio is quality is streets in front of gqrx.

My rating:

Windows SDRsharp 8/10
Gqrx                        2/10


 

[Kurt]

Creeeeeiiiiipes,

 

      All's I did was get a Kali Linux ISO image, burned it to DVD, loaded it on a 40gb laptop drive I had lying around,

used the Kali package manager to unload the endogenous gnu-radio and qthid fundongle stuff.  Used the build script for gnu-radio here to

do the three hour build after doing the script changes:

 

www.sbrac.org/files/build-gnuradio

 

Make the simple script changes recommended with this video:

 

http://dangerousprototypes.com/2013/05/22/tutorial-kali-linux-with-gnu-radio-gqrx-and-rtl-sdr-dongle/

 

Use a large enough video display so one can see the script changes the author is doing.  They're really quite simple.

 

Once that is done and the gnu-radio "suite" is installed do a qmake and make on gqrx and one is good to go.

 

I initially loaded Kali, did the script changes and built gnu-radio.  I then tried to build Gqrx to no avail.  What my problem was that

I had the "old" versions of gnu-radio and qthid sitting around from the original Kali install that Alex  pointed out needed to be deleted.

I used the Kali package manager to deleted the old files.  Once that was done, all was well.  Took me two days to get it going.

Follow these instructions and the time will be cut down to about 5 hours from a bare drive.

 

I've used Slackware since 1994 but I am by no means an expert or a programmer.  Rather than take weeks to get SDR to work on slack, I

took the easier way out by doing a different distro.

 

So basically, load Kali linux on any drive you have floating around and not using.  Unload the "endogenous" gnu-radio and qthid stuff.

The Kali package manager is quite clear and you will see the old version numbers.  Put 'em back into the box!

Modify the script and get it to do the 3 hour or more gnu-radio build.  Takes a loooooonnnnnng time but one gets a good installation.

Do the rtl_test command with one's dongle in place to make sure the device is recognized and then do the build on Gqrx.  Just do qmake gqrx.pro and then make. Should find the executable in the directory.  Fire it up and go.  The Gqrx build is done in minutes on the Kali linux

setup described above.

 

                                                                                        Kurt

--
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/f3c85c48-8de0-4b0d-b774-f4034b829bcc%40googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

[grege...@gmail.com]

I am a big fan of software defined radios.  I currently have an SDR-14 and an SDR-IQ from RFSpace, a QS1R from SRL, a Funcube Pro Plus, and an RTL dongle.  I am also a big fan of Linux for philosophical reasons.  I have been using Linux for years as the default OS on my desktops and laptops.  Whenever possible, I also use Linux with my SDR hardware.  In fact, I purchased the QS1R specifically because it's software, SDRMAX, can be compiled and run in Linux.  I of course greatly appreciate Gqrx as a Linux application for my FCD and RTL.

Having said all that, I am coming to the painful conclusion that as of today, SDR software just seems to run better under Windows than Linux.  Doesn't seem to matter which hardware or which software app.  Audio is usually better, spectrum displays are usually crisper, and CPU load is either the same or less under Windows.  Even with my QS1R running the same version of SDRMAX on the same (dual boot) computer, the performance under Windows is markedly better.

I am not a programmer or software engineer.  Does anybody know if there is something inherently "better" about the Windows architecture when it comes to real time DSP?  Or is the development of SDR software in Windows just more mature?

This is not a dig on Gqrx, I think it is one of the best things going in Linux SDR and I know it will only get better.

Greg Ella

[Alexandru Csete]

Hi Greg,

Thanks for your feedback and for formulating it in a way that makes
sense and is easy to relate to.

I am not going to question your conclusion that SDR on windows is a
better experience than SDR on linux. You are probably right. I don't
use windows so I can't really tell. I think one of the reasons why
that may be the case is the lack of proper drivers on linux. We have
come a long way since the 90'es when it really took a serious effort
to get linux up and running on anything. Today linux works out of the
box in most cases; despite that there are still many hardware vendors
who don't give a rats ass about linux and only provide drivers for
windows. Consequently, many linux drivers are reverse engineered from
windows binaries and can not take full advantage of the hardware. This
has become an increasing problem with cheap onboard audio devices
which often rely on the drivers to compensate for shortcomings of the
hardware itself.

I should probably also make it abundantly clear to everyone that it
has never been my objective to compete against any SDR application
running on windows. To me, windows is not an option; nor is it my goal
to convert people from windows to linux. If somebody is happy running
sdrsharp or any other sdr on windows then really why bother with linux
and gqrx???

Most SDR applications that I know of on windows are actually
professional and commercial applications. I don't know if people have
any idea what difference it can make that someone works on something 8
hours / day versus working on something few hours per week... Taking
that into consideration I should probably feel honored that gqrx is
good enough to be compared to other SDR running on windows.

There is also another matter worth considering. Most other SDR
applications you will find out there (for any OS) are designed and
written from scratch for end users. Gqrx is basically just a fancy GUI
built on top of GNU Radio. GNU Radio is a general purpose DSP and SDR
framework and as such is not optimized for "ham radio". I made gqrx
this way because I figured this could provide a flexible starting
point for others who wish to experiment with SDR by modifying gqrx and
playing around with the underlying gnuradio. Apparently, that scope
has exploded and gqrx has become and end user application.

I could go on for a long time. I'm not trying to find excuses; just
hope to shed some light on why things are the way they are..

Alex

[Simon Kennedy]

Hi Alex,

as always there are many sides to a story. My experience is that gqrx running under Lubuntu on my netbook with 1Gb RAM performs very well, where Windows 7 with any of the Windows SDR programs that I have tried will hardly run on the same machine. Of course, gqrx also works well on my desktop Ubuntu machine.

Keep up the good work.

Regards

Simon.

On 12 February 2014 21:40, Alexandru Csete <oz9...@gmail.com> wrote:

Hi Greg,

[Peter Barrett]

SDR# is open source (MIT license) except for the DSP components, which are MS-RSL=very much restricted (look, but don't touch!)
https://www.assembla.com/code/sdrsharp/subversion/nodes.

Simon can you be more specific about your hardware and the apps you have tried?

I don't want to direct people away from gnu any more than the most one-eyed linux fanboy but we must be objective.

assembler-level optimisation with SSE2 might get linux dsp up there with the MS/intel stuff?

73devk6fun

[Alexandru Csete]

On Thu, Feb 13, 2014 at 4:24 AM, Peter Barrett <vk6...@gmail.com> wrote:
>
> assembler-level optimisation with SSE2 might get linux dsp up there with the
> MS/intel stuff?

Optimisations may help but I'm not sure in the case of gqrx will have
much effect. Most of the DSP code in gnuradio is already optimized to
use assembly level optimisations through the volk library
(http://gnuradio.org/redmine/projects/gnuradio/wiki/Volk). Basically,
volk has the most common DSP operations implemented using various
architecture dependent code that can be selected at runtime. When you
start gqrx or any other gnuradio based application in a terminal, you
can see messages like:

Using Volk machine: sse4_2_64

If it prints "generic" instead of "sse...something" then there are no
optimizations available for that machine and it will be slow like
hell. One can try to run the volk_profile application and see if that
will change anything.

Anyway, as I wrote in my previous mail, gnuradio is a general purpose
SDR framework. It works equally well for a simple ham radio receiver
as for a complex digital systems. This leads to a lot of overhead that
can be optimized away when writing applications from scratch.

I have a proof of concept SDR application written without gnuradio
that performs everything required by a ham radio receiver (only DSP,
no graphics). It runs almost real-time on a raspberry pi and has no
significant CPU load on a PC where gqrx runs at ~40% CPU load. And I
haven't even done any assembly level optimizations.

Alex

[Peter Barrett]

Yep I would describe gnuradio as a research tool rather than a design system.

That VOLK stuff is good reading thanks for the link.

rtl_sdr on a raspi is about 20% cpu

I don't know how much optimization you can do with a RISC processor. Not as much as CISC and it would take the compiler a looooong time, I would have thought.

73devk6fun

On Saturday, February 8, 2014 9:06:14 PM UTC+8, Peter Barrett wrote: