GithubHelp home page GithubHelp logo

pothosware / soapysdrplay3 Goto Github PK

View Code? Open in Web Editor NEW
95.0 32.0 14.0 116 KB

Soapy SDR plugin for SDRPlay APIv3

Home Page: https://github.com/pothosware/SoapySDRPlay3/wiki

License: MIT License

CMake 4.19% C++ 95.81%
soapysdr gnuradio sdrplay sdr pothos

soapysdrplay3's Introduction

Soapy SDR module for SDRPlay

Documentation

Dependencies

Troubleshooting

This section contains some useful information for troubleshhoting

Message: [WARNING] Can't find label in args

An error message like this one:

Probe device driver=sdrplay
[WARNING] Can't find label in args
Error probing device: Can't find label in args

could be due to the OS not being able to 'see' the RSP as a USB device.

You may want to check using the command lsusb:

lsusb -d 1df7:

The output should look similar to this:

Bus 002 Device 006: ID 1df7:3010

If the lsusb command above returns nothing, it means the OS is not able to see the RSP (which could be due to a moltitude of reasons, like problems with the OS, bad USB cable, bad hardware, etc).

Another way to verify that the OS is able to see the RSP device is by running the dmesg command

dmesg

and look for lines similar to these (the idVendor value should be 1df7):

[ 1368.128506] usb 2-2: new high-speed USB device number 6 using xhci_hcd
[ 1368.255007] usb 2-2: New USB device found, idVendor=1df7, idProduct=3010, bcdDevice= 2.00
[ 1368.255016] usb 2-2: New USB device strings: Mfr=0, Product=0, SerialNumber=0

If there's nothing like that, try first to disconnect the RSP and then connect it back; if that does not work, try rebooting the computer; if that does not work either, try the RSP on a different computer with a different USB cable.

Licensing information

The MIT License (MIT)

Copyright (c) 2015 Charles J. Cliffe
Copyright (c) 2020 Franco Venturi - changes for SDRplay API version 3 and Dual Tuner for RSPduo

Permission is hereby granted, free of charge, to any person obtaining a copy of this software and associated documentation files (the "Software"), to deal in the Software without restriction, including without limitation the rights to use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies of the Software, and to permit persons to whom the Software is furnished to do so, subject to the following conditions:

The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software.

THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.

soapysdrplay3's People

Contributors

fventuri avatar guruofquality avatar theasp avatar willcode avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

soapysdrplay3's Issues

RSP1A still streaming even if disconnected from USB port

Hello,

I am running a simple python script to check my RSP1a but I am seeing a strange behavior. The script runs as expected, but when I remove my device from the USB port, the streaming doesn't stop. I can still see samples printed in the console !
Testing the same with an rtlsdr dongle, the streaming stops as I would expect.
Any clue ?
Thank you for your help.

#!/usr/bin/env python3

-- coding: utf-8 --

import SoapySDR
from SoapySDR import * #SOAPY_SDR_ constants
import numpy #use numpy for buffers

args = dict(driver="sdrplay")
sdr = SoapySDR.Device(args)

sdr.setSampleRate(SOAPY_SDR_RX, 0, 2e6)
sdr.setFrequency(SOAPY_SDR_RX, 0, 100e6)

rxStream = sdr.setupStream(SOAPY_SDR_RX, SOAPY_SDR_CF32)
sdr.activateStream(rxStream)

buff = numpy.array([0]*1024, numpy.complex64)

#receive some samples
for i in range(1000000000):
sr = sdr.readStream(rxStream, [buff], len(buff))
print('Ret', sr.ret, 'Flags', sr.flags, 'Time', sr.timeNs)
for j in range(1024): print(j, buff[j] )

#shutdown the stream
sdr.deactivateStream(rxStream) #stop streaming
sdr.closeStream(rxStream)

Additional optional sample rates in SoapySDRPlay driver

@SDRplay
Andy, I am creating this new issue in the SoapySDRPlay driver to ask your opinion about the following question.

Franco Spinelli IW2DHW (@frspin) and I have been working for some time to get John Melton's G0ORX linphsdr program to work with the SDRplay RSPs using the SoapySDRPlay driver (see my pull request to Johns' repository here: g0orx/linhpsdr#84)
John's program uses a DSP library called WDSP (https://github.com/g0orx/wdsp) by Warren Pratt NR0V, that has been specifically designed for the HPSDR class of SDRs; these SDRs work with sample rates in the 48kHz 'family', i.e. 48kHz, 96kHz, 192kHz, and 384kHz.

Based on the discussions with you and Vincent a while ago (and based on what SDRuno presents to the user), I was under the impression that the RSPs would work best with output sample rates of 2MHz (and 1M, 500k, 250k, 125k, 62.5k using decimation) with an IF of 1620kHz, and with sample rates > 2MHz with a zero IF.

What we would be interested instead is to be able to use them with a sample rate of say 1536kHz and a zero IF (which with decimation would yield all the sample rates above, since 1536/4=384, 1536/8=192, and so on).

Franco (@frspin) modified his own copy of the SoapySDRPlay driver, ran same tests, and it looks like this configuration would work, but, not being familiar at all with the internals of the RSPs and the libsdrplay_api library, I wanted to ask your counsel before moving forward.

If you think these sample rate values are acceptable and do not cause other problems, I thought they could be added to the SoapySDRPlay driver, either in the main code, or perhaps using a 'cmake' compilation flag (like we used to to have for the RF gain thing a while ago), or perhaps in a different repo branch (which might make things a little more complicated since the two branches would have to be kept in sync after that). Another option would be for us to create a fork somewhere with these additional optional values of the sample rate, but I am afraid it could cause unnecessary confusion among the customers.

Thanks,
Franco

findSDRPlay should not stop stream

When the device is streaming and findSDRPlay is called (which might be due to various reasons, esp. when running under SoapyRemote), the stream is stopped.

Here, I propose to instead just ignore the call and return no devices:

https://github.com/SDRplay/SoapySDRPlay/blob/master/Registration.cpp#L76

Patch (feel free to change, if accepted):

diff --git a/Registration.cpp b/Registration.cpp
index db02814..71c6a33 100644
--- a/Registration.cpp
+++ b/Registration.cpp
@@ -73,8 +73,8 @@ static std::vector<SoapySDR::Kwargs> findSDRPlay(const SoapySDR::Kwargs &args)
 
    if (activeStream)
    {
-      SoapySDR_log(SOAPY_SDR_WARNING, "findSDRPlay() called while the device is streaming. Deactivating stream.");
-      activeSoapySDRPlay->deactivateStream(activeStream, 0, 0LL);
+      SoapySDR_log(SOAPY_SDR_WARNING, "findSDRPlay() called while the device is streaming. Ignoring request.");
+      return {};
    }
 
    if (deviceSelected)

Setting LNA gain sometimes fails

NOTE: This is not about overriding default setGain()

I have found that setting LNA gain (RFGR) eventually stops working. When that happens, calls to SDRPlay APIv3 time out. This is usually preceded by a setFrequency() timeout, although the frequency still appears to update just fine:

: [WARNING] @@@ setFrequency(RF, 118800000)
: [WARNING] @@@ Setting RF frequency = 118800000
: [WARNING] Sample rate/decimation update timeout.
: [WARNING] @@@ writeSetting(rfgain_sel, 1)
: [WARNING] @@@ Updating rfgain_sel=1
: [WARNING] Gain reduction update timeout.

