Red Pitaya: an open hardware lab instrument you program from a browser

What Red Pitaya is and where it sits against bench instruments

Red Pitaya is described as a credit size mobile IoT hardware and software platform that replaces many expensive laboratory measurement and control instruments. The software examples are open source, the interfacing with sensors and actuators is straightforward, and the possibility to control it using Python, Jupyter, MATLAB or LabVIEW and C is what makes it a tool for education or rapid product development.

The hardware is the differentiator. A single board carries fast analog inputs and outputs plus an FPGA, and the instrument functions are software running on it. An oscilloscope, a spectrum analyzer, a signal generator, a Bode analyzer, an LCR meter and a Vector Network Analyzer are all applications on the same board rather than separate boxes.

That reframing has a practical consequence for a lab. The measurement chain is open, so the analysis scripts, the signal generation and the acquisition can live in the same Python environment as the rest of your experiment. For a control or prototyping setup, the same board acts as the instrument and as the controller.

The users are education and teaching contexts, which the project supports with teaching lectures and a knowledge base, and engineering teams doing rapid product development where a dedicated instrument would be slow to procure or too expensive to justify.

The boards are sold through the RedPitaya online store, and the project points you at a hardware specifications comparison table to understand how the product specifications differ between models, plus a supported features and apps table by model.

The instrument applications you get from a browser

Once you are connected to the device from a web browser it can be used immediately as an oscilloscope, a spectrum analyzer, a signal generator, a Bode analyzer, an LCR meter or a Vector Network Analyzer, and as more besides.

That list is the fastest way to understand the scope of the platform, because the hardware is a general purpose signal generator and analyser and the instrument identities are software on top of it. The Bode analyzer and the Vector Network Analyzer are the two that surprise people, since those are usually expensive dedicated boxes.

There are many other applications available on the RedPitaya marketplace, most of them contributed rather than shipped by the core project, and the documentation has a page for the featured applications.

The distinction matters when you plan a lab. The applications the project ships and documents are the ones that will keep working with an OS image release. The marketplace ones are community contributions, which is the usual bargain and the usual risk, and the supported features and apps table by model is the place to check what a given board model actually offers.

Software defined radio is a separate case, because SDR support for Red Pitaya is done and maintained by Pavel Demin, and the best place to get the latest software from is his own repository rather than the main tree.

Five ways to program the board

The documentation lists several ways to program or develop with Red Pitaya, and the choice usually comes down to where you want the code to live.

Remote control and programming can be done using the most popular rapid prototyping development tools, MATLAB, Labview, SCILAB or Python, remotely, and there are several examples available in the documentation.

Programming directly from the web browser or from Python is done through Jupyter, which means the code runs on the board itself in a notebook rather than on your laptop. That is the arrangement that turns the instrument into a programmable lab bench, because the acquisition, the analysis and the visualisation all happen in one place.

C and C++ programming gives direct access to the hardware features through C APIs, with many starting examples linked from the documentation.

FPGA programming is the deepest level. The information on how to compile the open source FPGA code is in the developer guide, and this is the layer where you change what the hardware itself can do.

Creating your own web applications is the fifth path, with the instructions in the developer guide for web apps. That is the route to a custom instrument interface that a specific experiment needs.

The progression is coherent. Jupyter for analysis, C for latency sensitive control, the FPGA for new hardware behaviour, and a custom web app for a custom front end.

The extension connector and the sensor ecosystem

Beyond the fast analog inputs and outputs, the board comes with an extension connector that lets users interface with other hardware devices or sensors over standard i2c, UART and SPI interfaces, and over additional slow analog inputs and outputs and digital GPIOs.

There are two main extension routes, and the distinction is between buying an existing module and building your own.

The first is to use a sensor extension module made by Red Pitaya. It provides direct connection to Grove sensors, and the documentation lists the catalogue: temperature, motion, touch, button, switch, tilt, potentiometer, light, air quality, vibration, moisture, water, alcohol, sound, UV, accelerometer and relay sensors, with the barometer noted as not supported at the moment. The module also provides compatibility with Arduino extension modules.

The second is creating your own add-on module that connects to the extension connector, and the developer guide has a page for the extension connector itself with the pinout and the details.

The honest caveat is that i2c, UART and SPI are slow interfaces. A Grove temperature sensor is not a substitute for the board's fast analog inputs, it is a way to add the many slow digital sensors a project needs without designing a board. And the Arduino compatibility claim is a convenience for people who already have modules and a mental model, not a statement that every Arduino shield will behave identically.

What the source tree actually contains

This repository is the ecosystem rather than a single application, and the tree shows it.

