I'm getting a segfault from trunk-recorder:

~snip~
[2019-11-02 18:13:03.580708] (info)   Driver: osmosdr
[2019-11-02 18:13:03.580738] (info)   Center: 8.555000e+08
[2019-11-02 18:13:03.580805] (info)   Rate: 10000000
[2019-11-02 18:13:03.580849] (info)   Error: 500
[2019-11-02 18:13:03.580885] (info)   PPM Error: 0
[2019-11-02 18:13:03.580914] (info)   Gain: 20
[2019-11-02 18:13:03.580950] (info)   IF Gain: 0
[2019-11-02 18:13:03.580979] (info)   BB Gain: 0
[2019-11-02 18:13:03.581009] (info)   LNA Gain: 0
[2019-11-02 18:13:03.581044] (info)   PGA Gain: 0
[2019-11-02 18:13:03.581082] (info)   TIA Gain: 0
[2019-11-02 18:13:03.581115] (info)   MIX Gain: 0
[2019-11-02 18:13:03.581147] (info)   VGA1 Gain: 0
[2019-11-02 18:13:03.581180] (info)   VGA2 Gain: 0
[2019-11-02 18:13:03.581210] (info)   Squelch: 0
[2019-11-02 18:13:03.581257] (info)   Idle Silence: false
[2019-11-02 18:13:03.581287] (info)   Digital Recorders: 3
[2019-11-02 18:13:03.581322] (info)   Debug Recorders: 0
[2019-11-02 18:13:03.581360] (info)   SigMF Recorders: 0
[2019-11-02 18:13:03.581391] (info)   Analog Recorders: 0
[2019-11-02 18:13:03.581426] (info)   Modulation: qpsk
[2019-11-02 18:13:03.581468] (info)   Source Device: soapy=0,driver=sdrplay
gr-osmosdr v0.1.4-127-g4d83c606 (0.1.5git) gnuradio 3.7.13.4
built-in source types: file fcd rtl rtl_tcp uhd hackrf rfspace soapy redpitaya 
[INFO] Using format CF32.
[2019-11-02 18:13:03.989391] (info)   SOURCE TYPE OSMOSDR (osmosdr)
[2019-11-02 18:13:03.989568] (info)   Setting sample rate to: 10000000
[2019-11-02 18:13:03.989851] (info)   Actual sample rate: 10000000
[2019-11-02 18:13:03.990037] (info)   Tunning to 8.555005e+08
[2019-11-02 18:13:03.990996] (info)   Gain Stage: IFGR supported values: 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 
[2019-11-02 18:13:03.991232] (info)   Gain Stage: RFGR supported values: 0 1 2 3 4 5 6 7 8 9 
[2019-11-02 18:13:03.991290] (info)   Max Freqency: 8.605000e+08
[2019-11-02 18:13:03.991365] (info)   Min Freqency: 8.505000e+08
[2019-11-02 18:13:03.991460] (info)   LNA Gain set to: 0
[2019-11-02 18:13:03.991527] (info)   TIA Gain set to: 0
[2019-11-02 18:13:03.991588] (info)   PGA Gain set to: 0
[2019-11-02 18:13:03.991659] (info)   Gain set to: 20
[2019-11-02 18:13:03.991747] (info)   Setting antenna to [RX]
~snip~
[2019-11-02 19:03:39.872087] (info)   	- Starting P25 Recorder Num [0]	TG: 1059	Freq: 8.523000e+08 	TDMA: false	Slot: 0
[2019-11-02 19:03:39.873122] (info)   [comirs]	TG: 1059	Freq: 8.523000e+08	Starting Recorder on Src: soapy=0,driver=sdrplay
[2019-11-02 19:03:44.910787] (info)   [comirs]	TG: 1059	Freq: 8.523000e+08	Update Retuning - New Freq: 8.511250e+08	Elapsed: 5s 	Since update: 2s
[2019-11-02 19:03:49.887167] (info)   	- Starting P25 Recorder Num [1]	TG: 1109	Freq: 8.516250e+08 	TDMA: false	Slot: 0
[2019-11-02 19:03:49.887714] (info)   [comirs]	TG: 1109	Freq: 8.516250e+08	Starting Recorder on Src: soapy=0,driver=sdrplay
[2019-11-02 19:03:52.083655] (info)   [comirs]	TG: 1059	Freq: 8.511250e+08	Update Retuning - New Freq: 8.563625e+08	Elapsed: 13s 	Since update: 2s
[2019-11-02 19:03:53.729387] (info)   [comirs]	TG: 1109	Freq: 8.516250e+08	Update Retuning - New Freq: 8.537875e+08	Elapsed: 4s 	Since update: 1s
[2019-11-02 19:03:57.224294] (info)   	- Starting P25 Recorder Num [2]	TG: 1227	Freq: 8.526875e+08 	TDMA: false	Slot: 0
[2019-11-02 19:03:57.224887] (info)   [comirs]	TG: 1227	Freq: 8.526875e+08	Starting Recorder on Src: soapy=0,driver=sdrplay
Segmentation fault (core dumped)

I poked around the backtrace and it appears to point to SoapySDRPlay:

(gdb) bt
#0  __memmove_sse2_unaligned_erms () at ../sysdeps/x86_64/multiarch/memmove-vec-unaligned-erms.S:262
#1  0x00007f38ba5cc366 in SoapySDRPlay::readStream(SoapySDR::Stream*, void* const*, unsigned long, int&, long long&, long) ()
   from /usr/local/lib/SoapySDR/modules0.8/libsdrPlaySupport.so
#2  0x00007f38be5d9c98 in soapy_source_c::work(int, std::vector<void const*, std::allocator<void const*> >&, std::vector<void*, std::allocator<void*> >&) ()
   from /usr/local/lib/libgnuradio-osmosdr.so.0.1.5git
#3  0x00007f38bfbca6f7 in gr::sync_block::general_work(int, std::vector<int, std::allocator<int> >&, std::vector<void const*, std::allocator<void const*> >&, std::vector<void*, std::allocator<void*> >&) () from /lib/x86_64-linux-gnu/libgnuradio-runtime.so.3.7.13
#4  0x00007f38bfb900a0 in gr::block_executor::run_one_iteration() () from /lib/x86_64-linux-gnu/libgnuradio-runtime.so.3.7.13
#5  0x00007f38bfbd3b29 in gr::tpb_thread_body::tpb_thread_body(boost::shared_ptr<gr::block>, boost::shared_ptr<boost::barrier>, int) ()
   from /lib/x86_64-linux-gnu/libgnuradio-runtime.so.3.7.13
#6  0x00007f38bfbc5ec4 in ?? () from /lib/x86_64-linux-gnu/libgnuradio-runtime.so.3.7.13
#7  0x00007f38bfb7b342 in ?? () from /lib/x86_64-linux-gnu/libgnuradio-runtime.so.3.7.13
#8  0x00007f38be549f65 in ?? () from /lib/x86_64-linux-gnu/libboost_thread.so.1.67.0
#9  0x00007f38be51bfa3 in start_thread (arg=<optimized out>) at pthread_create.c:486
#10 0x00007f38bdcca4cf in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95

I have the 600 megabyte core dump file if anyone would like to examine it in more detail. (Or let me know what else you would like to see... happy to run any gdb commands to poke at the core dump on request.)

For what it's worth, I've reproduced this issue five times so far (and I have core dumps for four of those times... they all look the same to me). I have only been able to reproduce the issue when the radio system is busy and trunk-recorder is using 3 or more recorder threads. I've run for quite a long time with 2 recorder threads with no segfaults; when I switch back to 3 recorder threads, a segfault comes along within an hour or so (whenever the radio system gets busy).

