SDRplay Updates: RSPdx Now Supported by SDR Console V3, RSPdx EXTIO Released
SDRplay have recently released an update regarding third party software support and availability of their latest RSPdx receiver. They write:
Happy new Year from all of us at SDRplay.
Here’s an update on additional software for the RSPdx. SDRplay’s SDRuno fully supports the RSPdx but it takes several weeks for other software to catch up to the capabilities offered on the other RSP models.
Simon Brown has released his latest version of SDR Console V3 which supports the RSPdx (Version 3.0.18 dated January 1st) over on https://www.sdr-radio.com/ (make sure you download the latest API 3.x from our downloads page first)
We have released an EXTIO plugin for the RSPdx which will enable the RSPdx to work with any EXTIO-based software (e.g. HDSDR) although it doesn’t support HDR mode. HDR mode will not be added and the source code for the plugin can be found on our GitHub repository (https://github.com/SDRplay/ExtIO_SDRplay) we will not be supporting the plugin source code or extending the plugins capabilities. They are all free to be modified.
It is important to note that the RSPdx ExtIO plugin does NOT, AND WILL NOT, support HDR mode. If you need HDR mode, then SDRuno is the best option. HDR mode requires the end application to work in a certain way and this is not something that can be controlled via the ExtIO protocol.
Work has also begun on supporting RSPdx for SoapySDR based applications such as Cubic SDR (again this won’t include HDR mode). A Gnu Radio source block for the RSPdx will follow.
We are working with Steve Andrew, author of the Software Analyser software programme (see https://www.sdrplay.com/spectrum-analyser/ ) to help get compatibility for the RSPdx – this is a slightly longer process so this will take several more weeks.
Regarding stocks of the RSPs, SDRplay and most of our resellers on www.sdrplay.com/distributors/ have plenty of stock of RSP1A and the RSPduo. However there continues to be a shortage of the RSPdx whereby many of the resellers have sold out of their first deliveries. SDRplay is queuing up their replacement orders on a first come, first served basis. We also have our own quantity planned in there to allow us to sell direct from our website. We still hope that by the end of January we will have supplied this second wave of RSPdx demand.
Yes that is true, but the Airspy HF+/HF+ Discovery both have a blob running as their firmware (that in theory could be doing anything) and all three Airspy hardware also have, that you can’t access anywhere but in SDR# amazing audio noise reduction and IF noise reduction that only work with Airspy hardware and I think possibly rtl-sdr dongles.
Where as the SDRplay hardware do have blobs running as their firmware and blobs running as their drivers, and on windows installs another blob as a service to provide access their API.
The most open hardware is the HackRF, and even it had a blob for it’s CPLD (but the CPLD is so small and fully utilised that it would be hard to hide anything in there), but when it comes to being great radio receiver it is like the RPi of the SDR world, it is optimised to be the best that is can be within the constraints imposed on it, but it is not optimal at any one thing. The next most open SDR is probably the LimeSDR, I’d like to say FreeSRP but they have not published their KiCad files yet, and LimeSDR only publishes Altium PCB files, which is about as unopen source friendly as you can get, but better that sdrplay/airspy neither of which have published either detailed block diagrams or schematics in a while.
Did I say a while, Airspy has not published them ever, but then again you could read their schematic mostly from looking at the PCB, there is a lot in the details but it is not like the hardware is overtly complex.
“does NOT, AND WILL NOT” defines SDRPlay.
Hello Youssef 🙂