Ask · Share · Build

What the PlutoSDR Frequency Extension Really Changes

Pavel

SDRstore_Pavel
Administrator
Staff member
Joined
Jul 30, 2026
Messages
121
Short answer: The frequency extension changes software limits exposed for the AD936x transceiver; it does not redesign the RF matching, filters, oscillator, shielding or validation of the Pluto board. Operation outside the original 325 MHz to 3.8 GHz specification is experimental and performance must be measured.

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: Save the original configuration and firmware state before modifying attributes. Confirm the exact board and understand how to restore its factory configuration.
  2. Step 2: After changing limits, verify only with a controlled receive signal through attenuation or a shielded path. Do not assume tuning success means calibrated sensitivity or clean transmit output.
  3. Step 3: Measure receive response, gain behavior, images and frequency accuracy at several points near and beyond the original range. For TX, add a spectrum analyzer, dummy load, attenuation and harmonic filtering.
  4. Step 4: Keep application and dataset labels clear that the measurement is outside original board specification. Restore normal limits if the project requires guaranteed documented performance.

Concrete example​

A Pluto may accept a 100 MHz or 5 GHz tuning command after extension, yet antenna matching and board response can be much poorer than near the original range. A visible carrier demonstrates reception, not sensitivity, linearity or spurious performance.

How to judge the result​

The modification is useful only when measured performance at the exact project frequency meets a defined requirement. Keep the result device-specific rather than publishing the extended range as a guaranteed specification.

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.
  • Using the extension as evidence that Pluto covers every frequency equally can produce incorrect buying advice and unsafe transmit assumptions.

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.
 
Top