Any one running any SDR solutions

[oxoocoffee]

Hello,

I am thinking about getting PBP but wondering if anyone here is running SDR (Software Defined Radio).

1. What districts you using?
2. What hardware you using?

• HackRF
  
• RLT-SDR
  

3. Does GNU Radio works?
4. Any other software success stories?

Cheers

[ab1jx]

RTL-SDR is very reliable, it's been around a long time, works well enough with a cheap standard RTL2832 dongle (under $10). BUT, if you step up to the fancier version with TCXO you don't have to enter a PPM correction for the cheap crystal. You'll probably get direct tuning (tries to tune some HF under 27 MHz), and bias tee support (can power a preamp or upconverter). I've got a couple I got for about $18 on Aliexpress. If you want to listen to SSB the cheaper dongles have enough drift to be a nuisance.

CubicSDR is probably the best software I've found. It's in the debs for Buster and up. I'd rather avoid Gnuradio, it's mostly bloatware. If you want to experiment with different modulation methods maybe but for everyday use it's just too complicated and big. GQRX uses Gnuradio, it's just an app under it. HackRF I think is used by CubicSDR, several things are, so you can try it by itself.

[midnightcheese]

I've played around with an RTL-SDR + Gqrx. Everything works as expected. CPU use is high, running about 50% across all 6 cores, but it's a good experience if all you're doing is listening.

[ab1jx]

If you want to listen use rtl_fm (in rtl_sdr).  It's very efficient but it has no GUI for tuning.  Use a GUI program to find what you want to listen to then set up some little scripts to call rtl_fm with the right frequency, mode, PPM correction, etc.  I had a cron job making daily podcasts of the BBC Newshour by recording in MP3 through Sox, worked quite well.  This was on a Raspberry Pi 3B.  It would work fine for monitoring a repeater, just get the right squelch level by experimenting.  Or any single frequency really.  It's not that practical to make it scan because if you go out of a 2 MHz range you get all these delays waiting for the PLL to lock.  1 dongle per frequency or 2 MHz band might work out, not sure how you'd combine the audio.  Try rtl_fm --help and study the output.

My newshour script:

Code:

#!/bin/sh
adate=`date +"%Y-%m-%d_%H-%M"`

/usr/local/bin/rtl_fm -f 89300000 -M fm -s 190k -p 59 -r 48k - | sox -t raw \
-r 48k -b 16 -e signed-integer -c 1 -V1 - -t  mp3 bbc_nh_$adate.mp3 trim 0 59:50

BBC is rebroadcast on a local NPR FM station here late at night.

It's the flashy GUI junk that's wasting CPU because none I've seen yet use the GPU for that.  Cubicsdr has several spectrum displays plus a waterfall or two going all the time, no way to turn them off.  Other than that it's not too bad.  It doesn't use Gnuradio like GQRX I don't think.  Gnuradio has tons of Python, not very efficient.

[manawyrm]

Running Manjaro with AirSpy HF+/R2, PlutoSDR (my favorite), HackRF and the RTL-SDR works pretty well. The USB port power supply is a bit weak, so I had to use an external powered hub for the HackRF. The PlutoSDR has a second power input, which is nice. 

I've tried GnuRadio and GQRX, with gqrx I was able to display ~2 MSPS without buffer overflows. It's quite the CPU intensive process after all. 
This can certainly be optimized when all the ARMv8/aarch64 NEON capabilities are correctly used, but I haven't looked into that yet. 

My recommendation for SDR is definitely try a modern mainline distro with aarch64 userland (like Manjaro), because you're wasting a lot of performance otherwise.

73, 
DL4TMA, Tobias

[Jeffersoniantoo]

I have been successful with a RTL-SDR and GQRX. I am still trying to get my SDRPlay RSP1A to work. It took me 50 hours to get it to work on my AMD laptop, so I have not given up yet. 8>D

Seems to be a Soapy interface issue.

[ab1jx]

The CPU intensive part of a GUI SDR program is the GUI itself, all the redrawing that the CPU is doing.  Find a way to turn that off, since you don't need it once you get a signal tuned in, or use the GPU to do that, or use rtl_fm.  I've been fiddling with trying to write one for a couple years, using librtlsdr to deal with the USB and dongle.  I've done the graphics at least 3 different ways and it's always the bottleneck.

Debian Buster (and later) has Cubic SDR in the debs, just click on it in Synaptic and it installs and works.  Both that and GQRX have tons of dependencies and neither is as efficient as it could be.

This is from 2014 by a Peter Onion https://www.youtube.com/watch?v=0IZxzm4R1bo  It's an SDR program of his running on a Raspberry Pi.  The graphics are done in OpenGL ES where the waterfall is actually a rotating texture.  It's not a full-fledged SDR program because it's just a panadapter that's showing the IF (Intermediate Frequency) output of some other radio.  I don't know what ever happened to it.   Notice there aren't widgets like text, frequencies, pointers.  I think you'd need to put the spectrum and waterfall into a window and put widgets around it.  The OpenGL ES would be rendering directly to the framebuffer and using the full screen, something like GLFW would make it more manageable.

Using OpenGL ES for this is kind of backwards and not very efficient but it sort of works.  It would probably be better to do it in Vulkan.  2 - 30 times per second you get a bufferfull of data which you need to scale and plot as the spectrum at the top.  Then with that same data you convert peak heights to colors and draw one line.  The waterfall is just copying that line down 1 pixel for each batch of data.  The GPU has at least dozens of processors that could be handling that.

[bluemage]

I've been trying to get my sdrplay rsp1a to work with the pinebook pro. I've gotten the sdrplay drivers/api to compile fine but I've been having trouble with cubic. It can compile. I tried with armbian bionic and got it working but then it subsequently crashed everytime after the first run. haven't tried armbian buster but I expect its about the same. I don't remember if I tried cubic with the default os but I think I did and ran into some problem.