In the example above, the frequency jumped, but the rfgain_sel did not. While I do not know why this happens and how to fix it, it looks like some additional caution needs to be taken when calling SDRPlay APIv3. Maybe adding mandatory delay between API calls?

PS: Since SoapySDRPlay3 does not keep track of settings that failed to update, it will not try to set these settings again unless they are changed by the application. It might be a good idea to keep at least a bitmask of failed settings and try reapplying them the next time.

Error probing device: Can't find label in args

Getting an error I haven't seen reported anywhere when trying to use this:

$ SoapySDRUtil --probe="driver=sdrplay"
######################################################
##     Soapy SDR -- the SDR abstraction library     ##
######################################################

Probe device driver=sdrplay
[WARNING] Can't find label in args
Error probing device: Can't find label in args

Could this be due to a recent change or version conflict with one of the libraries?

Here's the info:

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

Lib Version: v0.8.0-g926c86d9
API Version: v0.8.0
ABI Version: v0.8
Install root: /usr/local
Search path:  /usr/local/lib64/SoapySDR/modules0.8
Module found: /usr/local/lib64/SoapySDR/modules0.8/libremoteSupport.so  (0.6.0-c09b2f1)
Module found: /usr/local/lib64/SoapySDR/modules0.8/librtlsdrSupport.so  (0.3.1-52cb5c0)
Module found: /usr/local/lib64/SoapySDR/modules0.8/libsdrPlaySupport.so (0.3.0-5c7c21f)
Available factories... remote, rtlsdr, 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]

on an arm64/aarch linux system.

RF notch filter is always on

Is there a way to activate the RF notch filter via a device argument so that it always stays on when using RSP1A ?

cmake version error

cmake ..
CMake Error at CMakeLists.txt:4 (cmake_minimum_required):
CMake 3.13 or higher is required. You are running version 3.10.2

Problem setting frequency with RSPduo

I have been working on getting SdrGlut to work with the RSPduo. I have managed to open the two channels on one device in "Dual Tuner" mode. Almost everything is working - except when I change the center frequency - both channels are effected. I looked at the code and "setFrequency" is ignoring the channel number. If setFrequency would actually set the frequency for only the requested channel - the program would be quite usable.

dll not recognized by Soapy (Windows 11)

I am a newbie in installing stuff under Windows.
I have a perfectly working gnuradio installation under Ubuntu and am trying to port it to Windows 11.
To be able to use my RSP1A , I generated the .so under Linux and copied it in the directory where Soapy has it's modules and it worked at first try.
On Windows, I tested the RSP1A with SDRUNo and it works.
Under Windows, I used cmake and got a .sln file that created a release version (with Visual studio 2019 and 2022 ,both were identical) and copied the resulting .dll (sdrPlaySupport.dll) under SoapySDR/modules0.8 where the others are.
Then I ran in the following problem:

(radioconda) C:\Users\Jean\SoapySDRPlay3\build>soapysdrutil --info
######################################################

Soapy SDR -- the SDR abstraction library

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

Lib Version: v0.8.1-2
API Version: v0.8.0
ABI Version: v0.8
Install root: D:\Anaconda3\envs\radioconda\Library
Search path: D:\Anaconda3\envs\radioconda\Library/lib/SoapySDR/modules0.8
Module found: D:\Anaconda3\envs\radioconda\Library/lib/SoapySDR/modules0.8/airspyhfSupport.dll (0.2.0)
Module found: D:\Anaconda3\envs\radioconda\Library/lib/SoapySDR/modules0.8/airspySupport.dll (0.2.0)
Module found: D:\Anaconda3\envs\radioconda\Library/lib/SoapySDR/modules0.8/bladeRFSupport.dll (0.4.1)
Module found: D:\Anaconda3\envs\radioconda\Library/lib/SoapySDR/modules0.8/HackRFSupport.dll (0.3.4)
Module found: D:\Anaconda3\envs\radioconda\Library/lib/SoapySDR/modules0.8/LMS7Support.dll (22.09.0)
Module found: D:\Anaconda3\envs\radioconda\Library/lib/SoapySDR/modules0.8/PlutoSDRSupport.dll (0.2.1)
Module found: D:\Anaconda3\envs\radioconda\Library/lib/SoapySDR/modules0.8/remoteSupport.dll (0.5.2)
Module found: D:\Anaconda3\envs\radioconda\Library/lib/SoapySDR/modules0.8/rtlsdrSupport.dll (0.3.0)
Module found: D:\Anaconda3\envs\radioconda\Library/lib/SoapySDR/modules0.8/sdrPlaySupport.dll
LoadLibrary() failed: The specified module could not be found.

Module found: D:\Anaconda3\envs\radioconda\Library/lib/SoapySDR/modules0.8/uhdSupport.dll (0.4.1)
Available factories... airspy, airspyhf, bladerf, hackrf, lime, plutosdr, remote, rtlsdr, uhd
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]

(radioconda) C:\Users\Jean\SoapySDRPlay3\build>

Just to be sure, although I have the latest API, I tried the same trick with SoapySDRPlay (not 3) : same result.

There must be something very evident that escapes me.
Can anybody help?

SDRPlay 3.08 ABI breakage

The latest API from SDRPlay (released 5 days) has a change that causes a command like SoapySDRUtil.exe --find to crash
deep inside SoapySDR::Device::enumerate()'s destructor. The call-stack is huge.

These are diffs for sdrplay_api.h:

--- SDRplay-1.4.2/API/inc/sdrplay_api.h       2019-12-18 10:59:18
+++ SDRplay-1.41-beta2/API/inc/sdrplay_api.h  2021-08-21 10:51:16
@@ -21,7 +21,7 @@

 // Application code should check that it is compiled against the same API version
 // sdrplay_api_ApiVersion() returns the API version
-#define SDRPLAY_API_VERSION                   (float)(3.07)
+#define SDRPLAY_API_VERSION                   (float)(3.08)

 // API Constants
 #define SDRPLAY_MAX_DEVICES                   (16)
@@ -145,6 +145,7 @@
     unsigned char hwVer;
     sdrplay_api_TunerSelectT tuner;
     sdrplay_api_RspDuoModeT rspDuoMode;
+    unsigned char valid;
     double rspDuoSampleFreq;
     HANDLE dev;
 } sdrplay_api_DeviceT;
@@ -186,7 +187,7 @@
 typedef sdrplay_api_ErrT        (*sdrplay_api_Uninit_t)(HANDLE dev);
 typedef sdrplay_api_ErrT        (*sdrplay_api_Update_t)(HANDLE dev, sdrplay_api_TunerSelectT tuner, sdrplay_api_ReasonForUpdateT reasonForUpdate, sdrplay_api_ReasonForUpdateExtension1T reasonForUpdateExt1);
 typedef sdrplay_api_ErrT        (*sdrplay_api_SwapRspDuoActiveTuner_t)(HANDLE dev, sdrplay_api_TunerSelectT *tuner, sdrplay_api_RspDuo_AmPortSelectT tuner1AmPortSel);