There is an OS/ directory holding the Linux image that runs on the board, an fpga/ directory with the FPGA source, rp-api/ with the API libraries split by domain, including api-hw for hardware access, api-hw-can for the oscilloscope and spectrum analyser path, api-hw-calib for calibration, api-dsp for signal processing, api-sweep for the sweep, api-arb for the arbitrary waveform generator, api-formatter, api-update, api-app and a specific api-250-12 directory.

Then there is rp-web-api/ for the web API, scpi-server/ for the SCPI protocol server, apps-tools/ for the applications and their tooling, Examples/, tools/, build_scripts/, patches/, and a docker/ directory.

The Makefile is the build entry point, and it is a multi-target build. The all target pulls together api, nginx, examples, apps-tools, apps-pro, startupsh and scpi, and the individual pieces are separately buildable directories, so you can rebuild the web applications without touching the API libraries or the OS image.

The versioning scheme in that Makefile is worth reading. LINUX_VER is 3.00 for the required OS version, BUILD_NUMBER defaults to dev, REVISION comes from git rev-parse --short HEAD, and the combined VERSION string is what ends up in the built image. BUILD_MODE defaults to Release and the CMAKEVAR line passes the install directory, build type and all the version components into CMake. There is also a download cache directory and a separate streaming variant, STREAMING defaulting to MASTER.

Where Red Pitaya is the wrong choice

The first limit is the hardware, and it is the one that decides the purchase. Red Pitaya is a credit size board, and the accuracy, bandwidth, channel count, memory depth and input range are properties of the model rather than of the software. The project itself points you at the hardware specifications comparison table for exactly this reason, and a measurement that exceeds the board's specification is not fixable with better code.

The second is that the instrument identities are software, which is the same property that makes the platform flexible and also makes it dependent on the OS image. A release of the OS image can change behaviour for an application, and the project keeps a changelog, with separate changelogs for the Z20 hardware in the tree, which tells you that the hardware generations do not share a single history.

The third is the ecosystem split. The core applications and the SDR support are maintained by different people, the SDR work by Pavel Demin in his own repository, and the marketplace applications are community contributions. A project that depends on a marketplace app for its measurement chain inherits that dependency's maintenance, and the documentation does not make a support commitment about contributed applications.

The fourth is the interface. The extension connector is i2c, UART and SPI plus slow analog and GPIO, which is fine for sensors and actuators and completely wrong for anything that needs sustained high rate sampling alongside the board's fast inputs, and for anything that needs to drive a real motor rather than a relay.

Compare that with a rack instrument from a measurement vendor. The difference in approach is that a dedicated instrument gives you calibrated specifications, a support commitment and a protocol you can automate, and it costs more and gives you nothing you can modify. Red Pitaya trades the first three for the last one, and the comparison table is where you decide which of those you need.

Licence, releases and what to check before you commit

The platform is released under a custom licence that GitHub cannot categorise, with the terms in the COPYING file at the repository root. The project is a commercial hardware product with open source software, so the licence arrangement is worth reading properly, especially the parts that cover the FPGA bitstream and the OS image, and you should take your own advice on that rather than relying on a summary.

The release history shows a versioned OS image track rather than a package release. Release-2025.1 and Release-2025.2 both carry a December 2025 date, and Release-2026.1 came on 2026-07-07. The repository is not archived, and the last push was on 2026-10-09, so the tree is about two weeks old relative to today. There is also a CHANGELOG.md, a separate CHANGELOG_Z20.md, and further Z20 changelogs in the tree, which tells you the hardware generations track separately.

What to check before you commit to a board is a short list. Read the hardware specifications comparison table and pick the model whose bandwidth, sample rate and accuracy cover your measurement with margin, because a marginal model produces results you will later doubt. Then read the supported features and apps table for that model, so you know which of the instrument applications and which marketplace apps actually exist for it. After that, follow the quick start guide to connect to the device, and check the CHANGELOG for the OS image version you will be flashing.

If the plan is to develop rather than only to use, the developer guide is where the build instructions live, both for the FPGA code and for creating your own web applications, and those two pages decide how much of the platform you can realistically change.

Editorial conclusion

Red Pitaya fits a lab or a classroom that wants to replace several bench instruments with one open board, and a developer who wants the instrument's own source, its FPGA bitstreams and its web applications to read and modify rather than treat as a black box. It does not fit a measurement that needs more analog bandwidth, precision or channel count than the board model provides, since the hardware comparison table is where those differences live. Before you buy or adopt one, read the hardware specifications comparison table and the supported features and apps table, confirm the accuracy and bandwidth of the specific model against your measurement, and check the release notes for the OS image version you will actually flash.

Frequently asked questions

Official sources

1. Issues
2. README
3. RedPitaya/RedPitaya on GitHub
4. Releases