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.
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:
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).
Our PlutoSDR was shipped in carton box containing:
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.
Now a promised version identification dilemma - external label states Rev.C:
but PCB is marked as Rev.D
and indeed has all the promised connectors installed:
After connecting to the PC, PlutoSDR is initially recognized as USB mass storage device and USB-to-Serial adapter.
USB disks contains three important files:
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 192.168.2.1 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).
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):
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 https://github.com/pothosware/SoapyPlutoSDR
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 https://github.com/pothosware/SoapyPlutoSDR
$cd SoapyPlutoSDR
$mkdir build
$cd build
$cmake ..
$make
$sudo make install
and at the end check if some SoapySDR enabled application recognizes new hardware:
#rtl_433 -v -d "driver=plutosdr" -A
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.
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).
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 192.168.2.1, 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:
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):
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:
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.
Not wanting to consume more time for parsing unknown protocols, the test was narrowed to working sensors only.
Actual monitoring system involved:
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/rtl_433_influxdb_relay.py
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
> show MEASUREMENTS
name: measurements
name
----
Acurite-01185M
Acurite-609TXC
Acurite-986
GT-WT02
Microchip-HCS200
Nexus-T
Nexus-TH
Oregon-CM180i
Oregon-RTGN318
Oregon-RTGR328N
Oregon-SL109H
Renault
Rubicson-Temperature
Springfield-Soil
Toyota
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:
As can be seen, with minimal effort wireless data gathering system was created using PlutoSDR and standard open-source software.
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
[USB_Ethernet]
section, adding IP address for the new interface.
Next part - Ethernet card connection:
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
to the 0.37
Using latest firmware, USB network card was recognized, eth0 device was created, address assigned and communication established:
Pinging 192.168.3.10 with 32 bytes of data: Reply from 192.168.3.10: bytes=32 time<1ms TTL=64 Reply from 192.168.3.10: bytes=32 time<1ms TTL=64 Reply from 192.168.3.10: bytes=32 time=1ms TTL=64 Reply from 192.168.3.10: 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.
