pothosware / soapysdr Goto Github PK
View Code? Open in Web Editor NEWVendor and platform neutral SDR support library.
Home Page: https://github.com/pothosware/SoapySDR/wiki
License: Boost Software License 1.0
Vendor and platform neutral SDR support library.
Home Page: https://github.com/pothosware/SoapySDR/wiki
License: Boost Software License 1.0
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...
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.
Query errors on the device, underflows, overflows, late packets
Error codes:
Flags:
Create a server application that implements the RFSPACE network spec so that existing client code can use Soapy SDR devices.
Thoughts:
RangeList getMasterClockRates(void) const
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!
API calls to answer the questions:
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.
Used in osmosdr
this is very open ended, example: full vs half duplex
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
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
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!
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.
SoapySDRDevice_listSensors() and SoapySDRDevice_readSensor() with channel number and direction arguments -- typically for sensors associated with the frontend.
example: rssi, lo locked, register...
Expand SoapySDRUtil to provide stream testing and demonstration utilities:
Options to provide:
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!
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.
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 :)
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.
Hi guys,
Are you planning to realize Java (or maybe Clojure) binding support?
That would be very useful.
Thanks.
@guruofquality when you have a moment can you set up a SoapyAirspy repository at pothosware and add myself to administer? ;-)
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!
I've pushed up a working standalone RTL-SDR Support Module; still needs a lot of tweaking but it's mostly functional :)
Version info for client cmake builds
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:
Implementation
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:
Also TODO:
device, modules, registry, flags....
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.
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.
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
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 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 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 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.
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.
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.
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.
Upon connecting to the server, the client will spawn a UDP socket and thread to handle log messages from the server.
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.
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
example: register, filterbank...
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.
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.
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.
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.
######################################################
## 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
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!
A declarative, efficient, and flexible JavaScript library for building user interfaces.
๐ Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. ๐๐๐
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google โค๏ธ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.