These submodules were helpful initially when developing the Soapy SDR API. But at this point, SoapyUHD and SoapyOsmo are their own independent projects with github project pages, ubuntu packages, windows installers -- just like many others. Having them as git submodules is basically just a build convenience. So its time to take out the submodules:

• Not everyone needs to install them
• Extra dependencies listed in build guide
• Keeps the licensing more strait-forward
• Don't want to favour particular hardware

Also TODO:

• Cleanup build guide mentions of boost, its mentioned already on the build instructions for these submodules.

• for helpful print/log messages on error

Used in osmosdr

I'm contemplating launching a pothosware/homebrew-pothos tap to host formulas for Pothos, SoapySDR, and the many support modules. There are quite a few support modules and this would be an easier way for OSX users to get everything installed.

In addition, these formulas would be usable for linux system under linuxbrew. I would like to make it easier for users to have an up to date consistent install of everything -- with a simple update command no-less.

For reference, there are some formulas already here: https://github.com/dholm/homebrew-sdr

Use any Soapy SDR remotely

The overall goal is to use the existing API to transparently interact with any remote SDR device that has a soapy driver plugin -- over a local network link.

The server

The SoapyServer.exe application will run on the remote host and provide a TCP service to query and instantiate any SDR device found on the remote system. The server will spawn client sockets and threads for each device created.

The client

The client is a standard Soapy SDR plugin module that implements the remote protocol. The plugin's discovery routine will only report devices when the server's addresses is specified in the keyword arguments.

The protocol

The protocol for discovery, instantiation, and configuration is a simple reply/request transaction. The payloads are binary (encoded in network endianess) and always use platform independent representations.

The streams

Streaming will be implemented on-top of UDP, and will track underflow, overflow, and reordering conditions. We may support UDT as well (reliable UDP layer).

The server will spawn new threads and sockets to handle each stream. For the server, the receive stream thread pushes packets to the client endpoint. While the transmit stream thread waits for packets from the client endpoint. Threads and sockets are also spawned to handle the async status messages.

Stream API

The direct buffer access API will be implemented as the primary interface to the remote sockets. The receive and send buffer implementations will simply call into the direct buffer access calls and convert to the user-specified data type.

Stream options

The client may need to specify buffer sizes and number of buffers for the remote layer as well as the underlying SDR device. We will select and document stream keywords specifically for the remote device layer.

The logger

Upon connecting to the server, the client will spawn a UDP socket and thread to handle log messages from the server.

One of the patterns that have come up is that many devices support complex bytes or shorts, and we end up duplicating conversions to support other stream formats for the read/writeStream API. Conversion support routines would provide a standard set of stream formats and conversions between formats for any module. The SoapySDR conversion routines would also be optimized in some cases SIMD or lookup tables (for example we have duplicated neon routines on some of the arm boards).

Conversion.hpp would provide calls to:

1. given a native format, get a list of source formats that we can convert from
2. given a native format, get a list of target formats that we can convert to
3. given a source format and destination format, get a pointer to the conversion function

Implementation

• The default getStreamFormats API can use the first two calls to populate the list of supported formats given the native format. Otherwise, client modules can manually make this call as well.
• The setupStream() in a client module should use the third call to stash a function pointer. This function pointer will be invoked in the respective read/writeStream() API calls

I've got an idea to create a SoapyAudio module using RtAudio that will support input and output to sound cards using Real or Complex (stereo I/Q) for interfacing with VLF via mic connection or radio hardware that supports I/Q data.

Transmission of Real and I/Q data can be supported on line-out/speaker as well.

Additionally I/O from .WAV or other audio files will be supported through stream args / settings.

Could also be used as a general replacement for an audio driver; eliminating the need for built-in audio support.

If you can set up a repository for it I'll probably start hacking it together in the coming weeks :)

Create a server application that implements the RFSPACE network spec so that existing client code can use Soapy SDR devices.

example: rssi, lo locked, register...

If I enumerate the RTL devices returned from std::vectorSoapySDR::Kwargs results = SoapySDR::Device::enumerate(); and attempt to SoapySDR::Device::make(results[x]); a specific result I always get the first RTL device.

Is there something I might need to add or am I using the results parameters incorrectly?

Similarly I can't get SoapySDRUtil to --probe a specific device. It looks like the format should be --probe="driver=rtl,rtl=x" where 'x' is the device index according to the --find of:

Found device 0
  driver = rtl
  label = Realtek RTL2838UHIDIR SN: 00000003
  rtl = 0

where the 'rtl = 0' increases with each device.

Query errors on the device, underflows, overflows, late packets

