Field Guide · technology

Also known as: libiio, IIO library

libiio is a cross-platform C library from Analog Devices that provides a uniform way to access devices built on the Linux Industrial I/O (IIO) framework — the kernel subsystem for ADCs, DACs, and RF transceivers.1 In the software-defined-radio world its best-known job is driving the PlutoSDR and other radios built on Analog Devices’ AD9361/AD936x transceiver: libiio is how a host program tunes them, sets gains and sample rate, and streams IQ buffers in and out. It abstracts where the device lives, so the same code works whether the radio is local, on USB, or across a network.

host app (iio_context) libiio local USB network IIO device (AD9361) same API, interchangeable backends — the radio can be local or remote
libiio reaches an IIO device through interchangeable backends (local, USB, network) so a PlutoSDR looks the same to the application whether it is on the local bus or across the LAN.

How it works

libiio models hardware as a tree. The root is an iio_context, opened against a backend and a URI (for example usb:, ip:192.168.2.1, or a local context on the device itself). A context contains devices, each device has channels (an AD9361 has receive and transmit I and Q channels plus control channels), and each channel exposes attributes — tunable settings such as center frequency, RF bandwidth, sampling frequency, and gain, read and written as name/value pairs. This self-describing structure means an application can enumerate exactly what a device offers rather than hard-coding it.

Sample transfer uses buffers. The program marks the channels it wants, creates a buffer of a chosen size, then repeatedly refills it (receive) or pushes it (transmit); libiio moves the raw sample blocks across the active backend and provides helpers to step through the interleaved I/Q data with the correct format and scaling. Two properties make it well suited to SDR:

  • Backend transparency — the identical API works locally and remotely. Because the network backend forwards contexts over IP, a PlutoSDR plugged into one machine can be streamed by a program on another with only a URI change, similar in spirit to SoapyRemote.
  • Device-agnostic control — attributes are generic, so the same code drives any AD936x-based board, and non-radio IIO sensors, through one interface.

Language bindings (C, C++, Python, C#) and command-line tools (iio_info, iio_readdev) sit on top of the same core.

Relevance to SDR

libiio is the native access path for the Analog Devices SDR family — most visibly the PlutoSDR, a popular low-cost learning and experimentation radio, and the larger FMComms and ADALM boards built on the same transceivers. It plugs into the wider ecosystem through wrappers: GNU Radio reaches these radios via the gr-iio blocks, and SoapySDR offers a Pluto/libiio driver so the device also appears in any Soapy-based application. Its network backend is especially handy for the Pluto, whose common form factor is a USB-attached or Ethernet-gadget device that developers frequently drive from a separate host.

GopherTrunk does not use libiio and does not currently target the PlutoSDR; its front-end support centers on RTL-SDR, Airspy, and network IQ sources reached through GopherTrunk’s own Go device layer, keeping it a single dependency-free static binary. libiio is relevant here as the reference model of a well-structured device-access library — a self-describing tree of devices/channels/attributes, buffer-based streaming, and backend-transparent local-or-remote access — the same set of concerns any SDR front-end abstraction, GopherTrunk’s included, has to address.

Sources

  1. libiio — Analog Devices, documenting the IIO context/device/channel/attribute model, buffer-based sample streaming, the local/USB/network backends, and language bindings. 

See also