Purpose

Verbose communication between MRI scanners and external hardware is difficult in a research environment while maintaining the regulatory approval of the scanner. There are few non-RF outputs on modern scanners that are user programmable at a sequence level. Outputs that do exist often require manufacturer consent or software extensions. However, nearly all MRI scanners can output synchronization triggers through a dedicated electrical or optical output. These simplistic on/off triggers are normally used to trigger fMRI stimuli or other hardware that operates in step with the scanner.

We propose misappropriating this synchronization trigger by implementing a simplex TTL/UART serial protocol at the sequence level, allowing the scanner to transmit arbitrary data to an external device in real time. Via this method, hardware and software designers can have granular real time access to scanner operations and sequence debugging information via a verbose, temporally-synced output. This would greatly assist the development of 3rd-party hardware or software integrations that operate synchronously with the scanner without affecting regulatory approval.

Methods

Development occurred on a 3T clinical scanner (Skyra, Siemens Healthineers). A sequence level serial encoder was developed that respects the UART (Universal asynchronous receiver-transmitter) protocol.

Generally, the duration and start times of synchronization pulses can be programmed within a sequence. While UART is idle high, most synchronization triggers are idle low. Therefore, we encode the inverse of the desired signal, then convert from an optical to electrical TTL signal and finally use a hardware logic inverter. See Figure 1 for a system diagram.

A standard UART 8-E-2 frame (one start bit, eight bits of data, one even parity bit, two stop bits) was implemented for data and timing robustness. Figure 2 shows a sample encoding pattern. Setting T to the scanner’s real-time clock as the start of a UART frame, each bit can be scheduled at T + iB, with i representing the index of the bit within the frame. Only “high” bits need to be scheduled due to the idle low behaviour of the sync trigger. For more complex transmissions, such as full strings or byte arrays, a function was written to schedule sequential synchronization events. The total transmission time for data with number of frames/bytes n is given by:

String transmission time = 12*n/baud rate

Baud rate, or the number of bits sent per second, is the largest determinant of bandwidth. The baud rate’s effect on stability was tested experimentally with an off-the-shelf USB-to-serial adapter with support for up to 12 megabaud. Communication was tested with two experiments. First, we programmed a static string variable directly into the sequence at the beginning of the first repetition time (TR). Baud rates from 1220 to 512000 were tested to determine if communication succeeded. Second, we envisioned measuring online reconstruction times for individual real-time acquisition slices by serializing a unique seven-character identification string prior to the acquisition of each slice, providing verbose sequence status information to the external reconstruction machine. The duration of a real-time cardiac sequence with very short TRs was measured at each baud rate to determine the effect of the serial communication routine on time sensitive scans. Figure 3 shows the example cardiac pulse sequence diagram, including the UART scheduling.

Results

An 11-character test string was received repeatably, with accurate encoding/decoding of byte data at baud rates of up to 115200. For a sequence with TR=500ms, there was no noticeable delay in sequence execution for any baud rate tested. Above 115200, bit-flips and timing inaccuracy led to incorrect ASCII characters or incorrect parity bits.

In our second experiment, the unique slice identifiers were also accurately received at baud rates up to 115200. Whenever transmission time exceeded TR, an acquisition delay was introduced inverse to the baud rate. Increasing baud rate resolved the delay - see Figure 4 for delay data versus baud rates.

Discussion

We have shown that the sync trigger can be used for simplex serial data output from the scanner in an acquisition-locked manner. Arbitrary data transmission was reliable at baud rates up to 115200, although that limit may be due to the signal conversion / inversion hardware.

For a prototypical scan with a TR of 1000ms its possible to transfer 960 bytes of raw data per TR at a baud rate of 115200 without introducing sequence delay, compared to 1 bit of data per TR currently sent by the synchronization pulse. As data packets can be scheduled with events inside of each TR, this approach greatly expands the scanner’s output capabilities without scanner hardware or firmware modification.

Data scheduling must be considered in order to prevent noticeably slower acquisition times due to packet transmission. When transmission time exceeds a scan’s TR, the sequence execution time is artificially increased. However, due to the larger number of TRs per second, bandwidth can be recovered by splitting large data packets across sequential TRs, resolving the delay issue.

Serial encoding opens pathways to integrating custom hardware and software with existing commercial scanners without manufacturer consent or regulatory issues However, further research is needed to enable full duplex communication at a sequence level; inputs such as the ECG gating system might be able to be similarly misappropriated.

Acknowledgements

Siemens Healthcare, R01EB018108, NSF 1563805, R01DK098503, and R01HL094557.

References

No reference found.