Beginner's guide to SDR (using ADALM-Pluto)

Table of contents

RoadTest: Sign Up to Review the ADI Software-Defined Radio Learning Module ADALM-Pluto

Author: JWx

Creation date:

Evaluation Type: Development Boards & Tools

Did you receive all parts the manufacturer stated would be included in the package?: True

What other parts do you consider comparable to this product?: RTL-SDR LimeSDR HackRF One

What were the biggest problems encountered?: Emerging support from independent software not on official list

Detailed Review:


Software Defined Radio is defined as a radio-frequency communication system where some elements (for example: filters, de/modulators, detectors) - traditionally built as analog hardware blocks - are implemented in software, allowing for greater flexibility - the same circuit can be used for different transmission types simply by software swap.

Developed for military use first, it had limited use in hobby or education sector - as basic implementations involved personal computer's sound card (used as A/D converter) connected to the analog front-end (read as - radio transceiver), it was geared for people like HAM operators, which already had required equipment.

Inferring from types of SDR-related packages available in typical GNU/Linux  distribution, one of events that caused increase of popularity of SDR in general population was discovery of RTL-SDR - that a cheap, Realtek chipset based USB DVB-T dongle can be used as generic SDR receiver, covering wide frequency range (typically from about 24MHz to beyond 1700MHz).

From this design several modifications were created to overcome identified shortcomings of the original hardware - either as do-it-yourself kits or complete products, but all of them lacked one feature: radio transmission part.

And here we enter the space where ADALM-PLUTO (also known as PlutoSDR) exists - software defined radio transceivers. 

ADALM-Pluto, advertised as “portable self-contained RF learning module”  is an education and self-study geared, self contained, open hardware, GNU/Linux based appliance that can be run stand-alone or as an personal computer's peripheral. According to the hardware compatibility list for  GNU Radio, it is also one of most economic solutions for transmission-enabled module - and, as we see further in the text - parameters of current builds are even better than specified by this comparison.

Hardware versions

First version of ADALM Pluto was produced around year 2017 – it was marked as revision B and (according to the manufacturer’s information) initial batch of 1000 units was sold out in less than 4 days.

Current units are revision D (available from beginning of 2021) and have several improvements addressing issues people were complaining about (and modifying their units to make workarounds). Those improvements include:

  • UART emulation on second USB connector (labeled as POWER),
  • Additional U.FL connectors for second (previously unused) Rx/Tx channel pair and external clock input and output
  • I2C and SPI breakout pins
  • Some GPO 3.3V level compatibility

So if you ever wondered if you can solder wires for additional radio channels or replace (described as not very stable for specific use-cases by some authors) on-board oscillator - don't worry, now there are connectors already installed (as shown below - image taken from official ADI hardware wiki).


There is also some confusion about revision C/D identification – firmware for those revisions is the same (and reports as Rev.C), enclosure label is marked as Rev.C but PCB has “REV D” printed on it (we will show this in the next paragraph).

Box contents

Our PlutoSDR was shipped in carton box containing:

  • the module itself
  • USB to micro USB cable
  • microUSB to USB type A OTG adapter
  • loopback antenna cable
  • set of two antennas

inside the box

but no software nor any printed documentation.

One thing that is evident from first contact is that it is designed with education-use in mind - taking for example microUSB sockets installed - they look more sturdy than usually used, and anyone knows that those connectors are often weak points of any appliance, especially when frequent reconnecting is involved.

heavy duty USB ports

Now a promised version identification dilemma - external label states Rev.C:

external label marking

but PCB is marked as Rev.D

PCB marking

and indeed has all the promised connectors installed:

PCB connectors

Preparation and first tests

After connecting to the PC, PlutoSDR is initially recognized as USB mass storage device and USB-to-Serial adapter. 

mass storage

USB disks contains three important files:

  • licensing information
  • dynamically generated status page (info.html)
  • and configuration file (config.txt)

Status page contains not only "getting started" info with a link to driver package downloads, but also recommended software list (including Matlab, GNU Radio and SDRAngel among other tools),  information about running firmware version (and an indication about newer versions if they exist) and current configuration settings.

After installing driver pack, PlutoSDR is also recognized as network interface (with default address of and default root password for SSH - user is not advised to try to connect it to the LAN before changing the password using procedure provided by the manufacturer).

