How a $500 Open-Source MRI Console Sparked a Global Research Ecosystem

From MIT Classroom Tabletop to MaRCoS and Clinical-Style Low-Field MRI Workflows

Conventional Magnetic Resonance Imaging (MRI) consoles are expensive, closed systems. Proprietary spectrometer architectures, locked pulse-sequence compilers, and restrictive software interfaces make it difficult for students and researchers to inspect signal paths, modify low-level control loops, or build accessible scanners for education and low-field research.

In 2018, researchers at the Athinoula A. Martinos Center for Biomedical Imaging (Massachusetts General Hospital / MIT) addressed this barrier by developing OCRA (Open-source Console for Real-time Acquisition). Proving that an open console could be built from commercially available hardware, the team demonstrated imaging on a ~0.4 T educational tabletop MRI scanner using less than $500 in essential console electronics.

Key Takeaways

• Democratizing Low-Field MRI: Developed at MIT/MGH, OCRA proved that an open-source, sub-$500 console could replace expensive, closed MRI spectrometers using off-the-shelf components like the Red Pitaya STEMlab 125-14.
• Hands-On Educational Platform: The development of the OCRA1 shield enabled students at OVGU Magdeburg to build and program custom MRI hardware, bridging classroom theory and practical system engineering.
• High-Performance Architecture: By leveraging the Xilinx Zynq SoC, the system splits real-time tasks (7 ns timing granularity, IQ modulation/demodulation on FPGA) from high-level sequence management (embedded Linux on ARM CPU).
• Evolution to MaRCoS: Moving to the Red Pitaya SDRlab 122-16 upgraded the system with 16-bit ADCs, a streaming architecture for arbitrary sequence lengths, and native support for hardware-independent Pulseq files via PyPulseq.
• Clinical-Style Interface: The addition of MaRGE provides a user-friendly GUI featuring protocol management, DICOM export, and real-time reconstruction—enabling deployment on fieldable, low-field scanners in hospital environments.

The Hardware Setup: Off-the-Shelf Architecture

Rather than treating the console as a proprietary black box, OCRA transferred its critical control functions onto accessible, commercial components:

• RF Transceiver & Compute Core: A Red Pitaya STEMlab 125-14 built around a Xilinx Zynq-7010 SoC, featuring onboard 14-bit ADCs and DACs for RF transmit and receive.
• Gradient Control: Three external 18-bit precision DACs (Analog Devices AD5780) driven via high-speed digital lines from the FPGA expansion header, providing the three primary gradient channels (G_x, G_y, G_z)
• Analog Conditioning: Basic external RF preamplification and programmable step attenuators conditioned the received NMR signal before digitization.

Signal Flow & Heterogeneous Architecture

The core technical strength of OCRA was leveraging the Zynq SoC's heterogeneous architecture, pairing hardware determinism with flexible software control:

• FPGA Programmable Logic (PL): Executed pulse sequences in hard real time with approximately 7 ns timing granularity. The FPGA fabric handled Numerically Controlled Oscillator (NCO) digital mixing, digital IQ modulation and demodulation, and Direct Memory Access (DMA) streaming for transmit, receive, and gradient channels independent of CPU scheduling delays.
• ARM Processing System (PS): Ran an embedded Linux environment, handling sequence coordination and communicating asynchronously with an external host computer over Ethernet.

This architecture allowed RF pulses, gradient waveforms, and sequence timing to be updated just microseconds before execution, avoiding the constraints of static, precompiled experiments.

Image 2: OCRA to MaRGE timeline. Source: Red Pitaya.

From Open Console to Student-Built Hardware: The OCRA1 Shield

OCRA's low-cost and open architecture also made it well suited to education. OCRA was developed for the MGH/MIT tabletop MRI scanners, which are used in MIT classes to teach students about MRI. Its Python-based GUI was explicitly intended as an educational tool, giving students a way to interact with and learn from the underlying MRI system.

That combination of accessible hardware and hands-on experimentation continued at Otto von Guericke University (OVGU) Magdeburg and the STIMULATE research center. Between 2019 and the early 2020s, OCRA became part of hands-on MR system engineering education, where students could work with the hardware rather than simply operate a finished imaging system.

To make that work more accessible at the benchtop, the Magdeburg team developed the OCRA1 peripheral shield, mounting directly onto the Red Pitaya extension headers:

