pTx implementation

[berksilemek]

I published a parallel transmission (pTx) implementation as a new branch. it is using different type of spectrum cards. All RF. Let's check if we can implement it as a feature to the main.
I implemented phase control of the individual RF channels at calculate_rf function in sequence provider:

        # Calculate the static phase offset, defined by RF pulse also add pTx phases
        phase_offset = np.exp(1j * (block.phase_offset+(np.pi*(rf_phase/180.))))
        ...
        for k, (n_samples, block) in enumerate(zip(samples_per_block, blocks, strict=True)):

            if block.rf is not None and block.rf.signal.size > 0:
                # Every 4th value in _seq starting at index 0 belongs to RF
                if rf_start_sample_pos is None:
                    rf_start_sample_pos = self.sample_count
                self.calculate_rf(
                    block=block.rf,
                    unroll_arr=_seq[k][0::4],
                    unblanking=_unblanking[k],
                    b1_scaling=glob.parameter.b1_scaling,
                    rf_phase = 0.,
                    num_samples_rf_start=rf_start_sample_pos,
                )

I wonder what is the best way for implementing it at a higher level for example in:

# Construct a spin echo based spectrum sequence
seq = sequences.se_spectrum.constructor(
    echo_time=6e-3,          # 12 ms echo time
    rf_duration=300e-6,      # 200 us RF pulseq duration
    time_bw_product=2,
    use_sinc=False,           # Do not use sinc pulse, but block pulse
    rf_amplitudes = [1.0,1.0,1.0,1.0],
    rf_phases     = [0,45,90,135]
)
'''
There is no direct access from constructor to provider. Any ideas? 

[schote]

Hi Berk, many thanks for your work on the pTx implementation! Did you see that there has been some work on pTx for pulseq (e.g. https://pure.mpg.de/pubman/faces/ViewItemOverviewPage.jsp?itemId=item_3548170)?
I guess this is related to the Matlab implementation, not sure about pypulseq.

I think what might help to implement this is a separation between the calculation of gradient and RF events. We planned to separate the calculation, to be able to replay a sequence with different sampling rates for RF and gradients (if two different cards are available).

[berksilemek]

Hi David,

Yes, I am aware of some publications. Need to dive deeper, but as you indicated they are not pypulseseq. Before progressing at that side, I would like to fix some issues from our side. One critical thing is that our implementation may not be suitable for multiple cards, especially for synchronization. For example, in single card implementation the start operation is not considering if there are other transmit cards to wait for:

# Start card
self.log.debug("Starting card operation || Star-hub function: %s",self.sync_card_en)
if (not self.sync_card_en):
    error = spcm.spcm_dwSetParam_i32(
        self.card,
        spcm.SPC_M2CMD,
        spcm.M2CMD_CARD_START | spcm.M2CMD_CARD_ENABLETRIGGER,
    )
    self.handle_error(error)


avail_bytes = spcm.int32(0)
usr_position = spcm.int32(0)
transfer_count = 0

while (transferred_bytes < self.data_buffer_size) and not self.is_running.is_set():
...

If there is a star-hub, it is the master. E.g., M2CMD_CARD_START is only sent by star-hub. I implemented those parts but one needs to make sure that the data is properly transferred. I could start the cards with the star-hub but, now having buffer overflow issues. I will work on that aspect.
Another problem at the moment is that Python implementation with the star-hub is not working. The same driver calls with C implementation is synchronous. However, with python, DMA addresses changing, which is not the case for the C and 2 cards are asyc. I am in contact with Spectrum to make sure if it is a firmware issue or something about the way we implement with python (e.g., creating dma buffers etc.). I will keep updating. Let me know if there is any suggestion.

[berksilemek]

Okay. 2 updates from today. Star-hub module problems look like solved with kernel and firmware updates. These fixed the issues with the implementation: buffer size, speed of the transfer and synchronization, especially for Python. I do not think anybody would install an old firmware or kernel but we may need to pay attention for this in the future.

[schote]

Thanks for getting in touch with Spectrum. Our current implementation is designed for only two cards. This is why major changes of the current implementation are to be expected. With the valuable insights you have now, I would highly recommend starting on a more abstract level and making a plan for implementation. Then we can prioritize the implementation and go step by step.

Since our current implementation is working well (even though there is lots of room for improvement), I would like to implement the StarHub or pTx implementation along with unit, integration, and system tests to ensure the operability of the new implementation. Otherwise, testing in the end would be a nightmare.