search

schote / nexus-console

MRI console application based on spectrum-instrumentation measurement cards and pulse sequences from pypulseq. Read more in the docs!
https://schote.github.io/nexus-console/
GNU General Public License v3.0
10 stars 3 forks source link

Phase instability during and between acquisitions #66

Open LUMC-LowFieldMRI opened 7 months ago

LUMC-LowFieldMRI commented 7 months ago

There seem to be some phase stability issues with the data acquisition. For B0 mapping images with two slightly different timings are acquired and the phase difference between the two acquisitions is directly proportional to the local B0 offset. In order for this to work the phase has to be fully stable otherwise the instability results in errors in the B0 map.

The two images are acquired using a single seq file to maximise stability but there are still substantial errors in the B0 map, and if the same sequence is ran twice wildly different results can be obtained, this indicates that there is a problem with the phase not being consistent in the system. I've attached two acquisitions to demonstrate the issue Spectrum B0 mapping - Scan 2 Spectrum B0 mapping - Scan 1

berksilemek commented 7 months ago

In general, we (@schote) need to test and report phase stability of the console. The internal clock has its limitations. We need to determine and report our limitations for the application. @LUMC-LowFieldMRI What were the tested TR values? Total acquisition times? Did you use the updated rxdevice.py?

schote commented 6 months ago

I think a potential issue is the phase correction step, that we apply when the data is demodulated and decimated. We should investigate if this phase manipulation step is really necessary and if it is correct @berksilemek.

LUMC-LowFieldMRI commented 6 months ago

We tried a few things already, including no phase correction and phase correction before decimation (which I think is actually how it should be). No phase correction was a disaster and shows that clearly the phase correction is needed. The correction before the decimation also didn’t work but that might just have been a bug in the implementation.

Another thing to check is to see if moving from the FIFO acquisition to a triggered acquisition. If you read the description of the starhub (which I know you don’t have on the system in Berlin) it sounds like this is designed to take handle phase sensitive acquisitions.

From: David Schote @.> Sent: Friday, April 26, 2024 1:46:55 PM To: schote/spectrum-console @.> Cc: O'Reilly, T.P.A. (RADI) @.>; Mention @.> Subject: Re: [schote/spectrum-console] Phase instability during and between acquisitions (Issue #66)

I think a potential issue is the phase correction step, that we apply when the data is demodulated and decimated. We should investigate if this phase manipulation step is really necessary and if it is correct @berksilemekhttps://github.com/berksilemek.

— Reply to this email directly, view it on GitHubhttps://github.com/schote/spectrum-console/issues/66#issuecomment-2078734928, or unsubscribehttps://github.com/notifications/unsubscribe-auth/ANV57CS6567CXUEE4AG5KHLY7HZ57AVCNFSM6AAAAABFMPAUP6VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDANZYG4ZTIOJSHA. You are receiving this because you were mentioned.Message ID: @.***>