• Four-Channel Gradient DAC: Four 18-bit AD5781B DAC channels for primary X, Y, and Z gradients, with a fourth channel available for higher-order shimming or, in appropriate systems, B₀ control.
• Integrated RF Interfacing: Onboard RF attenuation and transmit-gate circuitry for interfacing with the RF transmit chain.

Integrated into OVGU’s MR System Engineering course, the shield turned the open console into a teaching platform: students could assemble hardware, characterize its behavior, program the control system, and see how their changes affected an actual MRI experiment. Instead of treating the scanner as a finished instrument, they could study and modify the individual building blocks that made the system work.

That educational use also illustrates an important part of OCRA’s evolution. Its open hardware and software made the underlying instrumentation accessible enough to be incorporated into hands-on engineering education.

Image 3: Red Pitaya, OCRA1 and a power-supply/distributor in a 19” case. Credit: Marcus Prier

The Architectural Rewrite: MaRCoS

As researchers began demanding longer and more complex experiments, limitations in OCRA's sequence length, timing flexibility, and assembly-style programming interface became apparent.

An international collaboration then took the OCRA approach further with MaRCoS (MAgnetic Resonance COntrol System), a ground-up re-engineering of the MRI control stack. While moving the main control platform to the Red Pitaya SDRlab 122-16, MaRCoS retained compatibility with the OCRA1 four-channel gradient hardware alongside newer gradient interfaces:

• Hardware Migration to SDRlab 122-16: MaRCoS moved to the Red Pitaya SDRlab 122-16, featuring 16-bit ADCs and a 122.88 MS/s sampling rate. Its ~50 MHz of usable bandwidth covers the proton Larmor frequencies encountered in low-field MRI up to roughly 1.17 T.
• Streaming Architecture: Sequence and acquisition data are streamed to and from the FPGA, allowing sequences of arbitrary length rather than relying on a fixed sequence-memory limit. MaRCoS uses a MessagePack-based protocol for communication between software components.
• Pulseq Compatibility: MaRCoS supports Pulseq-compatible sequence programming, including workflows using PyPulseq. This enables researchers to develop hardware-independent sequences in Python or MATLAB and execute them directly through the MaRCoS stack.

Want a deeper look at the MaRCoS hardware architecture?

Read the companion technical feature: MaRCoS: An Open-Source MRI Control System Built with Red Pitaya SDRlab 122-16.

From Research Console to Clinical-Style Workflows: MaRGE

In 2024, the consortium published MaRGE (MaRCoS Graphical Environment), providing a user-oriented interface tailored for clinical-style workflows—including protocol management, DICOM export, and integrated reconstruction tools.

The MaRCoS/MaRGE platform has been demonstrated across diverse experimental systems, including:

• An experimental 0.2 T scanner designed for hard-tissue imaging.
• A 72 mT portable scanner installed in the radiology department of a large hospital.

Image 4: MaRGE: A graphical environment for MaRCoS. Credit: https://www.sciencedirect.com/science/article/pii/S1090780724000466

• MaRCoS Control System on GitHub — https://github.com/marcos-mri/marcos_server
  Embedded server for the MaRCoS system.
• MaRGE GUI Repository — https://github.com/josalggui/MaRGE
  Clinical protocol management and DICOM interface.
• Red Pitaya SDRlab 122-16 Technical Documentation — https://redpitaya.readthedocs.io/
  Schematics and hardware specifications.
• Red Pitaya Academia Program — https://redpitaya.com/academia
  University lab support and hardware sponsorships.

Technical FAQ

Why use external DACs for gradient generation instead of the Red Pitaya’s onboard converters?

OCRA and OCRA1 use external 18-bit DACs (AD5780/AD5781B) for gradient generation, while the Red Pitaya’s high-speed onboard converters handle the RF transmit and receive paths. The external DACs provide the precision and analog output characteristics needed by the gradient-control chain, while the onboard high-speed converters are used for RF signal processing.

What makes MaRCoS different from OCRA?

MaRCoS represents a ground-up re-engineering rather than a simple software update: it changes how MRI sequences are represented, transferred, and executed. Its streaming architecture and Pulseq compatibility support sequences of arbitrary length while reducing the memory and assembly-level programming constraints of the original OCRA design.

Can MaRCoS run on the original STEMlab 125-14?

The MaRCoS project is primarily designed around the SDRlab 122-16, but community documentation notes that it could be ported to the STEMlab 125-14 with reduced receive FIFO depth. The SDRlab remains the primary hardware target because of its larger FPGA resource capacity and 16-bit ADC resolution.