device manager view 

Using serial or network interface, user can access PlutoSDR console (with SSH client when over network), logging as root with well-known password (if not changed before):

ssh console

Now a few words about software support.

Not counting programmatic interfaces, PlutoSDR is officially supported by applications like GNURadio and AngelSDR.

Beside this, there is a vendor neutral SDR library called SoapySDR that is being supported by growing number of  applications (in many cases previously supporting only RTL-SDR hardware).

As SoapySDR supports devices through loadable modules, is included in system repositories of popular GNU/Linux distributions and there is an existing module for ADALM Pluto, it looks really promising.

But as practice usually is not as good as the theory, there is one problem – neither Debian nor Ubuntu are providing packages for SoapySDR PlutoSDR driver, so some level of source compilation would be necessary.

PlutoSDR driver can be downloaded from

and compilation is not very complicated - first install as much as we can from official repository (to not create custom builds that are difficult to maintain):

#apt-get install cmake libiio-dev libad9361-dev libsoapysdr-dev libusb-1.0-0-dev

then download, compile and install PlutoSDR driver:

$git clone

$cd SoapyPlutoSDR

$mkdir build

$cd build

$cmake ..


$sudo make install

and at the end check if some SoapySDR enabled application recognizes new hardware:

#rtl_433 -v -d "driver=plutosdr" -A

Radio transmission test

Our next test case is radio transmission test - after all, transmission capability is something that differentiates ADALM Pluto from less advanced SDR hardware.

In this place one important thing should be empathized - radio transmission is something that is governed by the law and considering that device can work in very broad spectrum range,  there is high probability of running afoul of some regulation. Always check your local regulations before transmitting and then double-check frequency settings.

To test some real-world use case, I have decided to transmit constant tone to ISM frequency band walkie-talkie radio using GNU Radio application. Block diagram is as below - 5kHz sine signal is FM modulated, then transmitted at 462562kHz in license-free band, to be finally received using hand-held radio.

FM transmission diagram

One side note - handheld radio used has a feature called CTCSS (Continuous Tone Coded Squelch System) which silences transmission that is not including preconfigured pilot tone. This feature has to be disabled for this test to succeed (of course - signal with artificial pilot tone can be prepared - but as manual only states that there are 38 tones available from  the frequency range of 67-260 Hz, some additional research would be needed to map certain frequencies to code numbers). 

FM radio reception test

This one was supposed to be the first test executed - because what could be simpler for Software Defined Radio receiver than to emulate actual analog radio? Well - it seems, many things...

Our ADALM Pluto is based on AD9363 RF transceiver, geared for "3G/4G base stations, video transmission" and having bandwidth in the range of 325 MHz - 3.8 GHz, so - no FM radio frequency is covered.

What's now -  no FM radio emulator for our test? Not so fast. Official wiki states: "there were early PlutoSDR devices which use the AD9364, which is nearly identical to the AD9363 used in production builds" but has larger tuning range (70-6000 MHz) and larger bandwidth (56 MHz). After that sentence the documentation starts to show different parameters that can reconfigure PlutoSDR for operation not only with AD9364 but also AD9361 - despite the fact that there is no information of any builds utilizing this chipset.

Strange - isn't it? Official Wiki consumes several pages of text to inform the user how to reconfigure their device to behave as if some prototype-used or never actually used by ADI chipset was installed?

Additionally - many unofficial guides recommend setting those options for standard Plutos. So - let's check what happens when we set (using ssh session to, logging as root user with default password) parametr list that is recommended for rev. C/D hardware (never officially shipped with anything other than AD9363):

# fw_setenv attr_name compatible

# fw_setenv attr_val ad9361

# fw_setenv compatible ad9361

# fw_setenv mode 2r2t

# reboot

and run following graph using GNU Radio:

FM radio receiver

It seems that now we have working FM receiver on frequency range that was previously returning errors as not supported (103 MHz in this example):

This test shows that standard PlutoSDR is software limited to the official parameters of analog front-end and actual tuning range can be much wider.

By the way - above test will produce audio of worse quality when using provided by the manufacturer antennas (that are supposed to work best at 824-894 MHz
and 1710-2170 MHz bands according to the official documentation) - published results were obtained using the antenna (marked with red oval) from the photo below
(sold as GSM high-gain antenna):

