pothosware / soapyosmo

Soapy SDR plugins for Osmo supported SDR devices

Soapy SDR plugins for OsmoSDR devices

Build Status

• Travis:

Dependencies

• Boost C++ libraries
• SoapySDR - https://github.com/pothosware/SoapySDR/wiki
• SDR device libraries for osmosdr, mirisdr, rfspace, airspy

Documentation

• https://github.com/pothosware/SoapyOsmo/wiki

Licensing information

• GPLv3: http://www.gnu.org/licenses/gpl-3.0.html

soapyosmo's Issues

problem with return values in GrOsmoSDRStreamer::write

I think that I've found a problem in GrOsmoSDRStreamer::write. It's the if (ret == 0) ... condition on line 66 in GrOsmoSDRInterface.hpp:
https://github.com/pothosware/SoapyOsmo/blob/master/GrOsmoSDRInterface.hpp#L66

If I'm not mistaken it's normal for a sink block to return 0 since it does not produce any samples (number of consumed samples is returned via _consumed_total).

I have a sink block (new version of redpitaya_sink_c) that returns 0 and works with GNU Radio but does not work with Pothos. When I modify this block to return noutput_items, it works with Pothos but does not work with GNU Radio.

Implement new info query API calls

Calls to implement (not much):

• getStreamFormats() - CF32
• getNativeStreamFormat() - CF32

Related issue:

• pothosware/SoapySDR#37

SoapySDR has issues with HackRF

This issue is unique to SoapySDR, other gr-osmosdr based tools like osmocom_fft work fine.

env LIBUSB_DEBUG=3 SoapySDRUtil --probe                                      ‹soapysdr-support*› [08:24:04] 
######################################################
## Soapy SDR -- the SDR abstraction library
######################################################

Probe device 
libusb: warning [darwin_cache_device_descriptor] could not retrieve device descriptor 05ac:8510: device not responding (e00002ed). skipping device
Using HackRF One with firmware 2015.07.2 
libusb: error [darwin_claim_interface] USBInterfaceOpen: another process has device opened for exclusive access
Error probing device: Failed to open HackRF device (-1000) HACKRF_ERROR_LIBUSB

Add FCD support

Would be nice ot have funcube dongle also supported by SoapyOsmo.

I am trying to use SoapyOsmo&Remote for having a small ARM system running with the FCD attached at a good RF location and streaming the data over the netowrk to my main computer.
But unfortunately the fcd is not yet supported by SoapyOsmo/

RF Space build failure on MSVC

Currently RF Space support is disabled in the PothosSDR windows installer. The gr-osmosdr rfspace blocks have some network API incompatibilities that need to be resolved:

• ifdef for winsock headers vs unix headers
• replace close(sock) with closesocket(sock)
  • provide #define closesocket(s) close(s) macro for unix
• Call WSAStartup()

The changes can also be up-streamed to gr-osmosdr official repository. I have no way to test these changes other than getting the module to compile; so if you are interested in RF space support in the Pothos SDR environment please let us know.

Cross platform network includes for reference: https://github.com/pothosware/SoapyRemote/blob/master/common/SoapySocketDefs.in.hpp

fix segf in empty gain lists in gr-osmosdr (soapy wrapper)

Not the best place to put this, but we need a patch for empty gain lists in gr-osmosdr: https://lists.osmocom.org/pipermail/osmocom-sdr/2017-October/001606.html

Disable SoapyOsmo miri by default in favor of SoapyMiri

There is a native SoapySDR Driver SoapyMiri that is working fine: https://github.com/ericek111/SoapyMiri

So mirisdr support can be disabled now to avoid confusion.

Feature request: support libmirisdr-4 (modern fork of libmirisdr-2 / libmirisdr-3 with SDRplay support)

Hello,

would it be possible to support libmirisdr-4 library? It is actively developed fork of libmirisdr-2 / libmirisdr-3-bsz with direct support of SDRplay through a "flavour" option in the open function (this is also reason why build of SoapyOsmo fails with libmirisdr-4).

libmirisdr-4 is used by SDRangel app (similar to GQRX or CubicSDR) for SDRplay support. On my laptop (Lenovo ThinkPad 13, Intel Core i5 Skylake platform) SoapySDRplay (and generally everything which uses proprietary libsdrplay library) fails to read samples and according to SDRplay support it is known issue with some USB 3 drivers (my laptop doesn't have USB 2-only ports). But SDRangel with libmirisdr-4 works really great.

Maybe the best option would be separate SoapyMiriSDR driver, same as like SoapyRTLSDR and SoapyAirspy has been separated. It would be great because 1.) it is not so fragile as libsdrplay (works on more hardware configurations) and 2.) it is open source and therefore can be distributed without any problems.

