History and major releases

First version

This project is an offspring of SDRangelove and the first version retained most of its features but diversifying with more devices supported and some more channel plugins.

Multiple device support

Since version 2 SDRangel can integrate more than one hardware device running concurrently.

Transmission support

Since version 3 transmission or signal generation is supported for BladeRF, HackRF (since version 3.1), LimeSDR (since version 3.4) and PlutoSDR (since version 3.7.8) using a sample sink plugin. These plugins are:

• BladeRF1 output plugin
• BladeRF2 output plugin
• HackRF output plugin
• LimeSDR output plugin
• PlutoSDR output plugin
• XTRX output plugin Experimental.
• File output or file sink plugin
• Remote device via Network Linux only

REST API

Since version 4 a REST API is available to interact with the SDRangel application. More details are provided in the server instance documentation in the sdrsrv folder.

Server instance

Since version 4 the sdrangelsrv binary launches a server mode SDRangel instance that runs wihout the GUI. More information is provided in the Readme file of the sdrsrv folder.

Detached RF head server

Since version 4.1 the previously separated project SDRdaemon has been modified and included in SDRangel. The sdrangelsrv headless variant can be used for this purpose using the Remote source or sink channels.

MIMO support

Since version 5 the capability to process multiple coherent channels for both Rx and Tx has been added.

Feature plugins

Although there were existing with the v4 and v5 latest minor releases. The merge back of v5 branch into master as v6 makes feature plugins a prominent new feature in v6

Main UI complete revamping

The major change concerns the top level UI which is built around workspaces where the user can arrange the different component windows freely. This is radically parting from the rather rigid design imposed by the default Qt application main window with a central window that used to support the main spectrum and docking areas on the sides. With this update the essential of the screen space is what is called a MDI area standing for Multiple Document Interface which allows a lot more flexibility. As component windows become more autonomous they can also receive controls that match their own functionality. For example you will create a device from a workspace then add channels from the device. Flexibility in the arrangement of components allows you to compose the workspaces it the way it best fits your needs making a radio that is software defined rather than software defined by radio which I think used to be the case.