I wasn't able to find a way to set the RTL-SDR direct sampling mode via the device controls; is there something I've missed that can be used to toggle this setting?

Thanks!

I've pushed up a working standalone RTL-SDR Support Module; still needs a lot of tweaking but it's mostly functional :)

https://github.com/cjcliffe/SoapyRTLSDR

We are interested in doing other language bindings for SoapySDR so that anyone can get involved in SDR using their favourite language, tools, and libraries. We may already have a volunteer to tackle C# bindings for SoapySDR, but first we need to know if there is any interest. Please let us know in the comments. Thanks!

API calls to answer the questions:

• Is automatic DC offset supported?
• Is IQ imbalance correction supported?
• etc

We should be able to replace the in-tree osmosdr support module with one that can exist in the gr-osmosdr tree that works basically the same way.

Devices support in the gr-osmosdr library will be automatically available through the SoapySDR API.

RangeList getMasterClockRates(void) const

• This call will return a RangeList because it could have multiple ranges of values or discrete settings.

Put the uhd module build into in the UHD tree and submit a pull request. Only the build stuff needs minor changes for the UHD include and libraries which will not be in-tree.

Enjoying using SoapySDR so far; it's been quick to implement and looks like a good fit with my project.

I'm able to build and run my application (CubicSDR) with SoapySDR and run it from the terminal without issue; it finds and loads the modules and lists the factories and works with my rtl-sdr device.

Once bundled into an .app (libraries are imported with otool by cmake I believe) the installed soapy modules are found but none of the factories are available via 'SoapySDR::FindFunctions factories = SoapySDR::Registry::listFindFunctions();' except for 'null'.

Run from cli compiled binary:

SoapySDR init..
    API Version: v0.3.0-g603da6be
    ABI Version: v0.3-0
    Install root: /usr/local
    Module found: /usr/local/lib/SoapySDR/modules/libairspySupport.so
    Module found: /usr/local/lib/SoapySDR/modules/libbladerfSupport.so
    Module found: /usr/local/lib/SoapySDR/modules/libhackrfSupport.so
    Module found: /usr/local/lib/SoapySDR/modules/librfspaceSupport.so
    Module found: /usr/local/lib/SoapySDR/modules/librtlSupport.so
    Loading modules... done
    Available factories...airspy, bladerf, hackrf, null, rfspace, rtl
Found device 0
  driver = rtl
  label = Realtek RTL2838UHIDIR SN: 00000003
  rtl = 0
Make device driver=rtl
Using device #0 Realtek RTL2838UHIDIR SN: 00000003
Found Rafael Micro R820T tuner
[R82XX] PLL not locked!

Run from bundled app:

SoapySDR init..
    API Version: v0.3.0-g603da6be
    ABI Version: v0.3-0
    Install root: /usr/local
    Module found: /usr/local/lib/SoapySDR/modules/libairspySupport.so
    Module found: /usr/local/lib/SoapySDR/modules/libbladerfSupport.so
    Module found: /usr/local/lib/SoapySDR/modules/libhackrfSupport.so
    Module found: /usr/local/lib/SoapySDR/modules/librfspaceSupport.so
    Module found: /usr/local/lib/SoapySDR/modules/librtlSupport.so
    Loading modules... done
    Available factories...null
No devices found!

Any insight you might have would be great; let me know what I can do to help!

this is very open ended, example: full vs half duplex

@guruofquality when you have a moment can you set up a SoapyAirspy repository at pothosware and add myself to administer? ;-)

example: register, filterbank...

Can we get an option to limit the SoapySDR debug messages?

After working with the LMS7002M, it seems useful to have an API to configure various baseband paths. Typically, the antenna abstraction API has been a good way to handle multiple paths on the RF side of things, but baseband often has a degree of flexibility that is overlooked.

• Perhaps its not clear based on the desired BW in Hz which path would be optimal
• Consider internal loopback paths, either digital or analog after the ADC/DAC
• Filters with configurable taps and or configurable responses -- in FPGA or RFIC

This binding allows users to have a gr-osmosdr api for soapy sdr modules. This means that devices with soapysdr modules will have automatic support in gr-osmosdr applications.

SoapySDRDevice_listSensors() and SoapySDRDevice_readSensor() with channel number and direction arguments -- typically for sensors associated with the frontend.

Error codes:

• time error
• underflow

Flags:

• overflow (we have overflow as an error code, but it could be a flag when the data is valid, its just that the receive packet was part of an overflow)

There's now quite a handful of dedicated support modules for various SDR devices. Its about time Hack RF joined the ranks. Currently supported through SoapyOsmo, unfortunately there are issues. I will get started with stubs and filling in discovery, factory, and stream calls. Then I will need volunteers to help test the module. This issue is put in place to track progress and will be closed out when the support module is up and running.