-typedef sdrplay_api_ErrT        (*sdrplay_api_SwapRspDuoDualTunerModeSampleRate_t)(double *currentSampleRate);
+typedef sdrplay_api_ErrT        (*sdrplay_api_SwapRspDuoDualTunerModeSampleRate_t)(double *currentSampleRate, double newSampleRate);
 typedef sdrplay_api_ErrT        (*sdrplay_api_SwapRspDuoMode_t)(sdrplay_api_DeviceT *currDevice, sdrplay_api_DeviceParamsT **deviceParams,
                                                                 sdrplay_api_RspDuoModeT rspDuoMode, double sampleRate, sdrplay_api_TunerSelectT tuner,
                                                                 sdrplay_api_Bw_MHzT bwType, sdrplay_api_If_kHzT ifType, sdrplay_api_RspDuo_AmPortSelectT tuner1AmPortSel);
@@ -217,7 +218,7 @@
     _SDRPLAY_DLL_QUALIFIER sdrplay_api_ErrT        sdrplay_api_Uninit(HANDLE dev);
     _SDRPLAY_DLL_QUALIFIER sdrplay_api_ErrT        sdrplay_api_Update(HANDLE dev, sdrplay_api_TunerSelectT tuner, sdrplay_api_ReasonForUpdateT reasonForUpdate, sdrplay_api_ReasonForUpdateExtension1T reasonForUpdateExt1);
     _SDRPLAY_DLL_QUALIFIER sdrplay_api_ErrT        sdrplay_api_SwapRspDuoActiveTuner(HANDLE dev, sdrplay_api_TunerSelectT *currentTuner, sdrplay_api_RspDuo_AmPortSelectT tuner1AmPortSel);
-    _SDRPLAY_DLL_QUALIFIER sdrplay_api_ErrT        sdrplay_api_SwapRspDuoDualTunerModeSampleRate(HANDLE dev, double *currentSampleRate);
+    _SDRPLAY_DLL_QUALIFIER sdrplay_api_ErrT        sdrplay_api_SwapRspDuoDualTunerModeSampleRate(HANDLE dev, double *currentSampleRate, double newSampleRate);
     _SDRPLAY_DLL_QUALIFIER sdrplay_api_ErrT        sdrplay_api_SwapRspDuoMode(sdrplay_api_DeviceT *currDevice, sdrplay_api_DeviceParamsT **deviceParams,
                                                                               sdrplay_api_RspDuoModeT rspDuoMode, double sampleRate, sdrplay_api_TunerSelectT tuner,
                                                                               sdrplay_api_Bw_MHzT bwType, sdrplay_api_If_kHzT ifType, sdrplay_api_RspDuo_AmPortSelectT tuner1AmPortSel);

The sdrplay_api_DeviceT structure is now 1 byte longer (unsigned char valid).

Perhaps the SoapySDRPlayX code could check it's size at runtime to account for this breakage?

Module hangs SoapySDR

Hey folks, having some trouble with this module. Running a find or a probe from SoapySDRUtil while the SDRPlay module is =present= in /usr/local/lib/SoapySDR/modules0.x, even if find-ing or probe-ing against another driver, causes SoapySDRUtil to hang. Simply doing a "sudo rm libsdrPlaySupport.so; sudo ldconfig" restores functionality.

Ubuntu 21.04:
Linux lenny-bu 5.11.0-18-generic #19-Ubuntu SMP Fri May 7 14:22:03 UTC 2021 x86_64 x86_64 x86_64 GNU/Linux

SoapySDR 0.7.2 (either from binary package, or compiled from source package)
-- OR 0.8 (compiled from latest source).

SoapySDRPlay3 (compiled from latest source, recompiled to switch between Soapy 0.7.2 and 0.8).

Attachment:
CMakeOutput.log

The msi* kernel drivers are blacklisted.
This same constellation (using Soapy 0.8 compiled from source) worked fine on this same PC under Ubuntu 20.10/64.


Example 1 - Attempting to use SDRPlay driver, with both RTL-SDR and SDRPlay RSP1 hardware installed (any combination with/without hardware yields the same behavior, though the kernel and Rafael 820 message only appear if the RTL-SDR in plugged in)

$ SoapySDRUtil --info
######################################################

Soapy SDR -- the SDR abstraction library

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

Lib Version: v0.7.2-unknown
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/librtlsdrSupport.so (0.3.0)
Module found: /usr/local/lib/SoapySDR/modules0.7/libsdrPlaySupport.so (0.3.0)
Available factories... rtlsdr, 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]

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

Soapy SDR -- the SDR abstraction library

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

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

$ SoapySDRUtil --probe=sdrplay
######################################################

Soapy SDR -- the SDR abstraction library

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

Probe device sdrplay
Detached kernel driver
Found Rafael Micro R820T tuner
Reattached kernel driver


Example 2 - Trying to use rtlsdr driver while sdrplay driver is merely =present= in modules dir, with both RTL-SDR and SDRPlay RSP1 hardware installed (again, the kernel and Rafael 820 messages only appear if the RTL-SDR is plugged in

$ SoapySDRUtil --find="device=rtlsdr"
######################################################

Soapy SDR -- the SDR abstraction library

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

Detached kernel driver
Found Rafael Micro R820T tuner
Reattached kernel driver


Example 3 - Delete sdrplay driver from modules dir and re-try, RTL-SDR and SDRPlay RSP1 hardware installed

$ cd /usr/local/lib/SoapySDR/modules0.7
$ ls -l
total 320
-rw-r--r-- 1 root root 143312 Jun 15 16:25 librtlsdrSupport.so
-rw-r--r-- 1 root root 183304 Jun 15 16:30 libsdrPlaySupport.so
$ sudo rm libsdrPlaySupport.so
$ sudo ldconfig
$ cd

$ SoapySDRUtil --info
######################################################

Soapy SDR -- the SDR abstraction library

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

Lib Version: v0.7.2-unknown
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/librtlsdrSupport.so (0.3.0)
Available factories... rtlsdr
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]

$ SoapySDRUtil --probe=rtlsdr
######################################################

Soapy SDR -- the SDR abstraction library

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

Probe device rtlsdr
Detached kernel driver
Found Rafael Micro R820T tuner
Reattached kernel driver
Detached kernel driver
Found Rafael Micro R820T tuner


-- Device identification

driver=RTLSDR
hardware=R820T
origin=https://github.com/pothosware/SoapyRTLSDR
rtl=0


-- Peripheral summary

Channels: 1 Rx, 0 Tx
Timestamps: NO
Other Settings:
* Direct Sampling - RTL-SDR Direct Sampling Mode
[key=direct_samp, default=0, type=string, options=(0, 1, 2)]
* Offset Tune - RTL-SDR Offset Tuning Mode
[key=offset_tune, default=false, type=bool]
* I/Q Swap - RTL-SDR I/Q Swap Mode
[key=iq_swap, default=false, type=bool]
* Digital AGC - RTL-SDR digital AGC Mode
[key=digital_agc, default=false, type=bool]


-- RX Channel 0