Version information:

• SoapySDR 189bc69217846581e34456f391683cc07c43ae0d
• SoapySDRPlay 14ec39e
• gr-osmosdr 4d83c6067f059b0c5015c3f59f8117bbd361e877
• trunk-recorder 668fe62224ef7fb772d4263ed6f8c773683c0626
• All other software is the latest from Debian 10.1 repositories

I am not sure whether to file this bug report under SoapySDRPlay, gr-osmosdr, or trunk-recorder... based on the backtrace, I decided to start with SoapySDRPlay.

Please let me know if there's any additional testing I can do, or any additional information I can provide.

Hi

Just dropped the SDRPlay folks some questions regarding the enabling of the Bias T via Soapy on the RSPDx. Whilst I can enable via Cubic (tested the voltage and 4.7v out).

If I attempt to do so via the Soapy string (utilising RTL_Airband), I don't get any voltage. I wonder if this is to do with the lack of a hwVer 4 in the settings.ccp file and correctly enumerating the options and thus defaulting to an V1 RSP? Saying that, Cubic DOES enable this...so could it really be the API here?

My babble below.

If anyone could confirm what can be parsed via the string for the DX (and how to correctly enable the biasT...I would be much obliged).

Thanks

https://github.com/pothosware/SoapySDRPlay/blob/master/Settings.cpp

Breaks down the settings for Soapy specific for SDR Play devices.

Specific for the BiasT:
SoapySDR::ArgInfo BiasTArg;
BiasTArg.key = "biasT_ctrl";
BiasTArg.value = "true";
BiasTArg.name = "BiasT Enable";
BiasTArg.description = "BiasT Control";
BiasTArg.type = SoapySDR::ArgInfo::BOOL;
setArgs.push_back(BiasTArg);

and