antenna set

Let's make something usable

In this test we will build weather station using existing outdoors sensors - many weather stations are sold with wireless sensors that work in license-free frequency range and have well-researched communication protocols.

Our station will be based on rtl_433 application, that - as the name suggests - was initially RTL-SDR only but was recently modified to include SoapySDR devices support. 

RTL_433 recognizes many hundreds of different radio transmissions (from remotes, tyre pressure sensors, water or gas meters to wireless weather sensors), is able to parse them and write resulting data in many different formats.

To not be dependent on availability of some random sensors  from the neighborhood we have bought second-hand pack of sensors, which the seller was auctioning as not compatible with his weather station:

sensor pack

Initial tests showed that we have 50% success rate - rtl_433 recognizes transmission from two of those sensors (and several other from the vicinity), but middle ones cannot be recognized despite the fact that the driver that is meant to support them is present and enabled.

It seems that this is a problem of hardware marking - they are marked the same as current models but they are very old (2014 year) and probably using different protocol than later revisions.

Old lacrosse sensor

Not wanting to consume more time for parsing unknown protocols, the test was narrowed to working sensors only.

Actual monitoring system involved:

  • PlutoSDR working as data source for software defined radio
  • rtl_433 working as protocol decoder
  • provided with rtl_433 connector to InfluxDB that is parsing rtl_433 output and store it as time-series data
  • Grafana as visualization tool

As show in connector's code, rtl_433 was executed with the following arguments:

#/usr/bin/rtl_433 -d "driver=plutosdr" -F syslog::1433

and in another screen session the connector

#python3 /usr/share/doc/rtl-433/examples/

that is loading data into InfluxDB database named rtl433.

Example connector loads data for different sensors into different measurements (equivalent of tables from SQL databases), creating structure like this:

InfluxDB shell version: 1.8.10
name: measurements

with data in the following format:

> select * from "Oregon-RTGN318" limit 5;
name: Oregon-RTGN318
time battery_ok channel humidity id temperature_C
---- ---------- ------- -------- -- -------------
2023-06-21T15:01:50.178917Z 1 1 49 176 26.7
2023-06-21T15:01:50.235633Z 1 1 49 176 26.7
2023-06-21T15:03:36.088345Z 1 1 49 176 26.7
2023-06-21T15:03:36.136935Z 1 1 49 176 26.7
2023-06-21T15:04:29.042763Z 1 1 49 176 26.7

that can then be presented using Grafana to create panels like this:

Grafana panel

As can be seen, with minimal effort wireless data gathering system was created using PlutoSDR and standard open-source software.

Running standalone

Our last test is possibility to run PlutoSDR as remote data gathering module. To do this we will check if we can connect it to the Ethernet network using USB Ethernet card.

To do this we will need micro USB to USB OTG adapter - fortunately there is one provided with our package.

First thing we will need to do is modifying config.txt file (present on PlutoSDR mass storage) then ejecting a disk to make the appliance re-read settings.

We will modify 


section, adding IP address for the new interface.

Next part - Ethernet card connection:

running standalone

After connecting everything,  LED on USB card started blinking but there was no answer while pinging assigned address.

Now we can appreciate the fact that we have another serial console on power USB connection - this way we can access our PlutoSDR and debug the issue. It turned out that the adapter was recognized but no ethernet device was created and no address assigned. Now it's time for firmware upgrade - using official procedure (in short - copying all the files from unpacked firmware archive into mass storage drive, then ejecting it and waiting for blue led to stop blinking) we have upgraded from version 0.32

firmware 0.32

to the 0.37

firmware 0.37

Using latest firmware, USB network card was recognized, eth0 device was created, address assigned and communication established:

Pinging with 32 bytes of data:
Reply from bytes=32 time<1ms TTL=64
Reply from bytes=32 time<1ms TTL=64
Reply from bytes=32 time=1ms TTL=64
Reply from bytes=32 time=1ms TTL=64


Analog Devices ADALM Pluto is a very interesting module, getting better with each iteration and allowing for all sorts of radio-related experiments. It has adequate software support geared both towards experienced and novice user, with support from independent applications getting better with each passing month. It is also one of most cost-effective SDR modules with transmission capability, with parameters surpassing some of more expensive competitors.