Full-duplex: YES
Supports AGC: YES
Stream formats: CS8, CS16, CF32
Native format: CS8 [full-scale=128]
Stream args:
* Buffer Size - Number of bytes per buffer, multiples of 512 only.
[key=bufflen, units=bytes, default=262144, type=int]
* Ring buffers - Number of buffers in the ring.
[key=buffers, units=buffers, default=15, type=int]
* Async buffers - Number of async usb buffers (advanced).
[key=asyncBuffs, units=buffers, default=0, type=int]
Antennas: RX
Full gain range: [0, 49.6] dB
TUNER gain range: [0, 49.6] dB
Full freq range: [23.999, 1764] MHz
RF freq range: [24, 1764] MHz
CORR freq range: [-0.001, 0.001] MHz
Sample rates: 0.25, 1.024, 1.536, 1.792, 1.92, 2.048, 2.16, 2.56, 2.88, 3.2 MSps

Reattached kernel driver


End examples

Problems building SoapySDRplay on Windows 7

I installed SDRplay_RSP_API-Windows-3.06 and then I tried to build SoapSDRPlay on Windows 7. It complained about a missing definition of "HANDLE" - I put in the version of "HANDLE" out of "phread.h" and that got it to complain about "sdrplay_api_DbgLvl_Disable" missing. I commented out the lines with the sdrplay_api_DebugEnable calls that include the "sdrplay_api_DbgLvl_Disable". It then built and ran in "Duel Turner" mode.

Compilation errors on Windows

Hi @SDRplay ! I finally have (some) time to test the SoapySDRplay3 module under Windows10 x64.

I installed the API/DRIVER 3.06 package for Windows, side by side to the existing 2.13 package.

Unfortunatly, I quickly stumbled under the following errors:

  • FindLibSDRPlay.cmake : for WIN32, the definition still references mir_sdr.h / mir_sdr_api.lib instead of the sdrplay_api.h / sdrplay_api.lib. No big deal, I changed that.
  • Next step, the compilation failed because HANDLE was unknown. Indeed, its definition appeared nowhere in the include files.

My renewed interest for SDR is because I bought a Youloop from rtl-sdr.com :) I live in appartment, in a urban environnement, and it is the first time I can finally use my RSP2 on the HF band !

I plugged it in Port A. I also tried a horrible hack job to plug it in the Hi-Z port trying to follow the plug-your-coax-in-Hi-z method of the guide with no success but I'm terrible at that kind of things.

I got decodable LSB/USB signals eventually on the 40 m and 80 m band using port A. Since it is a passive loop, I'm forced to use it on RF ctrl = 0/1/2 and AGC on to be able to pick up signals, but the noise level was indeed much lower than when I used a simple wire on the Hi-Z.

Stopping the digression I wondered if the Soapy3 version put some better internal settings, given all the discussion we had with @fventuri and I wanted to test it.

RF gain for RSPdx has range 0-9 only

@SDRplay notified me that they noticed that the RF gain values for the RSPdx are only set in the range 0-9 even if the RF gain selection menu shows the full range 0-27.

The problem was due to the way the 'LNAstate' variable was read/written in the methods readSettings() and writeSettings() (as a set of if/else for the range 0-9 only);the new code uses 'std::to_string' and 'stoul', and can work with arbitrary large ranges.

implement device filter and open by serial

As part of standards compliance (just kidding). The find function and open should support the "serial" keyword, filtering on the keyword when specified in the hints, and even using it to open the device in the factory function. But most of the drivers actually support this so you can almost universally pass in a serial number in the args to uniquely specify a device and it should actually simplify the code a bit:

Here are a few notes:

SDRPlay v2 has a good example of this

Implementation changes

  • Dont parse the label string in Settings.cpp, just use the args["serial"] directly to match the device
  • In Registration.cpp, just add dev["serial"] = format(... SDRPLAY_MAX_SER_NO_LEN, rspDevs[i].SerNo)
  • And in Registration.cpp, skip the loop if dev["serial"] != args["serial"] when serial is present in the args

Other notes

  • dev["driver"] = "sdrplay"; is redundant, SoapySDR library will handle that

Missing RSPdx entries in getAntenna()

@vsonnier reported:

One minor issue I noticed while browsing Settings.cpp : apparently RSPDx management is missing in std::string SoapySDRPlay::getAntenna(const int direction, const size_t channel) const.

API version number reported is always 0.000

As reported by @SDRplay , when running the command 'SoapySDRUtil --probe', the API version returned is always 0.000.
This was caused by a bug where the variable ver was only internal to the sdrplay_api class - I have now exposed it with the 'get_version()' method, and changed 'SoapySDRPlay::getHardwareInfo()' to use 'sdrplay::get_version()' to return the correct value.

This is now fixed in master and in the other branches as well.

[Bug] no sdrplay device found when connected

When using a Raspberry Pi 4 + SoapySDRPlay3 + another USB device (connected to USB 3.0 port (bottom blue port if looking at the Pi)), SoapySDRUtil is unable to locate SDRplay devices. Once I remove the secondary USB device, reboot the machine, and execute SoapySDRUtil, it's able to find the SDRplay. Interestingly, applications that interface with SoapySDRPlay3 are still able to function properly, so it seems like only SoapySDRUtil --probe flag is running into this issue specifically.

Version info:

pi@raspberrypi:~ $ cat /etc/os-release
PRETTY_NAME="Raspbian GNU/Linux 10 (buster)"
NAME="Raspbian GNU/Linux"
VERSION_ID="10"
VERSION="10 (buster)"
VERSION_CODENAME=buster
ID=raspbian
ID_LIKE=debian

pi@raspberrypi:~ $ SoapySDRUtil --info
######################################################

Soapy SDR -- the SDR abstraction library

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

Lib Version: v0.8.0-unknown
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)
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]

Error:

pi@raspberrypi:~ $ SoapySDRUtil --probe="driver=sdrplay"
######################################################

Soapy SDR -- the SDR abstraction library

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

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

Troubleshooting:

When running the following commands I can see the SDR via lsusb as well as dmesg:
pi@raspberrypi:~ $ lsusb
Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 001 Device 004: ID 10c4:ea60 Cygnal Integrated Products, Inc. CP2102/CP2109 UART Bridge Controller [CP210x family]
Bus 001 Device 005: ID 1df7:3020
Bus 001 Device 002: ID 2109:3431 VIA Labs, Inc. Hub
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
pi@raspberrypi:~ $ dmesg | grep 1df7
[ 3.654142] usb 1-1.1: New USB device found, idVendor=1df7, idProduct=3020, bcdDevice= 2.00
[ 87.554668] usb 1-1.1: New USB device found, idVendor=1df7, idProduct=3020, bcdDevice= 2.08

Additional evidence:

I found another person that reported similar behavior on the SDRplay forums a year back: https://sdrplayusers.net/forums/topic/pi-4-anyone-have-a-rspdx-working/

Error compiling on Pi4 - /usr/local/lib/libsdrplay_api.so: file not recognized: file format not recognized

[ 16%] Linking CXX shared module libsdrPlaySupport.so
/usr/local/lib/libsdrplay_api.so: file not recognized: file format not recognized
collect2: error: ld returned 1 exit status
make[2]: *** [CMakeFiles/sdrPlaySupport.dir/build.make:165: libsdrPlaySupport.so] Error 1
make[1]: *** [CMakeFiles/Makefile2:123: CMakeFiles/sdrPlaySupport.dir/all] Error 2
make: *** [Makefile:149: all] Error 2