Btw. just for the reference there is build error when using libmirisdr-4:

/home/mikos/temp/soapyosmo-git/gr-osmosdr/lib/miri/miri_source_c.cc: In constructor 'miri_source_c::miri_source_c(const string&)':
/home/mikos/temp/soapyosmo-git/gr-osmosdr/lib/miri/miri_source_c.cc:119:40: error: invalid conversion from 'unsigned int' to 'mirisdr_hw_flavour_t' [-fpermissive]
   ret = mirisdr_open( &_dev, dev_index );
                                        ^
/home/mikos/temp/soapyosmo-git/gr-osmosdr/lib/miri/miri_source_c.cc:119:40: error: too few arguments to function 'int mirisdr_open(mirisdr_dev_t**, mirisdr_hw_flavour_t, uint32_t)'
In file included from /home/mikos/temp/soapyosmo-git/gr-osmosdr/lib/miri/miri_source_c.cc:41:0:
/usr/include/mirisdr.h:59:17: note: declared here
 MIRISDR_API int mirisdr_open (mirisdr_dev_t **p, mirisdr_hw_flavour_t hw_flavour, uint32_t index);
                 ^~~~~~~~~~~~
make[2]: *** [CMakeFiles/miriSupport.dir/build.make:63: CMakeFiles/miriSupport.dir/gr-osmosdr/lib/miri/miri_source_c.cc.o] Error 1
make[1]: *** [CMakeFiles/Makefile2:105: CMakeFiles/miriSupport.dir/all] Error 2
make: *** [Makefile:139: all] Error 2

Support stream args in GrOsmoSDR

This is more of an issue for the soapy support in GrOsmoSDR, which is a different but related project. Its just easier to track it here. The GrOsmoSDR API doesn't support stream args, but many of the support modules make use of them.

The simple work around is to stash the device args provided by the user and pass them into setupStream() -- that way GrOsmoSDR users can get full use of the stream arguments through the existing API and any GrOsmoSDR command line tools that only take the device args.

Conflicts with other Soapy modules

SoapyOsmo seems to conflict with other Soapy modules.

SoapyOsmo:

• libairspySupport.so
• libhackrfSupport.so
• libosmosdrSupport.so
• librfspaceSupport.so
• librtlSupport.so

SoapyAirspy:

• libairspySupport.so

SoapyHackRF:

• libHackRFSupport.so

SoapyRTLSDR:

• librtlsdrSupport.so

Both SoapyOsmo and SoapyAirspy provide libairspySupport.so. SoapyOsmo also provides dynamic libraries for other devices but they don't conflict as they have slighter different names. I assume SoapyOsmo needs a SoapySDR module for each device it supports, but why not call them something like libOsmo{Airspy,HackRF,RFSpacem,RtlSdr}Support.so?

cannot find SoapySDR library in /usr/local/lib64

I have the SoarpySDR lib in /usr/lib64 but it tries to look for it in a different path

I am building this with the following command:
cmake -DCMAKE_INSTALL_PREFIX:PATH=/usr -DLIB_INSTALL_DIR:PATH=lib64 -DLIB_SUFFIX=64 -DUSE_OSMO_RTLSDR=ON ..
and I get this error:

-- Build type not specified: defaulting to release.
CMake Error at /usr/local/share/cmake/SoapySDR/SoapySDRConfig.cmake:161 (message):
  cannot find SoapySDR library in /usr/local/lib64
Call Stack (most recent call first):
  CMakeLists.txt:42 (find_package)


-- Configuring incomplete, errors occurred!

(Request) Possibly support new bladeRF features

I was thinking how best to go about trying to get Soapy to account for changes Nuand made to gr-osmosdr. I suppose the best route would be for Soapy bladeRF to account for changes, but perhaps this SoapyOsmo may present an easy way for the time being.

Have a look here,
https://github.com/Nuand/gr-osmosdr

The last few commits enable a feature called, I believe, oversample or something of that nature. In this mode, it's reduced to an 8bit sample but it allows the bladeRF to achieve a 122Msps max sample rate/bandwidth setting.

Could a branch be created on this repo be created that uses Nuand's gr-osmosdr and somehow have the Soapy wrapper capable of activating the features? I would be happy to test.

add airspy support for bitpacking ?

For more details see:
http://git.osmocom.org/gr-osmosdr/commit/?id=164a09fc11cec2d8b15b38e8b512fa542d6cecc7

It is extremly similar to the three lines of code used to enable the BiasT