PlutoSDR MIMO and 2T2R Basics

[Pavel]

Short answer: The standard ADALM-Pluto exposes one receive and one transmit channel even though its transceiver family has more capability. Two-receive/two-transmit operation requires hardware that physically routes both channels, a matching FPGA image and host software; a chip marking or software attribute alone cannot create missing RF paths.

Before you start​

• Prove Pluto discovery through the Industrial I/O stack before opening GNU Radio or another SDR application.
• Separate USB mass storage, USB networking and I/Q streaming because each function can fail independently.

Step-by-step method​

1. Step 1: Identify the exact Pluto-compatible board and inspect which RX/TX connectors and RF paths are physically populated. Confirm documentation for simultaneous channels rather than relying on AD9361 or AD9363 alone.
2. Step 2: Match firmware, FPGA image, device tree and libiio channel definitions to the board. Back up a working image before changing channel configuration.
3. Step 3: Begin with both receive channels connected through equal attenuated paths to one known source. Use the same LO, sample rate, bandwidth and gain for a controlled channel comparison.
4. Step 4: Measure amplitude mismatch, phase behavior, timestamp alignment and stability over restart. For TX/RX tests, calculate isolation and protect every input with fixed attenuation.

Concrete example​

Seeing voltage samples from RX1 and RX2 is only the first check. A coherent experiment should split one reference signal into both inputs and measure relative phase over time and across restarts; unrelated antennas cannot reveal channel coherence cleanly.

How to judge the result​

A 2T2R setup is valid when both physical channels stream simultaneously at the required rate, are mapped correctly in IIO and meet the project's repeatable amplitude, phase and timing criteria.

What to record​

• Start with a moderate sample rate such as 1 to 2 MSPS for receive tests, then increase only after the baseline streams without loss.
• Record IIO context URI, local oscillator frequency, RF bandwidth, sample rate and gain mode for a reproducible Pluto setup.
• Treat any frequency-extension change as removal of software limits, not a guarantee of sensitivity, output power or filtering outside the original specification.

Common mistakes​

• Changing several hardware, software or RF variables at once, which removes the controlled comparison needed to identify the cause.
• Treating one autoscaled screenshot or one unusually good result as proof without recording the settings and repeating the test.
• Installing a two-channel FPGA image on hardware without the second RF path does not convert a standard Pluto into a complete 2T2R radio.

Final check​

Reconnect Pluto and repeat IIO discovery before starting the application. Save the context, firmware, sample rate, RF bandwidth and gain mode that reproduce the result.