pi@rpi4 ~/repos/SoapySDRPlay/build master 17s
❯ file /usr/local/lib/libsdrplay_api.so.3.07
/usr/local/lib/libsdrplay_api.so.3.07: ELF 64-bit LSB shared object, ARM aarch64, version 1 (SYSV), dynamically linked, BuildID[sha1]=3aea2df7ad2947cfa4a385f73779dca8f1eb3008, with debug_info, not stripped

SDRPlay api installed without errors using SDRplay_RSP_API-ARM64-3.07.1.run from SDRPlay
SoapySDR built from git

Hardware is RPi4 8GB with 64-bit kernel & 32-bit userland (which I am guessing causes the issue)

Make a tag/release

Please, consider making a tag or a release for SoapySDRPlay3. It would make packaging in Linux distributions much easier.

Question about rfnotch_ctrl

The SoapySDRPlay3 module has two filter controls, rfnotch_ctrl and dabnotch_ctrl (or maybe these are in the API, not the Soapy module?) The DAB notch control is self-explanatory (except that I don't know what DAB is), but other than that notch filter my RSP1A has two others. for the medium-wave AM and the FM broadcast bands. Does enabling the RF notch via rfnotch_ctrl=1 enable both of these broadcast band filters? I looked at the API documentation but couldn't find an answer: in there it appears that there may be separate controls for the MW and FM filters. Thanks.

link error on macos catalina

I have install sdrplay api v3, and then make. compile is ok, but error at linking:

[ 16%] Linking CXX shared module libsdrPlaySupport.so
Undefined symbols for architecture x86_64:
"SoapySDR::Device::setReferenceClockRate(double)", referenced from:
vtable for SoapySDRPlay in Settings.cpp.o
"SoapySDR::Device::getNativeDeviceHandle() const", referenced from:
vtable for SoapySDRPlay in Settings.cpp.o
"SoapySDR::Device::getReferenceClockRate() const", referenced from:
vtable for SoapySDRPlay in Settings.cpp.o
"SoapySDR::Device::getReferenceClockRates() const", referenced from:
vtable for SoapySDRPlay in Settings.cpp.o
ld: symbol(s) not found for architecture x86_64
clang: error: linker command failed with exit code 1 (use -v to see invocation)
make[2]: *** [libsdrPlaySupport.so] Error 1
make[1]: *** [CMakeFiles/sdrPlaySupport.dir/all] Error 2
make: *** [all] Error 2

what should I do?

Could not find a package configuration file provided by "SoapySDR"

Me again.

Following the build guide on latest Raspberry Pi OS, after the eventually successful SoapySDR install:

pi@sdrpi:~/SoapySDRPlay3/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/pi/SoapySDRPlay3/build/CMakeFiles/CMakeOutput.log".
pi@sdrpi:~/SoapySDRPlay3/build $ cmake .. -DSoapySDR_DIR=/home/pi/SoapySDR/cmake/Modules
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/pi/SoapySDR/cmake/Modules/SoapySDRConfig.cmake, version: unknown



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

Multiple clients with SoapyRemote

Launching SoapyServer
SoapySDRServer --bind

Then connecting with a client (ex cubic sdr, rx_tools,...) works perfectly.

However trying to connect a second client is unsucceful :

  • Cubic SDR return no devices

  • rx_tools return [WARNING] findSDRPlay() called while the device is streaming. Ignoring request. SoapySDRDevice_make failed Failed to open sdr device matching 'driver=remote,remote=tcp://[::]:55132'.

  • SoapySDRUtil --find="driver=remote,remote:driver=sdrplay" return
    No devices found! driver=remote,remote:driver=sdrplay

This seems to be the default behaviour as per issue #9

However multiple consumer on one server seem to be possible on SoapyRemote and seemed to be possible in past (seeing issue #46 on the SoapySDRPlay repository)

Trying to remove this line in Registration.cpp :
if (activeStream){ SoapySDR_log(SOAPY_SDR_WARNING, "findSDRPlay() called while the device is streaming. Ignoring request."); return results; }

Allow a device in use to be discovered from an other client, but give a segfault on connect.

Is this a limitation from the sdrplay driver? Have I misinterpreted the SoapyRemote page, and multiple client is not a feature?

Overflow with RSP1A approx. 4x per hour --> Single short audio pieces are missing in the stream (fraction of a second)

RTLSDR-Airband (latest unstable)
SoapySDR 0.8.0
SoapySDRPlay 0.3.0
SDRplay_RSP_API-ARM32-3.07.2

I am currently doing tests for a new LiveATC streaming setup. I am using two SDRs in parallel with RTLSDR airband via SoapySDR: an RSP1A and an Airspy mini.

With the official version of RTLSDR-Airband it always stopped after about 5 to 15 minutes with the following message: OSoapySDR device 'driver=sdrplay,biasT_ctrl=false': readStream failed: OVERFLOW, disabling

The author of RTLSDR-Airband then referred me to the current unstable branch, which does not stop in such a case. And indeed: RTLSDR-Airband now runs, even when overflows occur at RSP1A.

Since the Airspy mini is running in parallel, I have two more or less identical MP3 files, which I record. However, I notice the following: It is always recorded for an hour in parallel into an MP3 file. While at the beginning of an hour both files are absolutely at the same time, the RSP1A file is a few seconds ahead (about 3 seconds) until the end of the hour. I then noticed that per hour maybe 4 to 5 times short moments (fraction of a second) are missing in the stream of the RSP1A. This manifests itself as a few syllables being swallowed each time. This then seems to add up over an hour.

I assume that the swallowed short time segments always occur when an overflow occurs. Since the Airspy mini does not have this problem: Is there any way to tell what is causing these sporadic overflows and what I can do about it?

Master (RSPduo sample rate=8mhz)

I have that as an option in the list, but when I select it - it offers a maximum sample rate of 2 MHZ and if I ask it to do any sample rate above 2 MHZ - I complains a does not do it on macOS Monterey

libsdrPlaySupport.so cannot find libsdrplay_api.so.3.07

Fedora 34, SoapySDR-0.7.2-11.fc34.x86_64, SDRplay API 3.07.1, latest SoapySDRPlay3 master.

The installed libsdrPlaySupport.so cannot find libsdrplay_api.so.3.07 although it linked fine during the build process:

$ ldd /usr/local/lib64/SoapySDR/modules0.7/libsdrPlaySupport.so                                                                                                                                                           
	linux-vdso.so.1 (0x00007ffd893cb000)
	libsdrplay_api.so.3.07 => not found
	libSoapySDR.so.0.7 => /lib64/libSoapySDR.so.0.7 (0x00007f8688a5e000)
	libstdc++.so.6 => /lib64/libstdc++.so.6 (0x00007f868883f000)
	libm.so.6 => /lib64/libm.so.6 (0x00007f86886fb000)
	libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x00007f86886e0000)
	libpthread.so.0 => /lib64/libpthread.so.0 (0x00007f86886bf000)
	libc.so.6 => /lib64/libc.so.6 (0x00007f86884ee000)
	libdl.so.2 => /lib64/libdl.so.2 (0x00007f86884e7000)
	/lib64/ld-linux-x86-64.so.2 (0x00007f8688aec000)
$ SoapySDRUtil --probe="driver=sdrplay"
######################################################
##     Soapy SDR -- the SDR abstraction library     ##
######################################################

Probe device driver=sdrplay
[ERROR] SoapySDR::loadModule(/usr/local/lib64/SoapySDR/modules0.7/libsdrPlaySupport.so)
  dlopen() failed: libsdrplay_api.so.3.07: cannot open shared object file: No such file or directory

However, the built libsdrPlaySupport.so in build dir (before installing it with sudo make install) does not have this issue:

$ ldd SoapySDRPlay3/build/libsdrPlaySupport.so
	linux-vdso.so.1 (0x00007ffe6c14d000)
	libsdrplay_api.so.3.07 => /usr/local/lib/libsdrplay_api.so.3.07 (0x00007f8ec52d1000)
	libSoapySDR.so.0.7 => /lib64/libSoapySDR.so.0.7 (0x00007f8ec5269000)
	libstdc++.so.6 => /lib64/libstdc++.so.6 (0x00007f8ec504a000)
	libm.so.6 => /lib64/libm.so.6 (0x00007f8ec4f06000)
	libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x00007f8ec4eeb000)
	libpthread.so.0 => /lib64/libpthread.so.0 (0x00007f8ec4eca000)
	libc.so.6 => /lib64/libc.so.6 (0x00007f8ec4cf9000)
	librt.so.1 => /lib64/librt.so.1 (0x00007f8ec4cee000)
	libdl.so.2 => /lib64/libdl.so.2 (0x00007f8ec4ce7000)
	/lib64/ld-linux-x86-64.so.2 (0x00007f8ec5506000)