Current issues with gr-osmosdr

So it looks like there are some problems in the gr-osmosdr hackrf wrapper. Although I think most of these bugs don't come up under normal gr-osmosdr use. But with SoapyOsmo we need to instantiate and control both tx and rx sides, and support arbitrary stream buffer sizes. More details here: pothosware/SoapyOsmo#1

• being able to instantiate source and sink in the same process
• the source and sink start streaming without being explicitly activated
• possible bounds checking issue in the work function
• source and sink factory and discovery differ -- possible bugs

A new Soapy Hack RF

• This would be a single device wrapper for both receive and transmit sides so there's no issue with device handle sharing. And Soapy SDR reference counts its own device handles.
• Start and stop tx and rx, even if they cant overlap, the activate and deactivate hooks can properly be used to flowgraphs can use the source and sink at once in the design.
• Only one implementation for discovery of devices, and device instantiation
• SoapyHackRF can be implemented with the latest libhackrf, we dont need backwards compatibility
• Implement the direct buffer access API hooks ontop of the hackrf stream callback stuff, and the stream API with the conversions ontop of the direct buffer API.

Hi guys,
Are you planning to realize Java (or maybe Clojure) binding support?
That would be very useful.
Thanks.

device, modules, registry, flags....

Currently we offer a C++ and C API for platforms, but only a C++ API for vendor drivers. A C only vendor driver would probably consist of the following:

A definition for a struct of function pointers, each function pointer corresponds to a method of the Device class:

typedef struct 
{
    typedefForSetFreq setFreq;
   ....
} SoapySDRDeviceCFunctions;

A vendor module would supply a function that returns one of these device structures:

EXPORT_API SoapySDRDeviceCFunctions getDeviceFunctions(void)
{
    SoapySDRDeviceCFunctions myDevice;
    myDevice.setFreq = &myDriverSetFreqFunction;
   ...
    return myDevice;
}

The SoapySDR implementation would look for the getDeviceFunctions symbol in each module, and make a device object available by the usual means.

• start/stop controls
• optional time
• burst controls

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

API Version: v0.4.0-ge62dba9d
ABI Version: v0.4-2
Install root: /usr/local
Module found: /usr/local/lib/SoapySDR/modules/libremoteSupport.so
Module found: /usr/local/lib/SoapySDR/modules/librtlsdrSupport.so
Module found: /usr/local/lib/SoapySDR/modules/libsdrPlaySupport.so
Loading modules... [ERROR] SoapySDR::loadModule(/usr/local/lib/SoapySDR/modules/libremoteSupport.so)
  null failed ABI check: Library ABI=0.4-2, Module ABI=0.3-0
[ERROR] SoapySDR::loadModule(/usr/local/lib/SoapySDR/modules/libremoteSupport.so)
  remote failed ABI check: Library ABI=0.4-2, Module ABI=0.3-0
[ERROR] SoapySDR::loadModule(/usr/local/lib/SoapySDR/modules/librtlsdrSupport.so)
  rtlsdr failed ABI check: Library ABI=0.4-2, Module ABI=0.3-0
done
Available factories...null, sdrplay, 

Which makes that CubicSDR won't start either. Same error.

SoapySDR init..
    API Version: v0.4.0-ge62dba9d
    ABI Version: v0.4-2
    Install root: /usr/local
    Module found: /usr/local/lib/SoapySDR/modules/libremoteSupport.so
    Module found: /usr/local/lib/SoapySDR/modules/librtlsdrSupport.so
    Module found: /usr/local/lib/SoapySDR/modules/libsdrPlaySupport.so
    Loading modules... [ERROR] SoapySDR::loadModule(/usr/local/lib/SoapySDR/modules/libremoteSupport.so)
  null failed ABI check: Library ABI=0.4-2, Module ABI=0.3-0
[ERROR] SoapySDR::loadModule(/usr/local/lib/SoapySDR/modules/libremoteSupport.so)
  remote failed ABI check: Library ABI=0.4-2, Module ABI=0.3-0
[ERROR] SoapySDR::loadModule(/usr/local/lib/SoapySDR/modules/librtlsdrSupport.so)
  rtlsdr failed ABI check: Library ABI=0.4-2, Module ABI=0.3-0
done
    Available factories...null, sdrplay

I was looking into why SoapyRTLSDR sends out CS8 data when I thought the native format was unsigned, and found this: https://github.com/pothosware/SoapySDR/blob/master/include/SoapySDR/Device.hpp#L187

