guide_using_multiple_sdrlabs - vnegnev/marcos_extras GitHub Wiki
Last updated: 16/11/2024
This guide discusses how to set up a multiple-input multiple-output (MIMO) system with more than two RX and TX channels (currently four RX and TX channels are supported) using MaRCoS with multiple Red Pitaya boards.
Quickstart: see the MIMO cross-loopback tutorial for setting up and verifying your system, and the MIMO sequence programming guide
MaRCoS was originally developed to run on a single Red Pitaya SDRLab, with two input and output channels. To run a single MaRCoS sequence across multiple SDRLabs, three elements are required:
- Shared system clocks, to attain phase coherence on the TX and RX across all the SDRLabs,
- Synchronised starting of each device’s sequence, to run a single shared global sequence together,
- An API to program multiple boards using the MaRCoS software.
Shared system clocking is carried out by using one ‘master’ SDRLab to generate a clock source for the ‘slave’ SDRLabs. The clock on the standard SDRLab comes directly from an on-board oscillator and cannot be externally supplied to the ADCs without some delicate modifications of the PCB. Fortunately, Red Pitaya produce an SDRLab 122-16 external-clock version which is already modified, and requires a clock on two of its header pins to run the ADCs..
Using custom FPGA firmware on the master SDRLab, the FPGA clock is forwarded differentially to two of the SATA expansion pins. By stripping the wires on one end of a SATA cable and connecting the wires to the clock header pins of a slave SDRLab, the master’s clock can be forwarded to the slave.
More slaves can be connected by daisy-chaining the output clock on the first slave’s SATA connector to a second slave, and so on. This approach worsens the jitter of the clock (and thus the phase noise of the MRI system) due to its passing through the slave’s FPGA, so is probably not ideal for more than a few slaves.
To drive more slave SDRLabs, the master clock can be forwarded to a clock distribution PCB (in development), which produces clock signals for up to 16 slaves. The PCB can also be driven by an external clock source directly, and one of the ‘slave’ SDRLabs that the PCB drives can be treated as the master SDRLab for the purposes of this guide.
[Diagram of approach of master SDRLab with multiple slaves + PCB, and external clock + multiple slaves with one master.]
See the MIMO hardware connections guide for more information.
The SDRLabs can be triggered in unison to start their sequences; either with an external trigger, or by producing a trigger pulse from one master SDRLab. This SDRLab can either be internally- or externally-clocked, as long as it shares its clock with the other SDRLabs in the system.
The trigger logic in the SDRLab’s FPGA firmware recognises rising-edge and falling-edge transitions (low to high, or vice versa). A future update will make this selectable.
The software functions much as before, with each SDRLab having a unique IP address (or port if it’s being simulated) and a single Device object to control it. (The Device class was called the Experiment class in earlier MaRCoS client versions.)
The master SDRLab is programmed to output a trigger pulse, whose delay from the start of the sequence is adjustable. The slave SDRLabs await a trigger from the master before starting their sequence. The master and slaves are programmed simultaneously, and the master begins its execution immediately.
If the master is programmed and sends a trigger to the slaves before they are ready to accept it, synchronisation cannot take place. Thus, if the master has a significantly simpler sequence to run than the slaves do, some care must be taken to ensure that either a) the master’s programming is begun after the slaves so that they are all ready to start at roughly the same time, or b) the master’s trigger delay is longer than the difference in programming times between the master and the slave with the biggest program.
Once more complex sequences need to be run across the MIMO system, automatic synchronisation is planned so that the master does not start until all the slaves are ready. This feature will be added once it is needed for multiple masters and slaves.
Now that you’ve read the basic details, please see the MIMO cross-loopback tutorial for a more detailed guide.