Everything works fine after manually copying this file to the target directory:
sudo cp SoapySDRPlay3/build/libsdrPlaySupport.so /usr/local/lib64/SoapySDR/modules0.7/libsdrPlaySupport.so

(Question) Rsp1a bandwidth max

Good afternoon. According to documentation on the SDRPlay site it makes it seem like the rsp1a can view up to 10Mhz wide spectrum at a time. Where I get confused is it’s mention later on down the documentation about IF bandwidth and then also with SoapySDRUtil —probe driver=sdrplay it would lead me to believe the bandwidth is a max of 8. I recall the Sdrplay people may have explained this to me in the past, but I’ve long since forgot.

Is there a combination of settings, sample rate/bandwidth with soapy that will yield a 10Mhz wide chunk of the spectrum being received by the Rsp1a. Asking specifically to see if it can cover the same chunk as shown in the image (front page, scroll down a little) as the hackrf, bladerf etc.

https://github.com/muccc/gr-iridium

Mac M1 Issue

[ 16%] Linking CXX shared module libsdrPlaySupport.so
Undefined symbols for architecture arm64:
"SoapySDR::Device::getSettingInfo(std::__1::basic_string<char, std::__1::char_traits, std::__1::allocator > const&) const", referenced from:
vtable for SoapySDRPlay in Settings.cpp.o
"SoapySDR::Device::getSettingInfo(int, unsigned long, std::__1::basic_string<char, std::__1::char_traits, std::__1::allocator > const&) const", referenced from:
vtable for SoapySDRPlay in Settings.cpp.o
ld: symbol(s) not found for architecture arm64
clang: error: linker command failed with exit code 1 (use -v to see invocation)
make[2]: *** [libsdrPlaySupport.so] Error 1
make[1]: *** [CMakeFiles/sdrPlaySupport.dir/all] Error 2
make: *** [all] Error 2

Add explanatory message for the user when sdrplay_api_Open() fails

Currently if the sdrplay_api service is down or not responsive, when the call to sdrplay_api_Open() fails, the driver only return a failure message, that can be hard for the user to understand.
With this change a more explanatory message is returned suggesting the user to make sure the sdrplay_api service is healthy.

Start at the same time (and time synchronisation?)

Hi!
(Sorry for my terrible English)

I tried to use RSPDuo for synchronised by time/phase two-channel signal reception. As I understand - this device can solve this task in Dual Tuner mode with Independent RX. Your repo is exactly what I need! Thank you for your work!

Question: is there any way to start two channels at the same time? For now I see big difference between:
telegram-cloud-photo-size-2-5327846101522429445-x
As you see, red channel starts much later than blue.

For now I using your Soapy module from dual-tuner-submodules branch, and trying to write custom block for GnuRadio, here is device creation:

d_samp_rate = 1e6;

d_device = SoapySDR::Device::make(SoapySDR::KwargsFromString("driver=sdrplay, rspduo_mode=2, rspduo_dual_tuner_independent_rx=true"));

d_device->setSampleRate(SOAPY_SDR_RX, 0, d_samp_rate);
d_device->setSampleRate(SOAPY_SDR_RX, 1, d_samp_rate);

d_device->setGainMode(SOAPY_SDR_RX, 0, false);
d_device->setGainMode(SOAPY_SDR_RX, 1, false);

d_device->setFrequency(SOAPY_SDR_RX, 0, fc1);
d_device->setFrequency(SOAPY_SDR_RX, 1, fc2);

d_stream1 = d_device->setupStream(SOAPY_SDR_RX, "CF32", {0}, SoapySDR::KwargsFromString(""));
d_stream2 = d_device->setupStream(SOAPY_SDR_RX, "CF32", {1}, SoapySDR::KwargsFromString(""));
d_device->activateStream(d_stream1);
d_device->activateStream(d_stream2);

And buffers reading:

int
rspduo_source_impl::work(int noutput_items,
  gr_vector_const_void_star &input_items,
  gr_vector_void_star &output_items)
{
  int flags = 0;
  long long timeNs = 0;
  // read from first stream
  int read = d_device->readStream(d_stream1, &output_items[0], noutput_items, flags, timeNs);
  if (read < 0) {
    std::cout << "A";
  }
  // and read from second stream, with same count of items but into another buffer
  read = d_device->readStream(d_stream2, &output_items[1], noutput_items, flags, timeNs);
  if (read < 0) {
    std::cout << "B";
  }
  return noutput_items;
}

Looks like I missed something in docs, will be very appreciated for any help!

rspduo in diversity mode (mode 2)

I am working to get the rspduo working in mode 2 (diversity) feeding into gnu radio via the soapy interface. I have modified Streaming.cpp (probably inelegantly due to rusty c++!) to get both channels back to gnu radio (locally and remote). It appears to be working but the data doesn't appear to be synchronised, I think because the phase difference between the two channels varies considerably over short time spans. Modified Streaming.cpp attached, please no laughter😉. My soapy module in gnu radio is configured for 2 channels and sdrplay with a config line of "remote=192.168.0.10:1234,driver=remote,rspduo_mode=2". Any ideas about the data synchronisation? Thanks Bob
Streaming.cpp.zip

Device Not Detected

Well, that's the conclusion, although something is detected.
I have an SDRplay RSP1A with the Soapy modules v0.8 from SDRplay and I'm using CubicSDR 0.2.6a (a build also from SDRplay) along with the SDRplay provided v0.8 Soapy modules. All of this is on a Mac running 10.15.7. Probing the device with SoapySDRUtil yields the following output

##     Soapy SDR -- the SDR abstraction library     ##
######################################################

Probe device 
[INFO] devIdx: 0
[INFO] hwVer: 255