I'm guessing the documentation for here is incorrect. I'll submit a patch that switches the two lines.

• in osmosdr and uhd wrappers

SDRPlay is on the list of devices I'm hoping to support for my application through SoapySDR -- though
I'm informed that the OsmoSDR implementation for SDRPlay device is buggy (looks like it's only a few months old) and I was hoping you might be able to investigate adding a native module for the device.

I unfortunately don't have the hardware but @Toontje does and is eagerly standing by for testing anything related to SDRPlay if needed.

Thanks!

Create aquire/release API to expose device buffers for zero-copy implementations.

Note, its not necessary to demonstrate with a DMA or shared memory device: any situation which provides direct buffer access from the driver to avoid a copy or convert will do. This includes socket buffers and libusb buffers as well.

Lets make specifying formats a little less tedious and something that can be caught by the compiler. We still want to use strings for arbitrary formats. But otherwise, SoapySDR will provide the following:

#define SOAPY_SDR_CF32 "CF32"
#define SOAPY_SDR_CS16 "CS16"
///etc...

Version info for client cmake builds

Certain devices have unique requirements in unique situations. E.g., HackRF Jawbreaker requires a DC offset filter. RTL dongle requires... all sorts of shit to keep it linear. Any platform-neutral library will have to give the user the ability to figure out what hardware is actually running under the hood if it wants to be able to optimize for it.

Just like setGainMode(automatic) to enable AGC, bool hasGainMode(dir, chan) can be used by clients to check if AGC is available. Example: a graphical interface may choose to hide the AGC option when AGC is not available.

It'd be nice from a GUI perspective (especially for unknown modules) if the device args, formats, frequency names and stream args could be queried. I'm currently considering creating an xml document to ship with the application to try and hold the parameter information for known modules; but it'd be a lot nicer to just be able to query those things at runtime.

Available Kwargs could be returned by a key=param, value=parameter type (strings, args, ranges) for anything that accepts args.

Functions could be added to query an argument by name per type (strings, args or a ranges).

Would be useful to be able to query the defaults as well.

For GUI configuration this makes it simpler to build input fields to match the device properties without having to populate the form properties from another resource.

Looking for volunteers :-)

pybombs is a source-based software package manager for linux. A very close equivalent is homebrew on OSX. pybombs could make it easier for some users to install SoapySDR and its many support modules with much less tedium. We do try to maintain debian packaging for ubuntu, but this would be applicable to a much wider linux ecosystem.

TODO

• Read this: http://gnuradio.org/redmine/projects/pybombs/wiki/Contributing
• Clone and add to the recipes repo: https://github.com/gnuradio/recipes
• gr-osmosdr should also depend on soapysdr: https://github.com/gnuradio/recipes/blob/master/gr-osmosdr.lwr

satisfy_deb

One neat thing about pybombs, that seems to be missing in homebrew is that it supports deb packages as a binary alternative when available. So we can use the satisfy_deb: directive given packages in the drivers PPA here: https://launchpad.net/~myriadrf/+archive/ubuntu/drivers

Reference

This is the equivalent recipes for homebrew (called formulas). Homebrew is distributed, although it looks like pybombs is more centralized; but this repo should give an idea of the level of work involved: https://github.com/pothosware/homebrew-pothos There needs to be a similar .lwr file for each soapy*.rb file

Thoughts:

• enable/disable transmit might be used to perform switching in a half-duplex situation
• enable/disable receive starts and stops the streaming in the rx direction

It would be nice to get a result array from loadModules with module information including a pass/fail and any relevant message i.e. "failed ABI check" -- not everyone will have a console or be able to set an environment variable and I'd like a friendly way to mitigate this such as allowing them to pick the path or opting to point it at a bundled modules folder.

loadModule() could benefit from returning a single result for adding and evaluating unknown module files supplied by the user so I could allow them to use/import them in an informed manner as well.

Cheers!

Expand SoapySDRUtil to provide stream testing and demonstration utilities:

• receive a timed burst
• transmit a timed burst
• receive to a file/or null
• transmit from file/or waveform

Options to provide:

• --frequency
• --clockRate (optional)
• --settings (default empty or dict)
• --tuneArgs (default empty or dict)
• --channel (default 0)
• --streamArgs (default empty or dict)
• --rate (sample rate)
• --gain (number or dict)
• --file (optional)
• --waveform (sine, constant)
• --nsamps (specify for finite burst)
• --time (time from now for timed burst)

• add api call to set data direction register
• add api call to set an access mask, some implementations can cache this mask with a particular bank and use it to modify the other calls. Not all APIs will support an access mask.