Wiki › SDR SA PRO

ADALM-Pluto and Pluto+

In SDR SA PRO the ADALM-Pluto and Pluto+ (AD9361 / AD9363 chips) work as receivers: receive only, one channel. The app takes the samples over the device's own network — on USB that is the device's own network interface, and Pluto+ also has Ethernet — and needs no libiio. This page covers what the connection needs, what the start window shows, which controls sit in the Source group and which device limits were measured: noisier band edges, about 5 MS/s without losses over USB, marked gaps in the stream. PRO

What works with a Pluto 0.9.33

• Receive only, one channel (RX1), even though the Pluto Rev.C and the Pluto+ have two. On opening, the app switches off the transmitter LO — the device keeps it on after power-up — and touches nothing else in the transmit path.
• Frequency, sample rate and gain stay within the limits the device itself names. On the tested device — 70–6000 MHz and 2.5–30.72 MS/s.
• Everything that works with any IQ receiver: spectrum, waterfall, traces, detectors, sweep, the receiver and IQ recording.
• Levels are in dBFS, uncalibrated, as with the other IQ receivers; the dBFS — UNCAL badge on the trust bar is the reminder.

After connecting, the device sits at 2255 MHz with a sample rate of 2.5 MS/s — the lowest one offered — and a manual gain of 40 dB. The device controls are not saved between launches; the only thing the app remembers is an address you typed yourself (below).

Tested on a device on 2026-10-07 and 2026-10-08: a PlutoSDR Rev.C (AD9361, firmware v0.32), over USB, without an antenna. The figures on this page come from there.

Connection over the device's network

The Pluto is a small Linux computer. Its iiod service serves the samples over the network, TCP port 30431. Over USB, Windows sees the device as a network adapter; its address is 192.168.2.1 unless it was changed in the config.txt file on the device itself. A Pluto+ can also be connected with an Ethernet cable — then you need its address on your network.

• The Analog Devices driver. For a USB connection, install the device's driver package “PlutoSDR-M2k-USB-Drivers” from Analog Devices. Without it Windows does not see the device's network, and the app cannot reach it.
• No libiio needed. The client for the iiod protocol is the app's own. A service that does not answer in the text protocol the app expects is refused with it is not iiod on port …: the answer to VERSION was …. The app does not know the newer binary protocol (libiio 1.x).
• Connection to the device. The app connects to the device at the chosen address; while searching in the start window — to 192.168.2.1 and to a saved numeric address, up to 0.35 s for each. A name such as pluto.local is looked up on the network by Windows itself when you pick a row with it.

Choosing it in the start window

In the Select a receiver window the Pluto rows come after the app's own devices. Below the list there is a hint about the Pluto: connection over the device's network, receive only, one channel.

Without a valid key the rows are the same, but each ends with — an SDR SA PRO key is needed, and the device does not open — see SDR SA PRO.

If the device could not be opened, the app shows the Could not open the source window with the reason and advice and returns to the list.

What the app fixes on opening

Whatever another program left in the device lives there until the device restarts. So on opening the app reads it. What concerns reception it fixes and reports in an amber line in the Source group:

• the stream decimator (… samples/s) was on — switched off — programs based on SoapySDR leave the stream 8 times slower than the chip's rate, and the frequency axis would be untrue. If the decimator does not switch off, the app refuses with the advice to restart the device.
• the receiver LO was off — switched on.
• the transmitter LO could NOT be switched off: … or transmitter LO: no control — if the transmitter LO did not switch off. When all is well, there is no separate line.
• samples went beyond the scale of the “…” format: levels may be wrong — the very first buffer went beyond ±2048, so the scale may be wrong.

The “Source” group on the “Device” tab

The counters, Pause, Back to live and Reconnect are the same as for the HackRF One. Here is what the Pluto has of its own:

Type

pluto.

Instrument

The model, the firmware and the version of the device's service, for example “PlutoSDR Rev.C (Z7010-AD9361) · v0.32 · libiio …”. At the bottom of the group — a description: model, address, firmware, serial number.

Instrument sample rate