----------------------------------------------------
-- Device identification
----------------------------------------------------
  driver=SDRplay
  hardware=20060DD397
  sdrplay_api_api_version=0.000000
  sdrplay_api_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)]
     * 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: NO
  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.001, 2000] MHz
    RF freq range: [0.001, 2000] MHz
    CORR freq range:  MHz
  Sample rates: 0.0625, 0.125, 0.25, 0.5, 1, 6, 7, 8, 9, 10 MSps
  Filter bandwidths: 0.2, 0.3, 0.6, 1.536, 5, 6, 7, 8 MHz

As you can see, there are "Other Settings" available such as RF Gain Select and BiasT enable/disable. However, CubicSDR doesn't seem to fully see this device as evidenced by the lack of set/enable/disable options in the Settings menu for these "Other Settings". Below are some screenshots of the Settings menu and the initial dialog from CubicSDR. I will note that the radio does actually work in CubicSDR and I am able to receive MW AM broadcasts as well as VHF FM broadcasts. This issue has been discussed here
CubicSDR_Screenshot
SDRDevices_Screenshot

Error handling in SoapySDRPlay driver

This purpose of this discussion is to come up with a good way of handling errors in the SoapySDRPlay driver.

Part of this discussion is here: #16 (see posts by @vsonnier and @jketterl; @SDRplay and @guruofquality are also mentioned there).

To summarize that discussion there, one option could be to throw a std::runtime_error exception when an invalid value is requested in a 'set' function, and making sure that functions like listSampleRates() are consistent with the values acceptable by the corresponding 'set' function (i.e. setSampleRate() in this example), so that the SoapySDR client application knows which values and settings are valid in advance.

In a similar fashion an exception could possibly also be thrown if say a call to the underlying 'sdrplay_api' methods were to fail (for instance if the call to 'sdrplay_api_Update()' returned an error status code for some reason), since currently those return codes are ignored by the SoapySDRPlay driver in many cases.

Franco

New gain controls

