FAQ
Currently, most devices from gr-osmosdr are supported:
- bladerf
- hackrf
- rtl
- rfspace
- mirisdr
And devices from the UHD project:
- usrp
- umtrx
- myriadrf
These are just the devices we know about. Due to the nature of being an plugin architecture, any device could be supported under SoapySDR without changing the codebase, so we wouldn't necessarily know about it.
No, the osmosdr plugin uses a small shim directory of GNU Radio headers to avoid this dependency.
SoapySDR itself is under the Boost software license (a permissive BSD-style license). This means that anyone is free use the SoapySDR library in any application, platform, or hardware support module without serious restrictions. However, as with all libraries, its possible to use SoapySDR with combinations of software that would be license incompatible. Please respect the licensing of all software that you use with SoapySDR. And as always, this is a wiki, not legal advice, please consult a lawyer.
One API -- many devices. How many applications have duplicated the effort of wrapping up several vendor drives to gain support for that device? Thats tedious and difficult to maintain. Write your application with SoapySDR and automatically support all the devices.
Currently we have a system where platforms are being burdened with the changes in hardware drivers, even when the actual APIs for dealing with these devices have not changed. If you are a vendor, you dont want to have to upstream changes into various platforms and applications after an update. If you are a platform provider or application maintainer, you dont want to mix up your versioning and release system based on ABI and ABI fluctionations from various vendor drivers.
SoapySDR tries to move the burdens of maintaining platforms, applications, and drivers to where they belong, and are most easily maintained. Whether this leads to more or less overall software libraries depends. But reguardless, software will be simpler and easier to maintain.
Many applications have a profile table or conditional settings based on the specific device thats being used. These "profiles" are the result of many hours of tuning, testing, trial, and error. And we would like SoapySDR to support this type of highly specific application tweaking.
To enable this use case, users can identify a specific device using the following calls:
- Device::getDriverKey()
- Device::getHardwareKey()
- Device::getHardwareInfo()
Most settings calls support advanced options. For example channel gain can be set automaticaly, manually overall, but also individually per each amplification element in the chain. Also, tuning supports an additional key/value dictionary which can be used to do things like specify the tuning mode, fixing the LO frequency, manually adjusting a CORDIC, or other fine-tuning options. Anything device-specific is possible, but we still have the advantage of using a generic API that is otherwise identical in every other way for the rest of the devices out there.
SoapySDR has APIs for reading and writing, I2C, SPI, registers, arbitrary strings, UARTs, GPIO, misc sensors... but it still cant solve every problem. If you have something special that really cant fit into one of the existing calls, then please consider
- Is this something that could be supported in the existing API?
- Is this something that could be supported under a generic API?
- Or is SoapySDR just not appropriate for this particular task?
- Or, contact us, and we can figure something out!
