-
Notifications
You must be signed in to change notification settings - Fork 0
home
This documents the ocra-pack release, which is based on ocra with the MaRCoS server, client and setup scripts.
Delve into these to find information not included in the wiki.
[TODO UPDATE THESE] Mainline ocra and my development fork targeting the STEMlab-122: contain the ocra HDL, server and client. The latter two are superceded in the MaRCoS project by the MaRCoS server and client.
meta-openmri, a Yocto layer and guide to build the SD card image. Set up by Danny Park.
MaRCoS server, the C++ application running on the STEMlab managing the hardware
MaRCoS client, a set of Python scripts and eventually a GUI to control the Red Pitaya
ocra-pulseq, a Pulseq interpreter supporting the ocra hardware
The ocra-pack releases are based on Thomas Witzel’s open-source MRI platform, ocra.
It extends the original ocra with a different server and GUI, adds more user-facing documentation, and implements some HDL updates and bugfixes.
The ocra hardware consists of a Red Pitaya/StemLAB and a custom gradient DAC PCB, plus the amplifiers, coils etc that make up a simple MRI setup.
Ocra-pack runs on both the STEMlab 125-14 and the STEMlab 122.88-16 SDR boards, but we recommend using the STEMlab 122 due to its larger Zynq FPGA chip and 16-bit AC-coupled ADCs.
There is not yet a standard gradient DAC PCB in the ocra community. The OCRA1 PCB, based around four AD5781 DACs, was designed by Marcus Prier at OVGU/STIMULATE, and is used by several groups. Benjamin Menkuec at FH Dortmund has designed the GPA-FHDO, which is used by several more. See the gradient DAC page for info.
Ocra controls a single AC-coupled ADC input for sampling the MRI signal, a single DAC output for generating RF to drive the MRI coils, and digital outputs that control the gradient DACs. The ADC and DAC run at 122.88 MHz on the STEMlab 122.
The core of Ocra is a real-time pulse processor, micro_sequencer, which synchronously executes a custom program describing the MRI sequence you wish to run.
This may include RF pulses, gradient operations, pauses, adjustments of the blanking bit and other peripherals, as well as data acquisition that begins and ends at specific times in the sequence.
micro_sequencer has a custom instruction set for pulse sequencing, designed by Thomas Witzel; for the details, have a look at some example sequences and the Python-based assembler written by Suma Anand.
We recommend using ocra-pulseq rather than hand-coding assembly yourself, however.
micro_sequencer is connected to the other Ocra peripherals, primarily the RX and TX digital signal processing chains labelled rx_0 and tx_0, and the gradient DAC controllers gradient_writerx, gradient_writery and gradient_writerz (also z2 in some but not all branches of the firmware).
Both the RX and TX chains share a central numerically-controlled oscillator (NCO), nco_0, which outputs a constant digital tone at a fixed frequency during the course of an MRI experiment.
This is used in both the RX and TX chains to downconvert/upconvert data.
The TX chain essentially plays a stream of I/Q samples from a local BRAM at an adjustable rate and depth, and multiplies (upconverts) these by the tone from nco_0.
The BRAM, playback rate and playback depth are all controllable.
The results are output to the DAC.
The RX chain receives a stream of ADC samples and multiplies (downconverts) these by the tone from nco_0, to create a stream of I/Q samples.
These go through a pair of CICs, whose output rate is adjustable from 1/25 to 1/8192 of the ADC sampling rate, and then through a fixed FIR filter [TODO: find out where the coefficients come from].
The results are converted from fixed- to floating-point, and then stored in a FIFO for the server to read out.
Currently there is no proper FIFO flow control, and the only information available to the server is how many samples have been written to the FIFO since the start of the pulse sequence (up to ~ 2^15).
TODO
This just scratches the surface of the ocra firmware; there are many other cores, with subtle (and undocumented) details that are not worth concisely explaining here.
If you wish to understand the details of the ocra HDL for yourself, you will need to become familiar with Xilinx Vivado and the general FPGA development toolchain. The ocra HDL is based on the approach, and many of the cores, developed by Pavel Demin, in particular those in the Red Pitaya notes and STEMlab SDR notes repos. Note that some parts of these repos, like ocra, are obsolete or no longer relevant; use them as a guide only.
The ocra software consists of
TODO