Given the diversity of opinions on how the gain controls should work (see discussion here: #27), I spent some time over the weekend thinking about a possible way of dealing with all the different tastes and preferences, and I just pushed my changes to the new-gain-controls branch.

Basically I created four different 'models' of gain controls, selectable via a line in the cmake config file CMakeLists.txt (https://github.com/pothosware/SoapySDRPlay3/blob/new-gain-controls/CMakeLists.txt#L43).

The four models are:

  • Legacy: this one behaves exactly like the code currently in master (IFGR and RFGR, no "generic" setGain(), etc); if these changes land in master, the default could be initially set to 'Legacy' for compatibility with the existing clients; this way the distributions would use the 'Legacy' mode by default, and there would be little to no disruption to the end users.
  • SDRplay: this one is exactly the new gain controls code that @SDRplay wrote almost a year ago (see here: cjcliffe/CubicSDR#825), and it could be used to compare the other gain control models with his proposal.
  • DB: this is a new one I added based on our discussion last week; the gain controls are just RF and IF, and the values are expressed in dB (higher values mean more gain, i.e. stronger signal). Since the two gain control values use the same units, I also added a generic setGain() (and getGain()), where the requested gain is split between RF and IF in parts proportional to the range of each gain control (see the source code for details). The dB range of these "gains" is arbitrary: for IF I chose the range [20,59], while for RF I chose the range [X,100] (where X depends on the RSP model, frequency band, etc). For those who prefer negative values like @dlaw, commenting out lines 49-51 in CMakeLists.txt will do just that.
  • LNA: finally this is another new gain control model I added based on @vsonnier's wish to be able to see and use the raw LNA state: the gain controls in this case are LNA and IF(higher values mean more gain, i.e. stronger signal). The default range for IF is the same as before ([20,59]), while the default range for LNA is [0,max(LNAstate)]. Since these values use incompatible units, I did not define a generic setGain() (or getGain()) for this case. For those who prefer negative values, again commenting out lines 46-48 in CMakeLists.txt will do the trick.

To make it easier to work with all the different gain control models (and perhaps to add more if we like to explore other options), I pulled out of Settings.cpp all the code for the gain API, and reorganized it in four different source files, one for each of these gain control models (plus one for some common code related to the gain reduction tables from the SDRplay API specification document).

One final note about the gains in dB: I spent some time yesterday afternoon playing around with SDRuno, switching the RF gain display mode back and forth between 'Gain' and 'Attenuation', and I noticed that while the dB values for RF attenuations in SDRuno match exactly the values in the gain reduction tables in the SDRplay API specification, the same is not true when the RF gain display mode is set to 'Gain': the dB values in this case have decimals, their spacing is different than shown in the tables (for instance the gain reduction tables might have 7dB difference between two successive LNA state values, while the SDRuno RF gain changes 6.5dB between the same LNA states); the minimum and maximum values depend on the frequency band, the RSP model, and possibly other factors.
In other words I have the impression that SDRplay have done a good amount of work in figuring out the real gains in dB (and those are displayed in SDRuno when the RF gain control is set to 'Gain'), while the figures from the gain reduction tables are just rough approximations, and it is not obvious to me how the two are related, i.e. how to compute the real RF gain from the LNA state (I searched around for a bit, but I couldn't find much information about these RF gain values).
As a consequence the RF "gains" in dB of the third gain control model (the one I called 'DB') are not the real gains, and shouldn't be treated as such; they are just some arbitrary values in dB that "approximate" the behavior of the real gain, in the sense that increasing the RF gain control by 10dB increases the signal by about 10dB, but the RF gain value shown is purely arbitrary (I hope this rambling makes sense).

One last caveat when using CubicSDR with the new gain controls: CubicSDR stores the last used config under $HOME/.CubicSDR/config.xml (on Linux; there's probably a similarly named file on Windows and Mac); in my case this file had the last used gains controls as IFGR and RFGR, and threw a few error messages about invalid gain range when starting the RSP, because those names are different in some of the gain control models; if you see similar error messages, you may want to recreate the CubicSDR config.xml file from scratch (or edit it to change the names and values of the gain controls, if you don't want to lose the rest of the CubicSDR configuration).

@SDRplay, @vsonnier, @dlaw, @nmaster2042, please give it a try and let me know what you think (I just ran a few quick tests here streaming a local FM station, and they worked, but there are probably still bugs in the code).

Franco

The version from May 6 works terribly

Bug.
I have Debian v. 10 running steadily for a long time.
But when I installed your version of SoapySDRPlay3 from May 6, it regularly causes Debian crashes.
Once every few days, it stops working.
The system stops responding and does not respond to the keyboard.
The network also does not work and does not ping from the outside.
But there is no kernel panic. The OS froze as if rooted to the spot.
Ctrl-Alt-Del and "Magic Button" SysRq/Printscreen don't help. Only Reset helps.
When I stopped using your software, Debian again began to work as before, steadily.

Disadvantage.
The process of your SoapySDRPlay3 from May 6 consumes a very lot of resources - 30% or more.
Other Soapy consumes a units of percent.

Driver name

I'm using SoapySDRPlay with "API/HW DRIVER – V3" and gr-soapy inside Gnu Radio.
During the proces I noticed the driver name in your code is "sdrPlay" instead of "sdrplay". In fact opened an issue at SoapySDRPlay: https://gitlab.com/librespacefoundation/gr-soapy/-/issues/84

But, I'm wondering if the driver name change it was deliberated or not.
I guess if you change the driver name some softwares (cubicsdr, gqrx, etc..) could stop working.

undefined symbol

I have an SDRPlay RSP2Pro and built the module after installing the latest api from sdrplay. When I execute SoapySDRUtil --probe=sdrplay I get the following.

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

Soapy SDR -- the SDR abstraction library

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

Probe device sdrplay
[ERROR] SoapySDR::loadModule(/usr/local/lib/SoapySDR/modules0.7/libsdrPlaySupport.so)
dlopen() failed: /usr/local/lib/SoapySDR/modules0.7/libsdrPlaySupport.so: undefined symbol: _ZNK8SoapySDR6Device16hasIQBalanceModeEim

System is Debian 11. No errors when compiling but the above describes the error. I do not get a SDRPlay interface in CubicSDR or GQRX because the module will not load

Error: undefined reference to `pthread_cond_clockwait' when compiling on Fedora 32

As reported by @jawatson here (fventuri/SoapySDRPlay#2), building the SoapySDRPlay driver on Fedora 32 fails with an error message that looks like this:

Streaming.cpp:(.text+0xaa5): undefined reference to `pthread_cond_clockwait'

After some research this morning, I suspect it is because std::condition_variable::wait_for() is now implemented using pthread_cond_clockwait(), and this symbol is defined in libpthread (not in libc) in Fedora 32 (and possibly other Linux distributions).

As suggested by @jawatson, I added the '-pthread' flag to the target link options in CMakeLists.txt for the specific case of Linux gcc version >= 10.

Once I get a better idea of what exactly triggers this behavior, I can change the conditions for adding the '-pthread' flag as needed.

Franco

Overriding default setGain() function

Hello, Franco!

While trying to make an RSP device work with OpenWebRX, I have found that the single-value gain setting essentially drives Soapy crazy on RSP.

Further investigation has shown that the default setGain() method in Soapy tries approximating requested gain with multiple stage gains. Since RSP stage gains are essentially negative, and the RFGR value isn't even meadured in decibels, the whole setGain() thing fails rather miserably.

Because of that, I would like to ask you to override the default setGain() in SoapySDRPlay3 with implementation that ONLY sets IFGR to the requested value. This should at least sort out some confusion.

I have pending OpenWebRX changes to have separate RFGR and IFGR settings for RSP, with AUTO only affecting IFGR, as it does in hardware

Uninitialized value of outputSampleRate variable for RSP1a

Hello everyone,

I just received my RSP1a this week and it's working fine on my Ubuntu 20.10 machine. But GQRX is crashing on my RPi3 B+ setup.

I'm using the latest Raspberry Pi OS with self compiled gnuradio-3.8.1, the latest SoapySDRPlay3 and GQRX.

It looks like GQRX is trying to get sample rate during selection of new input device (https://github.com/csete/gqrx/blob/07722f21d0be2b63ae4e5d6f34601ece8625afe6/src/applications/gqrx/receiver.cpp#L221) but SoapySDRPlay3 is returning some uninitialized value different from 0, so GQRX will try to set back this value as sample rate.

And this will cause an crash, because it's not supported sample rate value.

Initializing the value of outputSampleRate variable (for example to 2MHz) will fix the issue for me. Something similar is already done for RSPDuo here:

outputSampleRate = defaultRspDuoOutputSampleRate;
.

Thank you,
Roman

RSP1A not found under MAC OS after update from SoapySDRplay to SoapySDRplay3

Hello,

RSP1A cant be found under MAC OS after update from SoapySDRplay to SoapySDRplay3 (OS is Catalina 1.15.7).
If i revert back to SoapySDRplay and SDRplay (package install all via MAC PORTs) it will be recognized and running fine.

Also i noticed that RSP1A is after a fresh boot up only been seen then run "SoapySDRUtil --find" twice times (under old SoapySDRplay). I read in SDRplay Forum this is a known BUG and solved with Catalina OS, but seems its not. Anyway back to SoapySDRplay3 and my RSP1A not found problem. I tested the following:

  • a complete fresh install of MAC OS
  • install SoapySDRplay3 and SDRplay3 + dependencies via MAC ports
  • also i tested the install of the latest API package SDRplay_RSP_API-MacOSX-3.07.3.pkg from SDRplay Website

Then i verified that OS see my RSPA1 via lsusb:

alpha@iMAC ~ % uptime
11:06 up 53 secs, 2 users, load averages: 2,29 0,63 0,23

alpha@iMAC ~ % lsusb -v -d 1df7:3000
Bus 020 Device 003: ID 1df7:3000 SDRplay RSP1a
Device Descriptor:
bLength 18
bDescriptorType 1
bcdUSB 2.00
bDeviceClass 255 Vendor Specific Class
bDeviceSubClass 255 Vendor Specific Subclass
bDeviceProtocol 255 Vendor Specific Protocol
bMaxPacketSize0 64
idVendor 0x1df7 SDRplay
idProduct 0x3000 RSP1a
bcdDevice 2.00
iManufacturer 0
iProduct 0
iSerial 0
bNumConfigurations 1
Configuration Descriptor:
bLength 9
bDescriptorType 2
wTotalLength 66
bNumInterfaces 1
bConfigurationValue 1
iConfiguration 0
bmAttributes 0x80
(Bus Powered)
MaxPower 400mA
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 0
bAlternateSetting 0
bNumEndpoints 0
bInterfaceClass 255 Vendor Specific Class
bInterfaceSubClass 255 Vendor Specific Subclass
bInterfaceProtocol 255 Vendor Specific Protocol
iInterface 0
.....

alpha@iMAC ~ % SoapySDRUtil --probe=sdrplay
######################################################
Soapy SDR -- the SDR abstraction library
######################################################
Probe device sdrplay
Error probing device: SoapySDR::Device::make() no driver specified and no enumeration results

alpha@iMAC ~ % SoapySDRUtil --find=sdrplay
######################################################
Soapy SDR -- the SDR abstraction library
######################################################

-------> here it hangs without proceed
^C

alpha@iMAC ~ % SoapySDRUtil --info
######################################################
Soapy SDR -- the SDR abstraction library
######################################################

Lib Version: v0.8.1-unknown
API Version: v0.8.0
ABI Version: v0.8
Install root: /opt/local
Search path: /opt/local/lib/SoapySDR/modules0.8
Module found: /opt/local/lib/SoapySDR/modules0.8/libsdrPlaySupport.so (0.4.0)
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]

alpha@iMAC ~ % ps aux |grep sdrplay

root 253 0,0 0,0 4301168 1868 ?? S 11:54am 0:00.09 /opt/local/bin/sdrplay_apiService
root 100 0,0 0,0 4456720 2728 ?? Ss 11:54am 0:00.01 /opt/local/bin/daemondo --label=sdrplay_service --start-cmd /opt/local/bin/sdrplay_apiService ; --pid=exec
alpha 1074 0,0 0,0 4408516 756 s016 S+ 1:13pm 0:00.00 grep sdrplay

As stated, then i revert to the old packages SDRplay + SoapySDRplay the RSP1A works as exspected.
Need your help to figure out whats going on here please

regards André

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.