From the list 2.5, 3, 4, 5, 6, 8, 10, 12.5, 16, 20, 25, 30.72, 40, 50, 56 and 61.44 MS/s — only those within the limits the device names; on the tested device, 2.5 to 30.72 MS/s. There are no lower rates: below 25/12 MS/s (≈2.08 MS/s) the AD9361 does not work without a decimating filter, and the app loads no filters. The app sets the analogue filter bandwidth to the full rate by itself. A rate change starts the chip's calibration: measured 0.37–0.40 s from 2.5 to 30.72 MS/s and 1.7–2.8 s back.

Gain

Who controls the gain: manual, AGC slow, AGC fast, AGC hybrid — only the modes the device names. In manual mode levels are comparable between frames; under AGC the gain changes without your knowledge, which is no good for measurements.

Gain, dB

One number for the whole receive path: the chip itself splits it between its stages. The device names the limits itself, and they depend on frequency — −3…71 dB on the tested device; when the frequency crosses 1300 or 4000 MHz the app reads them again. The decibels follow the chip's table and are uncalibrated; what is shown is what the device took. Under AGC the slider is disabled.

Total gain

In manual mode — the same number. Under AGC — device AGC — unknown: the device then drives the gain, and the app does not read it.

Reconnect

Closes the connection to the device, opens it again, then starts the stream.

Losses: the device's network cannot keep up

The device captures samples faster than its network carries them over USB. The network was measured to carry about 5.5 MS/s:

The app does offer the higher rates: the span on screen is wider. But the stream then comes in pieces, and the Lost in transit counter shows how many samples did not arrive.

• The app knows where exactly the stream broke. The device's service says nothing about gaps, so the app reconstructs the device's own queue from the moments the buffers arrived. Every gap is marked at its place, and the spectrum is not glued across it. Verified on the device by the phase of its own marker: of 1952 gaps at 4, 5, 6, 8, 10 and 30.72 MS/s not one was left unmarked.
• The number on the panel is a lower bound: in none of the runs did it exceed the shortfall by the clock.
• The model rests on four blocks in the device's queue — as in the typical libiio build and on the tested device. On a device with a different build the gap marks will land a few buffers off.
• In an IQ recording every gap is an annotation in the SigMF sidecar — no more than 2000 per recording, the rest as the sdrsa:transport_breaks counter 0.9.36. Details — IQ recording.

After every retune the app restarts the device stream: whatever lay in its queue from the old frequency disappears together with the queue. Measured 50–85 ms to the first block at the new frequency; 76 retunes out of 76 gave the new frequency from the very first block.

Sweep

The sweep on a Pluto is a software one: the app retunes the device for every segment, as with the RTL-SDR, and takes the widest rate in the list. From each tuning only the middle of the band goes into the sweep: the edges are noisier (below).

• Measured: 2100–2400 MHz at 30.72 MS/s — 25 segments, a pass of 0.65–0.78 s 0.9.35.
• A sweep step takes 16–22 ms. The HackRF sweeps by itself in firmware with a 1.2 ms step, so the full range on a Pluto is many times slower.
• At rates where the network cannot keep up, only the first four buffers from each tuning arrive contiguous — up to 524,288 samples. A frame longer than that is never contiguous, and such a segment stays without data.
• Leaving the sweep takes as long as a rate change: the chip calibrates.

The band edges are noisier than the middle

The app does not load the chip's FIR filter yet. Without it the ADC noise lands on the band edges: at gains up to 40 dB the floor at the edges is 13–25 dB higher than in the middle. The clean middle is roughly 50–70 % of the band. The spectrum shows this as it is, without tidying.

Limitations

• Receive only, and one channel of two. There is no USB exchange outside the device's network.
• Without losses only up to ~5 MS/s over USB, and that on an idle machine. The throughput over Ethernet (Pluto+) has not been measured.
• The FIR filter is not loaded — the band edges are noisier.
• Gap accounting assumes four blocks in the device's queue.
• The Pluto+ as a model of its own and the AntSDR have not been tested.
• Levels are dBFS, uncalibrated.
• The device controls are not saved between launches.

The other PRO receivers are the Fobos SDR and the bladeRF 2.0 micro; for the key and the app itself see SDR SA PRO.

The wiki describes version 0.9.49. Your app's version is shown in the Help menu, under About. Found a mistake? Write to us.