else if (key == "biasT_ctrl")
{
if (biasTen == 0) return "false";
else return "true";

So may try using biasT_ctrl=1 rather than TRUE ( 0 and 1 are used as a boolean anyway and formatted True / False).

UPDATE.  Nope.

device_string = "driver=sdrplay,biasT_ctrl=1"

doesn't work either.  I note the SoapySDRPlay settings.ccp doesn't specifically address settings towards the DX

hwVer == 1 matches to RSP1????
hwVer == 2 matches to RSP2/RSP2Pro
hwVer == 3 matches to RSPduo
hwVer > 253 matches to RSP1A  

Don't see anything specific for the DX and that is hwVer 4 according to a probe of the device via SoapySDRUtil --probe.

I wonder if we need an update to SoapySDRplay as it will likely be falling back to the hwVer1 maybe?  Although the Antenna selection seem correct.

I can get it to work, ik keep getting "no sdrplay device found". Hoppefully i included all information needed to pinpoint the issue, if not say so

user@machine:~$ cat /etc/os-release
NAME="Linux Mint"
VERSION="19.3 (Tricia)"
ID=linuxmint
ID_LIKE=ubuntu
PRETTY_NAME="Linux Mint 19.3"
VERSION_ID="19.3"
HOME_URL="https://www.linuxmint.com/"
SUPPORT_URL="https://forums.ubuntu.com/"
BUG_REPORT_URL="http://linuxmint-troubleshooting-guide.readthedocs.io/en/latest/"
PRIVACY_POLICY_URL="https://www.linuxmint.com/"
VERSION_CODENAME=tricia
UBUNTU_CODENAME=bionic

user@machine:~$ dmesg
[ 6372.934848] usb 1-3: USB disconnect, device number 3
[ 6390.296634] usb 1-3: new high-speed USB device number 5 using xhci_hcd
[ 6390.445657] usb 1-3: New USB device found, idVendor=1df7, idProduct=2500, bcdDevice= 2.00
[ 6390.445659] usb 1-3: New USB device strings: Mfr=0, Product=0, SerialNumber=0
[ 6390.446567] msi2500 1-3:1.0: Registered as swradio0
[ 6390.446568] msi2500 1-3:1.0: SDR API is still slightly experimental and functionality changes may follow

user@machine:~$ lsusb
Bus 008 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 007 Device 004: ID 04a9:190f Canon, Inc.
Bus 007 Device 006: ID 10c4:ea60 Cygnal Integrated Products, Inc. CP210x UART Bridge / myAVR mySmartUSB light
Bus 007 Device 005: ID 08bb:29b3 Texas Instruments PCM2903B Audio CODEC
Bus 007 Device 003: ID 0424:2512 Standard Microsystems Corp. USB 2.0 Hub
Bus 007 Device 002: ID 046d:c084 Logitech, Inc.
Bus 007 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 006 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 005 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 004 Device 002: ID 2109:0813 VIA Labs, Inc.
Bus 004 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 003 Device 003: ID 0b05:18f3 ASUSTek Computer, Inc.
Bus 003 Device 002: ID 2109:2813 VIA Labs, Inc.
Bus 003 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 001 Device 004: ID 058f:6364 Alcor Micro Corp. AU6477 Card Reader Controller
Bus 001 Device 005: ID 1df7:2500
Bus 001 Device 002: ID 045e:07f8 Microsoft Corp. Wired Keyboard 600 (model 1576)
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub

user@machine:~$ SoapySDRUtil --info
######################################################

Soapy SDR -- the SDR abstraction library

######################################################

Lib Version: v0.8.0-gf722f9ce
API Version: v0.8.0
ABI Version: v0.8
Install root: /usr/local
Search path: /usr/local/lib/SoapySDR/modules0.8
Module found: /usr/local/lib/SoapySDR/modules0.8/libsdrPlaySupport.so (0.3.0-14ec39e)
Available factories... sdrplay
Available converters...

• CF32 -> [CF32, CS16, CS8, CU16, CU8]
• CS16 -> [CF32, CS16, CS8, CU16, CU8]
• CS32 -> [CS32]
• CS8 -> [CF32, CS16, CS8, CU16, CU8]
• CU16 -> [CF32, CS16, CS8]
• CU8 -> [CF32, CS16, CS8]
• F32 -> [F32, S16, S8, U16, U8]
• S16 -> [F32, S16, S8, U16, U8]
• S32 -> [S32]
• S8 -> [F32, S16, S8, U16, U8]
• U16 -> [F32, S16, S8]
• U8 -> [F32, S16, S8]

user@machine:~$ SoapySDRUtil --check=sdrplay
######################################################

Soapy SDR -- the SDR abstraction library

######################################################

Loading modules... done
Checking driver 'sdrplay'... PRESENT

user@machine:~$ SoapySDRUtil --find="driver=sdrplay"
######################################################

Soapy SDR -- the SDR abstraction library

######################################################

No devices found! driver=sdrplay

user@machine:~$ SoapySDRUtil --probe="driver=sdrplay"
######################################################

Soapy SDR -- the SDR abstraction library

######################################################

Probe device driver=sdrplay
Error probing device: no sdrplay device found

I've followed most of the troubleshooting steps I've found online and chatted a bit on freenode but haven't been able to figure out why my RSP2 isn't being enumerated. I'm using:
SoapySDRUtil --info
######################################################

Soapy SDR -- the SDR abstraction library

######################################################

Lib Version: v0.6.1-unknown
API Version: v0.6.0
ABI Version: v0.6
Install root: /usr
Search path: /usr/lib64/SoapySDR/modules0.6
Search path: /usr/local/lib64/SoapySDR/modules0.6
Module found: /usr/lib64/SoapySDR/modules0.6/libsdrPlaySupport.so
Loading modules... done
Available factories...null, sdrplay,

SoapySDRUtil --probe
######################################################

Soapy SDR -- the SDR abstraction library

######################################################

Probe device

-- Device identification

driver=null
hardware=null

-- Peripheral summary

Channels: 0 Rx, 0 Tx
Timestamps: NO

SoapySDRUtil --check=sdrplay
######################################################

Soapy SDR -- the SDR abstraction library

######################################################

Loading modules... done
Checking driver 'sdrplay'... PRESENT

Linux ham1 4.17.14 #1 SMP Thu Aug 9 09:45:34 EDT 2018 x86_64 AMD Ryzen 3 2200G with Radeon Vega Graphics AuthenticAMD GNU/Linux

I'm happy to attach kernel configs or whatever you're interested in (strace/etc), or try patches/etc. This is on Gentoo, but my kernel is custom, and I packaged soapysdrplay and the sdrplay libraries myself (soapysdr is the repository version). If I get it working I'll likely add the packages to the main repo.

I have enabled just about all the USB-related options in the kernel except gadget-related options. Also, "lsmod | grep msi" returns nothing. The usb device does show up in /dev/bus/usb with 0666 permissions so the udev rule seems to be working fine.

Is there anything else you can think of that I can do to troubleshoot, or can you think of any kernel-related config settings that might be relevant?

Current gqrx does not restore the HW AGC at startup and gqrx starts up with HW AGC enabled randomly. This exposed a bug in soapysdrplay which is missing the initialization of SoapySDRPlay::agcEnabled. The attached patch fixes this (renamed to .txt to allow upload)

0001-Settings.cpp-initialize-agcEnabled.patch.txt

Trying to install SoapySDR on a Windows 10 PC with an SDRPlay RSP2.
(Plan is, once it works locally, to use SoapySDR Remote to connect to the RSP2 across the LAN.)
Using Cmake GUI, I have configured SoapySDR, but when configuring SoapySDRPlay, I get the following ...

"CMake Error at CMakeLists.txt:7 (find_package):
Could not find a configuration file for package "SoapySDR" that is
compatible with requested version "0.4.0".
The following configuration files were considered but not accepted:
C:/_SoapySDR_2/src/SoapySDR-master/cmake/Modules/SoapySDRConfig.cmake, version: unknown
"
Tried installing PothosSDR but the necessary files don't appear there either.

I'm a bit out-of-my-league so any help is appreciated.

mir_sdr_DebugEnable(1) should be removed or set to 0 for production. If not, this will slow the processing down.

It's used in both Registration.cpp and Streaming.cpp

Thanks,

SDRplay Support

Any chance of creating a release 0.1 so I can add the driver to MacPorts?

Thanks

Richard

I have downloaded CubicSDR, SoapySDR and SoapySDRPlay for testing with my SDRPlay on Ubuntu 14.04.
No problem at all for compile and link and for run it.
But in USB mode and with a 6000 for bandwidth I get audio starting from 800-900 Hz (upper limit is from Fldigi). How can I modify this? A correct bandwidth for PSK is 200-2700 Hz or 200-3000 Hz
See a screenshot of CubicSDR and Fldigi connected by Pulseaudio
Regards

Franco Spinelli
IW2DHW

I am giving a try to beta version of linhpsdr, now supporting SoapySDR, with my SDRPlay.
Sample rate required by linhpsdr, for WDSP library, is 1536000. WDSP library require input sample rate as a power of 2 and also a power of 2 for internal decimation. So input sample rate is fixed to 1536000 by program, internal DSP sample rate is fixed to 96000 (1536000/16) and audio sample rate is fixed to 48000 (96000/2)
But there is no possibility to obtain this sample rate with SoapySDRPlay in Zero_IF mode.

As I can see in code, sample rate from 200000 to 500000 are obtained using 2000000/8,
sample rate from 500000 to 100000 are obtained using 2000000/4 and sample rate from 1000000 to 2000000 using 2000000/2. Sample rate greater than 2000000 don't use decimation
So, if I set sample rate as 1536000 I obtain a real sample rate of 1000000.

Why I can not define decimation directly? I can define a sample rate of 3072000 and a decimation of 2 but actual SoapySDRPlay return a sample rate of 3072000

Regards
Franco Spinelli
IW2DHW

The new API now supports a frequency range from 0.01MHz to 2GHz. SoapySDRPlay Driver needs updating to reflect this.

The device specific controls that are available via SoapySDRPlay do not seem to be accessible in GQRX. Is there any way for those controls to work?

Antenna switching is there for the RSP2, but things like BiasT or notch filters aren't.

If a bandwidth 0 is set with SoapySDRPlay::setBandwidth(), the optimum bandwidth for the current sample rate should be selected. Instead of this alwys the maximum bandwithd of 8MHZ is selected, which later may lead to an error in the mir driver (bandwidth too high for current sample rate).

The attached patch fixes this (renamed to .txt to allow upload)

0002-setBandWidth-Select-select-optimum-bandwidth-for-sam.patch.txt

I installed SoapySDR support for SDRPlay and try some applications which worked with other hardware.
Strange enough I was getting very weak signals, like near or below the digitization level, even setting the maximum gain.
The I tried lower gain and then the signals got stronger and stronger... the strongest and like normal level is wneh I set gain to zero ?!

It appears as if the gain acts in reverse: higher gain is lower amplification and the reverse.
Did anybody notice such behavior ?

I am informing you that SDRPlay has changed their naming for critical includes while upgrading their API version from SDRplay_RSP_API-Linux-2.13.1.run to SDRplay_RSP_API-Linux-3.01.beta1.run

As the result, SoapySDRPlay is not compiling anymore for SDRPlay b/c the "requirements are not met". The issue: the warning on the git page saying "Get SDR Play driver binaries 'API/HW driver v2.x' (not v3.x)" remains invisible for people just cloning your code.

Could it plz be possible to amend the SoapySDRPlay with a compile time warning against the 3.0.1 version?! As just a sysadm I am lacking the qualifications to tell you whether just the naming scheme have been changed or were some deeper incompatibilities incorporated. Below are the visible differences, the excerpts from the relevant install_lib files (of SDRPlay API):

ver 2.13.1:
echo "Install /usr/local/lib/libmirsdrapi-rsp.so.2.13"
sudo cp ${ARCH}/libmirsdrapi-rsp.so.${VERS} /usr/local/lib/.
sudo chmod 644 /usr/local/lib/libmirsdrapi-rsp.so.${VERS}
sudo ln -s /usr/local/lib/libmirsdrapi-rsp.so.${VERS} /usr/local/lib/libmirsdrapi-rsp.so.2
sudo ln -s /usr/local/lib/libmirsdrapi-rsp.so.2 /usr/local/lib/libmirsdrapi-rsp.so
[..]
echo "Install /usr/local/include/mirsdrapi-rsp.h"
sudo cp mirsdrapi-rsp.h /usr/local/include/.
sudo chmod 644 /usr/local/include/mirsdrapi-rsp.h

ver 3.0.1
export VERS="3.01"
export MAJVERS="3"
[..]
echo -n "Installing /usr/local/lib/libsdrplay_api.so.${VERS}..."
sudo rm -f /usr/local/lib/libsdrplay_api.so.${VERS}
sudo cp -f ${ARCH}/libsdrplay_api.so.${VERS} /usr/local/lib/.
sudo chmod 644 /usr/local/lib/libsdrplay_api.so.${VERS}
sudo rm -f /usr/local/lib/libsdrplay_api.so.${MAJVERS}
sudo ln -s /usr/local/lib/libsdrplay_api.so.${VERS} /usr/local/lib/libsdrplay_api.so.${MAJVERS}
sudo rm -f /usr/local/lib/libsdrplay_api.so
sudo ln -s /usr/local/lib/libsdrplay_api.so.${MAJVERS} /usr/local/lib/libsdrplay_api.so
echo "Done"
[..]
echo -n "Installing header files in /usr/local/include..."
sudo cp -f inc/sdrplay_api*.h /usr/local/include/.
sudo chmod 644 /usr/local/include/sdrplay_api*.h
echo "Done"

SoapySDR 0.7.1, SoapySDRPlay 0.2.0 on Ubuntu 14.04 lts, x86-64.
I get "Error probing device: map::at" with SoapySDRUtil --probe every time, I can't use Soapy at all.

after uncommenting try and catch @guruofquality mentioned in #50

Probe device 
terminate called after throwing an instance of 'std::out_of_range'
  what():  map::at
Aborted (core dumped)

despite what it says about a core dump, I do not have a core dump file because ubuntu. I will post it if I find it or succeed in producing it.

(gdb) run --probe
Starting program: /usr/local/bin/SoapySDRUtil --probe
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
######################################################
##     Soapy SDR -- the SDR abstraction library     ##
######################################################

Probe device 
[New Thread 0x7ffff3e03700 (LWP 25327)]
[New Thread 0x7ffff3602700 (LWP 25328)]
[Thread 0x7ffff3e03700 (LWP 25327) exited]
[New Thread 0x7ffff3e03700 (LWP 25329)]
[Thread 0x7ffff3e03700 (LWP 25329) exited]
[Thread 0x7ffff3602700 (LWP 25328) exited]
terminate called after throwing an instance of 'std::out_of_range'
  what():  map::at

Program received signal SIGABRT, Aborted.
0x00007ffff6fbdc37 in raise () from /lib/x86_64-linux-gnu/libc.so.6
(gdb) bt
#0  0x00007ffff6fbdc37 in raise () from /lib/x86_64-linux-gnu/libc.so.6
#1  0x00007ffff6fc1028 in abort () from /lib/x86_64-linux-gnu/libc.so.6
#2  0x00007ffff77e4535 in __gnu_cxx::__verbose_terminate_handler() () from /usr/lib/x86_64-linux-gnu/libstdc++.so.6
#3  0x00007ffff77e26d6 in ?? () from /usr/lib/x86_64-linux-gnu/libstdc++.so.6
#4  0x00007ffff77e2703 in std::terminate() () from /usr/lib/x86_64-linux-gnu/libstdc++.so.6
#5  0x00007ffff77e26c7 in std::rethrow_exception(std::__exception_ptr::exception_ptr) () from /usr/lib/x86_64-linux-gnu/libstdc++.so.6
#6  0x00007ffff7b6ba97 in std::__basic_future<SoapySDR::Device*>::_M_get_result (this=0x7fffffffd6b0) at /usr/include/c++/4.8/future:598
#7  0x00007ffff7b683cc in std::shared_future<SoapySDR::Device*>::get (this=0x7fffffffd6b0) at /usr/include/c++/4.8/future:804
#8  0x00007ffff7b5d90f in SoapySDR::Device::make (inputArgs=...) at /home/vrm/sw/src/SoapySDR-soapy-sdr-0.7.1/lib/Factory.cpp:192
#9  0x00007ffff7b5db56 in SoapySDR::Device::make (args=...) at /home/vrm/sw/src/SoapySDR-soapy-sdr-0.7.1/lib/Factory.cpp:201
#10 0x0000000000413571 in probeDevice (argStr=...) at /home/vrm/sw/src/SoapySDR-soapy-sdr-0.7.1/apps/SoapySDRUtil.cpp:200
#11 0x0000000000413a1c in main (argc=2, argv=0x7fffffffda08) at /home/vrm/sw/src/SoapySDR-soapy-sdr-0.7.1/apps/SoapySDRUtil.cpp:320
(gdb)

My ARMv8 device:

root@aml:~# arch
aarch64

With correct SDRPlay API installed (https://www.sdrplay.com/arm64dl.php)

Besides, modules were blacklisted correctly. It looks like everything is OK.

At this time, RSP1 can be detected by typing the lsusb command.

root@aml:~# lsusb
Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 001 Device 002: ID 1df7:2500
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub

What is puzzling me is that I got an error after executing the SoapySDRUtil --probe command.

root@aml:~# SoapySDRUtil --probe
######################################################
##     Soapy SDR -- the SDR abstraction library     ##
######################################################

Probe device
Error probing device: no sdrplay device found

What's more, I can't use the command lsusb to detect my RSP1 again.

root@aml:~# lsusb
Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub

Hello,
I am getting this CMake error when trying to build SoapySDRPlay

gary@gary-MSI-Wind-Ubuntu:~/SoapySDRPlay/build$ cmake ..
CMake Error at CMakeLists.txt:7 (find_package):
Could not find a package configuration file provided by "SoapySDR"
(requested version 0.4.0) with any of the following names:

SoapySDRConfig.cmake
soapysdr-config.cmake

Add the installation prefix of "SoapySDR" to CMAKE_PREFIX_PATH or set
"SoapySDR_DIR" to a directory containing one of the above files. If
"SoapySDR" provides a separate development package or SDK, be sure it has
been installed.

-- Configuring incomplete, errors occurred!
See also "/home/gary/SoapySDRPlay/build/CMakeFiles/CMakeOutput.log".

I believe I have followed the instructions listed in the SoapySDR Wiki to the letter.

The directory listing of SoapySDRPlay is:
gary@gary-MSI-Wind-Ubuntu:~/SoapySDRPlay$ ls
build CMakeLists.txt LICENSE.txt Registation.cpp SoapySDRPlay.hpp
Changelog.txt FindLibSDRplay.cmake README.md Settings.cpp Streaming.cpp

Any advice on how to proceed?

Thank you,
Gary

Really missed not being able to select the ports in gqrx using soapy until i saw a comment on facebook with a fork adding these features.

https://github.com/fcrohas/SoapySDRPlay

can these features be added to the main repo?

With new version of SoapySDRPlay and with SoapySDR from GIT my SDRPlay is not found

This is the output of SoapySDRUtil --info
######################################################

Soapy SDR -- the SDR abstraction library

######################################################

Lib Version: v0.6.0-g5e823fc1
API Version: v0.6.0
ABI Version: v0.6-dev
Install root: /usr/local
Search path: /usr/local/lib/SoapySDR/modules0.6-dev
Module found: /usr/local/lib/SoapySDR/modules0.6-dev/librtlsdrSupport.so
Module found: /usr/local/lib/SoapySDR/modules0.6-dev/libsdrPlaySupport.so
Loading modules... done
Available factories...null, rtlsdr, sdrplay,

And this is the output of SoapySDRUtil --find
######################################################

Soapy SDR -- the SDR abstraction library

######################################################

mir_sdr_usb_GetDevices Dev0:vid=1df7 pid=2500 rev=0206 serno=B0002P0001 bus=002 port=001 devAvail=0
No devices found!

How can I get it to work?

Regards

Franco Spinelli

My decvice is SDRPlay RSP1. I installed its driver and packages step by step ( SDRPlay Driver, SoapySDR, SoapySDRPlay, rx_tools, csdr ) on my Raspberry Pi 2. Everything seems to be OK.

But when I run the command rx_sdr - | csdr through > /dev/null to test if everything is all right, I got the error

root@yukiho:~# rx_sdr - | csdr through > /dev/null
Using device B0002P0001: mir_sdr_api_version=2.130000 mir_sdr_hw_version=1
Found 1 antenna(s): RX
Found 2 gain(s): IFGR RFGR
Found 2 frequencies: RF CORR
Found 13 sample rates: 250000 500000 1000000 2000000 2048000 3000000 4000000 5000000 6000000 7000000 8000000 9000000 10000000
Found 8 bandwidths: 200000 300000 600000 1536000 5000000 6000000 7000000 8000000
[INFO] Using format CS16.
Using output format: CU8 (input format CS16)
Sampling at 2048000 S/s.
Tuned to 100000000 Hz.
Reading samples in sync mode...
Failed to activate stream

I've blacklisted the kernel modules correctly, but it still was... Even I changed my OS from Debian to Ubuntu.

root@yukiho:~# SoapySDRUtil --probe
######################################################
##     Soapy SDR -- the SDR abstraction library     ##
######################################################

Probe device

----------------------------------------------------
-- Device identification
----------------------------------------------------
  driver=SDRplay
  hardware=B0002P0001
  mir_sdr_api_version=2.130000
  mir_sdr_hw_version=1

----------------------------------------------------
-- Peripheral summary
----------------------------------------------------
  Channels: 1 Rx, 0 Tx
  Timestamps: NO
  Other Settings:
     * RF Gain Select - RF Gain Select
       [key=rfgain_sel, default=1, type=string, options=(0, 1, 2, 3)]
     * IF Mode - IF frequency in kHz
       [key=if_mode, default=Zero-IF, type=string, options=(Zero-IF, 450kHz, 1620kHz, 2048kHz)]
     * IQ Correction - IQ Correction Control
       [key=iqcorr_ctrl, default=true, type=bool]
     * AGC Setpoint - AGC Setpoint (dBfs)
       [key=agc_setpoint, default=-30, type=int, range=[-60, 0]]

----------------------------------------------------
-- RX Channel 0
----------------------------------------------------
  Full-duplex: YES
  Supports AGC: YES
  Stream formats: CS16, CF32
  Native format: CS16 [full-scale=32767]
  Antennas: RX
  Corrections: DC removal
  Full gain range: [0, 42] dB
    IFGR gain range: [20, 59] dB
    RFGR gain range: [0, 3] dB
  Full freq range: [0.01, 2000] MHz
    RF freq range: [0.01, 2000] MHz
    CORR freq range:  MHz
  Sample rates: 0.25, 0.5, 1, 2, 2.048, 6, 7, 8, 9, 10 MSps
  Filter bandwidths: 0.2, 0.3, 0.6, 1.536, 5, 6, 7, 8 MHz

So I checked again, it seems the driver is correctly installed, so I think there's something problem with my Pi...

There's no such problem like this, so I got puzzled... Help...

When i'm installing follow the installation process in the wiki, and execute the "make" command, this error appears. any recomendation?

pi@raspberrypi:~/SoapySDRPlay/build $ make
Scanning dependencies of target sdrPlaySupport
[ 25%] Building CXX object CMakeFiles/sdrPlaySupport.dir/Registation.cpp.o
[ 50%] Building CXX object CMakeFiles/sdrPlaySupport.dir/Settings.cpp.o
[ 75%] Building CXX object CMakeFiles/sdrPlaySupport.dir/Streaming.cpp.o
[100%] Linking CXX shared module libsdrPlaySupport.so
/usr/local/lib/libmirsdrapi-rsp.so: file not recognized: File format not recognized
collect2: error: ld returned 1 exit status
CMakeFiles/sdrPlaySupport.dir/build.make:148: recipe for target 'libsdrPlaySupport.so' failed
make[2]: *** [libsdrPlaySupport.so] Error 1
CMakeFiles/Makefile2:67: recipe for target 'CMakeFiles/sdrPlaySupport.dir/all' failed
make[1]: *** [CMakeFiles/sdrPlaySupport.dir/all] Error 2
Makefile:127: recipe for target 'all' failed
make: *** [all] Error 2

Thanks a lot

Hi, new to this type of SDR and to SoapySDR as well, so not sure where this issue would be or if its maybe even a hw issue, but the bias-t option as seen through CubicSDR using SoapySDRPlay (all just built from source today on Ubuntu 14.04) doesn't seem to work. I'm also not sure if the RF Notch option works, not sure best way to confirm. Other than this, seems to work great in Cubic. (I'm new to that as well, came from SDR#, gqrx using rtl-sdr and hackrf.)

Thanks!

######################################################

Soapy SDR -- the SDR abstraction library

######################################################

Probe device

-- Device identification

driver=SDRplay
hardware=255 1712xxxxxx
mir_sdr_api_version=2.110000
mir_sdr_hw_version=2

-- Peripheral summary

Channels: 1 Rx, 0 Tx
Timestamps: NO
Other Settings:
* IF Mode - IF frequency in kHz
[key=if_mode, default=Zero-IF, type=string, options=(Zero-IF, 450kHz, 1620kHz, 2048kHz)]
* IQ Correction - IQ Correction Control
[key=iqcorr_ctrl, default=true, type=bool]
* AGC Setpoint - AGC Setpoint (dBfs)
[key=agc_setpoint, default=-30, type=int, range=[-60, 0]]
* ExtRef Enable - External Reference Control
[key=extref_ctrl, default=true, type=bool]
* BiasT Enable - BiasT Control
[key=biasT_ctrl, default=true, type=bool]
* RfNotch Enable - RF Notch Filter Control
[key=rfnotch_ctrl, default=true, type=bool]

-- RX Channel 0

Full-duplex: YES
Supports AGC: YES
Stream formats: CS16, CF32
Native format: CS16 [full-scale=32767]
Antennas: Antenna A, Antenna B, Hi-Z
Corrections: DC removal
Full gain range: [0, 47] dB
IFGR gain range: [20, 59] dB
RFGR gain range: [0, 8] dB
Full freq range: [0.01, 2000] MHz
RF freq range: [0.01, 2000] MHz
CORR freq range: MHz
Sample rates: 0.25, 0.5, 1, 2, 2.048, 6, 7, 8, 9, 10 MSps
Filter bandwidths: 0.2, 0.3, 0.6, 1.536, 5, 6, 7, 8 MHz

Changing frequency (when doing frequency hopping / sweeping spectrum) is extremely slow. The problem is that device is always reinitialized when changing frequency to a new one if freq. difference is >= rate / 2 (see here: https://github.com/pothosware/SoapySDRPlay/blob/master/Streaming.cpp#L416).

But this condition is wrong, according to PDF at http://www.sdrplay.com/docs/Mirics_SDR_API_Specification.pdf, device needs to be reinitialized only when a frequency band edge is crossed (see frequency allocation table at the end of the PDF). There is no need for freqDiff < rate / 2.0 condition.

SoapySDRUtil reports Supports AGC: NO for SoapySDRPlay driver. Problem seems to be missing hasGainMode method in Settings.cpp (setGainMode / getGainMode is not enough).

@cjcliffe I was wondering the reasoning behind the label parsing stuff that uses kwargs to string:

std::string strargs = SoapySDR::KwargsToString(args);
...
size_t posidx = strargs.find("SDRplay Dev");
...
unsigned int devIdx = strargs.at(posidx + 11) - 0x30;

It looks as if the code just wants to parse the label string for device version markup. Would it have made more sense to use std::string strargs; if(args.count("label")!=0)strargs = args.at("label"); to parse just the label string? I ask because KwargsToString API isnt yet in a release, and a lot of builds work off of releases of SoapySDR, including myself. Otherwise we should at least bump the find_package(SoapySDR ... requirement if needed or find some workaround.

I'm on arch linux and I'm getting this compile error.

/usr/bin/ld: CMakeFiles/sdrPlaySupport.dir/Streaming.cpp.o: in function `SoapySDRPlay::acquireReadBuffer(SoapySDR::Stream*, unsigned long&, void const**, int&, long long&, long)': Streaming.cpp:(.text+0x872): undefined reference to `pthread_cond_clockwait' collect2: error: ld returned 1 exit status make[2]: *** [CMakeFiles/sdrPlaySupport.dir/build.make:151: libsdrPlaySupport.so] Error 1 make[1]: *** [CMakeFiles/Makefile2:96: CMakeFiles/sdrPlaySupport.dir/all] Error 2 make: *** [Makefile:150: all] Error 2 ==> ERROR: A failure occurred in build(). Aborting...

I made a fork under my account and created a branch called 'RSPduo_fixes' (https://github.com/fventuri/SoapySDRPlay/tree/RSPduo_fixes).
I cleaned up a couple of warnings during compile and I also straightened up the code for the RSPduo mode/tunes and antennas (hopefully).
I tested my changes this afternoon using 'SoapySDRUtil' with the following commands:

SoapySDRUtil --probe="driver=sdrPlay, rspduo_mode=Tuner A (Single Tuner)"
SoapySDRUtil --probe="driver=sdrPlay, rspduo_mode=Tuner B (Single Tuner)"
SoapySDRUtil --probe="driver=sdrPlay, rspduo_mode=Tuner A (Master/Slave)"
SoapySDRUtil --probe="driver=sdrPlay, rspduo_mode=Tuner B (Master/Slave)"
SoapySDRUtil --probe="driver=sdrPlay, rspduo_mode=Dual Tuner"

and in each case 'SoapySDRUtil' returned what I expected (including 2 RX channels in the last case with 'Dual Tuner').

Please give it a try and if it looks OK to you, I'll go ahead and send a pull request.

Franco

Originally posted by @fventuri in pothosware/SoapySDRPlay3#58 (comment)

Need help. gcc version is 6.2.0.

What else?

root@go:/usr/src/SoapySDRPlay/build# make
[ 25%] Building CXX object CMakeFiles/sdrPlaySupport.dir/Registation.cpp.o
In file included from /usr/src/SoapySDRPlay/Registation.cpp:25:0:
/usr/src/SoapySDRPlay/SoapySDRPlay.hpp: In constructor ‘SDRPlayGainPref::SDRPlayGainPref(double, double, double, int, int, int)’:
/usr/src/SoapySDRPlay/SoapySDRPlay.hpp:51:26: warning: ‘SDRPlayGainPref::grLNA’ will be initialized after [-Wreorder]
int grTarget, grMax, grLNA;
^~~~~
/usr/src/SoapySDRPlay/SoapySDRPlay.hpp:51:19: warning: ‘int SDRPlayGainPref::grMax’ [-Wreorder]
int grTarget, grMax, grLNA;
^~~~~
/usr/src/SoapySDRPlay/SoapySDRPlay.hpp:53:5: warning: when initialized here [-Wreorder]
SDRPlayGainPref(double lo, double min, double max, int targetGain = 40, int lnaGain = 24, int maxGain = 102) : loFreq(lo), freqMin(min), freqMax(max), grTarget(targetGain), grLNA(lnaGain), grMax(maxGain) { }
^~~~~~~~~~~~~~~
[ 50%] Building CXX object CMakeFiles/sdrPlaySupport.dir/Settings.cpp.o
In file included from /usr/src/SoapySDRPlay/Settings.cpp:25:0:
/usr/src/SoapySDRPlay/SoapySDRPlay.hpp: In constructor ‘SDRPlayGainPref::SDRPlayGainPref(double, double, double, int, int, int)’:
/usr/src/SoapySDRPlay/SoapySDRPlay.hpp:51:26: warning: ‘SDRPlayGainPref::grLNA’ will be initialized after [-Wreorder]
int grTarget, grMax, grLNA;
^~~~~
/usr/src/SoapySDRPlay/SoapySDRPlay.hpp:51:19: warning: ‘int SDRPlayGainPref::grMax’ [-Wreorder]
int grTarget, grMax, grLNA;
^~~~~
/usr/src/SoapySDRPlay/SoapySDRPlay.hpp:53:5: warning: when initialized here [-Wreorder]
SDRPlayGainPref(double lo, double min, double max, int targetGain = 40, int lnaGain = 24, int maxGain = 102) : loFreq(lo), freqMin(min), freqMax(max), grTarget(targetGain), grLNA(lnaGain), grMax(maxGain) { }
^~~~~~~~~~~~~~~
/usr/src/SoapySDRPlay/Settings.cpp: In constructor ‘SoapySDRPlay::SoapySDRPlay(const Kwargs&)’:
/usr/src/SoapySDRPlay/Settings.cpp:31:18: warning: variable ‘err’ set but not used [-Wunused-but-set-variable]
mir_sdr_ErrT err;
^~~
/usr/src/SoapySDRPlay/Settings.cpp: In member function ‘virtual SoapySDR::Kwargs SoapySDRPlay::getHardwareInfo() const’:
/usr/src/SoapySDRPlay/Settings.cpp:81:18: warning: unused variable ‘err’ [-Wunused-variable]
mir_sdr_ErrT err;
^~~
/usr/src/SoapySDRPlay/Settings.cpp: In static member function ‘static std::__cxx11::string SoapySDRPlay::IFtoString(mir_sdr_If_kHzT)’:
/usr/src/SoapySDRPlay/Settings.cpp:465:14: error: ‘mir_sdr_IF_Undefined’ was not declared in this scope
case mir_sdr_IF_Undefined:
^~~~~~~~~~~~~~~~~~~~
make[2]: *** [CMakeFiles/sdrPlaySupport.dir/build.make:87: CMakeFiles/sdrPlaySupport.dir/Settings.cpp.o] Error 1
make[1]: *** [CMakeFiles/Makefile2:68: CMakeFiles/sdrPlaySupport.dir/all] Error 2
make: *** [Makefile:128: all] Error 2

Hey,

my RSP1 works pretty well on Windows but using Soapy/SoapySDRPlay on Linux seems to add some weird noise as well as some weird peaks shown in GQRX as well as CubicSDR, but not on Windows.

Any idea what could cause those?

In the GQRX screenshot you'll better see those ..., like resets? Theres also some noise that's not seen in the waterfall, some crackling.

The frequency range / bandwidth on the GQRX is also very small compared to the one on HDSDR on Windows. On CubicSDR it looks bigger (see the small hill between 86.2 - ~86.5 on the GQRX one). So I can't see anything before or after that area while I do see way more on Windows. With seeing I mean being able to see peaks when someone is actually sending. This one might be a GQRX issue though.

CubicSDR: https://drive.google.com/file/d/1UNIhMEJl5aKO8IJ7D8moPqwmXl9T9kLw/view?usp=sharing
GQRX: https://drive.google.com/file/d/1NRePCb7IP9lPzJfwCssclY87_J1JR5SU/view?usp=sharing

build error: libsdrplay not found.

As provided, this will not build.

SoapySDR assumes that gains are additive in dB. When Device::setGain is called without a name, it automatically distributes the requested gain between all available gain stages:
https://github.com/pothosware/SoapySDR/blob/master/lib/Device.cpp#L281

Unfortunately, SDRPlay gains are unconventional. There are two gains exposed via SoapySDR, called "RFGR" and "IFGR".

1. "IFGR" stands for "intermediate frequency gain reduction". It takes a value between 20 and 59. Contrary to what SoapySDR expects, the greatest amplification is obtained with the smallest numerical value. The IFGR has units of dB.
2. "RFGR" stands for "radio frequency gain reduction". It takes a value between 0 and 9. As with the IFGR, the greatest amplification is obtained with the smallest value. In addition, the RFGR does not have units of dB! The actual gain reduction is nonlinear and frequency-dependent, but tends to be about 7 dB per count.
   (a) Note that RFGR is also settable via the "rxgain_sel" menu item.
   (b) RFGR attenuation tables in dB are available in the SDRPlay API documentation, section 5.3.
   (c) Most SDRPlay technical documents refer to the RFGR as the LNA state. I am not sure which terminology is preferred.

When we put these unconventional gain definitions together with SoapySDR's default gain distribution algorithm, disaster follows. Nearly any call to
void SoapySDR::Device::setGain(const int, const size_t, const double)
will force the RFGR to 9 (more than 60 dB of attenuation!) before allocating the remainder of the requested gain to the IFGR. Now you might argue that SDRPlay users should always set their gains by name -- but unfortunately, certain unenlightened applications do not expose the individual named gains, and there may be no way to avoid a call to the automatic gain distribution algorithm.

Proposed solution 1: quick and easy

• Override the default SoapySDR implementation of SoapySDR::Device::setGain(const int, const size_t, const double). Rather than attempting to distribute gain between stages, the requested gain will be assigned directly to the IFGR and the RFGR will not be changed.
• For consistency, also override SoapySDR::Device::getGainRange(const int dir, const size_t channel) to exclude the RFGR.
• SDRPlay's automatic gain control works in much the same way -- it varies the IFGR but does not touch the RFGR.

Proposed solution 2: fix the abstraction, break some existing configurations

• Remove RFGR from the list of available gains. It will remain available through the "rfgain_sel" menu item (which perhaps should be renamed to "LNA_state").
• Invert the sign of IFGR in SoapySDR, so that it spans from -20 to -59 rather than +20 to +59. This will match the SoapySDR sign convention of a bigger number representing more amplification, while preserving a clear correspondence with the numerical IFGR values present in SDRPlay documentation.
• With these abstractions fixed, setGain and getGainRange will now do the right thing without any further changes.

I am very new to SoapySDR (and SDR in general, for that matter). I would be happy to send in a pull request, but first I'd appreciate some feedback from the maintainers regarding the preferred approach.

Huge thanks to SDRPlay support for helping me understand what is going on in the hardware... responding in 15 minutes at midnight on Saturday!

Can SoapySDRPlay (perhaps with some minimal modifications) be used as a PVR backend, or would that fall outside of the scope of SoapySDRPlay itself?

cf. my question on Tvheadend forum:

Do any software defined radios (SDRs) work with Tvheadend, e.g., the SDRPlay ( http://www.sdrplay.com/ )?

This person used the SDRPlay to decode ATSC: https://coolsdrstuff.blogspot.com/2015/09/watching-atsc-hdtv-on-sdrplay-rsp.html?m=1
He used GNUradio: http://gnuradio.org/
His blog post also mentions how the SDRPlay hardware itself has been used in Europe to decode TV and radio.

thanks

I am a programmer, but the vagueness of C++ and cmake is not something I deal in often.

I had a warning about exceptions not being handled which I resolved with CMAKE_CXX_FLAGS.

The real problem is 75 unresolved external references.

LNK2001 unresolved external symbol "public: virtual bool __thiscall SoapySDR::Device::getFullDuplex(int,unsigned int)const " (?getFullDuplex@Device@SoapySDR@@UBE_NHI@Z) sdrPlaySupport D:\SoapySDR\build\Settings.obj 1

I presume that either I am missing some files or the cmake isnt treating the hpp file properly. devices.cpp is in the root folder under SoapySDRPlay.hpp but never gets copied or delt with in build as far as I can see.
Any help would be appreciated. Thank you.

Visual C++ 2015 (version 14) community. Fresh download of cmake

If you agree I will do it and make a pull request at some time.

Running probe multiple times will eventually block the my RSP1. Environment
is Raspberry PI3.

The only chance is to reboot the Raspberry.

Library mir:
root@xxxxx~ # ls -l /usr/local/lib/libmirsdrapi-rsp.so.2.13
-rw-r--r-- 1 root staff 183188 Mar 15 11:00 /usr/local/lib/libmirsdrapi-rsp.so.2.13

root@xxxxx:~ # SoapySDRUtil --probe="driver=sdrplay"
######################################################

Soapy SDR -- the SDR abstraction library

######################################################

Probe device driver=sdrplay

-- Device identification

driver=SDRplay
hardware=18070ED596
mir_sdr_api_version=2.130000
mir_sdr_hw_version=255

-- Peripheral summary

Channels: 1 Rx, 0 Tx
Timestamps: NO
Other Settings:
* RF Gain Select - RF Gain Select
[key=rfgain_sel, default=4, type=string, options=(0, 1, 2, 3, 4, 5, 6, 7, 8, 9)]
* IF Mode - IF frequency in kHz
[key=if_mode, default=Zero-IF, type=string, options=(Zero-IF, 450kHz, 1620kHz, 2048kHz)]
* IQ Correction - IQ Correction Control
[key=iqcorr_ctrl, default=true, type=bool]
* AGC Setpoint - AGC Setpoint (dBfs)
[key=agc_setpoint, default=-30, type=int, range=[-60, 0]]
* BiasT Enable - BiasT Control
[key=biasT_ctrl, default=true, type=bool]
* RfNotch Enable - RF Notch Filter Control
[key=rfnotch_ctrl, default=true, type=bool]
* DabNotch Enable - DAB Notch Filter Control
[key=dabnotch_ctrl, default=true, type=bool]

-- RX Channel 0

Full-duplex: YES
Supports AGC: YES
Stream formats: CS16, CF32
Native format: CS16 [full-scale=32767]
Antennas: RX
Corrections: DC removal
Full gain range: [0, 48] dB
IFGR gain range: [20, 59] dB
RFGR gain range: [0, 9] dB
Full freq range: [0.01, 2000] MHz
RF freq range: [0.01, 2000] MHz
CORR freq range: MHz
Sample rates: 0.25, 0.5, 1, 2, 2.048, 6, 7, 8, 9, 10 MSps
Filter bandwidths: 0.2, 0.3, 0.6, 1.536, 5, 6, 7, 8 MHz

root@xxxxx~ #
root@xxxxxx:~ # SoapySDRUtil --probe="driver=sdrplay"
######################################################

Soapy SDR -- the SDR abstraction library

######################################################

Probe device driver=sdrplay
Error probing device: map::at
root@xxxxx:~ # SoapySDRUtil --probe="driver=sdrplay"
######################################################

Soapy SDR -- the SDR abstraction library

######################################################

Probe device driver=sdrplay

^C
root@xxxx:~ #

Starting an issue for current development status and work for shared discussion.

Already making some actual progress:

cjmacbook:build ccliffe$ SoapySDRUtil --probe="driver=sdrplay"
######################################################
## Soapy SDR -- the SDR abstraction library
######################################################

Probe device driver=sdrplay
mir_sdr version: 1.1
Segmentation fault: 11

:)

In CubicSDR and in gr-osmosdr I get some random holes in packet receiving, producing some seconds of silence in audio play.
Using gr-osmosdr with Gnuradio I get this message:
[CRITICAL] ds_mir_sdr_ReadPacket() error: 1

No problem using gr-osmosdr with device sdrplay directly, both with Gqrx and Gnuradio

SDRPlay API is 1.97
Soapy from github, self compiled
System is Ubuntu 16.04/64 bit up to date

This issue is sent also in SDRPlay Community forum

Regards
Franco Spinelli
IW2DHW

I guess getDriverKey should return something that works in this command, but nope:

vrm@zivatar:~$ SoapySDRUtil --find='driver = SDRplay'
######################################################
##     Soapy SDR -- the SDR abstraction library     ##
######################################################

No devices found!
vrm@zivatar:~$ SoapySDRUtil --find='driver = sdrplay'
######################################################
##     Soapy SDR -- the SDR abstraction library     ##
######################################################

Found device 0
  driver = sdrplay
  label = SDRplay Dev0 RSP1
  serial = [removed]

Trying to build SoapySDRplay on Ubuntu 18.04, using the packaged binaries for SoapySDR and friends.

Initially, it couldn't find:

SoapySDRConfig.cmake

So, grabbed the latest source package from git and pointed Cmake at that file in the source package.

That yielded:

CMake Error at CMakeLists.txt:7 (find_package):
Could not find a configuration file for package "SoapySDR" that is
compatible with requested version "0.4.0".

The following configuration files were considered but not accepted:

/home/mleech/SoapySDR/cmake/Modules/SoapySDRConfig.cmake, version: unknown

Which means that the SoapySDRPlay package needs a version of SoapySDR that is older than
that in the PPAs or in the distro packages.

What do, what do?

Also add output of SoapySDRUtil --probe="driver=sdrplay" to the wiki for demonstration (scrub any serials)

been a while, just a thought

If one consumer uses a Soapy SDRPlay source, a concurrent call to SoapySDRUtil --find returns No devices found!.
When using the SoapyRemote server, the device is detected correctly and works with the first client. However when the second client attaches (through the server), both clients break with the following message:

[ERROR] SoapyRemote::find(tcp://192.168.2.24:55132) -- transact FAIL: SoapyRPCUnpacker::recv(header) FAIL:

Version used:

SoapySDRUtil --info
######################################################
##     Soapy SDR -- the SDR abstraction library     ##
######################################################

Lib Version: v0.7.1-g2da7c192
API Version: v0.7.1
ABI Version: v0.7
Install root: /usr/local
Search path:  /usr/local/lib/SoapySDR/modules0.7
Module found: /usr/local/lib/SoapySDR/modules0.7/libremoteSupport.so  (0.5.1-2a7363e)
Module found: /usr/local/lib/SoapySDR/modules0.7/libsdrPlaySupport.so (0.2.0-ff37683)
Available factories... remote, sdrplay
Available converters...
 -  CF32 -> [CF32, CS16, CS8, CU16, CU8]
 -  CS16 -> [CF32, CS16, CS8, CU16, CU8]
 -  CS32 -> [CS32]
 -   CS8 -> [CF32, CS16, CS8, CU16, CU8]
 -  CU16 -> [CF32, CS16, CS8]
 -   CU8 -> [CF32, CS16, CS8]
 -   F32 -> [F32, S16, S8, U16, U8]
 -   S16 -> [F32, S16, S8, U16, U8]
 -   S32 -> [S32]
 -    S8 -> [F32, S16, S8, U16, U8]
 -   U16 -> [F32, S16, S8]
 -    U8 -> [F32, S16, S8]

looking forward to get this updated version running but it seems that it will only build against the as yet unreleased v0.6 SoapySDR as it uses the new KwargsToString API which was added after the 0.5.4 release. CubicSDR 0.2.0 is also built against SoapySDR 0.5.2 so I presume the only way of getting CubicSDR to use this is to build it from source?

Thanks

Richard

It would add dual tuner support for RSP Duo.
The 3.01 API is avaliable on open beta.

So it looks like the SDRPlay drivers are a bit of a black-box with some registration required to get a hold of them. I'd like to figure out how I can use the drivers PPA and build support in the Pothos SDR environment. Things to figure out...

• Are they dynamic or static libraries?
  • Can SDRPlay drivers be statically linked in to a client library?
  • or if dynamic, redistributed with a binary installer?
• If we use dlopen and dlsym -- instead of linking, then the drivers can be a runtime dependency and not a build-time dependency. This solves the above issues by letting us build and package the SoapySDRPlay without the need of the SDRPlay drivers. It will be up to the end user to install the SDRPlay drivers to a well-known location. In addition, this is the only way we can have SDRPlay built for the ubuntu PPA -- because there wont be a source package for the SDRPlay drivers.

Hi, I have raspian buster running on RPi 3 B+.

I have done these steps:
sudo apt install cmake g++ libpython-dev python-numpy swig git
git clone https://github.com/pothosware/SoapySDR.git
cd SoapySDR
mkdir build
cd build
cmake ..
make -j4
sudo make install
sudo ldconfig
chmod 777 SDRplay_RSP_API-RPi-2.11.1.run
./SDRplay_RSP_API-RPi-2.11.1.run
git clone https://github.com/pothosware/SoapySDRPlay.git
cd SoapySDRPlay
mkdir build
cd build
cmake ..

and here he told me:

CMake Error at CMakeLists.txt:16 (message):
SDRPlay development files not found...

Any ideeas?
Thank you

Hello @SDRplay, are you planning to rewrite the SoapySDRPlay module with the API v3.0 to support
double tuner access on RSPDuo ?
For instance, allowing 2 CubicSDR instances in pseudo master / slave mode, running a different tuner each ?

Hello @SDRplay !
I tried the API v2.13 with your latest compatibility change with CubicSDR on Win64, but it appears
the Gain Change Callback (§3.56 page 65) passed to mir_sdr_ErrT mir_sdr_StreamInit is broken concerning at least the gRdB value.

This value is used in the getGain call by CubicSDR to refresh the gain sliders values. The observable behaviour is that the gain slider goes back to 0, and stays here no matter we apply another setting.

Turns out the callback value gRdB retreived with SoapySDRPlay::gr_callback(unsigned int gRdB, unsigned int lnaGRdB) may suddenly have completely out-of bounds values (INT_MIN for instance) and no further gain application can restore a normal behaviour.

The callback exposes wrong values either with AGC on or OFF. Suddenly, values will get off-the-charts and never come back again.

As a side note, I noticed inconsistencies in the callback description:
§3.4 Callback function prototypes page 11 describes:
typedef void (*mir_sdr_GainChangeCallback_t)(unsigned int gRidx, unsigned int gRdB,
unsigned int lnaGRdB, void *cbContext);

while

§3.56 Gain Change Callback p65 describes:
typedef void (*mir_sdr_GainChangeCallback_t)(unsigned int gRdB, unsigned int lnaGRdB,
void *cbContext);

consistent with the API signature.
But it also mentions §2.12:
2.12 Gain Message ID Enumerated Type Used to identify messages passed back in the gRdB field of the gain typedef enum { mir_sdr_GAIN_MESSAGE_START_ID = 0x80000000, mir_sdr_ADC_OVERLOAD_DETECTED = mir_sdr_GAIN_MESSAGE_START_ID mir_sdr_ADC_OVERLOAD_CORRECTED = mir_sdr_GAIN_MESSAGE_START_ID } mir_sdr_GainMessageIdT;

which may relate to this unknown parameter gRidx.

Build instructions in the Wiki should call for a release build

cmake ../ -DCMAKE_BUILD_TYPE=Release

to improve performance of the module.