Slice timing of MB-EPI-BOLD sequence across TRs

[julfou81]

Hello cmrr-mb community,

I noticed a surprising behavior of the epi-bold sequence regarding the actual time delay between slices depending on the TR used. For our application, we require a very regular acoustic sound of the whole epi sequence (over multiple TRs) for an optimal "real-time denoising". The recently added option to being able to remove the frequency update (which adds 20ms at the end of each TR) was a great step forward to get a regular sound across TRs. However, this makes it still no a perfectly regular sounds across the whole sequence (over multiple TR). The delay between the beginning of the last slice of a TR and the 1st slice of the following TR is indeed always longer that the other inter-slice timings. Not much, but also not the same amount depending on the TR used, all other parameters being equal. My guess is that extra time must be coming from rounding off all the delays in a TR mixed up with minimal sampling time available in IDEA. The rest of the division must be added to the last slice of every TR.
We checked with a clock at 80MHz frequency and we empirically measured an extra time ranging from 0.2ms and 0.02ms. This is fine for most applications but the consequence is dramatic for our real-time denoising algorithm, which creates periodic glitches at every TR when this extra time is higher.

We measured all those timings using the triggers send by the sequence at every TR, option only available in the mb sequence, but I think the same is true for the product Siemens EPI sequence.

On a side note, we also found that the inter-trigger interval measured precisely with our clock differs significantly (several ms ) from the inter-slice timing if we refers to the slice times found in the DICOM header.

Thank you for your patience for reading this message and I hope somebody has some information on this very peculiar topic.

Julien

PS: we are currently using the R015 version on VE11B on a Prisma Scanner.

[eauerbach]

In addition to the 20 ms delay for frequency updating, there are typically two other delays that take place at the end of each TR. One is a mandatory clock synchronization event which is inserted by the framework: 340 µs on VBxx, 20 µs on VDxx/VExx. The other is, as you know, the remainder after the division of the TR fill time by the number of acquired slices. Any "Delay In TR" that you specify on the Contrast/Dynamic card would also be applied there, but obviously you would set that to 0.

I added a checkbox to the next version of the C2P (R016) to optionally force equal inter-slice timing. It basically does two things: First, it forces the inter-slice TR fill to be at least as long as the sync event (20-340 µs), so the minimum TR may go up a bit depending on the system/protocol. Then it just discards any remaining fill that would normally be played out at the end of each measurement.

Unfortunately, a consequence is that with this option enabled the TR displayed in the UI will usually be a bit inaccurate, since without more rework than I am willing to get into at this time, the UI will always round up to the nearest millisecond. However, in order to have perfectly even timing we need the TR to be some exact multiple of nSlices/MBfactor*0.01 ms. My proposed compromise is that the tooltip for the checkbox will show you the "true" TR, and it will also be logged. I think the deviation will always be less than 1 ms. I assume this would be acceptable?

[julfou81]

Thank you very much Eddie for this complete and detailed answer!
I understand now why the minimum extra time at the end of the TR was always 0.02 ms! (we are on VE11B)
I am looking forward to seeing this new checkbox in the next version. For our applications, a "wrong" displayed TR value by less than 1 ms will not be in issue, especially if we can get access the real TR value by one way or another.

[julfou81]

UPDATE: We downloaded the very fresh R016 version of the MB BOLD sequence last night (for VE11B), just a few hours before the first inclusions of the new project involving online denoising of the MRI acoustic noise! We quickly checked with our 80MHz clock that the timings were as expected with the new option, and they were (of course ;-)!). The new "equal inter-slice" option showed even improved denoising performance of the microphone and this helped to make this first day of acquisition campaign a promising success.
What a timing! ;-) Thank you very much!

EDIT: just a side note on the behavior of the tooltip for the "equal interstice" option: it correctly displays the difference between the "real TR" and the "protocol TR" right after the checkbox is checked but the difference disappears in the display later on when for instance one looks at a scan that was already run . Also if one checks the box, changes the TR and looks at the tooltip again, the difference seems to stay at zero, except if one unchecked and checks the checkbox gain . But again, not a big deal.

[eauerbach]

Yes, the way this was (quickly) implemented, the UI tooltip is unstable in the ways you have noticed. I added it mostly for my own testing, but I left it in to give you some idea of what to expect when you are planning a new protocol. The value written to the log at run time should always be correct, though, so look for a message like this in logviewer if you need the true timing for reference:

Forced equal inter-slice timing is enabled. The true TR is XXX usec shorter than the protocol value.

Possibly the inter-slice timing in the DICOMs (MosaicRefAcqTimes) may also be correct?